Re: Hot Standby and DROP DATABASE
От | Andres Freund |
---|---|
Тема | Re: Hot Standby and DROP DATABASE |
Дата | |
Msg-id | 201002061739.08541.andres@anarazel.de обсуждение исходный текст |
Ответ на | Re: Hot Standby and DROP DATABASE (Andres Freund <andres@anarazel.de>) |
Список | 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
В списке pgsql-hackers по дате отправления: