Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

2010-10-05 Thread Simon Riggs
On Tue, 2010-10-05 at 08:56 -0400, Robert Haas wrote: > On Mon, Oct 4, 2010 at 12:42 PM, Simon Riggs wrote: > > On Mon, 2010-10-04 at 20:38 +0900, Fujii Masao wrote: > >> > > >> > That looks contrary to the documented behavior. Shouldn't i get a forced > >> > disconnect on this connection instead?

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

2010-10-05 Thread Robert Haas
On Mon, Oct 4, 2010 at 12:42 PM, Simon Riggs wrote: > On Mon, 2010-10-04 at 20:38 +0900, Fujii Masao wrote: >> > >> > That looks contrary to the documented behavior. Shouldn't i get a forced >> > disconnect on this connection instead? >> >> Probably yes. To do that, ISTM that we should make ALTER

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

2010-10-05 Thread Fujii Masao
On Tue, Oct 5, 2010 at 5:11 PM, Simon Riggs wrote: > On Tue, 2010-10-05 at 13:29 +0900, Fujii Masao wrote: >> On Tue, Oct 5, 2010 at 3:42 AM, Tom Lane wrote: >> > OTOH, we don't have a similar interlock to prevent renaming users >> > who have active sessions, so maybe we are being overprotective

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

2010-10-05 Thread Simon Riggs
On Tue, 2010-10-05 at 13:29 +0900, Fujii Masao wrote: > On Tue, Oct 5, 2010 at 3:42 AM, Tom Lane wrote: > > OTOH, we don't have a similar interlock to prevent renaming users > > who have active sessions, so maybe we are being overprotective here. > > Yep. What is worse is that we can drop users w

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

2010-10-05 Thread Simon Riggs
On Mon, 2010-10-04 at 20:38 +0900, Fujii Masao wrote: > > > > That looks contrary to the documented behavior. Shouldn't i get a forced > > disconnect on this connection instead? > > Probably yes. To do that, ISTM that we should make ALTER DATABASE .. RENAME > issue something like XLOG_DBASE_RENAME

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

2010-10-04 Thread Fujii Masao
On Tue, Oct 5, 2010 at 3:42 AM, Tom Lane wrote: > OTOH, we don't have a similar interlock to prevent renaming users > who have active sessions, so maybe we are being overprotective here. Yep. What is worse is that we can drop users who have active sessions on the standby. Then we can get the foll

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

2010-10-04 Thread Robert Haas
On Mon, Oct 4, 2010 at 3:16 PM, Josh Berkus wrote: > On 10/4/10 10:24 AM, Robert Haas wrote: >> I understand that we need to disconnect users if the database is >> dropped (it's kind of hard to access a database that's not there any >> more...) but I'm fuzzy on why we'd need to do that if it is me

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

2010-10-04 Thread Kevin Grittner
Robert Haas wrote: > Don't we already have some mechanism for notifying clients of > parameter changes they might care about? Are you thinking of GUC_REPORT? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgr

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

2010-10-04 Thread Bernd Helmle
--On 4. Oktober 2010 13:24:37 -0400 Robert Haas wrote: I understand that we need to disconnect users if the database is dropped (it's kind of hard to access a database that's not there any more...) but I'm fuzzy on why we'd need to do that if it is merely renamed. Yeah, if there's no real

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

2010-10-04 Thread Josh Berkus
On 10/4/10 10:24 AM, Robert Haas wrote: > I understand that we need to disconnect users if the database is > dropped (it's kind of hard to access a database that's not there any > more...) but I'm fuzzy on why we'd need to do that if it is merely > renamed. This seems like an unexpected benefit, a

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

2010-10-04 Thread Robert Haas
On Mon, Oct 4, 2010 at 2:42 PM, Tom Lane wrote: > Robert Haas writes: >> I understand that we need to disconnect users if the database is >> dropped (it's kind of hard to access a database that's not there any >> more...) but I'm fuzzy on why we'd need to do that if it is merely >> renamed. > > I

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

2010-10-04 Thread Tom Lane
Robert Haas writes: > I understand that we need to disconnect users if the database is > dropped (it's kind of hard to access a database that's not there any > more...) but I'm fuzzy on why we'd need to do that if it is merely > renamed. I think that modern backends might survive that okay (thoug

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

2010-10-04 Thread Robert Haas
On Mon, Oct 4, 2010 at 7:38 AM, Fujii Masao wrote: > On Mon, Oct 4, 2010 at 2:05 AM, Bernd Helmle wrote: >> Our documentation in >> currently >> says the following: >> >> >> Running DROP DATABASE, ALTER DATABASE ... SET TABLESPACE

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

2010-10-04 Thread Fujii Masao
On Mon, Oct 4, 2010 at 2:05 AM, Bernd Helmle wrote: > Our documentation in > currently > says the following: > > > Running DROP DATABASE, ALTER DATABASE ... SET TABLESPACE, or ALTER DATABASE > ... RENAME on the primary will generat

[HACKERS] ALTER DATABASE RENAME with HS/SR

2010-10-03 Thread Bernd Helmle
Our documentation in currently says the following: Running DROP DATABASE, ALTER DATABASE ... SET TABLESPACE, or ALTER DATABASE ... RENAME on the primary will generate a WAL entry that will cause all users connected to that dat