Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Amir Rohan <amir.rohan@zoho.com>
From: Amir Rohan <amir.rohan@zoho.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Noah Misch <noah@leadboat.com>,
Andres Freund <andres@2ndquadrant.com>,
PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
Greg Smith <gsmith@gregsmith.com>
Date: 2015-10-09T11:47:52Z
Lists: pgsql-hackers
On 10/09/2015 02:12 PM, Michael Paquier wrote: > On Fri, Oct 9, 2015 at 8:25 AM, Michael Paquier > <michael.paquier@gmail.com> wrote: >> On Thu, Oct 8, 2015 at 11:28 PM, Amir Rohan wrote: >>> Wouldn't this work? >>> 1) start timer >>> 2) Grab pg_stat_replication.sent_location from master >>> 3) pg_switch_xlog() # I /think/ we want this, could be wrong >> >> For a warm standby, you would want that, but this depends on two factors: >> - The moment master completes archiving of this segment >> - The moment standby restores it. >> On slow machines, those two things become by far the bottleneck, >> imagine a PI restricted on I/O with a low-class SD card in the worst >> case (I maintain one, with a good card, still the I/O is a >> bottleneck). >> >>> 4) Poll slave's pg_last_xlog_replay_location() until LSN shows up >>> 5) stop timer >> >> That's not really solid, there is an interval of time between the >> moment the LSN position is taken from the master and the standby. An >> accurate method is to log/store on master when a given WAL position >> has been flushed to disk, and do the same on slave at replay for this >> LSN position. In any case this is doing to flood badly the logs of >> both nodes, and as the backend cares about the performance of >> operations in this code path we won't want to do that anyway. >> >> To make it short, it seems to me that simply waiting until the LSN a >> test is waiting for has been replayed is just but fine for this set of >> tests to ensure their run consistency, let's not forget that this is >> the goal here. > > In terms of features, it seems that this patch has everything it needs > to allow one to design tests to work on both Linux and Windows, and it > is careful regarding CVE-2014-0067. Thoughts about moving that as > "Ready for committer"? > Ok, I've put myself down as reviewer in cfapp. I don't think I can provide any more useful feedback that would actually result in changes at this point, but I'll read through the entire discussion once last time and write down final comments/notes. After that I have no problem marking this for a committer to look at. Amir
Commits
-
Add a test framework for recovery
- 49148645f7f3 9.6.0 landed
-
Refactor Perl test code
- 1caef31d9e55 9.6.0 cited
-
pgindent run for 9.5
- 807b9e0dff66 9.5.0 cited