On 1/10/18 22:24, Michael Paquier wrote:
> On Wed, Jan 10, 2018 at 09:45:56PM -0500, Peter Eisentraut wrote:
>> On 1/8/18 23:47, Michael Paquier wrote:
>> Should we just remove it? Apparently, it was never functional to begin
>> with. Otherwise, we'd have to write a second query to return the val
On Wed, Jan 10, 2018 at 09:45:56PM -0500, Peter Eisentraut wrote:
> On 1/8/18 23:47, Michael Paquier wrote:
> Should we just remove it? Apparently, it was never functional to begin
> with. Otherwise, we'd have to write a second query to return the value
> to print. wait_for_slot_catchup has the
On 1/8/18 23:47, Michael Paquier wrote:
>> @@ -1505,7 +1515,7 @@ sub wait_for_catchup
>>. $target_lsn . " on "
>>. $self->name . "\n";
>> my $query =
>> -qq[SELECT '$target_lsn' <= ${mode}_lsn FROM pg_catalog.pg_stat_replication
>> WHERE application_name = '$standby_name';];
>
On Mon, Jan 08, 2018 at 09:46:21PM -0500, Peter Eisentraut wrote:
> It appears that we have unwittingly created some duplicate and
> copy-and-paste-prone code in src/test/subscription/ to wait for a
> replication subscriber to catch up, when we already have
> almost-sufficient code in PostgresNode
ctor subscription tests to use PostgresNode's
wait_for_catchup
---
src/test/perl/PostgresNode.pm | 16 +---
src/test/subscription/t/001_rep_changes.pl | 19 +--
src/test/subscription/t/002_types.pl | 15 ---
src/test/subscription/t/003_const