On Tue, Jul 06, 2021 at 05:07:04PM +0530, Bharath Rupireddy wrote:
> Thanks. Anyways, I removed WL_LATCH_SET for PreAuthDelay as
> well. PSA v4 patch.
For the moment, please note that I have marked the patch as committed
in the CF app. It may be better to start a new thread with the
remaining
On Tue, Jul 6, 2021 at 4:33 PM Michael Paquier wrote:
>
> On Tue, Jul 06, 2021 at 03:54:07PM +0530, Bharath Rupireddy wrote:
> > Thanks. You are right. The issue is due to the MyLatch being set by
> > SwitchToSharedLatch before WaitLatch. If we use (WL_TIMEOUT |
> > WL_EXIT_ON_PM_DEATH), then the
On Tue, Jul 06, 2021 at 03:54:07PM +0530, Bharath Rupireddy wrote:
> Thanks. You are right. The issue is due to the MyLatch being set by
> SwitchToSharedLatch before WaitLatch. If we use (WL_TIMEOUT |
> WL_EXIT_ON_PM_DEATH), then the backends will honour the
> post_auth_delay as well as detect the
On Tue, Jul 6, 2021 at 1:38 PM Michael Paquier wrote:
>
> On Tue, Jul 06, 2021 at 12:42:21PM +0530, Bharath Rupireddy wrote:
> > I'm sorry to say that I didn't get what was said above. We reset the
> > latch after we come out of WaitLatch but not before going to wait. And
> > the reason to have
On Tue, Jul 06, 2021 at 12:42:21PM +0530, Bharath Rupireddy wrote:
> I'm sorry to say that I didn't get what was said above. We reset the
> latch after we come out of WaitLatch but not before going to wait. And
> the reason to have WL_LATCH_SET, is to exit the wait loop if MyLatch
> is set for
On Tue, Jul 6, 2021 at 6:15 AM Michael Paquier wrote:
> On Mon, Jul 05, 2021 at 09:42:29PM +0530, Bharath Rupireddy wrote:
> > I agree. I'm attaching the patch that replaces pg_usleep with
> > WaitLatch for {pre, post}_auth_delay. I'm also attaching Michael's
> > latest patch
On Mon, Jul 05, 2021 at 09:42:29PM +0530, Bharath Rupireddy wrote:
> I agree. I'm attaching the patch that replaces pg_usleep with
> WaitLatch for {pre, post}_auth_delay. I'm also attaching Michael's
> latest patch stop-backup-latch-v2.patch, just for the sake of cfbot.
I don't object to the
On Mon, Jul 5, 2021 at 9:25 PM Stephen Frost wrote:
> In general, I agree with Tom's up-thread comment about children hanging
> around after postmaster death making things more difficult for debugging
> and just in general, so I'm in favor of trying to eliminate as many
> cases where that's
On Mon, Jul 5, 2021 at 7:33 AM Michael Paquier wrote:
>
> On Fri, Jul 02, 2021 at 12:03:07PM +0530, Bharath Rupireddy wrote:
> > My bad. I was talking about the cases when do_pg_stop_backup is called
> > while the server is in recovery mode i.e. backup_started_in_recovery =
> >
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Fri, Jul 02, 2021 at 12:03:07PM +0530, Bharath Rupireddy wrote:
> > My bad. I was talking about the cases when do_pg_stop_backup is called
> > while the server is in recovery mode i.e. backup_started_in_recovery =
> >
At Fri, 2 Jul 2021 10:27:21 +0900, Michael Paquier wrote
in
> On Mon, Jun 28, 2021 at 11:01:57AM -0400, Tom Lane wrote:
> > Dunno ... I cannot recall ever having had that as a debugging requirement
> > in a couple of decades worth of PG bug-chasing. If the postmaster is
> > dying, you
On Fri, Jul 02, 2021 at 12:03:07PM +0530, Bharath Rupireddy wrote:
> My bad. I was talking about the cases when do_pg_stop_backup is called
> while the server is in recovery mode i.e. backup_started_in_recovery =
> RecoveryInProgress(); evaluates to true. I'm not sure in these cases
> whether we
On Fri, Jul 2, 2021 at 9:53 AM Michael Paquier wrote:
>
> On Mon, Jun 28, 2021 at 08:21:06PM +0530, Bharath Rupireddy wrote:
> > The recoveryWakeupLatch and procLatch/MyLatch are being used for WAL
> > replay and recovery conflict, respectively. Actually, I was earlier
> > using
On Mon, Jun 28, 2021 at 08:21:06PM +0530, Bharath Rupireddy wrote:
> The recoveryWakeupLatch and procLatch/MyLatch are being used for WAL
> replay and recovery conflict, respectively. Actually, I was earlier
> using procLatch/MyLatch, but came across the commit 00f690a23 which
> says that the two
On Mon, Jun 28, 2021 at 11:01:57AM -0400, Tom Lane wrote:
> Dunno ... I cannot recall ever having had that as a debugging requirement
> in a couple of decades worth of PG bug-chasing. If the postmaster is
> dying, you generally want to deal with that before bothering with child
> processes.
Bharath Rupireddy writes:
> On Thu, Jun 24, 2021 at 12:04 PM Michael Paquier wrote:
>> On top of that, not reacting on signals can be
>> interesting to keep as a behavior for developers?
> Yeah, it can be useful at times as it enables debugging even when the
> postmaster dies.
Dunno ... I
On Thu, Jun 24, 2021 at 12:04 PM Michael Paquier wrote:
>
> On Tue, Apr 20, 2021 at 07:36:39AM +0530, Bharath Rupireddy wrote:
> > I'm attaching 3 patches that replace pg_usleep with WaitLatch: 0001 in
> > lazy_truncate_heap, 0002 in do_pg_stop_backup and 0003 for Pre and
> > Post Auth Delay.
On Tue, Apr 20, 2021 at 07:36:39AM +0530, Bharath Rupireddy wrote:
> I'm attaching 3 patches that replace pg_usleep with WaitLatch: 0001 in
> lazy_truncate_heap, 0002 in do_pg_stop_backup and 0003 for Pre and
> Post Auth Delay. Regression tests pass with these patches. Please
> review them.
+
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
This patch looks fine. Tested on MacOS Catalina; master
On Tue, Apr 20, 2021 at 7:36 AM Bharath Rupireddy
wrote:
>
> On Thu, Apr 15, 2021 at 11:48 AM Bharath Rupireddy
> wrote:
> > > We definitely have replaced a lot of sleeps with latch.c primitives
> > > over the past few years, since we got WL_EXIT_ON_PM_DEATH and
> > > condition variables. There
On Thu, Apr 15, 2021 at 11:48 AM Bharath Rupireddy
wrote:
> > We definitely have replaced a lot of sleeps with latch.c primitives
> > over the past few years, since we got WL_EXIT_ON_PM_DEATH and
> > condition variables. There may be many more to improve... You
> > mentioned autovacuum... yeah,
On Thu, Apr 15, 2021 at 5:28 AM Thomas Munro wrote:
Thanks a lot for the detailed explanation.
> On Thu, Apr 15, 2021 at 2:06 AM Bharath Rupireddy
> wrote:
> > 1) Is it really harmful to use pg_usleep in a postmaster child process
> > as it doesn't let the child process detect postmaster
Hi Bharath,
On Thu, Apr 15, 2021 at 2:06 AM Bharath Rupireddy
wrote:
> 1) Is it really harmful to use pg_usleep in a postmaster child process
> as it doesn't let the child process detect postmaster death?
Yeah, that's a bad idea. Any long-term waiting (including short waits
in a loop) should
Hi,
In my dev system(Ubuntu) when the postmaster is killed with SIGKILL,
SIGPWR is being sent to its child processes (backends/any other bg
process). If a child process is waiting with pg_usleep, it looks like
it is not detecting the postmaster's death and it doesn't exit
immediately but stays
24 matches
Mail list logo
