From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade using appname to lock out other users |
Date: | 2011-06-15 03:40:22 |
Message-ID: | 201106150340.p5F3eM427316@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > You might remember we added a postmaster/postgres -b switch to indicate
> > binary upgrade mode. The attached patch prevents any client without an
> > application_name of 'binary-upgrade' from connecting to the cluster
> > while it is binary upgrade mode. This helps prevent unauthorized users
> > from connecting during the upgrade. This will not help for clusters
> > that do not have the -b flag, e.g. pre-9.1.
>
> > Does this seem useful?
>
> No ... that seems like a kluge. It's ugly and it's leaky.
>
> What we really ought to be doing here is fixing things so that
> pg_upgrade does not need to have a running postmaster in either
> installation, but works with some variant of standalone mode.
> That would actually be *safe* against concurrent connections,
> rather than only sorta kinda maybe safe.
I keep replying to that suggestion by reminding people that pg_upgrade
relies heavily on psql features, as does pg_dumpall, and recoding that
in the backend will be error-prone.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-06-15 03:43:31 | Re: [WIP] cache estimates, cache access cost |
Previous Message | Tom Lane | 2011-06-15 03:31:13 | Re: pg_upgrade using appname to lock out other users |