From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Yet another failure mode in pg_upgrade |
Date: | 2012-08-13 10:46:43 |
Message-ID: | CABUevEyBekBrZ8VwFTAO=mvSypMzAYCPTB6+xJ1BTdu4vH9Gaw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 13, 2012 at 4:34 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I've been experimenting with moving the Unix socket directory to
> /var/run/postgresql for the Fedora distribution (don't ask :-().
> It's mostly working, but I found out yet another way that pg_upgrade
> can crash and burn: it doesn't consider the possibility that the
> old or new postmaster is compiled with a different default
> unix_socket_directory than what is compiled into the libpq it's using
> or that pg_dump is using.
>
> This is another hazard that we could forget about if we had some way for
> pg_upgrade to run standalone backends instead of starting a postmaster.
Yeah, that would be nice.
> But in the meantime, I suggest it'd be a good idea for pg_upgrade to
> explicitly set unix_socket_directory (or unix_socket_directories in
> HEAD) when starting the postmasters, and also explicitly set PGHOST
> to ensure that the client-side code plays along.
That sounds like a good idea for other reasons as well - manual
connections attempting to get in during an upgrade will just fail with
a "no connection" error, which makes sense...
So, +1.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2012-08-13 13:45:13 | Re: Bug in libpq implentation and omission in documentation? |
Previous Message | Amit Kapila | 2012-08-13 08:07:35 | Re: default_isolation_level='serializable' crashes on Windows |