On Fri, 12 Dec 2003, Peter Eisentraut wrote: > Tom Lane wrote: > > I think it's important to be able to run pg_upgrade with the > > postmaster shut down. Otherwise there is too much risk that some > > other user will change the database while we are working. The > > original pg_upgrade script left it to the DBA to ensure this wouldn't > > happen, but that seems like a foot-gun of much too large caliber. > > Instead, all operations should be done through a standalone backend. > > An additional advantage of doing it this way is that a standalone > > backend is implicitly superuser, and so no SQL permissions issues > > will get in the way. > > This would also be a nice solution for people who want a standalone, > server-less database system. But for the purpose of pg_upgrade it > seems like a lot of work for what could just be a magic switch in the > postmaster to really kick everyone else out.
I was going to ask that one, in relation to a 'READONLY' mode that only the superuse can do writes (ie. single master, multi slave with slaves used as readonly databases), but ... how often do ppl write apps that connect as the superuse in their normal interactions? I know in our case, even though I should know better, we still do it to a large extent ... so how would you know who to legitimately 'kick out'? Hrmmmmm ... how about a READ ONLY EXCEPT FROM <IP> mode? In the case of a slave, the IP would be the master server itself ... in the case of pg_upgrade, it would be localhost? Then again, in the case of pg_upgrade, wouldn't just disabling access from anywhere except localhost prevent others from getting in? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
