On Mon, Nov 23, 2020 at 06:13:17PM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
>> Please feel free to go ahead, including the change to ProcSleep.
>
> Will do.
Thank you both for 450c823 and 789b938.
--
Michael
signature.asc
Description: PGP signature
On 2020-Nov-23, Tom Lane wrote:
> I never cared that much for "is_log_level_output" either. Thinking
> about renaming it to "should_output_to_log()", and then the new function
> would be "should_output_to_client()".
Ah, that sounds nicely symmetric and grammatical.
Thanks!
Alvaro Herrera writes:
> On 2020-Nov-23, Tom Lane wrote:
>> I'm not too fussed about whether we invent is_log_level_output_client,
>> although that name doesn't seem well-chosen compared to
>> is_log_level_output.
> Just replacing "log" for "client" in that seemed strictly worse, and I
> didn't
On 2020-Nov-23, Tom Lane wrote:
> Ah, I see I didn't cover the case in ProcSleep that you were originally on
> about ... I'd just looked for existing references to log_min_messages
> and client_min_messages.
Yeah, it seemed bad form to add that when you had just argued against it
:-)
> I think
Alvaro Herrera writes:
> Your version has the advantage that errstart() doesn't get a new
> function call. I'm +1 for going with that ... we could avoid the
> duplicate code with some additional contortions but this changes so
> rarely that it's probably not worth the trouble.
I was considering
Alvaro Herrera writes:
> On 2020-Nov-23, Tom Lane wrote:
>> Here's a draft patch.
> Here's another of my own. Outside of elog.c it seems identical.
Ah, I see I didn't cover the case in ProcSleep that you were originally on
about ... I'd just looked for existing references to log_min_messages
On 2020-Nov-23, Alvaro Herrera wrote:
> On 2020-Nov-23, Tom Lane wrote:
>
> > Here's a draft patch.
>
> Here's another of my own. Outside of elog.c it seems identical.
Your version has the advantage that errstart() doesn't get a new
function call. I'm +1 for going with that ... we could
On 2020-Nov-23, Tom Lane wrote:
> Here's a draft patch.
Here's another of my own. Outside of elog.c it seems identical.
diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index 03c553e7ea..a4ab9090f9 100644
--- a/src/backend/access/transam/xact.c
+++
Here's a draft patch.
regards, tom lane
diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index 03c553e7ea..9cd0b7c11b 100644
--- a/src/backend/access/transam/xact.c
+++ b/src/backend/access/transam/xact.c
@@ -5344,7 +5344,7 @@ static void
On 2020-Nov-23, Tom Lane wrote:
> Alvaro Herrera writes:
> > Well, we already do this in a number of places. But I can get behind
> > this:
>
> >> Maybe it'd be a good idea to have elog.c expose a new function
> >> along the lines of "bool message_level_is_interesting(int elevel)"
> >> to
Alvaro Herrera writes:
> Well, we already do this in a number of places. But I can get behind
> this:
>> Maybe it'd be a good idea to have elog.c expose a new function
>> along the lines of "bool message_level_is_interesting(int elevel)"
>> to support this and similar future optimizations in a
On 2020-Nov-23, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2020-Nov-19, Michael Paquier wrote:
> >> By the way, it strikes me that you could just do nothing as long as
> >> (log_min_messages > DEBUG1), so you could encapsulate most of the
> >> logic that plays with the lock tag using that.
Alvaro Herrera writes:
> On 2020-Nov-19, Michael Paquier wrote:
>> By the way, it strikes me that you could just do nothing as long as
>> (log_min_messages > DEBUG1), so you could encapsulate most of the
>> logic that plays with the lock tag using that.
> Good idea, done.
I'm less sure that
On 2020-Nov-19, Michael Paquier wrote:
> On Thu, Nov 19, 2020 at 12:13:44PM +0900, Michael Paquier wrote:
> > That still looks useful for debugging, so DEBUG1 sounds fine to me.
>
> By the way, it strikes me that you could just do nothing as long as
> (log_min_messages > DEBUG1), so you could
On Thu, Nov 19, 2020 at 12:13:44PM +0900, Michael Paquier wrote:
> That still looks useful for debugging, so DEBUG1 sounds fine to me.
By the way, it strikes me that you could just do nothing as long as
(log_min_messages > DEBUG1), so you could encapsulate most of the
logic that plays with the
On Wed, Nov 18, 2020 at 02:48:40PM -0800, Andres Freund wrote:
> On 2020-11-18 18:41:27 -0300, Alvaro Herrera wrote:
>> We could make this more concurrent by copying lock->tag to a local
>> variable, releasing the lock, then doing all the string formatting and
>> printing. See attached
Hi,
On 2020-11-18 18:41:27 -0300, Alvaro Herrera wrote:
> The amount of stuff that this is doing with ProcArrayLock held
> exclusively seems a bit excessive; it sounds like we could copy the
> values we need first, release the lock, and *then* do all that memory
> allocation and string printing
> On 2020-11-17 12:55:01 -0300, Alvaro Herrera wrote:
> > ... ah, but I realize now that this means that we can use shared lock
> > here, not exclusive, which is already an enormous improvement. That's
> > because ->pgxactoff can only be changed with exclusive lock held; so as
> > long as we hold
18 matches
Mail list logo
