Re: pg_receivewal starting position

From: Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Subject: Re: pg_receivewal starting position
Date: 2021-10-20 09:40:18
Message-ID: 14470011.tv2OnDr8pf@aivenronan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Le mercredi 20 octobre 2021, 07:13:15 CEST Michael Paquier a écrit :
> On Tue, Oct 19, 2021 at 05:32:55PM +0200, Ronan Dunklau wrote:
> > Following recommendations, I stripped most of the features from the patch.
> > For now we support only physical replication slots, and only provide the
> > two fields of interest (restart_lsn, restart_tli) in addition to the slot
> > type (fixed at physical) to not paint ourselves in a corner.
> >
> > I also removed the part about pg_basebackup since other fixes have been
> > proposed for that case.
>
> Patch 0001 looks rather clean. I have a couple of comments.

Thank you for the quick review !

>
> + if (OidIsValid(slot_contents.data.database))
> + elog(ERROR, "READ_REPLICATION_SLOT is only supported for
> physical slots");
>
> elog() can only be used for internal errors. Errors that can be
> triggered by a user should use ereport() instead.

Ok.
>
> +ok($stdout eq '||',
> + "READ_REPLICATION_SLOT returns NULL values if slot does not exist");
> [...]
> +ok($stdout =~ 'physical\|[^|]*\|1',
> + "READ_REPLICATION_SLOT returns tuple corresponding to the slot");
> Isn't result pattern matching something we usually test with like()?

Ok.
>
> +($ret, $stdout, $stderr) = $node_primary->psql(
> + 'postgres',
> + "READ_REPLICATION_SLOT $slotname;",
> + extra_params => [ '-d', $connstr_rep ]);
> No need for extra_params in this test. You can just pass down
> "replication => 1" instead, no?

In that test file, every replication connection is obtained by using
connstr_rep so I thought it would be best to use the same thing.

>
> --- a/src/test/recovery/t/006_logical_decoding.pl
> +++ b/src/test/recovery/t/006_logical_decoding.pl
> [...]
> +ok($stderr=~ 'READ_REPLICATION_SLOT is only supported for physical slots',
> + 'Logical replication slot is not supported');
> This one should use like().

Ok.

>
> + <para>
> + The slot's <literal>restart_lsn</literal> can also beused as a
> starting + point if the target directory is empty.
> + </para>
> I am not sure that there is a need for this addition as the same thing
> is said when describing the lookup ordering.

Ok, removed.

>
> + If nothing is found and a slot is specified, use the
> + <command>READ_REPLICATION_SLOT</command>
> + command.
> It may be clearer to say that the position is retrieved from the
> command.

Ok, done. The doc also uses the active voice here now.

>
> +bool
> +GetSlotInformation(PGconn *conn, const char *slot_name, XLogRecPtr
> *restart_lsn, TimeLineID* restart_tli)
> +{
> Could you extend that so as we still run the command but don't crash
> if the caller specifies NULL for any of the result fields? This would
> be handy.

Done.

>
> + if (PQgetisnull(res, 0, 0))
> + {
> + PQclear(res);
> + pg_log_error("replication slot \"%s\" does not exist",
> slot_name);
> + return false;
> + }
> + if (PQntuples(res) != 1 || PQnfields(res) < 3)
> + {
> + pg_log_error("could not fetch replication slot: got %d rows
> and %d fields, expected %d rows and %d or more fields",
> + PQntuples(res), PQnfields(res), 1, 3);
> + PQclear(res);
> + return false;
> + }
> Wouldn't it be better to reverse the order of these two checks?

Yes it is, and the PQntuples condition should be removed from the first error
test.

>
> I don't mind the addition of the slot type being part of the result of
> READ_REPLICATION_SLOT even if it is not mandatory (?), but at least
> GetSlotInformation() should check after it.

Ok.

>
> +# Setup the slot, and connect to it a first time
> +$primary->run_log(
> + [ 'pg_receivewal', '--slot', $slot_name, '--create-slot' ],
> + 'creating a replication slot');
> +$primary->psql('postgres',
> + 'INSERT INTO test_table VALUES (generate_series(1,100));');
> +$primary->psql('postgres', 'SELECT pg_switch_wal();');
> +$nextlsn =
> + $primary->safe_psql('postgres', 'SELECT pg_current_wal_insert_lsn();');
> +chomp($nextlsn);
> Wouldn't it be simpler to use CREATE_REPLICATION_SLOT with RESERVE_WAL
> here, rather than going through pg_receivewal? It seems to me that
> this would be cheaper without really impacting the coverage.

You're right, we can skip two invocations of pg_receivewal like this (for the
slot creation + for starting the slot a first time).

--
Ronan Dunklau

Attachment Content-Type Size
v7-0003-Add-documentation-for-pg_receivewal.patch text/x-patch 1.6 KB
v7-0001-Add-READ_REPLICATION_SLOT-command.patch text/x-patch 12.8 KB
v7-0002-Use-READ_REPLICATION_SLOT-command-in-pg_receivewa.patch text/x-patch 8.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2021-10-20 10:01:31 [PATCH] Fix memory corruption in pg_shdepend.c
Previous Message Greg Nancarrow 2021-10-20 09:33:17 Re: Data is copied twice when specifying both child and parent table in publication