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 |
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 |