From: | <oonishitk(at)nttdata(dot)co(dot)jp> |
---|---|
To: | <alvherre(at)2ndquadrant(dot)com>, <masao(dot)fujii(at)gmail(dot)com> |
Cc: | <pgsql-docs(at)postgresql(dot)org>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: max_worker_processes on the standby |
Date: | 2015-10-01 04:01:00 |
Message-ID: | cbbd7d012478460ba28c18927891ea9a@MP-MSGSS-MBX004.msg.nttdata.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
> Here's a patch.
Thank you!
With this patch, the standby server down disappears in my environment.
Regards,
========
Takashi Ohnishi
oonishitk(at)nttdata(dot)co(dot)jp
-----Original Message-----
From: Alvaro Herrera [mailto:alvherre(at)2ndquadrant(dot)com]
Sent: Thursday, October 01, 2015 7:48 AM
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>; SPS 大西 高史(三技術) <oonishitk(at)nttdata(dot)co(dot)jp>
Cc: pgsql-docs <pgsql-docs(at)postgresql(dot)org>; pgsql-hackers(at)postgresql(dot)org
Subject: Re: [DOCS] max_worker_processes on the standby
oonishitk(at)nttdata(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2015-10-01 10:46:04 | Re: max_worker_processes on the standby |
Previous Message | Alvaro Herrera | 2015-09-30 22:48:06 | Re: [DOCS] max_worker_processes on the standby |
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2015-10-01 04:02:19 | Re: Idea for improving buildfarm robustness |
Previous Message | Tom Lane | 2015-10-01 03:46:30 | Re: LISTEN denial of service with aborted transaction |