Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Michael Paquier wrote: > On Tue, Mar 1, 2016 at 5:13 PM, Kyotaro HORIGUCHI > wrote: > + return wantarray ? ($stdout, $stderr) : $stdout; > So you are willing to extend that so as you could perform conparison > tests on the error strings returned. Why no, it

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 1 March 2016 at 21:05, Craig Ringer wrote: > On 1 March 2016 at 20:45, Michael Paquier > wrote: > >> On Tue, Mar 1, 2016 at 5:13 PM, Kyotaro HORIGUCHI >> wrote: >> > 0001-Change-behavior-... >> > >> >

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 1 March 2016 at 20:45, Michael Paquier wrote: > On Tue, Mar 1, 2016 at 5:13 PM, Kyotaro HORIGUCHI > wrote: > > 0001-Change-behavior-... > > > > Changes of PostmasterNode.pm and TestLib.pm to add some > > features and change a

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Tue, Mar 1, 2016 at 5:13 PM, Kyotaro HORIGUCHI wrote: > 0001-Change-behavior-... > > Changes of PostmasterNode.pm and TestLib.pm to add some > features and change a behavior. + # Preserve temporary directory for this test if failure +

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Hello, At Fri, 26 Feb 2016 15:43:14 -0300, Alvaro Herrera wrote in <20160226184314.GA205945@alvherre.pgsql> > Kyotaro HORIGUCHI wrote: > > > So, I'd like to propose four (or five) changes to this harness. > > > > - prove_check to remove all in tmp_check > > > > -

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Kyotaro HORIGUCHI wrote: > So, I'd like to propose four (or five) changes to this harness. > > - prove_check to remove all in tmp_check > > - TestLib to preserve temporary directories/files if the current >test fails. > > - PostgresNode::get_new_node to create data directory with >

[HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, Feb 04, 2016 at 09:13:46PM +0300, Victor Wagner wrote: > On Thu, 4 Feb 2016 18:33:27 +0300 Michael Paquier > wrote: > > > Really, it is not so hard to add configure checks for perl modules. > > > And we need to test not only for IPC::Run, but for Test::More

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Hello, I'm studying this. Two hunks in 0003 needed a fix but the other part applied cleanly on master. At Fri, 22 Jan 2016 15:17:51 +0900, Michael Paquier wrote in

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Mon, Dec 21, 2015 at 4:45 PM, Michael Paquier wrote: > As this thread is stalling a bit, please find attached a series of > patch gathering all the pending issues for this thread: > - 0001, fix config_default.pl for MSVC builds to take into account TAP tests > -

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Sat, Dec 12, 2015 at 8:29 PM, Michael Paquier wrote: > On Sat, Dec 12, 2015 at 11:37 AM, Noah Misch wrote: >> On Fri, Dec 11, 2015 at 09:34:34PM +0900, Michael Paquier wrote: >>> On Fri, Dec 11, 2015 at 8:48 PM, Alvaro Herrera >>>

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Sat, Dec 12, 2015 at 11:37 AM, Noah Misch wrote: > On Fri, Dec 11, 2015 at 09:34:34PM +0900, Michael Paquier wrote: >> On Fri, Dec 11, 2015 at 8:48 PM, Alvaro Herrera >> wrote: >> > Michael Paquier wrote: >> >> On Fri, Dec 11, 2015 at 5:35 AM,

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Michael Paquier wrote: > On Fri, Dec 11, 2015 at 5:35 AM, Alvaro Herrera > wrote: > > Since we now have the node name in the log file name, perhaps we no > > longer need the port number in there > > There is no node name in the log file name as of now, they are built >

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Fri, Dec 11, 2015 at 8:48 PM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Fri, Dec 11, 2015 at 5:35 AM, Alvaro Herrera >> wrote: >> I guess that to complete your idea we could allow PostgresNode to get >> a custom name for its log

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Fri, Dec 11, 2015 at 09:34:34PM +0900, Michael Paquier wrote: > On Fri, Dec 11, 2015 at 8:48 PM, Alvaro Herrera > wrote: > > Michael Paquier wrote: > >> On Fri, Dec 11, 2015 at 5:35 AM, Alvaro Herrera > >> wrote: > >> I guess that to

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Noah Misch wrote: > On Mon, Dec 07, 2015 at 02:34:39PM +0900, Michael Paquier wrote: > > I don't directly see any limitation with the use of kill on Windows.. > > http://perldoc.perl.org/functions/kill.html > > But indeed using directly pg_ctl kill seems like a better fit for the > > PG

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Fri, Dec 11, 2015 at 5:35 AM, Alvaro Herrera wrote: > Noah Misch wrote: >> On Mon, Dec 07, 2015 at 02:34:39PM +0900, Michael Paquier wrote: >> > > Postmaster log file names became less informative. Before the commit: >> > > Should nodes get a name, so we instead see

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

I've been giving RecoveryTest.pm a look. I wonder if we really need that as a separate package. My first thought was that we could have another class that inherits from PostgresNode (say RecoveryNode). But later it occured to me that we could have the new functions just be part of PostgresNode

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, Dec 10, 2015 at 6:46 AM, Alvaro Herrera wrote: > I've been giving RecoveryTest.pm a look. I wonder if we really need that > as a separate package. My first thought was that we could have another > class that inherits from PostgresNode (say RecoveryNode). But

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Mon, Dec 07, 2015 at 02:34:39PM +0900, Michael Paquier wrote: > On Mon, Dec 7, 2015 at 12:06 PM, Noah Misch wrote: > > On Wed, Dec 02, 2015 at 06:59:09PM -0300, Alvaro Herrera wrote: > >> +sub DESTROY > >> +{ > >> + my $self = shift; > >> + return if not defined

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Michael Paquier wrote: > > If that's not a hard-coded PG version number then I don't know > > what it is. Maybe it would be better to use random() instead, > > but surely this isn't good as-is. > > We would definitely want something within the ephemeral port range, so > we are up to that: >

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Michael Paquier wrote: > On Thu, Dec 3, 2015 at 6:59 AM, Alvaro Herrera wrote: > > I didn't push the changed for config_default you requested a few > > messages upthread; it's not clear to me how setting it to undef affects > > the whole thing. If setting it to undef makes the MSVC toolchain run

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Alvaro Herrera writes: > Michael Paquier wrote: >> We would definitely want something within the ephemeral port range, so >> we are up to that: >> rand() * 16384 + 49152; > Yes, this seems to produce the correct range. Speaking of ephemeral port range ... if

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Tom Lane wrote: > Alvaro Herrera writes: > > Michael Paquier wrote: > >> We would definitely want something within the ephemeral port range, so > >> we are up to that: > >> rand() * 16384 + 49152; > > > Yes, this seems to produce the correct range. > > Speaking of

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Tue, Dec 8, 2015 at 7:46 AM, Alvaro Herrera wrote: > Michael Paquier wrote: > > On Thu, Dec 3, 2015 at 6:59 AM, Alvaro Herrera wrote: > > > I didn't push the changed for config_default you requested a few > > > messages upthread; it's not clear to me how setting it

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Dec 02, 2015 at 06:59:09PM -0300, Alvaro Herrera wrote: > It seemed better to me to have the import list be empty, i.e. "use > TestLib ()" and then qualify the routine names inside PostgresNode, > instead of having to list the names of the routines to import, so I > pushed it that way

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Mon, Dec 7, 2015 at 12:06 PM, Noah Misch wrote: > On Wed, Dec 02, 2015 at 06:59:09PM -0300, Alvaro Herrera wrote: >> --- a/src/bin/pg_basebackup/t/010_pg_basebackup.pl >> +++ b/src/bin/pg_basebackup/t/010_pg_basebackup.pl > >> -like($recovery_conf, qr/^standby_mode =

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Andrew Dunstan writes: > On 11/29/2015 04:28 PM, Noah Misch wrote: >> Never mutate the filesystem in a BEGIN block, because "perl -c" runs BEGIN >> blocks. (Likewise for the BEGIN block this patch adds to TestLib.) > Yeah, those two lines might belong in an INIT block.

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Sat, Dec 5, 2015 at 1:11 AM, Alvaro Herrera wrote: > Michael Paquier wrote: > >> By the way, if there are no objections, I am going to mark this patch >> as committed in the CF app. Putting in the infrastructure is already a >> good step forward, and I will add an

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Michael Paquier wrote: > By the way, if there are no objections, I am going to mark this patch > as committed in the CF app. Putting in the infrastructure is already a > good step forward, and I will add an entry in next CF to track the > patch to add tests for recovery itself. Alvaro, what do

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Noah Misch wrote: > git checkout 807b9e0 > (find src -name \*.pl -o -name \*.pm ) | sort -u | xargs perltidy > --profile=src/tools/pgindent/perltidyrc > > perltidy v20090616 leaves the working directory clean, but perltidy v20150815 > introduces diffs: > > src/backend/catalog/genbki.pl

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, Dec 3, 2015 at 3:44 PM, Michael Paquier wrote: > On Thu, Dec 3, 2015 at 6:59 AM, Alvaro Herrera wrote: >> I didn't push the changed for config_default you requested a few >> messages upthread; it's not clear to me how setting it to undef affects >> the whole

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Fri, Dec 04, 2015 at 02:47:36PM +0900, Michael Paquier wrote: > On Fri, Dec 4, 2015 at 2:43 PM, Noah Misch wrote: > > On Wed, Dec 02, 2015 at 04:33:50PM -0300, Alvaro Herrera wrote: > >> How did you figure > >> that that was the version used, anyway? > > > > I asked Bruce at

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Fri, Dec 4, 2015 at 2:43 PM, Noah Misch wrote: > On Wed, Dec 02, 2015 at 04:33:50PM -0300, Alvaro Herrera wrote: >> How did you figure >> that that was the version used, anyway? > > I asked Bruce at one point. So we are trying to use the same version over the years to keep

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Dec 02, 2015 at 04:33:50PM -0300, Alvaro Herrera wrote: > Noah Misch wrote: > > On Tue, Dec 01, 2015 at 08:11:21PM -0300, Alvaro Herrera wrote: > > > Finally, I ran perltidy on all the files, which strangely changed stuff > > > that I didn't expect it to change. I wonder if this is

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, Dec 3, 2015 at 6:59 AM, Alvaro Herrera wrote: > I didn't push the changes for config_default you requested a few > messages upthread; it's not clear to me how setting it to undef affects > the whole thing. If setting it to undef makes the MSVC toolchain run >

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Noah Misch wrote: > On Tue, Dec 01, 2015 at 08:11:21PM -0300, Alvaro Herrera wrote: > > Finally, I ran perltidy on all the files, which strangely changed stuff > > that I didn't expect it to change. I wonder if this is related to the > > perltidy version. > > The last pgindent run (commit

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, Dec 3, 2015 at 6:59 AM, Alvaro Herrera wrote: > I didn't push the changed for config_default you requested a few > messages upthread; it's not clear to me how setting it to undef affects > the whole thing. If setting it to undef makes the MSVC toolchain run > the tap tests in the default

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Michael Paquier wrote: > Well, Alvaro has whispered me a more elegant method by using TestLib() > to only import a portion of the routines and avoid the redefinition > errors. Hence, patch 0001 attached creates equivalents of command_* > for PostgresNode and tests use it without setting PGPORT.

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Michael Paquier wrote: > OK... I have merged TestLib and PostgresNode of the previous patch > into PostgresNode into the way suggested by Noah. TestBase has been > renamed back to TestLib, and includes as well the base test functions > like command_ok. Great, thanks. Here's one more version,

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Dec 2, 2015 at 8:11 AM, Alvaro Herrera wrote: > - I discovered that not setting PGPORT was causing some of the tests > that fail (using command_fails) to fail to test what was being tested. > The problem is that the command was failing with "could not connect

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Michael Paquier wrote: > On Wed, Dec 2, 2015 at 8:11 AM, Alvaro Herrera > wrote: > > - It would be nice to have command_ok and command_fails in PostgresNode > > too; that would remove the need for setting $ENV{PGPORT} but it's > > possible to run commands outside a

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Dec 2, 2015 at 1:04 PM, Michael Paquier wrote: > On Wed, Dec 2, 2015 at 12:01 PM, Alvaro Herrera > wrote: >> Michael Paquier wrote: >>> On Wed, Dec 2, 2015 at 8:11 AM, Alvaro Herrera >>> wrote: >> >>> > - It

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Tue, Dec 01, 2015 at 08:11:21PM -0300, Alvaro Herrera wrote: > Finally, I ran perltidy on all the files, which strangely changed stuff > that I didn't expect it to change. I wonder if this is related to the > perltidy version. The last pgindent run (commit 807b9e0) used perltidy v20090616,

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Dec 2, 2015 at 12:01 PM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Wed, Dec 2, 2015 at 8:11 AM, Alvaro Herrera >> wrote: > >> > - It would be nice to have command_ok and command_fails in PostgresNode >> > too; that would

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Mon, Nov 30, 2015 at 11:51 PM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Mon, Nov 30, 2015 at 6:28 AM, Noah Misch wrote: > >> > The proposed code is short on guidance about when to put a function in >> > TestLib >> > versus TestBase.

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Michael Paquier wrote: > On Mon, Nov 30, 2015 at 6:28 AM, Noah Misch wrote: > > The proposed code is short on guidance about when to put a function in > > TestLib > > versus TestBase. TestLib has no header comment. The TestBase header > > comment > > would permit, for

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 11/29/2015 04:28 PM, Noah Misch wrote: +BEGIN +{ + $windows_os = $Config{osname} eq 'MSWin32' || $Config{osname} eq 'msys'; + + # Determine output directories, and create them. The base path is the + # TESTDIR environment variable, which is normally set by the invoking +

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Fri, Nov 27, 2015 at 07:53:10PM -0300, Alvaro Herrera wrote: > Michael Paquier wrote: > > The result of a couple of hours of hacking is attached: > > - 0001 is the refactoring adding PostgresNode and RecursiveCopy. I have > > also found that it is quite advantageous to move some of the routines

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Sun, Nov 29, 2015 at 12:13 AM, Alvaro Herrera wrote: > Here's your recovery test patch rebased, for your (and others'!) > perusal. It passes for me. (Test 003 is unchanged.) Are you planning to push that as well? It does not have much coverage but I guess that's quite good for a first shot,

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Mon, Nov 30, 2015 at 6:28 AM, Noah Misch wrote: > > On Fri, Nov 27, 2015 at 07:53:10PM -0300, Alvaro Herrera wrote: > > Michael Paquier wrote: > > > The result of a couple of hours of hacking is attached: > > > - 0001 is the refactoring adding PostgresNode and RecursiveCopy.

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Sat, Nov 28, 2015 at 7:53 AM, Alvaro Herrera wrote: > I moved all the initialization code (deleting stuff from environment, > detecting Windows, opening SimpleTie filedescs etc) into BEGIN blocks, > which run earlier than any other code. Ah, OK. Thanks. That makes visibly the whole set of

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Michael Paquier wrote: > On Sat, Nov 28, 2015 at 7:53 AM, Alvaro Herrera wrote: > > Hmm. I just noticed RewindTest sets $ENV{PGDATABASE} outside BEGIN. Not > > sure what to think of that. Could instead pass the database name in > > $node->getConnStr() calls, like run_pg_rewind() is already

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Michael Paquier wrote: > The result of a couple of hours of hacking is attached: > - 0001 is the refactoring adding PostgresNode and RecursiveCopy. I have > also found that it is quite advantageous to move some of the routines that > are synonyms of system() and the stuff used for logging into

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Nov 25, 2015 at 11:00 AM, Michael Paquier wrote: > On Wed, Nov 25, 2015 at 10:55 AM, Alvaro Herrera > wrote: > >> Michael Paquier wrote: >> > On Wed, Nov 25, 2015 at 6:22 AM, Alvaro Herrera < >> alvhe...@2ndquadrant.com> >> > wrote:

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Michael Paquier wrote: > - Manage node information using package/class PostgresNode.pm and have > RecoveryTest use it. I have actually made PostgresNode bare-bone and simple > on purpose: one can initialize the node, append configuration parameters to > it and manage it through start/stop/restart

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Nov 25, 2015 at 6:22 AM, Alvaro Herrera wrote: > Michael Paquier wrote: > > > - Manage node information using package/class PostgresNode.pm and have > > RecoveryTest use it. I have actually made PostgresNode bare-bone and > simple > > on purpose: one can

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Michael Paquier wrote: > On Wed, Nov 25, 2015 at 6:22 AM, Alvaro Herrera > wrote: > > > Michael Paquier wrote: > > This looks great as a starting point. I think we should make TestLib > > depend on PostgresNode instead of the other way around. I will have a > > look

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Nov 25, 2015 at 10:55 AM, Alvaro Herrera wrote: > Michael Paquier wrote: > > On Wed, Nov 25, 2015 at 6:22 AM, Alvaro Herrera < > alvhe...@2ndquadrant.com> > > wrote: > > > > > Michael Paquier wrote: > > > > This looks great as a starting point. I think we

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Tue, Nov 24, 2015 at 2:14 PM, Michael Paquier wrote: > I'll rework this patch and will update a new version soon. > So, attached is a new patch addressing all the comments received. The new version has the following changes: - Print more verbosely stderr output in

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Thanks for the review. On Tue, Nov 24, 2015 at 6:15 AM, Alvaro Herrera wrote: > I just noticed that RecoveryTest.pm is lacking "use strict; use > warnings;". With those added, there's a number of problems reported: > Most of them are easily fixable by adding the

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Tue, Nov 24, 2015 at 6:27 AM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Thu, Nov 19, 2015 at 12:21 AM, Alvaro Herrera >> wrote: > >> > Hi, I just started looking this over a bit. The first thing I noticed >> > is that it adds a

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

I just noticed that RecoveryTest.pm is lacking "use strict; use warnings;". With those added, there's a number of problems reported: Global symbol "%datadir_nodes" requires explicit package name at /pgsql/source/master/src/test/perl/RecoveryTest.pm line 66. Global symbol "%backup_nodes"

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Michael Paquier wrote: > On Thu, Nov 19, 2015 at 12:21 AM, Alvaro Herrera > wrote: > > Hi, I just started looking this over a bit. The first thing I noticed > > is that it adds a dependency on Archive::Tar which isn't already used > > anywhere else. Did anybody check

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 11/19/15 11:05 AM, Robert Haas wrote: > On Wed, Nov 18, 2015 at 10:21 AM, Alvaro Herrera > wrote: >> In my days of Perl, it was starting to become frowned upon to call >> subroutines without parenthesizing arguments. Is that no longer the >> case? Because I notice

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Nov 18, 2015 at 10:21 AM, Alvaro Herrera wrote: > In my days of Perl, it was starting to become frowned upon to call > subroutines without parenthesizing arguments. Is that no longer the > case? Because I notice there are many places in this patch and pre- >

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, Nov 19, 2015 at 10:05 AM, Robert Haas wrote: > On Wed, Nov 18, 2015 at 10:21 AM, Alvaro Herrera > wrote: > > In my days of Perl, it was starting to become frowned upon to call > > subroutines without parenthesizing arguments. Is that no

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Hi, I just started looking this over a bit. The first thing I noticed is that it adds a dependency on Archive::Tar which isn't already used anywhere else. Did anybody check whether this exists back in 5.8 installations? Why is "recovery" added to ALWAYS_SUBDIRS in src/test/Makefile instead of

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 2015-11-18 16:21, Alvaro Herrera wrote: Hi, I just started looking this over a bit. The first thing I noticed is that it adds a dependency on Archive::Tar which isn't already used anywhere else. Did anybody check whether this exists back in 5.8 installations? Apparently it did not yet

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Nov 18, 2015 at 01:21:45PM -0200, Alvaro Herrera wrote: > In my days of Perl, it was starting to become frowned upon to call > subroutines without parenthesizing arguments. Is that no longer the > case? I've not witnessed those frowns. > Because I notice there are many places in this

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, Nov 19, 2015 at 12:21 AM, Alvaro Herrera wrote: > > Hi, I just started looking this over a bit. The first thing I noticed > is that it adds a dependency on Archive::Tar which isn't already used > anywhere else. Did anybody check whether this exists back in 5.8

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 10/11/2015 01:19 PM, Michael Paquier wrote: > On Sun, Oct 11, 2015 at 4:44 PM, Amir Rohan wrote: >> On 10/11/2015 02:47 AM, Michael Paquier wrote: >> I apologize -- that didn't came out right. >> What I meant to suggest was "open an issue" to track >> any works that needs to be done. But I

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 10/11/2015 02:47 AM, Michael Paquier wrote: > On Sat, Oct 10, 2015 at 10:52 PM, Amir Rohan wrote: >> On 10/10/2015 04:32 PM, Michael Paquier wrote: >> I was arguing that it's an on-going task that would do >> better if it had a TODO list, instead of "ideas for tests" >>

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Sun, Oct 11, 2015 at 4:44 PM, Amir Rohan wrote: > On 10/11/2015 02:47 AM, Michael Paquier wrote: > I apologize -- that didn't came out right. > What I meant to suggest was "open an issue" to track > any works that needs to be done. But I guess that's > not the PG way. No problem. I was not

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 10/10/2015 04:32 PM, Michael Paquier wrote: > On Sat, Oct 10, 2015 at 9:04 PM, Amir Rohan wrote: >> Now that v9 fixes the problem, here's a summary from going over the >> entire thread one last time: > > Thanks a lot for the summary of the events. > >> # Windows and TAP sets >> Noah (2015-03)

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Sat, Oct 10, 2015 at 10:52 PM, Amir Rohan wrote: > On 10/10/2015 04:32 PM, Michael Paquier wrote: > I was arguing that it's an on-going task that would do > better if it had a TODO list, instead of "ideas for tests" > being scattered across 50-100 messages spanning a year

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 10/10/2015 02:43 PM, Michael Paquier wrote: > On Fri, Oct 9, 2015 at 8:53 PM, Michael Paquier > wrote: >> On Fri, Oct 9, 2015 at 8:47 PM, Amir Rohan wrote: >>> Ok, I've put myself down as reviewer in cfapp. I don't think I can >>> provide any more useful feedback

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Fri, Oct 9, 2015 at 8:53 PM, Michael Paquier wrote: > On Fri, Oct 9, 2015 at 8:47 PM, Amir Rohan wrote: >> 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,

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Sat, Oct 10, 2015 at 9:04 PM, Amir Rohan wrote: > Now that v9 fixes the probkem, here's a summary from going over the > entire thread one last time: Thanks a lot for the summary of the events. > # Windows and TAP sets > Noah (2015-03) mentioned TAP doesn't work on windows, and hoped > this

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 10/10/2015 04:32 PM, Michael Paquier wrote: > On Sat, Oct 10, 2015 at 9:04 PM, Amir Rohan wrote: >> The patch focuses on providing facilities, while providing new coverage >> for several features. There should be a TODO list on the wiki (bug >> tracker, actually), where the list of tests to be

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Fri, Oct 9, 2015 at 8:25 AM, Michael Paquier 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

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 10/09/2015 02:12 PM, Michael Paquier wrote: > On Fri, Oct 9, 2015 at 8:25 AM, Michael Paquier > 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)

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Fri, Oct 9, 2015 at 8:47 PM, Amir Rohan wrote: > 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

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 10/08/2015 08:19 AM, Michael Paquier wrote: > On Wed, Oct 7, 2015 at 5:44 PM, Amir Rohan wrote: >> On 10/07/2015 10:29 AM, Michael Paquier wrote: >>> On Wed, Oct 7, 2015 at 4:16 PM, Amir Rohan wrote: Also, the removal of poll_query_until from pg_rewind looks suspiciously like a

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, Oct 8, 2015 at 3:59 PM, Amir Rohan wrote: > On 10/08/2015 08:19 AM, Michael Paquier wrote: >> On Wed, Oct 7, 2015 at 5:44 PM, Amir Rohan wrote: >>> On 10/07/2015 10:29 AM, Michael Paquier wrote: On Wed, Oct 7, 2015 at 4:16 PM, Amir Rohan wrote: > Also, the

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 10/08/2015 10:39 AM, Michael Paquier wrote: > On Thu, Oct 8, 2015 at 3:59 PM, Amir Rohan wrote: >> On 10/08/2015 08:19 AM, Michael Paquier wrote: >>> On Wed, Oct 7, 2015 at 5:44 PM, Amir Rohan wrote: On 10/07/2015 10:29 AM, Michael Paquier wrote: > On Wed, Oct 7,

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, Oct 8, 2015 at 6:03 PM, Amir Rohan wrote: > On 10/08/2015 10:39 AM, Michael Paquier wrote: >>> Someone mentioned a daisy chain setup which sounds fun. Anything else in >>> particular? Also, it would be nice to have some canned way to measure >>> end-to-end replication latency for variable

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 10/08/2015 04:47 PM, Michael Paquier wrote: > On Thu, Oct 8, 2015 at 6:03 PM, Amir Rohan wrote: >> On 10/08/2015 10:39 AM, Michael Paquier wrote: Someone mentioned a daisy chain setup which sounds fun. Anything else in particular? Also, it would be nice to have some canned way to

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

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

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 10/07/2015 09:27 AM, Michael Paquier wrote: > On Wed, Oct 7, 2015 at 7:51 AM, Michael Paquier > wrote: >> On Wed, Oct 7, 2015 at 7:43 AM, Michael Paquier >> wrote: >>> On Wed, Oct 7, 2015 at 5:58 AM, Robert Haas wrote: On Sat, Oct 3,

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Oct 7, 2015 at 4:16 PM, Amir Rohan wrote: > On 10/07/2015 09:27 AM, Michael Paquier wrote: >> On Wed, Oct 7, 2015 at 7:51 AM, Michael Paquier >> wrote: >>> On Wed, Oct 7, 2015 at 7:43 AM, Michael Paquier >>>

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 25 September 2015 at 14:29, Michael Paquier wrote: > I also arrived at the conclusion that it would be > better to place the new package file in src/test/perl instead of > src/test/recovery to allow any users of the TAP tests to have it in their > PERL5LIB path and

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Oct 7, 2015 at 7:51 AM, Michael Paquier wrote: > On Wed, Oct 7, 2015 at 7:43 AM, Michael Paquier > wrote: >> On Wed, Oct 7, 2015 at 5:58 AM, Robert Haas wrote: >>> On Sat, Oct 3, 2015 at 7:38 AM, Michael Paquier wrote: >>> It seems

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 10/07/2015 10:29 AM, Michael Paquier wrote: > On Wed, Oct 7, 2015 at 4:16 PM, Amir Rohan wrote: >> On 10/07/2015 09:27 AM, Michael Paquier wrote: >>> On Wed, Oct 7, 2015 at 7:51 AM, Michael Paquier >>> wrote: On Wed, Oct 7, 2015 at 7:43 AM,

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Oct 7, 2015 at 5:44 PM, Amir Rohan wrote: > On 10/07/2015 10:29 AM, Michael Paquier wrote: >> On Wed, Oct 7, 2015 at 4:16 PM, Amir Rohan wrote: >>> Also, the removal of poll_query_until from pg_rewind looks suspiciously >>> like a copy-paste gone bad. Pardon if I'm missing something. >> >>

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Sat, Oct 3, 2015 at 7:38 AM, Michael Paquier wrote: >> Granted, you have to try fairly hard to shoot yourself in the leg, >> but since the solution is so simple, why not? If we never reuse ports >> within a single test, this goes away. > > Well, you can reuse the

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Oct 7, 2015 at 5:58 AM, Robert Haas wrote: > On Sat, Oct 3, 2015 at 7:38 AM, Michael Paquier wrote: > It seems that these days 'make check' creates a directory in /tmp > called /tmp/pg_regress-RANDOMSTUFF. Listening on TCP ports is > disabled, and the socket goes inside this directory

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Oct 7, 2015 at 7:43 AM, Michael Paquier wrote: > On Wed, Oct 7, 2015 at 5:58 AM, Robert Haas wrote: >> On Sat, Oct 3, 2015 at 7:38 AM, Michael Paquier wrote: >> It seems that these days 'make check' creates a directory in /tmp >> called

[HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Sat, Oct 3, 2015 at 10:47 PM, Michael Paquier wrote: > On Sat, Oct 3, 2015 at 9:50 PM, Amir Rohan wrote: Block until recovery is finished, before testing. eliminate races, and avoid the stupid sleep(3) I used. >>> >>> TODO > > Well. I just recalled this item in the list of things you

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On October 4, 2015 3:27:00 PM GMT+02:00, Amir Rohan wrote: >Perhaps it would help a little if you posted the latest patch here as >well? So that at least the app picks it up again. You can as additional threads in the cf app. -- Please excuse brevity and formatting - I am

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 10/04/2015 04:29 PM, Andres Freund wrote: > On October 4, 2015 3:27:00 PM GMT+02:00, Amir Rohan > wrote: > >> Perhaps it would help a little if you posted the latest patch here as >> well? So that at least the app picks it up again. > > You can as additional threads in

  1   2   >