On Fri, Jan 27, 2023 at 12:41 PM Thomas Munro wrote:
>
> There's also the walwriter to look into; from memory it was a little
> less fuzzy but I haven't looked recently.
Thanks. I tried to do away with the walwriter hibernation for just
some time and made it wait indefinitely until an event occur
On Fri, Jan 27, 2023 at 7:37 PM Bharath Rupireddy
wrote:
> On Wed, Jan 25, 2023 at 2:10 AM Tom Lane wrote:
> > 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, a
On Wed, Jan 25, 2023 at 2:10 AM Tom Lane wrote:
>
> Thomas Munro 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
>
Thomas Munro 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
On Wed, Nov 30, 2022 at 7:40 PM Simon Riggs
wrote:
> On Wed, 30 Nov 2022 at 03:50, Thomas Munro wrote:
> > I'm just curious, and not suggesting that 60s wakeups are a problem
> > for the polar ice caps, but why even time out at all? Are the latch
> > protocols involved not reliable enough? At a
On Wed, 30 Nov 2022 at 03:50, Thomas Munro wrote:
>
> On Wed, Nov 30, 2022 at 1:32 AM Simon Riggs
> wrote:
> > Re-attaching patch for bgwriter and walwriter, so it is clear this is
> > not yet committed.
>
> I'm just curious, and not suggesting that 60s wakeups are a problem
> for the polar ice c
On Wed, Nov 30, 2022 at 1:32 AM Simon Riggs
wrote:
> Re-attaching patch for bgwriter and walwriter, so it is clear this is
> not yet committed.
I'm just curious, and not suggesting that 60s wakeups are a problem
for the polar ice caps, but why even time out at all? Are the latch
protocols involv
On Sun, 20 Nov 2022 at 20:00, Simon Riggs wrote:
>
> On Thu, 24 Mar 2022 at 16:21, Robert Haas wrote:
> >
> > On Thu, Mar 24, 2022 at 12:02 PM Simon Riggs
>
> > > What changes will be acceptable for bgwriter, walwriter and logical
> > > worker?
> >
> > Hmm, I think it would be fine to introduce
On Mon, 28 Nov 2022 at 23:16, Thomas Munro wrote:
>
> I found some more comments and some documentation to word-smith very
> lightly, and pushed.
Thanks
> The comments were stray references to the
> trigger file. It's
> a little confusing because the remaining mechanism also uses a file,
> but
I found some more comments and some documentation to word-smith very
lightly, and pushed. The comments were stray references to the
trigger file. It's
a little confusing because the remaining mechanism also uses a file,
but it uses a signal first so seems better to refer to promotion
requests rat
Robert Haas writes:
> I think we should remove those mentions. Otherwise the documentation
> just collects mentions of an increasing number of things that are no
> longer relevant.
Yeah, I think the same. There will be a release-note entry, and
I don't object to having something about it in appe
On Sun, Nov 27, 2022 at 6:57 PM Thomas Munro wrote:
> The main documentation of pg_promote() etc now has "The parameter
> promote_trigger_file has been removed" in the
> places where the GUC was previously mentioned. Perhaps we should just
> remove the mentions completely (it's somehow either too
On Mon, Nov 28, 2022 at 5:27 AM Thomas Munro wrote:
>
> "The trigger_file and promote_trigger_file have been removed." was
> missing some words. I've also added a sentence to say which releases
> were involved, to make it like nearby paragraphs about other obsolete
> stuff.
LGTM.
> The funny th
On Sun, Nov 27, 2022 at 6:15 PM Ian Lawrence Barwick wrote:
> 2022年11月22日(火) 5:50 Laurenz Albe :
> > On Mon, 2022-11-21 at 12:11 -0500, Tom Lane wrote:
> > > Robert Haas writes:
> > > > The reason that I pushed back -- not as successfully as I would have
> > > > liked -- on the changes to pg_stop
2022年11月22日(火) 5:50 Laurenz Albe :
>
> On Mon, 2022-11-21 at 12:11 -0500, Tom Lane wrote:
> > Robert Haas writes:
> > > The reason that I pushed back -- not as successfully as I would have
> > > liked -- on the changes to pg_stop_backup / pg_start_backup is that I
> > > know there are people using
On Mon, 2022-11-21 at 12:11 -0500, Tom Lane wrote:
> Robert Haas writes:
> > The reason that I pushed back -- not as successfully as I would have
> > liked -- on the changes to pg_stop_backup / pg_start_backup is that I
> > know there are people using the old method successfully, and it's not
> >
Robert Haas writes:
> The reason that I pushed back -- not as successfully as I would have
> liked -- on the changes to pg_stop_backup / pg_start_backup is that I
> know there are people using the old method successfully, and it's not
> just a 1:1 substitution. Here I don't, and it is. I'm totally
On Mon, Nov 21, 2022 at 3:40 AM Laurenz Albe wrote:
> We have had a deprecation period? I looked at the documentation, but found
> no mention of a deprecation. How hard can it be to leave the GUC and only
> poll for the existence of the file if it is set?
>
> I personally don't need the GUC, and
On Mon, 21 Nov 2022 at 08:40, Laurenz Albe wrote:
>
> On Mon, 2022-11-21 at 07:36 +, Simon Riggs wrote:
> > On Mon, 21 Nov 2022 at 05:07, Laurenz Albe wrote:
> > >
> > > On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote:
> > > > I'll wait 24 hours before committing, to
> > > > provide a l
On Mon, 2022-11-21 at 07:36 +, Simon Riggs wrote:
> On Mon, 21 Nov 2022 at 05:07, Laurenz Albe wrote:
> >
> > On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote:
> > > I'll wait 24 hours before committing, to
> > > provide a last chance for anyone who wants to complain about dropping
> > >
On Mon, 2022-11-21 at 11:42 +0530, Bharath Rupireddy wrote:
> On Mon, Nov 21, 2022 at 10:37 AM Laurenz Albe
> wrote:
> >
> > On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote:
> > > I'll wait 24 hours before committing, to
> > > provide a last chance for anyone who wants to complain about dr
On Sun, 20 Nov 2022 at 22:55, Nathan Bossart wrote:
>
> On Mon, Nov 21, 2022 at 10:31:15AM +1300, Thomas Munro wrote:
> > On Mon, Nov 21, 2022 at 9:00 AM Simon Riggs
> > wrote:
> >> As a 3rd patch, I will work on making logical workers hibernate.
> >
> > Duelling patch warning: Nathan mentioned[1
On Mon, 21 Nov 2022 at 05:07, Laurenz Albe wrote:
>
> On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote:
> > I'll wait 24 hours before committing, to
> > provide a last chance for anyone who wants to complain about dropping
> > promote_trigger_file.
>
> Remove "promote_trigger_file"? Now I ha
On Mon, Nov 21, 2022 at 2:43 AM Thomas Munro wrote:
>
> On Mon, Nov 21, 2022 at 3:35 AM Simon Riggs
> wrote:
> > On Sat, 19 Nov 2022 at 10:59, Simon Riggs
> > wrote:
> > > New version attached.
> >
> > Fix for doc xref
>
> I removed a stray variable declaration from xlogrecovery.h, and wrote
>
On Mon, Nov 21, 2022 at 10:37 AM Laurenz Albe wrote:
>
> On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote:
> > I'll wait 24 hours before committing, to
> > provide a last chance for anyone who wants to complain about dropping
> > promote_trigger_file.
>
> Remove "promote_trigger_file"? Now I
On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote:
> I'll wait 24 hours before committing, to
> provide a last chance for anyone who wants to complain about dropping
> promote_trigger_file.
Remove "promote_trigger_file"? Now I have never seen anybody use that
parameter, but I don't think that
On Mon, Nov 21, 2022 at 10:31:15AM +1300, Thomas Munro wrote:
> On Mon, Nov 21, 2022 at 9:00 AM Simon Riggs
> wrote:
>> As a 3rd patch, I will work on making logical workers hibernate.
>
> Duelling patch warning: Nathan mentioned[1] that he's hacking on a
> patch for that, along the lines of the
On Mon, Nov 21, 2022 at 9:00 AM Simon Riggs
wrote:
> As a 3rd patch, I will work on making logical workers hibernate.
Duelling patch warning: Nathan mentioned[1] that he's hacking on a
patch for that, along the lines of the recent walreceiver change IIUC.
[1]
https://www.postgresql.org/message-
On Mon, Nov 21, 2022 at 3:35 AM Simon Riggs
wrote:
> On Sat, 19 Nov 2022 at 10:59, Simon Riggs
> wrote:
> > New version attached.
>
> Fix for doc xref
I removed a stray variable declaration from xlogrecovery.h, and wrote
a draft commit message. I'll wait 24 hours before committing, to
provide
On Thu, 24 Mar 2022 at 16:21, Robert Haas wrote:
>
> On Thu, Mar 24, 2022 at 12:02 PM Simon Riggs
> > What changes will be acceptable for bgwriter, walwriter and logical worker?
>
> Hmm, I think it would be fine to introduce some kind of hibernation
> mechanism for logical workers. bgwriter and w
On Sat, 19 Nov 2022 at 10:59, Simon Riggs wrote:
> New version attached.
Fix for doc xref
--
Simon Riggshttp://www.EnterpriseDB.com/
hibernate_startup.v10.patch
Description: Binary data
On Fri, 18 Nov 2022 at 20:26, Thomas Munro wrote:
>
> On Sat, Nov 19, 2022 at 7:54 AM Simon Riggs
> wrote:
> > I agree. I can't see a reason to keep it anymore.
>
> +Use of promote_trigger_file is deprecated. If you're
>
> I think 'deprecated' usually implies that it still works but you
> sho
On Sat, Nov 19, 2022 at 7:54 AM Simon Riggs
wrote:
> I agree. I can't see a reason to keep it anymore.
+Use of promote_trigger_file is deprecated. If you're
I think 'deprecated' usually implies that it still works but you
should avoid it. I think you need something stronger.
> I'm nervous
On Thu, 17 Nov 2022 at 20:38, Robert Haas wrote:
>
> On Thu, Nov 17, 2022 at 2:55 AM Simon Riggs
> wrote:
> > No, it will have a direct effect only on people using promote_trigger_file
> > who do not read and act upon the deprecation notice before upgrading
> > by making a one line change to thei
On Fri, 18 Nov 2022 at 08:55, Bharath Rupireddy
wrote:
> However, I'm a bit
> worried about how it'll affect the tools/providers/extensions that
> depend on it.
Who is that? Which ones depend upon it?
--
Simon Riggshttp://www.EnterpriseDB.com/
On Fri, Nov 18, 2022 at 2:08 AM Robert Haas wrote:
>
> On Thu, Nov 17, 2022 at 2:55 AM Simon Riggs
> wrote:
> > No, it will have a direct effect only on people using promote_trigger_file
> > who do not read and act upon the deprecation notice before upgrading
> > by making a one line change to th
On Fri, Nov 18, 2022 at 6:29 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-11-17 13:06:23 +0530, Bharath Rupireddy wrote:
> > I understand. I know it's a bit hard to measure the power savings, I'm
> > wondering if there's any info, maybe not necessarily related to
> > postgres, but in general how mu
Hi,
On 2022-11-17 13:06:23 +0530, Bharath Rupireddy wrote:
> I understand. I know it's a bit hard to measure the power savings, I'm
> wondering if there's any info, maybe not necessarily related to
> postgres, but in general how much power gets saved if a certain number
> of waits/polls/system cal
On Thu, Nov 17, 2022 at 2:55 AM Simon Riggs
wrote:
> No, it will have a direct effect only on people using promote_trigger_file
> who do not read and act upon the deprecation notice before upgrading
> by making a one line change to their failover scripts.
TBH, I wonder if we shouldn't just nuke p
On Thu, 17 Nov 2022 at 07:36, Bharath Rupireddy
wrote:
> > promote_trigger_file is not tested and there are better ways, so
> > deprecating it in this release is fine.
>
> Hm, but..
>
> > Anyone that relies on it can update their mechanisms to a supported
> > one with a one-line change. Realistic
On Wed, Nov 16, 2022 at 8:35 PM Simon Riggs
wrote:
>
> On Wed, 16 Nov 2022 at 12:47, Bharath Rupireddy
> wrote:
> >
> > On Wed, Nov 16, 2022 at 2:34 PM Simon Riggs
> > wrote:
> > >
> > > Reposting v6 now so that patch tester doesn't think this has failed
> > > when the patch on other thread gets
On Wed, 16 Nov 2022 at 12:47, Bharath Rupireddy
wrote:
>
> On Wed, Nov 16, 2022 at 2:34 PM Simon Riggs
> wrote:
> >
> > Reposting v6 now so that patch tester doesn't think this has failed
> > when the patch on other thread gets applied.
>
> Intention of the patch, that is, to get rid of promote_t
On Wed, Nov 16, 2022 at 2:34 PM Simon Riggs
wrote:
>
> Reposting v6 now so that patch tester doesn't think this has failed
> when the patch on other thread gets applied.
Intention of the patch, that is, to get rid of promote_trigger_file
GUC sometime in future, looks good to me. However, the time
On Sun, 13 Nov 2022 at 23:07, Simon Riggs wrote:
>
> On Sun, 13 Nov 2022 at 21:28, Thomas Munro wrote:
> >
> > On Mon, Nov 14, 2022 at 5:52 AM Simon Riggs
> > wrote:
> > > The attached patch is a reduced version of the original. It covers only:
> > > * deprecation of the promote_trigger_file - t
On Sun, 13 Nov 2022 at 21:28, Thomas Munro wrote:
>
> On Mon, Nov 14, 2022 at 5:52 AM Simon Riggs
> wrote:
> > The attached patch is a reduced version of the original. It covers only:
> > * deprecation of the promote_trigger_file - there are no tests that
> > use that, hence why there is no test
On Mon, Nov 14, 2022 at 5:52 AM Simon Riggs
wrote:
> The attached patch is a reduced version of the original. It covers only:
> * deprecation of the promote_trigger_file - there are no tests that
> use that, hence why there is no test coverage for the patch
> * changing the sleep time of the start
On Thu, 24 Mar 2022 at 16:02, Simon Riggs wrote:
>
> On Thu, 24 Mar 2022 at 15:39, Robert Haas wrote:
> >
> > On Thu, Mar 24, 2022 at 6:59 AM Simon Riggs
> > wrote:
> > > The proposals of this patch are the following, each of which can be
> > > independently accepted/rejected:
> > > 1. fix the s
2022年3月25日(金) 1:03 Simon Riggs :
>
> On Thu, 24 Mar 2022 at 15:39, Robert Haas wrote:
> >
> > On Thu, Mar 24, 2022 at 6:59 AM Simon Riggs
> > wrote:
> > > The proposals of this patch are the following, each of which can be
> > > independently accepted/rejected:
> > > 1. fix the sleep pattern of b
On Thu, Mar 24, 2022 at 12:02 PM Simon Riggs
wrote:
> What about (1)? That directly affects the powersave capability. I
> didn't read anything specific to that.
>
> If we don't fix (1) as well, the changes for startup and walreceiver
> will be ineffective for powersaving.
>
> What changes will be
On Thu, 24 Mar 2022 at 15:39, Robert Haas wrote:
>
> On Thu, Mar 24, 2022 at 6:59 AM Simon Riggs
> wrote:
> > The proposals of this patch are the following, each of which can be
> > independently accepted/rejected:
> > 1. fix the sleep pattern of bgwriter, walwriter and logical worker
> > (direct
On Thu, Mar 24, 2022 at 6:59 AM Simon Riggs
wrote:
> The proposals of this patch are the following, each of which can be
> independently accepted/rejected:
> 1. fix the sleep pattern of bgwriter, walwriter and logical worker
> (directly affects powersave)
> 2. deprecate promote_trigger_file, which
On Thu, 24 Mar 2022 at 07:16, Kyotaro Horiguchi wrote:
> > Most of these timeouts are a bad idea and should not exist. We repeatedly
> > have
> > had bugs where we were missing wakeups etc but those bugs were harder to
>
> I basically agree to this.
As a general point, maybe. But we have a lot
At Thu, 10 Mar 2022 11:45:10 -0800, Andres Freund wrote in
> Hi,
>
> On 2022-03-10 17:50:47 +, Simon Riggs wrote:
> > On Wed, 9 Mar 2022 at 01:16, Zheng Li wrote:
> >
> > > > 1. Standardize the hibernation time at 60s, using a #define
> > > > HIBERNATE_DELAY_SEC 60
> > >
> > > I notice in
On Tue, 22 Mar 2022 at 00:54, Andres Freund wrote:
>
> On 2022-02-21 21:04:19 +, Simon Riggs wrote:
> > On Mon, 21 Feb 2022 at 16:49, Chapman Flack wrote:
> >
> > > Shouldn't the comment be "with work_done=false" ?
> >
> > Good catch, thanks.
> >
> > I've also added docs to say that "promote_
On 2022-02-21 21:04:19 +, Simon Riggs wrote:
> On Mon, 21 Feb 2022 at 16:49, Chapman Flack wrote:
>
> > Shouldn't the comment be "with work_done=false" ?
>
> Good catch, thanks.
>
> I've also added docs to say that "promote_trigger_file" is now
> deprecated. There were no tests for that fun
Hi,
On 2022-03-10 17:50:47 +, Simon Riggs wrote:
> On Wed, 9 Mar 2022 at 01:16, Zheng Li wrote:
>
> > > 1. Standardize the hibernation time at 60s, using a #define
> > > HIBERNATE_DELAY_SEC 60
> >
> > I notice in patch 3 HIBERNATE_DELAY_SEC has been increased to 300
> > seconds, what’s the r
On Wed, 9 Mar 2022 at 01:16, Zheng Li wrote:
> > 1. Standardize the hibernation time at 60s, using a #define
> > HIBERNATE_DELAY_SEC 60
>
> I notice in patch 3 HIBERNATE_DELAY_SEC has been increased to 300
> seconds, what’s the reasoning behind it? Is longer hibernation delay
> better? If so can
On Sat, 26 Feb 2022 at 17:44, Tom Lane wrote:
>
> Magnus Hagander 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?
>
>
Hi,
> Replication never got the memo, so power consumption on an
> idle server is not very effective on standby or logical subscribers.
> The code and timing for hibernation is also different for each worker,
> which is confusing.
Agree, this patch makes it easier to understand the hibernation
be
Jim Nasby writes:
> I'm wondering if it'd be worth linking autovac wakeup from a truly idle
> state to the stats collector. If there's no stats messages coming in
> clearly there's nothing new for autovac.
That seems pretty scary in the current system design, where the
stats collector is intent
Magnus Hagander 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
On Mon, Feb 21, 2022 at 5:11 PM Simon Riggs
wrote:
>
> On Sat, 19 Feb 2022 at 17:03, Andres Freund wrote:
> >
> > Hi,
> >
> > On 2022-02-19 14:10:39 +, Simon Riggs wrote:
> > IMO we should instead consider either deprecating file based promotion, or
> > adding an optional dependency on filesy
On Mon, 21 Feb 2022 at 16:49, Chapman Flack wrote:
> Shouldn't the comment be "with work_done=false" ?
Good catch, thanks.
I've also added docs to say that "promote_trigger_file" is now
deprecated. There were no tests for that functionality, so just as
well it is being removed.
v3 attached.
Hi,
On 02/21/22 11:11, Simon Riggs wrote:
> This patch seeks to change the situation for the better in PG15, i.e.
> soon, so the changes proposed are deliberately light. It also seeks to
> provide a framework that writers of background worker processes can
> follow, since we can't just fix core, w
On Sat, 19 Feb 2022 at 17:03, Andres Freund wrote:
>
> Hi,
>
> On 2022-02-19 14:10:39 +, Simon Riggs wrote:
> > Some years ago we did a pass through the various worker processes to
> > add hibernation as a mechanism to reduce power consumption on an idle
> > server. Replication never got the m
On Sun, Feb 20, 2022 at 6:03 AM Andres Freund wrote:
> On 2022-02-19 14:10:39 +, Simon Riggs wrote:
> > * wal_receiver - 100ms, currently gets woken when WAL arrives
>
> This is a fairly insane one. We should compute a precise timeout based on
> wal_receiver_timeout.
I proposed a patch to do
Hi,
On 2022-02-19 14:10:39 +, Simon Riggs wrote:
> Some years ago we did a pass through the various worker processes to
> add hibernation as a mechanism to reduce power consumption on an idle
> server. Replication never got the memo, so power consumption on an
> idle server is not very effecti
67 matches
Mail list logo
