Re: max_worker_processes on the standby

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

In response to

Browse pgsql-docs by date

  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

Browse pgsql-hackers by date

  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