Re: pg_upgrade using appname to lock out other users
От | Robert Haas |
---|---|
Тема | Re: pg_upgrade using appname to lock out other users |
Дата | |
Msg-id | BANLkTinxjccckPbJUv=09Ykm66P6zMzJGw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_upgrade using appname to lock out other users (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: pg_upgrade using appname to lock out other users
|
Список | pgsql-hackers |
On Wed, Jun 15, 2011 at 12:12 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Excerpts from Robert Haas's message of mié jun 15 08:45:21 -0400 2011: > Seems good, except that passing the password as a command line argument > is obviously broken from a privacy perspective -- anyone could see the > process list and get it. Maybe have postmaster ask for it on startup > somehow, or have pg_upgrade write it in a file which is read by > postmaster. Writing it to a file which is ready by postmaster seems promising. Then you wouldn't even need a command line option; you could just have the postmaster write out binary_upgrade.conf and have that work like recovery.conf to trigger the system to start up in a different mode. >> As a separate issue, I tend to agree with Tom that using psql as part >> of the pg_upgrade process is a lousy idea and we need a better >> solution. But let's fix one thing at a time. > > Agreed on both counts ... but ... does this mean that we need a > different program for programmable tasks as opposed to interactive > ones? Dealing with standalone backends *is* a pain, that's for sure. I'm not sure exactly what is needed here - what programmable tasks are you thinking of, other than pg_upgrade? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: