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 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> [1] https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-RECOVERY-CONTROL -- Euler Taveira EDB https://www.enterprisedb.com/
