Re: ERROR: unexpected chunk number 0 (expected 1) for toast value 76753264 in pg_toast_10920100

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ERROR: unexpected chunk number 0 (expected 1) for toast value 76753264 in pg_toast_10920100
Дата
Msg-id 25544.1522962278@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ERROR: unexpected chunk number 0 (expected 1) for toast value 76753264 in pg_toast_10920100  (adsj@novozymes.com (Adam Sjøgren))
Ответы Re: ERROR: unexpected chunk number 0 (expected 1) for toast value76753264 in pg_toast_10920100  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Список pgsql-general
adsj@novozymes.com (Adam =?utf-8?Q?Sj=C3=B8gren?=) writes:
>> [... still waiting for the result, I will return with what it said
>> when the server does ...]

> It did eventually finish, with the same result:

Huh.  So what we have here, apparently, is that regular MVCC snapshots
think there is exactly one copy of the 1698936148/0 row, but TOAST fetches
think there is more than one.  This is darn odd, not least because we
never do UPDATEs in toast tables, only inserts and deletes, so there
certainly shouldn't be update chains there.

It seems like you've got some corner case wherein SnapshotToast sees a row
that isn't visible according to MVCC --- probably a row left over from
some previous cycle of life.  That is, I'm imagining the OID counter
wrapped around and we've reused a toast OID, but for some reason there's
still a row in the table with that OID.  I'm not sure offhand how we could
get into such a state.  Alvaro, does this ring any bells (remembering that
this is 9.3)?

            regards, tom lane


В списке pgsql-general по дате отправления:

Предыдущее
От: Jerry Sievers
Дата:
Сообщение: Re: PgUpgrade bumped my XIDs by ~50M?
Следующее
От: hmidi slim
Дата:
Сообщение: decompose big queries