Re: Inconsistent DB data in Streaming Replication - Mailing list pgsql-hackers

Hello,

>The only potential use case for this that I can see, would be for system maintenance and a controlled failover. I agree: that's a major PITA >when doing DR testing, but I personally don't think this is the way to fix that particular edge case.

This is the use case we are trying to address (I work with Samrat).

You just shut down the old master and let the standby catch
up (takas a few microseconds ;) ) before you promote it.

After this you can start up the former master with recovery.conf
and it will follow nicely.

We were wondering why this may not be a good fix?

The proposed fix - halting all writes of data pages to disk and
to WAL files while waiting ACK from standby - will tremendously
slow down all parallel work on master.

And it does just turn around "master is ahead of slave" problem
into "slave is ahead of master" problem :)

Regards
Hannu

regards

Sameer

On Thu, Apr 11, 2013 at 3:52 PM, Ants Aasma <ants@cybertec.at> wrote:

On Thu, Apr 11, 2013 at 10:09 AM, Amit Kapila <amit.kapila@huawei.com> wrote:
> Consider the case old-master crashed during flushing the data page, now you
> would need full page image from new-master.
> It might so happen that in new-master Checkpoint would have purged (reused)
> the log file's from that time line, in that case
> it will be difficult to get the full page image, user can refer WAL archive
> for that, but I think it will not be straight forward.

Using a WAL archive is standard procedure when you do not wish to take
new base backups all the time. This already works now, when archive
recovery is set up the WAL will be automatically fetched from the
archive.

> One more point, what will be the new behavior when there are 2 transactions
> one has synchronous_commit =off and other with on?

Exactly the same as now - waiting for commit record replication when
reporting commit success to the client and waiting for WAL replication
before writing a data page are orthogonal features.

Regards,
Ants Aasma
--

Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt

Web: http://www.postgresql-support.de

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers