Re: Yet another failure mode in pg_upgrade
От | Bruce Momjian |
---|---|
Тема | Re: Yet another failure mode in pg_upgrade |
Дата | |
Msg-id | 20120901194714.GE13604@momjian.us обсуждение исходный текст |
Ответ на | Re: Yet another failure mode in pg_upgrade (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Sat, Sep 1, 2012 at 03:05:01PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > My point is that we are still going to need traditional connections for > > live checks. > > Yes, but that's not terribly relevant, IMO. All it means is that we > don't want to invent some solution that doesn't go through libpq. > > > If we could find a solution for Windows, the socket in > > current directory might be enough to lock things down, especially if we > > put the socket in a new subdirectory that only we can read/write to. > > Who is "we"? Somebody else logged in under the postgres userid could > still connect. But they have to find the current directory to do that; seems unlikely. They could kill -9 pg_upgrade too if they are the same user id. > > Should I persue that in my patch? > > I think this is just a band-aid, and we shouldn't be putting more > effort into it than needed to ensure that unexpected configuration > settings won't break it. The right fix is a better form of > standalone-backend mode. Maybe I will go pursue that, since nobody > else seems to want to. I am worried that is going to be a complex solution to a very minor problem. Also, how is that going to get backpatched? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: