On 2013-12-02 02:39:55 -0500, Jaime Casanova wrote: > === performance === > > i expected a regression on performance with the module turned on > because of the new XLOG records and wrote of files in pg_committs but > the performance drop is excessive. > Master 437.835674 tps > Patch, guc off 436.4340982 tps > Patch, guc on 0.370524 tps
There clearly is something wrong. The additional amount of xlog records should be nearly unnoticeable because committs piggybacks on commit records. > I started the server with the module off, then after some work turned > the module on and restarted the server and run a few benchs then > turned it off again and restart the server and get a message like: > > """ > LOG: database system was not properly shut down; automatic recovery in > progress > LOG: record with zero length at 0/3112AE58 > LOG: redo is not required > FATAL: cannot make new WAL entries during recovery > LOG: startup process (PID 24876) exited with exit code 1 > LOG: aborting startup due to startup process failure > """ Alvaro: That's because of the location you call StartupCommitts - a) it's called at the beginning of recovery if HS is enabled b) it's called before StartupXLOG() does LocalSetXLogInsertAllowed(). So I think you need to split StartupCommitts into StartupCommitts() and TrimCommitts() where only the latter does the trimming if committs is disabled. I also wonder if track_commit_timestamp should be tracked by the the XLOG_PARAMETER_CHANGE stuff? So it's not disabled on the standby when it's enabled on the primary? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
