Getting TOAST errors
I am occasionally getting this kind of error when attempting a SELECT statement.
PGError: ERROR: missing chunk number 0 for toast value 27143 in pg_toast_2619
What does this mean? Is some sort of corruption creeping into the database?
Postgres 9.0 linux.
Tim Uckun <timuckun@gmail.com> writes:
I am occasionally getting this kind of error when attempting a SELECT statement.
PGError: ERROR: missing chunk number 0 for toast value 27143 in pg_toast_2619
What does this mean? Is some sort of corruption creeping into the database?
Hard to tell. We've seen enough reports like that to make it seem like
there may be some bug buried there, but no one has provided anything to
do any debugging work with. Can you create a reproducible test case?
Postgres 9.0 linux.
9.0.what?
regards, tom lane
Hard to tell. We've seen enough reports like that to make it seem like
there may be some bug buried there, but no one has provided anything to
do any debugging work with. Can you create a reproducible test case?
Not really. I have a nightly process which downloads data and sticks
it into a text field. Afterwards another process reads that text data
and processes it creating rows in another table. The problem occurs in
the last step and at seemingly random intervals. For example one time
it might happen when you are creating row 1000 another time it might
be when you are creating row 2000.
Postgres 9.0 linux.
9.0.what?
9.0.4
Tim Uckun <timuckun@gmail.com> writes:
Hard to tell. We've seen enough reports like that to make it seem like
there may be some bug buried there, but no one has provided anything to
do any debugging work with. Can you create a reproducible test case?
Not really. I have a nightly process which downloads data and sticks
it into a text field. Afterwards another process reads that text data
and processes it creating rows in another table. The problem occurs in
the last step and at seemingly random intervals. For example one time
it might happen when you are creating row 1000 another time it might
be when you are creating row 2000.
Well, I'm not asking for perfect reproducibility --- a test case that
fails even 1% of the time would be great.
regards, tom lane
Not really. I have a nightly process which downloads data and sticks
it into a text field. Afterwards another process reads that text data
and processes it creating rows in another table. The problem occurs in
the last step and at seemingly random intervals. For example one time
it might happen when you are creating row 1000 another time it might
be when you are creating row 2000.Well, I'm not asking for perfect reproducibility --- a test case that
fails even 1% of the time would be great.
What exactly do you need?
The database is not too large but the data is proprietary. Despite
this I am willing to provide a sampling of the data in the two tables
involved. The code itself is ruby but has a lot of library
dependencies so it might not be possible to give you a working
application. The idea is pretty simple though, you fetch a text field,
it contains CSV data, you iterate through the data updating or
inserting records into the second table.
Tim Uckun <timuckun@gmail.com> writes:
Well, I'm not asking for perfect reproducibility --- a test case that
fails even 1% of the time would be great.
What exactly do you need?
A self-contained test case (code and data) that triggers the error.
If it only does so probabilistically, once in every-so-many runs,
that's fine.
The database is not too large but the data is proprietary. Despite
this I am willing to provide a sampling of the data in the two tables
involved.
Perhaps you could sanitize or anonymize the data? It's unlikely that a
bug of this sort has all that much to do with the exact data content.
Whether the bug would still show for a "sample" is a different question,
and one you'd have to resolve by experiment.
regards, tom lane