Rusty Conover wrote:
> It seems like this is a race condition cause by the system catalog cache not being locked properly. I've included a perl script below that causes the crash on my box consistently.
> The script forks two different types of processes:
> #1 - begin transaction, create a few temp tables and analyze them in a transaction, commit (running in database foobar_1)
> #2 - begin transaction, truncate table, insert records into table from select in a transaction, commit (running in database foobar_2)
> I setup the process to have 10 instances of task #1 and 1 instance of task #2.
> Running this script causes the crash of postgres within seconds on my box.
Thanks, that script crashes on my laptop too, with assertions enabled.
According to the comments above RelationClearRelation(), if it's called
with 'rebuild=true', the caller should hold a lock on the relation, i.e
refcnt > 0. That's not the case in RelationFlushRelation() when it
rebuilds a new relcache entry.
Attached patch should fix that, by incrementing the reference count
while the entry is rebuilt. It also adds an Assertion in
RelationClearRelation() to check that the refcnt is indeed > 0.
In response to
pgsql-hackers by date
|Next:||From: Craig Ringer||Date: 2010-04-14 11:19:49|
|Subject: [Fwd: [BUGS] build error: strlcat/strlcpy used from heimdal libroken.so]|
|Previous:||From: Robert Haas||Date: 2010-04-14 11:07:34|
|Subject: Re: master in standby mode croaks|
pgsql-bugs by date
|Next:||From: Craig Ringer||Date: 2010-04-14 11:41:44|
|Subject: Re: Bug in CREATE FUNCTION with character type (CONFIRMED
|Previous:||From: cool shower||Date: 2010-04-14 11:02:49|
|Subject: BUG #5421: pg_attribute broken|