Re: tracking commit timestamps

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