From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: base backup client as auxiliary backend process |
Date: | 2019-07-11 21:28:27 |
Message-ID: | 19575.1562880507@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 2019-07-11 22:20, Robert Haas wrote:
>> On Thu, Jul 11, 2019 at 4:10 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> How's the postmaster to know that it's supposed to run pg_basebackup
>>> rather than start normally? Where will it get the connection information?
>>> Seem to need configuration data *somewhere*.
>>
>> Maybe just:
>>
>> ./postgres --replica='connstr' -D createme
> What you are describing is of course theoretically possible, but it
> doesn't really fit with how existing tooling normally deals with this,
> which is one of the problems I want to address.
I don't care for Robert's suggestion for a different reason: it presumes
that all data that can possibly be needed to set up a new replica is
feasible to cram onto the postmaster command line, and always will be.
An immediate counterexample is that's not where you want to be specifying
the password for a replication connection. But even without that sort of
security issue, this approach won't scale. It also does not work even a
little bit nicely for tooling in which the postmaster is not supposed to
be started directly by the user. (Which is to say, all postgres-service
tooling everywhere.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2019-07-11 22:16:21 | Re: Adding SMGR discriminator to buffer tags |
Previous Message | Julien Rouhaud | 2019-07-11 21:14:20 | REINDEX filtering in the backend |