On 31.05.2012 08:06, Erik Rijkers wrote:
On Thu, May 31, 2012 03:30, Robert Haas wrote:
On Wed, May 30, 2012 at 6:00 PM, Erik Rijkers<e...@xs4all.nl>  wrote:
directory
2012-05-30 23:40:57.909 CEST 3909 CONTEXT:  writing block 5152 of relation 
base/21268/26569
        xlog redo multi-insert (init): rel 1663/21268/26581; blk 3852; 35 tuples
TRAP: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 
1741)
2012-05-30 23:40:58.006 CEST 5331 FATAL:  could not open file 
"base/21268/26569": No such file
or
directory
2012-05-30 23:40:58.006 CEST 5331 CONTEXT:  writing block 5153 of relation 
base/21268/26569
2012-05-30 23:40:59.661 CEST 3908 LOG:  startup process (PID 3909) was 
terminated by signal 6:
Aborted
2012-05-30 23:40:59.661 CEST 3908 LOG:  terminating any other active server 
processes

Hmm.  I set up what I believe to be the same test case you were using,
and it's not crashing for me.  In fact, with the latest code, I
haven't been able to produce any error at all.  When I reverted my
last commit, I managed to get this:

ERROR:  could not open relation with OID 18229
STATEMENT:  select current_setting('port') port, count(*) from t

...but just once, and with no other error messages.    So I'm either
missing a step somewhere, or something about your system just happens
to tickle this moreso than on mine.

In my test, I run the bash code (the bits that I posted earlier) in a while 
loop so that the table
is CREATEd, COPYied into, and DROPped every few seconds -- perhaps that wasn't 
clear.  That loop
is necessary; a few iterations are often successful.

I can test it today on a few other systems to see if it is reproducible.

I could no longer reproduce it after Robert's fix, the test case has been running for about an hour now. Please triple-check that you have it applied in the standby :-).

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to