Message-ID: <be4f4c7c-2a8a-41c8-a926-ffd5d1d1ceb7@iki.fi>
Date: Mon, 4 Nov 2024 19:11:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: pgsql: Implement pg_wal_replay_wait() stored procedure
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
 Alexander Korotkov <aekorotkov@gmail.com>,
 Michael Paquier <michael@paquier.xyz>, Pavel Borisov
 <pashkin.elfe@gmail.com>, Peter Eisentraut <peter@eisentraut.org>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
References: 
 <CAPpHfdtp2giJtmoXcfyhAKu19=A5my53umR79W3nS0fb75HcyA@mail.gmail.com>
 <202411041419.qif3lqaisktw@alvherre.pgsql>
 <CA+Tgmobnk_CRhgmXkzmbfa4_1S6Sp6rvE2PhZn+TqagVSN-HyA@mail.gmail.com>
 <8d60e621-e971-458e-9e20-f5902c8c852a@iki.fi>
 <CA+TgmoaJ4=eq=6A9UMWH6vFuvOSE0Zy5-HN3RPP=58be6zA8Jw@mail.gmail.com>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: 
 <CA+TgmoaJ4=eq=6A9UMWH6vFuvOSE0Zy5-HN3RPP=58be6zA8Jw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/be4f4c7c-2a8a-41c8-a926-ffd5d1d1ceb7%40iki.fi>
Precedence: bulk

On 04/11/2024 18:53, Robert Haas wrote:
> On Mon, Nov 4, 2024 at 10:57 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>>> Maybe that's just a better fit and we don't need either a procedure
>>> or new syntax.
>> I think it would still be good to expose the feature at SQL level too.
>> Makes it easier to test and makes it usable without client library
>> changes, for example.
> 
> OK. Well then I agree with Álvaro. If using a procedure isn't working
> out nicely, it's better to consider alternatives than to force a round
> peg into a square hole (with due regard for the fact that you can fit
> anything through the square hole if you make the square hole big
> enough...).

Agreed. Off the top of my, summary of issues I'm aware of:

- Missing documentation. The function itself is documented, but it's 
clearly intended for implementing read-after-write consistency in a 
cluster setup, so we should document how to do that.
- Not clear to me what the use case for the 'timeout' and 'noerror' 
arguments is. Why do we need it at all? (See first point on missing docs).
- Separate pg_wal_replay_wait_status() function to get result status is 
awkward
- Inconsistencies in behavior if server is not in recovery (Alexander's 
latest patch addresses this, but I didn't review it yet)
- pg_wal_replay_wait_status() is incorrectly marked as STABLE and 
PARALLEL SAFE
- Broken with default_transaction_isolation ='repeatable read'

Let's revert commit e546989a26 and rethink. I think the basic 
pg_wal_replay_wait() interface before e546989a26 was fine. Some of the 
above are issues above were present before e546989a26 already and need 
to be addressed in any case, but I believe they can be fixed without 
changing the interface.

-- 
Heikki Linnakangas
Neon (https://neon.tech)