pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>
Cc: Benoit Lobréau <benoit.lobreau@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Bossart, Nathan <bossartn@amazon.com>
Cc: David Steele <david@pgmasters.net>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Magnus Hagander <magnus@hagander.net>
Cc: Stephen Frost <sfrost@snowman.net>
Subject: Re: archive modules
Date: Wed, 14 Sep 2022 16:47:23 -0400
Message-ID: <2884265.1663188443@sss.pgh.pa.us> (raw)
In-Reply-To: <37857474-5caa-ccb3-92a3-150ddfe851ab@enterprisedb.com>
References: <CAPE8EZ7vh6gdgHjAYhuvjUJzvZm7PGeZQaDDBfSYmDmfa+QeFg@mail.gmail.com>
	<20220824221723.GA1347845@nathanxps13>
	<CAPE8EZ4F3d06diQ27D=5qxN2FVHA0qsaRghzkLDf=KZHEUN7rg@mail.gmail.com>
	<20220825200600.GA1465148@nathanxps13>
	<20220829224621.GB541895@nathanxps13>
	<CAPE8EZ7SQKKkreVT2Cjrheg8dChT_qSDRBS71r-r+girEMQ4bw@mail.gmail.com>
	<20220830163048.GA544233@nathanxps13>
	<613541.1662842656@sss.pgh.pa.us>
	<20220910211046.GA2651323@nathanxps13>
	<9ee5d180-2c32-a1ca-d3d7-63a723f68d9a@enterprisedb.com>
	<20220914200305.GA2984249@nathanxps13>
	<37857474-5caa-ccb3-92a3-150ddfe851ab@enterprisedb.com>

Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 14.09.22 22:03, Nathan Bossart wrote:
>> I originally did it this way, but changed it based on this feedback [0].  I
>> have no problem with the general idea, but the recovery_target_* logic does
>> have the following note:
>> 
>> * XXX this code is broken by design.  Throwing an error from a GUC assign
>> * hook breaks fundamental assumptions of guc.c.  So long as all the variables
>> * for which this can happen are PGC_POSTMASTER, the consequences are limited,
>> * since we'd just abort postmaster startup anyway.  Nonetheless it's likely
>> * that we have odd behaviors such as unexpected GUC ordering dependencies.

> Ah yes, that won't work.  But maybe we can just check it at run time, 
> like in LoadArchiveLibrary().

Yeah, the objection there is only to trying to enforce such
interrelationships in GUC hooks.  In this case it seems to me that
we could easily check and complain at the point where we're about
to use the GUC values.

			regards, tom lane





view thread (102+ messages)  latest in thread

Message-ID: <2884265.1663188443@sss.pgh.pa.us>
Permalink:  ../2884265.1663188443@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/2884265.1663188443@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, peter.eisentraut@enterprisedb.com, nathandbossart@gmail.com, benoit.lobreau@gmail.com, alvherre@alvh.no-ip.org, robertmhaas@gmail.com, bossartn@amazon.com, david@pgmasters.net, masao.fujii@oss.nttdata.com, michael@paquier.xyz, magnus@hagander.net, sfrost@snowman.net
  Subject: Re: archive modules
  In-Reply-To: <2884265.1663188443@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox