On Wed, Jan 25, 2023 at 2:10 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Thomas Munro <thomas.munro@gmail.com> writes:
> > Yeah, I definitely want to fix it. I just worry that 60s is so long
> > that it also needs that analysis work to be done to explain that it's
> > OK that we're a bit sloppy on noticing when to wake up, at which point
> > you might as well go to infinity.
>
> Yeah. The perfectionist in me wants to say that there should be
> explicit wakeups for every event of interest, in which case there's
> no need for a timeout. The engineer in me says "but what about bugs?".
> Better a slow reaction than never reacting at all. OTOH, then you
> have to have a discussion about whether 60s (or any other
> ice-cap-friendly value) is an acceptable response time even in the
> presence of bugs.
>
> It's kind of moot until we've reached the point where we can
> credibly claim to have explicit wakeups for every event of
> interest. I don't think we're very close to that today, and
> I do think we should try to get closer. There may come a point
> of diminishing returns though.
IIUC, we're discussing here whether or not to get rid of hibernate
loops, IOW, sleep-wakeup-doworkifthereisany-sleep loops and rely on
other processes' wakeup signals to reduce the overall power
consumption, am I right?
I'm trying to understand this a bit - can the signals (especially,
SIGURG that we use to set latches to wake up processes) ever get lost
on the way before reaching the target process? If yes, how? How
frequently can it happen? Is there any history of reported issues in
postgres because a signal got lost?
I'm reading about Pending Signals and queuing of signals with
sigqueue() (in linux), can any of these guarantee that signals sent
never get lost?
FWIW, a recent commit cd4329d that removed promote_trigger_file also
removed hibernation and added wait forever relying on the latch set.
If we're worried that the signals can get lost on the way, then this
also needs to be fixed. And, I also see lot of
WaitLatch() with waiting forever relying on others to wake them up.
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com