hi all,
I found that hot-standby server redo coredumped when the master do a
concurrency test in drop database, auto-vacuum and immediate shutdown scene.
Amm...the test steps as follow:
1. execute select txid_current() to force the auto vacuum launch frequenctly
2. in another session drop the database and concurrently, kill the master
3. start the master
4. execute select txid_current()
5. then i found the hot standby server redo failed in FATAL like this:
FATAL: incorrect index offsets supplied
CONTEXT: xlog redo vacuum: rel 1663/16638/13309; blk 1995,
lastBlockVacuumed 1994
LOG: startup process (PID 31968) was terminated by signal 1: Hangup
I use pg_xlogdump to hack the wal file and found that: not only the btree
vacuum record but also heap clean/freeze/visible records, the tuples in
those records seem very strange... there are very the same with the record
before kill the master. And all the wal files are replicated from master...
so i think the problem is referred to master rather than standby.
During to the decoding records, the problem is very clear:
in drop database process, we take a checkpoint request, yeah, that's fine.
But before we insert the drop database record, the master got killed.
the transaction has not been committed.
the drop database code logic is like this:
dropDatabaseDependencies
DropDatabaseBuffers -- drop the dirty buffer directly
ForgetDatabaseFsyncRequests
RequestCheckpoint -- flush nothing
(here we got killed)
remove_dbtablespaces -- insert the wal record
see, we invalid the dirty buffer directly, that's why there are two same
vacuum record in wal.
and in the standby server, for the database drop transaction has not been
committed and no drop database record has been replicated. in database redo,
the startup process would not to invalid the buffer, so the standby server
thinks that the first and second vacuum are all valid.
--------------------------------
the buffer dirty tag should not be cleaned up before the buffer has been
flush to disk.
that's a rule to keep consistency. but the rule has been broken in drop
database scene.
suggestion:
before we dropped the dirty buffer, we should request a checkpoint first
'cause in create database we request checkpoint for twice...
regards,
fanbin
--
View this message in context:
http://postgresql.nabble.com/in-drop-database-auto-vacuum-and-immediate-shutdown-concurrency-scene-hot-standby-server-redo-FATAL-tp5895675.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.