oonishitk@nttdata.co.jp wrote:
> The below error messages were shown in standby server log:
>
> FATAL: could not access status of transaction 9009
> DETAIL: Could not read from file "pg_commit_ts/0000" at offset 90112: Success.
> CONTEXT: xlog redo Transaction/COMMIT: 2015-09-30 15:52:41.924141+09
> LOG: startup process (PID 23199) exited with exit code 1
> LOG: terminating any other active server processes
>
> Before this FATAL, there were some INFO but annoying messages:
>
> LOG: file "pg_commit_ts/0000" doesn't exist, reading as zeroes
Here's a patch.
I went over the commit_ts.c code a few more times. I eventually
realized that we were trying to update the value of the GUC, which is a
rather unreliable thing to do; this was made worse by the fact that we
were updating it in one process only.
I thought it was better to have a separate boolean flag, affecting the
recovery process only, which is set at startup time or when the
XLOG_PARAMETER_CHANGE message is received. The module is enabled if
either the GUC is set or we see that the master has the module enabled.
This only enables it as far as replaying xlog records though: if you use
the SQL interface, it will still raise an error that you cannot read
values unless the GUC is enabled. This seems fine to me.
A curious but benign effect of this patch is that if you have the module
disabled in the master but enabled in the standby, you can actually
query the commit times in the standby, and they will correspond to
whatever the master used in the commit xlog record.
Other small changes:
- Moved some code out of xlog_redo into a new public commit_ts.c
routine; made ActivateCommitTs and Deactivate* statics.
- In the previous commit I added an assert that we're not writing xlog
and replaying xlog at the same time. This is pointless because xlog.c
already complains about that, so this commit takes it out again.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
