Re: pg_upgrade improvements
От | Andres Freund |
---|---|
Тема | Re: pg_upgrade improvements |
Дата | |
Msg-id | 201204051824.56092.andres@anarazel.de обсуждение исходный текст |
Ответ на | Re: pg_upgrade improvements (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thursday, April 05, 2012 06:12:48 PM Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On Thursday, April 05, 2012 05:39:19 PM Tom Lane wrote: > >> Yeah, that would be a small pain in the neck, but it eliminates a huge > >> pile of practical difficulties, like your blithe assumption that you can > >> find a "private directory" somewhere (wrong) or disallow access to other > >> people (also wrong, if they are using the same account as you). > > > > I don't think this needs to protect against malicious intent of a user > > running with the *same* privileges as the postmaster. > > Who said anything about malicious intent? Please re-read the original > gripe in this thread. There's nothing un-legitimate about, eg, clients > trying to connect to the database during your maintenance window. Yes, there is not. But those clients won't connect to a socket in some directory thats created extra for this purpose which they don't even know the name of. Scanning the directory tree for that would require malicious intent. > What we want is to be sure that nobody can connect to the database > except the person running the standalone instance. To my mind "sure" > means "sure"; it does not include qualifiers like "unless some > other process tries to do the same thing at about the same time". Its not like creating a file/directory/pipename with a random name and retrying if it already exists is an especially hard thing. That does make *sure* it does not happen by accident. Beside the fact that single run backend should already make sure were not running concurrently. So even a *fixed* atomically created filename name should be enough if its not the regular name and in a place thats not accessible from the outside. Anyway, I don't think those reasons are sensible, but I don't care enough to argue further. Andres
В списке pgsql-hackers по дате отправления: