| 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:32:43 |
| Message-ID: | 201002061732.46200.andres@anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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);
has to be
CancelDBBackends(dbid, PROCSIG_RECOVERY_CONFLICT_DATABASE, true);
Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2010-02-06 16:39:07 | Re: Hot Standby and DROP DATABASE |
| Previous Message | Bruce Momjian | 2010-02-06 16:02:18 | Re: Backup history file should be replicated in Streaming Replication? |