public inbox for [email protected]
help / color / mirror / Atom feedFrom: Petr Jelinek <[email protected]>
To: Robert Haas <[email protected]>
To: Andres Freund <[email protected]>
Cc: Craig Ringer <[email protected]>
Cc: Simon Riggs <[email protected]>
Cc: Konstantin Knizhnik <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Logical replication and multimaster
Date: Fri, 11 Dec 2015 20:45:26 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+TgmobiQUpXpiJ0z+=PMjL4at5TteZ27A8JPMY+QQb_9NeyJA@mail.gmail.com>
References: <[email protected]>
<CANP8+jLmPXKxDsqXwf6RNSp9Q-6uc7UcZo=KNfCzH0PeehhE=w@mail.gmail.com>
<CAMsr+YEfTEp35bQ5ia__nDwc2MwzYUQcuQ__vT_b=UNOHyooMA@mail.gmail.com>
<CA+TgmoaqJJsPNb7JDAHTtGZbH7CSenuf=0trQ_j1+_scLE-c0w@mail.gmail.com>
<CAMsr+YFf4hA=hLTe2hvPZ95-Fxf3bT80-_8CWwrDpDzva3LTOw@mail.gmail.com>
<[email protected]>
<CA+TgmobiQUpXpiJ0z+=PMjL4at5TteZ27A8JPMY+QQb_9NeyJA@mail.gmail.com>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>
On 2015-12-11 19:24, Robert Haas wrote:
> On Fri, Dec 11, 2015 at 5:16 AM, Andres Freund <[email protected]> wrote:
>> On 2015-12-11 18:12:55 +0800, Craig Ringer wrote:
>>> On 10 December 2015 at 03:19, Robert Haas <[email protected]> wrote:
>>>> On Sun, Dec 6, 2015 at 10:24 PM, Craig Ringer <[email protected]>
>>>> wrote:
>>>>> * A way to securely make a libpq connection from a bgworker without
>>>> messing
>>>>> with passwords etc. Generate one-time cookies, sometihng like that.
>>>>
>>>> Why would you have the bgworker connect to the database via TCP
>>>> instead of just doing whatever it wants to do directly?
>>
>>> pg_dump and pg_restore, mainly, for copying the initial database state.
>>
>> Well, you don't want to necessarily directly connect from the bgworker,
>> but from processes started from a bgworker. I guess that's where a good
>> bit of the Robert's confusion originated.
>
> That's part of it, yeah. I'm a little scared of this design. I mean,
> I understand now why Craig wants to do this (thanks for explaining,
> Craig!), but it seems like it's going to have a lot of the same
> reliability problems that pg_upgrade does. I'm not saying there's a
> better way to get the functionality, but it's pretty obvious that
> depending on tools other than the server itself, and in particular
> pg_dump, vastly increases the failure surface area.
>
Well, it's better than trying to write completely new catalogs dump tool
for this. As Craig said, it would be best if pg_dump functionality was
moved to functions in a backend, but that's probably not gonna happen
tomorrow.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
view thread (38+ messages) latest in thread
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: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Logical replication and multimaster
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox