On Wed, Jul 19, 2023 at 01:46:02PM +0530, Bharath Rupireddy wrote:
> Printing LSN on signal exit won't be correct - if signal is received
> before cur_record_lsn gets assigned, we will be showing an old LSN if
> it was previously assigned or invalid LSN if it wasn't assigned
> previously. Signal
On Wed, Jul 19, 2023 at 01:33:15PM +0530, Bharath Rupireddy wrote:
> I think the delay is expected for the reason specified below and is
> not because of any of the changes in v5. As far as CTRL+C is
> concerned, it is a clean exit and hence we can't escape the while(1)
> loop.
Yes, that's also
On Wed, Jul 19, 2023 at 1:41 PM Michael Paquier wrote:
>
> > 3. pg_log_info("end position %X/%X reached on signal", For
> > signal, end position is a bit vague wording and I think we can just
> > say pg_log_info("received interrupt signal, exiting"); like
> > pg_receivewal. We really can't
On Wed, Jul 19, 2023 at 12:07:21PM +0530, Bharath Rupireddy wrote:
> 1. I don't think we need a stop_lsn variable, the cur_record_lsn can
> help if it's defined outside the loop. With this, the patch can
> further be simplified as attached v6.
Okay by me.
> 2. And, I'd prefer not to assume the
On Wed, Jul 19, 2023 at 12:07 PM Bharath Rupireddy
wrote:
>
> 4. With v5, it was taking a while to exit after the first CTRL+C, see
> multiple CTRL+Cs at the end:
> ubuntu::~/postgres/inst/bin$ ./pg_recvlogical --slot=lsub1_repl_slot
> --file=lsub1.data --start --verbose
> pg_recvlogical:
On Wed, Jul 19, 2023 at 8:04 AM Michael Paquier wrote:
>
> It took me some time to come back to this one, but attached is what I
> had in mind. This stuff has three reasons to stop: keepalive, end LSN
> or signal. This makes the code easier to follow.
>
> Thoughts or comments?
Thanks. I have
On Mon, Jul 10, 2023 at 01:44:45PM +0900, Michael Paquier wrote:
> As StreamLogicalLog() states once it leaves its main loop because
> time_to_abort has been switched to true, we want a clean exit. I
> think that this patch is just a more complicated way to avoid doing
> twice the operations done
On Thu, Jul 06, 2023 at 10:29:10AM -0500, Tristan Partin wrote:
> On Thu Apr 27, 2023 at 12:54 AM CDT, Bharath Rupireddy wrote:
>> Why do we need both time_to_abort and ready_to_exit?
>
> I am trying to understand why we need both as well. Maybe I am missing
> something important :).
As
On Thu Apr 27, 2023 at 12:54 AM CDT, Bharath Rupireddy wrote:
> Thanks for reviewing. I removed the (void) casts like elsewhere in the
> code, however, I didn't change such casts in prepareToTerminate() to
> not create a diff.
>
> I'm attaching the v4 patch for further review.
Bharath,
I signed
On Thu, Apr 27, 2023 at 11:24:52AM +0530, Bharath Rupireddy wrote:
> IMO, +1 for HEAD/PG16 and +0.5 for backpatching as it may not be so
> critical to backpatch all the way down. What may happen without this
> patch is that the output file isn't fsync-ed upon SIGINT/SIGTERM.
> Well, is it a
On Tue, Apr 11, 2023 at 11:42 AM Michael Paquier wrote:
>
> On Mon, Oct 24, 2022 at 08:15:11AM +0530, Bharath Rupireddy wrote:
> > The attached patch (pg_recvlogical_graceful_interrupt.text) has a
> > couple of problems, I believe. We're losing prepareToTerminate() with
> > keepalive true and
On Mon, Oct 24, 2022 at 08:15:11AM +0530, Bharath Rupireddy wrote:
> The attached patch (pg_recvlogical_graceful_interrupt.text) has a
> couple of problems, I believe. We're losing prepareToTerminate() with
> keepalive true and we're not skipping pg_log_error("unexpected
> termination of
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Hello
The patch applies and tests fine. I like the way to have
On Fri, Oct 28, 2022 at 4:41 AM Andres Freund wrote:
>
> On 2022-10-24 08:15:11 +0530, Bharath Rupireddy wrote:
>
>
> > + /* When we get SIGINT/SIGTERM, we exit */
> > + if (ready_to_exit)
> > + {
> > + /*
> > + * Try
Hi,
On 2022-10-24 08:15:11 +0530, Bharath Rupireddy wrote:
> I came up with the attached v2 patch, please have a look.
Thanks for working on this!
> + /* When we get SIGINT/SIGTERM, we exit */
> + if (ready_to_exit)
> + {
> + /*
> +
On Mon, Oct 24, 2022 at 8:15 AM Bharath Rupireddy
wrote:
>
> On Fri, Oct 21, 2022 at 7:52 AM Kyotaro Horiguchi
> wrote:
> >
> > > +1. How about emitting a message like its friend pg_receivewal, like
> > > the attached patch?
> >
> > I'm not a fan of treating SIGINT as an error in this case. It
On Fri, Oct 21, 2022 at 7:52 AM Kyotaro Horiguchi
wrote:
>
> > +1. How about emitting a message like its friend pg_receivewal, like
> > the attached patch?
>
> I'm not a fan of treating SIGINT as an error in this case. It calls
> prepareToTerminate() when time_to_abort and everything goes fine
At Thu, 20 Oct 2022 13:28:45 +0530, Bharath Rupireddy
wrote in
> On Thu, Oct 20, 2022 at 3:10 AM Andres Freund wrote:
> >
> > Hi,
> >
> > While reviewing
> > https://postgr.es/m/CAD21AoBe2o2D%3Dxyycsxw2bQOD%3DzPj7ETuJ5VYGN%3DdpoTiCMRJQ%40mail.gmail.com
> > I noticed that pg_recvlogical prints
On Thu, Oct 20, 2022 at 3:10 AM Andres Freund wrote:
>
> Hi,
>
> While reviewing
> https://postgr.es/m/CAD21AoBe2o2D%3Dxyycsxw2bQOD%3DzPj7ETuJ5VYGN%3DdpoTiCMRJQ%40mail.gmail.com
> I noticed that pg_recvlogical prints
> "pg_recvlogical: error: unexpected termination of replication stream: "
>
>
Hi,
While reviewing
https://postgr.es/m/CAD21AoBe2o2D%3Dxyycsxw2bQOD%3DzPj7ETuJ5VYGN%3DdpoTiCMRJQ%40mail.gmail.com
I noticed that pg_recvlogical prints
"pg_recvlogical: error: unexpected termination of replication stream: "
when signalled with SIGINT/TERM.
Oddly enough, that looks to have
20 matches
Mail list logo
