On 26.05.2012 12:21, Erik Rijkers wrote:
> But when that if-block is added the client crashes after a while (sometimes almost immediately; it
> never survives longer then 20 minutes):
>
> 2012-05-26 10:44:22.617 CEST 10274 ERROR: could not fsync file "base/21268/32807": No such file
> or directory
> 2012-05-26 10:44:28.465 CEST 10274 ERROR: could not fsync file "base/21268/32867": No such file
> or directory
> 2012-05-26 10:44:28.587 CEST 10270 FATAL: could not open file "base/21268/32994": No such file or
> directory
> 2012-05-26 10:44:28.588 CEST 10270 CONTEXT: writing block 2508 of relation base/21268/32994
> xlog redo multi-insert (init): rel 1663/21268/33006; blk 3117; 58 tuples
> TRAP: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 1741)
> 2012-05-26 10:44:31.131 CEST 10269 LOG: startup process (PID 10270) was terminated by signal 6:
> Aborted
> 2012-05-26 10:44:31.131 CEST 10269 LOG: terminating any other active server processes
>
>
> Crazy scenario , I'll admit, but surely this shouldn't be able to crash the client?
Thanks for the report. I was able to reproduce this with that script,
and I think I see what's going on now.
There's something wrong with the way AccessExclusiveLocks work on a
standby. I did "begin; truncate foo; -- leave the xact open" in the
master, and waited until the xlog records are shipped to the standby.
Then I did this in the standby:
testdb=# begin;
BEGIN
testdb=# select * from foo; id
----
(0 rows)
testdb=# select locktype, database, relation, virtualtransaction, pid,
mode, granted, fastpath from pg_locks where locktype='relation' and
relation='foo'::regclass; locktype | database | relation | virtualtransaction | pid |
mode | granted | fastpath
----------+----------+----------+--------------------+-------+---------------------+---------+---------- relation |
16384| 27332 | 2/78 | 24984 |
AccessShareLock | t | t relation | 16384 | 27332 | 1/0 | 24344 |
AccessExclusiveLock | t | f
(2 rows)
The "select * from foo" query should have blocked, because the
transaction in the master is holding an AccessExclusiveLock on the table.
The process holding the AccessExclusiveLock is the startup process. It's
holding the lock on behalf of the transaction in the master. But
something's wrong, and the AccessExclusiveLock doesn't stop a regular
backend from acquiring the AccessShareLock on the table. I suspect the
fast-path locking patch, because this works on 9.1.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com