Re: ALTER DATABASE RENAME with HS/SR - Mailing list pgsql-hackers

From Robert Haas
Subject Re: ALTER DATABASE RENAME with HS/SR
Date
Msg-id AANLkTikuqKrH74fq26LpNkrznk=DYYYAf-ASrFgb=03e@mail.gmail.com
Whole thread Raw
In response to Re: ALTER DATABASE RENAME with HS/SR  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: ALTER DATABASE RENAME with HS/SR  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Mon, Oct 4, 2010 at 12:42 PM, Simon Riggs <simon@2ndquadrant.com> 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 DATABASE .. RENAME
>> issue something like XLOG_DBASE_RENAME record, and make the standby server
>> call ResolveRecoveryConflictWithDatabase() when that record is applied.
>> Simon?
>
> Certainly contrary to documented behaviour, thanks for the report.
>
> Question: do we want that documented behaviour, or should we leave it as
> is? Probably want to throw a conflict, but it seems worth asking, since
> I know for certain I just made up the documented behaviour.
>
> I'll patch if we agree its required.

Per comments from Josh, Bernd, and myself upthread, I think the
consensus is that we should patch the documentation.  Aside from the
fact that the restriction seems fairly arbitrary in any event, I'm
unexcited about back-patching a WAL format change.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: Hitoshi Harada
Date:
Subject: Re: top-level DML under CTEs
Next
From: Robert Haas
Date:
Subject: Re: standby registration (was: is sync rep stalled?)