Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)
Дата
Msg-id CAMkU=1wR1op24Vn6Q4cm6LoJrBRo=rt1kKWTZ5ONOYED9O0-vw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)  (Andres Freund <andres@anarazel.de>)
Ответы Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Tue, May 10, 2016 at 9:19 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2016-05-10 08:09:02 -0400, Robert Haas wrote:
>> On Tue, May 10, 2016 at 3:05 AM, Andres Freund <andres@anarazel.de> wrote:
>> > The easy way to trigger this problem would be to have an oid wraparound
>> > - but the WAL shows that that's not the case here.  I've not figured
>> > that one out entirely (and won't tonight). But I do see WAL records
>> > like:
>> > rmgr: XLOG        len (rec/tot):      4/    30, tx:          0, lsn: 2/12004018, prev 2/12003288, desc: NEXTOID
4302693
>> > rmgr: XLOG        len (rec/tot):      4/    30, tx:          0, lsn: 2/1327EA08, prev 2/1327DC60, desc: NEXTOID
4302693

Were there any CHECKPOINT_SHUTDOWN records, or any other NEXTOID
records, between those two records you show?


My current test harness updates the scalar count field on every
iteration, but changes the (probably toasted) text_array field with a
probability of only 1% each time.  Perhaps making that more likely (by
changing line 186 of count.pl) would make it easier to trigger the
bug.  I'll try that in my next iteration of tests.

Cheers,

Jeff



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: pg_dump dump catalog ACLs