From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Subject: | Re: Hot Standby and DROP DATABASE |
Date: | 2010-02-06 16:39:07 |
Message-ID: | 201002061739.08541.andres@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Saturday 06 February 2010 17:32:43 Andres Freund wrote:
> On Saturday 06 February 2010 02:25:33 Tatsuo Ishii wrote:
> > Hi,
> >
> > While testing Hot Standby, I have encountered strange behavior with
> > DROP DATABASE command.
> >
> > 1) connect to "test" database at standby via psql
> > 2) issue DROP DATABASE test command to primary
> > 3) session #1 works fine
> > 4) close session #1
> > 5) "test" database dropped on standby
> >
> > Fromt the manual:
> > Running DROP DATABASE, ALTER DATABASE ... SET TABLESPACE, or ALTER
> > DATABASE ... RENAME on primary will generate a log message that will
> > cause all users connected to that database on the standby to be
> > forcibly disconnected. This action occurs immediately, whatever the
> > setting of max_standby_delay.
> >
> > So it seems at least the behavior is quite different from what the
> > docs stats. Am I missing something here?
>
> Its a small bug/typo in standby.c:ResolveRecoveryConflictWithDatabase
>
> The line:
> CancelDBBackends(dbid, PROCSIG_RECOVERY_CONFLICT_TABLESPACE, true);
For the case it should not be clear, the reason that
PROCSIG_RECOVERY_CONFLICT_TABLESPACE did not kill the session is that
currently all tablespace conflicts are valid only inside a transaction, so when
receiving the recovery conflict checks whether its not inside a transaction
block "anymore" and continues happily.
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-02-06 17:35:42 | Re: psql 8.4 \c repeats version banner |
Previous Message | Andres Freund | 2010-02-06 16:32:43 | Re: Hot Standby and DROP DATABASE |