On 2015-12-11 19:24, Robert Haas wrote:
On Fri, Dec 11, 2015 at 5:16 AM, Andres Freund <and...@anarazel.de> wrote:
On 2015-12-11 18:12:55 +0800, Craig Ringer wrote:
On 10 December 2015 at 03:19, Robert Haas <robertmh...@gmail.com> wrote:
On Sun, Dec 6, 2015 at 10:24 PM, Craig Ringer <cr...@2ndquadrant.com>
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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
