Re: Yet another failure mode in pg_upgrade
От | Magnus Hagander |
---|---|
Тема | Re: Yet another failure mode in pg_upgrade |
Дата | |
Msg-id | CABUevEyBekBrZ8VwFTAO=mvSypMzAYCPTB6+xJ1BTdu4vH9Gaw@mail.gmail.com обсуждение исходный текст |
Ответ на | Yet another failure mode in pg_upgrade (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Yet another failure mode in pg_upgrade
|
Список | pgsql-hackers |
On Mon, Aug 13, 2012 at 4:34 AM, Tom Lane <tgl@sss.pgh.pa.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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: