On Tue, May 10, 2016 at 9:19 AM, Andres Freund <and...@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 <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
