Re: [DOCS] max_worker_processes on the standby - Mailing list pgsql-hackers

From
Subject Re: [DOCS] max_worker_processes on the standby
Date
Msg-id cbbd7d012478460ba28c18927891ea9a@MP-MSGSS-MBX004.msg.nttdata.co.jp
Whole thread Raw
In response to Re: [DOCS] max_worker_processes on the standby  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
> Here's a patch.

Thank you!
With this patch, the standby server down disappears in my environment.

Regards,

========
Takashi Ohnishi
oonishitk@nttdata.co.jp

-----Original Message-----
From: Alvaro Herrera [mailto:alvherre@2ndquadrant.com] 
Sent: Thursday, October 01, 2015 7:48 AM
To: Fujii Masao <masao.fujii@gmail.com>; SPS 大西 高史(三技術) <oonishitk@nttdata.co.jp>
Cc: pgsql-docs <pgsql-docs@postgresql.org>; pgsql-hackers@postgresql.org
Subject: Re: [DOCS] max_worker_processes on the standby

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
theGUC, which is a rather unreliable thing to do; this was made worse by the fact that we were updating it in one
processonly.
 

I thought it was better to have a separate boolean flag, affecting the recovery process only, which is set at startup
timeor when the XLOG_PARAMETER_CHANGE message is received.  The module is enabled if either the GUC is set or we see
thatthe 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
errorthat 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
thecommit 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
pointlessbecause 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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: LISTEN denial of service with aborted transaction
Next
From: Josh Berkus
Date:
Subject: Re: Idea for improving buildfarm robustness