On Tue, Oct 5, 2010 at 5:49 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 04.10.2010 17:22, Fujii Masao wrote:
>>
>> If we make all the transactions wait until specified standbys have
>> connected to the master, how do we take a base backup from the
>> master for those standbys? We seem to be unable to do that because
>> pg_start_backup also waits forever. Is this right?
>
> Hmm, pg_start_backup() writes WAL, but it doesn't commit. Only a commit
> needs to wait for acknowledgment from the standby, so 'wait forever'
> behavior doesn't necessarily mean that you can't take a base backup. If you
> run it outside a transaction you get an implicit commit, though, which will
> wait, so you might need to do something odd like "begin; select
> pg_start_backup(); rollback".
Yep. Similarly, we would need to enclose also pg_stop_backup with begin
and rollback.
I have another question: when should the waiting transactions resume?
It's a moment the standby has connected to the master? It's a moment
the standby has caught up with the master? For no data loss, the
latter seems to be required. Right?
The third question: if the WAL file is unfortunately recycled when a
transaction waits for that WAL file to be shipped forever, how should
that transaction behave? Still waiting? Cause PANIC? Give up waiting?
For no data loss, ISTM that the second should be chosen. Right?
This can happen because we can write WAL to the master without waiting
for replication by enclosing a query with begin and rollback, even if
all the transaction *commit* are waiting for replication forever.
> But I agree with Tom that as long as it's possible to change the
> configuration on the fly, it's not a show-stopper if you can't take a new
> base backup while the standby is disconnected.
Yep. If people who want the "wait-forever" can live with such an odd
backup procedure, I have no objection to implement that.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center