On Mon, Oct 28, 2024 at 5:47 PM Robert Haas wrote:
> Point of order:
>
> Discussions of commits and potential followup commits are best
> redirected to -hackers rather than continuing to use -committers.
Thank you for pointing this.
My response to Heikki's last message will be redirected to -hack
Point of order:
Discussions of commits and potential followup commits are best
redirected to -hackers rather than continuing to use -committers.
...Robert
On 25/10/2024 14:56, Alexander Korotkov wrote:
I see that pg_wal_replay_wait_status() might look weird, but it seems
to me like the best of feasible solutions.
I haven't written many procedures, but our docs say:
> Procedures do not return a function value; hence CREATE PROCEDURE
lacks a RET
Hi, Heikki!
On Fri, Oct 25, 2024 at 9:06 AM Heikki Linnakangas wrote:
> If you call this procedure on a stand-alone server, you get:
>
> postgres=# call pg_wal_replay_wait('1234/0');
> ERROR: recovery is not in progress
> DETAIL: Recovery ended before replaying target LSN 1234/0; last replay
>
If you call this procedure on a stand-alone server, you get:
postgres=# call pg_wal_replay_wait('1234/0');
ERROR: recovery is not in progress
DETAIL: Recovery ended before replaying target LSN 1234/0; last replay
LSN 0/0.
The DETAIL seems a bit misleading. Recovery never ended, because it
n
On Wed, Oct 23, 2024 at 9:02 AM Pavel Borisov wrote:
> On Wed, 23 Oct 2024 at 00:12, Alexander Korotkov wrote:
>> Thank you for your review.
>>
>> On Tue, Oct 22, 2024 at 4:30 PM Pavel Borisov wrote:
>> > On Tue, 22 Oct 2024 at 13:26, Alexander Korotkov
>> > wrote:
>> >>
>> >> On Wed, Oct 16,
Hi, Alexander!
On Wed, 23 Oct 2024 at 00:12, Alexander Korotkov
wrote:
> Hi, Pavel!
>
> Thank you for your review.
>
> On Tue, Oct 22, 2024 at 4:30 PM Pavel Borisov
> wrote:
> > On Tue, 22 Oct 2024 at 13:26, Alexander Korotkov
> wrote:
> >>
> >> On Wed, Oct 16, 2024 at 11:20 PM Alexander Korot
Hi, Pavel!
Thank you for your review.
On Tue, Oct 22, 2024 at 4:30 PM Pavel Borisov wrote:
> On Tue, 22 Oct 2024 at 13:26, Alexander Korotkov wrote:
>>
>> On Wed, Oct 16, 2024 at 11:20 PM Alexander Korotkov
>> wrote:
>> >
>> > On Wed, Oct 16, 2024 at 10:35 PM Peter Eisentraut
>> > wrote:
>>
Fix a typo of myself:
> Maybe refactoring for loop for assigning result variable and breaking a
> loop instead of immediate return would look better and lead to natural call
> of after the loop before returning.
>
Maybe refactoring for loop for assigning result variable and breaking a
loop instea
Hi, Alexander!
On Tue, 22 Oct 2024 at 13:26, Alexander Korotkov
wrote:
> On Wed, Oct 16, 2024 at 11:20 PM Alexander Korotkov
> wrote:
> >
> > On Wed, Oct 16, 2024 at 10:35 PM Peter Eisentraut
> wrote:
> > > On 02.09.24 01:55, Alexander Korotkov wrote:
> > > > On Mon, Sep 2, 2024 at 2:28 AM Mic
On Wed, Oct 16, 2024 at 11:20 PM Alexander Korotkov
wrote:
>
> On Wed, Oct 16, 2024 at 10:35 PM Peter Eisentraut
> wrote:
> > On 02.09.24 01:55, Alexander Korotkov wrote:
> > > On Mon, Sep 2, 2024 at 2:28 AM Michael Paquier
> > > wrote:
> > >> On Sun, Sep 01, 2024 at 10:35:27PM +0300, Alexande
On Wed, Oct 16, 2024 at 10:35 PM Peter Eisentraut wrote:
> On 02.09.24 01:55, Alexander Korotkov wrote:
> > On Mon, Sep 2, 2024 at 2:28 AM Michael Paquier wrote:
> >> On Sun, Sep 01, 2024 at 10:35:27PM +0300, Alexander Korotkov wrote:
> >>> This path hasn't changes since the patch revision when i
On 02.09.24 01:55, Alexander Korotkov wrote:
On Mon, Sep 2, 2024 at 2:28 AM Michael Paquier wrote:
On Sun, Sep 01, 2024 at 10:35:27PM +0300, Alexander Korotkov wrote:
This path hasn't changes since the patch revision when it was a
utility command. I agree that this doesn't look like proper pa
Hi!
On Sun, Sep 29, 2024 at 1:40 PM Alexander Korotkov wrote:
>
> Thank you for your review.
>
> On Fri, Sep 27, 2024 at 7:35 AM Michael Paquier wrote:
> >
> > On Fri, Sep 20, 2024 at 03:00:20PM +0300, Alexander Korotkov wrote:
> > > Please, check the attached patchset for implementation of prop
Hi!
Thank you for your review.
On Fri, Sep 27, 2024 at 7:35 AM Michael Paquier wrote:
>
> On Fri, Sep 20, 2024 at 03:00:20PM +0300, Alexander Korotkov wrote:
> > Please, check the attached patchset for implementation of proposed approach.
>
> 0001 looks like it requires an indentation in its .h
On Fri, Sep 27, 2024 at 7:57 AM Michael Paquier wrote:
> On Fri, Sep 27, 2024 at 01:35:23PM +0900, Michael Paquier wrote:
> > I would suggest to keep things simple and have one single function
> > rather than introduce two more pg_proc entries with slight differences
> > in their error reporting,
On Fri, Sep 27, 2024 at 01:35:23PM +0900, Michael Paquier wrote:
> I would suggest to keep things simple and have one single function
> rather than introduce two more pg_proc entries with slight differences
> in their error reporting, making the original function return a text
> about the reason of
On Fri, Sep 20, 2024 at 03:00:20PM +0300, Alexander Korotkov wrote:
> Please, check the attached patchset for implementation of proposed approach.
0001 looks like it requires an indentation in its .h diffs.
+typedef enum
+{
+ WaitLSNResultSuccess, /* Target LSN is reached */
+ WaitLSN
On Thu, Sep 26, 2024 at 06:41:18PM +0300, Alexander Korotkov wrote:
> On Thu, Sep 26, 2024 at 11:19 AM Michael Paquier wrote:
>> Please use something in the 8000- range, as required by
>> 98eab30b93d5.
>
> Fixed, sorry for messing this up.
Thanks for taking care of that.
> I would appreciat
On Thu, Sep 26, 2024 at 11:19 AM Michael Paquier wrote:
> On Fri, Aug 02, 2024 at 06:22:21PM +, Alexander Korotkov wrote:
> > Implement pg_wal_replay_wait() stored procedure
> >
> > pg_wal_replay_wait() is to be used on standby and specifies waiting for
> > the specific WAL location to be repl
Hi Alexander,
On Fri, Aug 02, 2024 at 06:22:21PM +, Alexander Korotkov wrote:
> Implement pg_wal_replay_wait() stored procedure
>
> pg_wal_replay_wait() is to be used on standby and specifies waiting for
> the specific WAL location to be replayed. This option is useful when
> the user makes
On Thu, Sep 19, 2024 at 3:47 PM Alexander Korotkov wrote:
> On Tue, Sep 3, 2024 at 4:07 PM Alexander Korotkov
> wrote:
> > On the other hand, I see that returning status could make sense for
> > certain use cases. I think I could write two patches to provide that.
> > 1. Make WaitForLSNReplay()
On Tue, Sep 3, 2024 at 4:07 PM Alexander Korotkov wrote:
> On the other hand, I see that returning status could make sense for
> certain use cases. I think I could write two patches to provide that.
> 1. Make WaitForLSNReplay() return status, and make pg_wal_replay_wal()
> be responsible for thro
On Tue, Sep 3, 2024 at 4:07 PM Alexander Korotkov wrote:
> If no objections, I will push the patch moving code then go ahead
> writing the two patches above.
The patch for code movement missed couple of includes. Revised
version is attached.
--
Regards,
Alexander Korotkov
Supabase
v2-0001
Hi, Michael!
On Mon, Sep 2, 2024 at 3:25 AM Michael Paquier wrote:
>
> On Mon, Sep 02, 2024 at 02:55:50AM +0300, Alexander Korotkov wrote:
> > Could you, please, check the attached patch?
>
> The patch moving the code looks correct at quick glance.
Thank you for your feedback.
> Now, I've been
On Mon, Sep 02, 2024 at 02:55:50AM +0300, Alexander Korotkov wrote:
> Could you, please, check the attached patch?
The patch moving the code looks correct at quick glance.
Now, I've been staring at this line, wondering why this is required
while WaitForLSNReplay() does not return any status:
+
On Mon, Sep 2, 2024 at 2:28 AM Michael Paquier wrote:
> On Sun, Sep 01, 2024 at 10:35:27PM +0300, Alexander Korotkov wrote:
> > This path hasn't changes since the patch revision when it was a
> > utility command. I agree that this doesn't look like proper path for
> > stored procedure. But I don
On Sun, Sep 01, 2024 at 10:35:27PM +0300, Alexander Korotkov wrote:
> This path hasn't changes since the patch revision when it was a
> utility command. I agree that this doesn't look like proper path for
> stored procedure. But I don't think src/backend/utils/adt is
> appropriate path either, be
On Fri, Aug 30, 2024 at 10:42 PM Peter Eisentraut wrote:
> On 02.08.24 20:22, Alexander Korotkov wrote:
> > Implement pg_wal_replay_wait() stored procedure
>
> Why is this under src/backend/command/? Wouldn't it belong under
> src/backend/utils/adt/?
This path hasn't changes since the patch revi
On 02.08.24 20:22, Alexander Korotkov wrote:
Implement pg_wal_replay_wait() stored procedure
Why is this under src/backend/command/? Wouldn't it belong under
src/backend/utils/adt/?
pg_wal_replay_wait() is to be used on standby and specifies waiting for
the specific WAL location to be repl
Implement pg_wal_replay_wait() stored procedure
pg_wal_replay_wait() is to be used on standby and specifies waiting for
the specific WAL location to be replayed. This option is useful when
the user makes some data changes on primary and needs a guarantee to see
these changes are on standby.
The
Hi,
On Wed, Apr 3, 2024 at 4:58 AM Alexander Korotkov
wrote:
>
> Implement pg_wal_replay_wait() stored procedure
>
> pg_wal_replay_wait() is to be used on standby and specifies waiting for
> the specific WAL location to be replayed before starting the transaction.
> This option is useful when the
On Wed, Apr 3, 2024 at 9:42 AM Alexander Korotkov wrote:
> On Tue, Apr 2, 2024 at 10:58 PM Alexander Korotkov
> wrote:
> > Implement pg_wal_replay_wait() stored procedure
>
> I'm trying to figure out if this failure could be related to this commit...
> https://buildfarm.postgresql.org/cgi-bin/sho
On Wed, 3 Apr 2024 at 09:42, Alexander Korotkov wrote:
> I'm trying to figure out if this failure could be related to this commit...
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=culicidae&dt=2024-04-02%2020%3A24%3A55
Yeah, I think it is.
The problem is that in WaitLSNSetLatches() wa
On Tue, Apr 2, 2024 at 10:58 PM Alexander Korotkov
wrote:
> Implement pg_wal_replay_wait() stored procedure
I'm trying to figure out if this failure could be related to this commit...
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=culicidae&dt=2024-04-02%2020%3A24%3A55
--
Regards,
A
Implement pg_wal_replay_wait() stored procedure
pg_wal_replay_wait() is to be used on standby and specifies waiting for
the specific WAL location to be replayed before starting the transaction.
This option is useful when the user makes some data changes on primary and
needs a guarantee to see thes
36 matches
Mail list logo
