> I'd guess some WAL record arising from the post-crash master restart makes the > standby do so. When a crash isn't involved, the commit or abort record is >that > signal. You could test and find out how it happens after a master crash > with >a > procedure like this: > > 1. Start a master and standby on the same machine. > 2. Connect to master; CREATE TABLE t(); BEGIN; ALTER TABLE t ADD c int; > 3. kill -9 -`head -n1 $master_PGDATA/postmaster.pid` > 4. Connect to standby and confirm that t is still locked. > 5. Attach debugger to standby startup process and set breakpoints on > StandbyReleaseLocks and StandbyReleaseLocksMany. > 6. Restart master.
Well yes, based on the test the stack is something like: StandbyReleaseLocksManyStandbyReleaseOldLocks ProcArrayApplyRecoveryInfo xlog_redo It's not very clear to me what ProcArrayApplyRecoveryInfo does (not too familiar with the standby part I guess) but I see it's called by xlog_redo in the "info == XLOG_CHECKPOINT_SHUTDOWN" case and by StartupXLOG. But I don't know if calling ResetUnloggedRelations before the call to ProcArrayApplyRecoveryInfo in xlog_redo makes sense... if it makes sense, it would solve the problem of the stray files in the master crashing case I guess? > > > When you promote the standby, though, > > ShutdownRecoveryTransactionEnvironment() > > > releases the locks. If I understand the code, ResetUnloggedRelations is called before ShutdownRecoveryTransactionEnvironment, so that part shouldn't be an issue Leonardo -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
