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
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,
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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]
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
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
>
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
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
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
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
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
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.
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
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
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
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 -
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
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
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
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
> >
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,
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
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
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
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
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
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
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
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,
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
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
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 effective on standby or logical subscribers.
The code and timing for
68 matches
Mail list logo
