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?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

Search Discussions

  • Andres Freund at Feb 6, 2010 at 4:33 pm

    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
  • Andres Freund at Feb 6, 2010 at 4:39 pm

    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
  • Simon Riggs at Feb 7, 2010 at 4:49 pm

    On Sat, 2010-02-06 at 17:32 +0100, Andres Freund wrote:

    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);
    Well spotted, thanks for the report and the analysis.

    The code for drop database worked when committed but it looks like the
    re-factoring of the code broke it. Will fix.

    --
    Simon Riggs www.2ndQuadrant.com

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedFeb 6, '10 at 1:47a
activeFeb 7, '10 at 4:49p
posts4
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase