[BUGS] BUG #5412: test case produced, possible race condition.
in [PgSql]
|
From: Tom Lane on 14 Apr 2010 17:24 Rusty Conover <rconover(a)infogears.com> writes: > [ same stack trace for the simplified test case ] Ah, got it finally. There *is* a relcache flush happening during INSERT in the 8.4 code, because of FSM extension: (gdb) bt #0 RegisterRelcacheInvalidation (dbId=40264, relId=848094) at inval.c:439 #1 0x000000000067a30d in CacheInvalidateRelcache (relation=0x7f39b88403f0) at inval.c:1141 #2 0x00000000005c9c45 in fsm_extend (fsm_nblocks=<value optimized out>, rel=<value optimized out>) at freespace.c:589 #3 fsm_readbuf (fsm_nblocks=<value optimized out>, rel=<value optimized out>) at freespace.c:522 #4 0x00000000005ca2e4 in fsm_set_and_search (rel=0x9d48, addr=<value optimized out>, slot=0, newValue=220 '\334', minValue=200 '\310') at freespace.c:608 #5 0x00000000005ca675 in RecordAndGetPageWithFreeSpace (rel=0x7f39b88403f0, oldPage=<value optimized out>, oldSpaceAvail=<value optimized out>, spaceNeeded=<value optimized out>) at freespace.c:163 #6 0x0000000000464149 in RelationGetBufferForTuple (relation=0x7f39b88403f0, len=<value optimized out>, otherBuffer=0, options=<value optimized out>, bistate=<value optimized out>) at hio.c:303 #7 0x0000000000462e77 in heap_insert (relation=0x7f39b88403f0, tup=0x14aa580, cid=<value optimized out>, options=0, bistate=0x0) at heapam.c:1890 This code path doesn't exist in CVS HEAD, which means (I think) that the given test case can't fail in HEAD. I think I got myself confused by experimenting variously with HEAD and 8.4 in regular and CLOBBER_CACHE_ALWAYS modes --- only one of those four combinations will exhibit a failure with this test case. Although the particular case apparently can't arise in HEAD, I'm going to apply Heikki's patch there anyway, since there's clearly a risk of related problems. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 14 Apr 2010 17:37 "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> What this suggests is that CLOBBER_CACHE_ALWAYS is actually too >> strong to provide a thorough test of cache flush hazards. Maybe >> we need an alternate setting along the lines of >> CLOBBER_CACHE_SOMETIMES that would randomly choose whether or not >> to flush at any given opportunity. But if such a setup did produce >> a crash, it'd be awfully hard to reproduce for investigation. >> Ideas? > Seed the random number generator such that each run of the test gets > the same "random" numbers? Or *allow* the seed to be set, with the > default being a random seed which is logged so that it can be forced > for a repeat of the run? The seed alone wouldn't be enough to duplicate the behavior, since the behavior of random() typically varies across platforms. So we might get a report and still be unable to reproduce it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 14 Apr 2010 17:45 Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > The seed alone wouldn't be enough to duplicate the behavior, since > the behavior of random() typically varies across platforms. So we > might get a report and still be unable to reproduce it. At least the person getting the initial failure would be able to recreate it, and possibly provide a stack trace. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 14 Apr 2010 18:55 "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> The seed alone wouldn't be enough to duplicate the behavior, since >> the behavior of random() typically varies across platforms. So we >> might get a report and still be unable to reproduce it. > At least the person getting the initial failure would be able to > recreate it, and possibly provide a stack trace. On second thought, since there's no need for a particularly high-quality RNG here, we could just embed some brain-dead one-liner implementation, which should behave the same everywhere. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 14 Apr 2010 19:04
Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > On second thought, since there's no need for a particularly > high-quality RNG here, we could just embed some brain-dead > one-liner implementation, which should behave the same everywhere. Sounds good to me. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |