From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reducing power consumption on idle servers |
Date: | 2022-02-26 17:44:09 |
Message-ID: | 2222369.1645897449@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Deprecating explicit file-based promotion is possible and simple, so
>> that is the approach in the latest version of the patch.
> Is there any actual use-case for this other than backwards
> compatibility?
The fundamental problem with signal-based promotion is that it's
an edge-triggered rather than level-triggered condition, ie if you
miss the single notification event you're screwed. I'm not sure
why we'd want to go there, considering all the problems we're having
with edge-triggered APIs in nearby threads.
We could combine the two approaches, perhaps: have "pg_ctl promote"
create a trigger file and then send a signal. The trigger file
would record the existence of the promotion request, so that if the
postmaster isn't running right now or misses the signal, it'd still
promote when restarted or otherwise at the next opportunity.
But with an approach like this, we could expect quick response to
the signal in normal conditions, without need for constant wakeups
to check for the file. Also, this route would allow overloading
of the signal, since it would just mean "wake up, I asked you to
do something" rather than needing to carry the full semantics of
what is to be done.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-02-26 19:07:05 | Missed condition-variable wakeups on FreeBSD |
Previous Message | Magnus Hagander | 2022-02-26 17:14:56 | Re: Reducing power consumption on idle servers |