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