Re: pgsql: Integrate recovery.conf into postgresql.conf

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

To: Sergei Kornilov <sk@zsrv.org>, Michael Paquier <michael@paquier.xyz>

Cc: Postgres hackers <pgsql-hackers@postgresql.org>

Date: 2018-11-26T13:06:36Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Integrate recovery.conf into postgresql.conf
- 2dedf4d9a899 12.0 cited

On 26/11/2018 13:32, Sergei Kornilov wrote:
>> Timed out while waiting for standby to catch up at
>> t/003_recovery_targets.pl line 34.
> 
> I can reproduce this and notice wrong assign settings order. For example standby_6 has
>> 	recovery_target_name = '$recovery_name'
>> 	recovery_target_xid  = '$recovery_txid'
>> 	recovery_target_time = '$recovery_time'
> But recoveryTarget was set to RECOVERY_TARGET_XID
> Without -DEXEC_BACKEND all fine.
> 
> As far as I understand the guc.c code with EXEC_BACKEND all processes uses different config processing logic. We serialize all GUC and restore at process start. And we sort GUC by name in build_guc_variables - so we restore settings in wrong order. I was afraid that the GUC system does not guarantee the order of settings...
> 
> What is preferable solution? Seems we can not simple change this logic.

What is the reason for allowing multiple recovery_target_* settings and
taking the last one?  Could we change this aspect to make this behave
better?

> I think i can reorganize all new recovery_target_* GUC into single one with format, for example, recovery_target = "xid:607" (was mentioned in patch discussion).

That would be another option.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services