From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Euler Taveira <euler(at)eulerto(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Kartyshov Ivan <i(dot)kartyshov(at)postgrespro(dot)ru>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [HACKERS] make async slave to wait for lsn to be replayed |
Date: | 2024-03-29 12:44:56 |
Message-ID: | CAPpHfduGLJgQERBmQ+=bsr4Oy6F8HCVgQpCYva6=Ncib2X2oUA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi, Euler!
On Fri, Mar 29, 2024 at 1:38 AM Euler Taveira <euler(at)eulerto(dot)com> wrote:
> On Thu, Mar 28, 2024, at 9:39 AM, Alexander Korotkov wrote:
>
> Fixed along with other issues spotted by Alexander Lakhin.
>
>
> [I didn't read the whole thread. I'm sorry if I missed something ...]
>
> You renamed the function in a previous version but let me suggest another one:
> pg_wal_replay_wait. It uses the same pattern as the other recovery control
> functions [1]. I think "for" doesn't add much for the function name and "lsn" is
> used in functions that return an LSN (that's not the case here).
>
> postgres=# \df pg_wal_replay*
> List of functions
> -[ RECORD 1 ]-------+---------------------
> Schema | pg_catalog
> Name | pg_wal_replay_pause
> Result data type | void
> Argument data types |
> Type | func
> -[ RECORD 2 ]-------+---------------------
> Schema | pg_catalog
> Name | pg_wal_replay_resume
> Result data type | void
> Argument data types |
> Type | func
Makes sense to me. I tried to make a new procedure name consistent
with functions acquiring various WAL positions. But you're right,
it's better to be consistent with other functions controlling wal
replay.
> Regarding the arguments, I think the timeout should be bigint. There is at least
> another function that implements a timeout that uses bigint.
>
> postgres=# \df pg_terminate_backend
> List of functions
> -[ RECORD 1 ]-------+--------------------------------------
> Schema | pg_catalog
> Name | pg_terminate_backend
> Result data type | boolean
> Argument data types | pid integer, timeout bigint DEFAULT 0
> Type | func
>
> I also suggests that the timeout unit should be milliseconds, hence, using
> bigint is perfectly fine for the timeout argument.
>
> + <para>
> + Throws an ERROR if the target <acronym>lsn</acronym> was not replayed
> + on standby within given timeout. Parameter <parameter>timeout</parameter>
> + is the time in seconds to wait for the <parameter>target_lsn</parameter>
> + replay. When <parameter>timeout</parameter> value equals to zero no
> + timeout is applied.
> + </para></entry>
This generally makes sense, but I'm not sure about this. The
milliseconds timeout was used initially but received critics in [1].
Links.
1. https://www.postgresql.org/message-id/b45ff979-9d12-4828-a22a-e4cb327e115c%40eisentraut.org
------
Regards,
Alexander Korotkov
Attachment | Content-Type | Size |
---|---|---|
v14-0001-Implement-pg_wal_replay_wait-stored-procedure.patch | application/octet-stream | 24.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-03-29 12:46:33 | Re: Possibility to disable `ALTER SYSTEM` |
Previous Message | Bertrand Drouvot | 2024-03-29 12:21:32 | Re: Synchronizing slots from primary to standby |