Re: pg_start_backup and pg_stop_backup Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Aidan Van Dyk <aidan(at)highrise(dot)ca> wrote:
>
>> I'm hoping to be able to build a tool that:
>>
>> 1) Connects to PG walsender (a la walreceiver)
>> 2) Streams WAL from pg master
>> 3) Saves WAL into "files" (a la archive)...
>>
>> i.e. I'm looking to keep a more-up-to-date PITR archive than
>> waiting for traditional WAL file archiving...
>
> I'm interested in that, too.

That looks like we have that integrated into walreceiver the day we have
cascading support, right? Or maybe we need a special mode of operation
where the receiver is (talking to) an archiver.

>> I don't personally care about streaming replication replaying WAL
>> as it comes, or running queries in recovery...
>
> I'm with you that far, but I wouldn't want the sender to wait for
> remote persistence.

That's synchronous replication and its set of synchronicity setting,
ranging from sent on the network to the slave, fsync()ed at the slave
and applied already on the slave.

IMO the real fun begins when we talk about multi-slaves support and
their roles (a failover slave wants the master to wait for it to have
applied the WAL before to commit, a reporting slave not so much). So
you'd set the Availability level on each slave and wouldn't commit on
the master until each slave got what it's configured for, or something
like that.

SyncRep in 9.1 already sounds darn interesting :)

Regards,
--
dim