Re: Inconsistent DB data in Streaming Replication
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). We were wondering why this may not be a good fix?
regards
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:Using a WAL archive is standard procedure when you do not wish to take
> 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.
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.Exactly the same as now - waiting for commit record replication when
> One more point, what will be the new behavior when there are 2 transactions
> one has synchronous_commit =off and other with on?
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 GmbHWeb: http://www.postgresql-support.de
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: