public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Andres Freund <[email protected]>
Cc: [email protected]
Cc: Robert Haas <[email protected]>
Subject: Re: catalog access with reset GUCs during parallel worker startup
Date: Wed, 09 Feb 2022 18:56:41 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

Andres Freund <[email protected]> writes:
> Do we really need to reset GUCs to their boot value? Particularly for
> PGC_SIGHUP variables I don't think we can do that if we want to do
> RestoreGUCState() in a transaction.  It'd obviously involve a bit more code,
> but it seems entirely possible to just get rid of the reset phase?

In an EXEC_BACKEND build, they're going to start out with those
values anyway.  If you're not happy about the consequences,
"skipping the reset" is not the way to improve matters.

Can we arrange to absorb the leader's values before starting the
worker's transaction, instead of inside it?

			regards, tom lane

view thread (6+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: catalog access with reset GUCs during parallel worker startup
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox