Tom Lane 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@po
"Kevin Grittner" writes:
> Tom Lane 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 wou
Tom Lane 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
"Kevin Grittner" writes:
> Tom Lane 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
Rusty Conover 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 0x0067a30d
On Apr 14, 2010, at 3:30 PM, Tom Lane wrote:
> Rusty Conover writes:
>> On Apr 14, 2010, at 2:31 PM, Tom Lane wrote:
>>> There is another slightly odd thing here, which is that the stack trace
>>> Rusty provided clearly shows the crash occurring during processing of a
>>> local relcache invalida
Rusty Conover writes:
> On Apr 14, 2010, at 2:31 PM, Tom Lane wrote:
>> There is another slightly odd thing here, which is that the stack trace
>> Rusty provided clearly shows the crash occurring during processing of a
>> local relcache invalidation message for the truncated relation.
> The test
On Apr 14, 2010, at 2:31 PM, Tom Lane wrote:
> I wrote:
>> [ theory about cause of Rusty's crash ]
>
> I started to doubt this theory after wondering why the problem hadn't
> been exposed by CLOBBER_CACHE_ALWAYS testing, which is done routinely
> by the buildfarm. That setting would surely caus
Tom Lane 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 oppor
I wrote:
> [ theory about cause of Rusty's crash ]
I started to doubt this theory after wondering why the problem hadn't
been exposed by CLOBBER_CACHE_ALWAYS testing, which is done routinely
by the buildfarm. That setting would surely cause the cache flush to
happen at the troublesome time. Afte
10 matches
Mail list logo
