pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feed"as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
18+ messages / 4 participants
[nested] [flat]
Commits from this thread:
2020-11-24 789b938bf2 Centralize logic for skipping useless ereport/elog calls.
2020-11-23 450c8230b1 Don't hold ProcArrayLock longer than needed in rare cases
* "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
@ 2020-11-18 21:41 Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 18+ messages in thread
From: Alvaro Herrera @ 2020-11-18 21:41 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Michael Paquier <michael@paquier.xyz>; Dmitry Dolgov <9erthalion6@gmail.com>; James Coleman <jtc331@gmail.com>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
> 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 shared, the array item cannot move.
>
> Uh, wait a second. The acquisition of this lock hasn't been affected by
> the snapshot scalability changes, and therefore are unrelated to
> ->pgxactoff changing or not.
I'm writing a response trying to thoroughly analyze this, but I also
wanted to report that ProcSleep is being a bit generous with what it
calls "as quickly as possible" here:
LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
/*
* Only do it if the worker is not working to protect against Xid
* wraparound.
*/
statusFlags = ProcGlobal->statusFlags[autovac->pgxactoff];
if ((statusFlags & PROC_IS_AUTOVACUUM) &&
!(statusFlags & PROC_VACUUM_FOR_WRAPAROUND))
{
int pid = autovac->pid;
StringInfoData locktagbuf;
StringInfoData logbuf; /* errdetail for server log */
initStringInfo(&locktagbuf);
initStringInfo(&logbuf);
DescribeLockTag(&locktagbuf, &lock->tag);
appendStringInfo(&logbuf,
_("Process %d waits for %s on %s."),
MyProcPid,
GetLockmodeName(lock->tag.locktag_lockmethodid,
lockmode),
locktagbuf.data);
/* release lock as quickly as possible */
LWLockRelease(ProcArrayLock);
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 -- it's a lock of code for such a
contended lock. Anytime a process sees itself as blocked by autovacuum
and wants to signal it, there's a ProcArrayLock hiccup (I didn't
actually measure it, but it's at least five function calls). 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 quickly.patch.
Now, when this code was written (d7318d43d, 2012), this was a LOG
message; it was demoted to DEBUG1 later (d8f15c95bec, 2015). I think it
would be fair to ... remove the message? Or go back to Simon's original
formulation from commit acac68b2bca, which had this message as DEBUG2
without any string formatting.
Thoughts?
Attachments:
quickly.patch (text/x-diff, 1.2K) download
diff --git a/src/backend/storage/lmgr/proc.c b/src/backend/storage/lmgr/proc.c
index d1738c65f5..caefff41e2 100644
--- a/src/backend/storage/lmgr/proc.c
+++ b/src/backend/storage/lmgr/proc.c
@@ -1325,20 +1325,22 @@ ProcSleep(LOCALLOCK *locallock, LockMethod lockMethodTable)
int pid = autovac->pid;
StringInfoData locktagbuf;
StringInfoData logbuf; /* errdetail for server log */
+ LOCKTAG locktag_copy;
+
+ /* release lock as quickly as possible */
+ locktag_copy = lock->tag;
+ LWLockRelease(ProcArrayLock);
initStringInfo(&locktagbuf);
initStringInfo(&logbuf);
- DescribeLockTag(&locktagbuf, &lock->tag);
+ DescribeLockTag(&locktagbuf, &locktag_copy);
appendStringInfo(&logbuf,
_("Process %d waits for %s on %s."),
MyProcPid,
- GetLockmodeName(lock->tag.locktag_lockmethodid,
+ GetLockmodeName(locktag_copy.locktag_lockmethodid,
lockmode),
locktagbuf.data);
- /* release lock as quickly as possible */
- LWLockRelease(ProcArrayLock);
-
/* send the autovacuum worker Back to Old Kent Road */
ereport(DEBUG1,
(errmsg("sending cancel to blocking autovacuum PID %d",
* Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
@ 2020-11-18 22:48 Andres Freund <andres@anarazel.de>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 18+ messages in thread
From: Andres Freund @ 2020-11-18 22:48 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Michael Paquier <michael@paquier.xyz>; Dmitry Dolgov <9erthalion6@gmail.com>; James Coleman <jtc331@gmail.com>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
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 -- it's a lock of code for such a
> contended lock.
Yea, that's a good point.
> Anytime a process sees itself as blocked by autovacuum
> and wants to signal it, there's a ProcArrayLock hiccup (I didn't
> actually measure it, but it's at least five function calls).
I'm a bit doubtful it's that important - it's limited in frequency
by deadlock_timeout. But worth improving anyway.
> 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 quickly.patch.
Sounds like a plan.
> Now, when this code was written (d7318d43d, 2012), this was a LOG
> message; it was demoted to DEBUG1 later (d8f15c95bec, 2015). I think it
> would be fair to ... remove the message? Or go back to Simon's original
> formulation from commit acac68b2bca, which had this message as DEBUG2
> without any string formatting.
I don't really have an opinion on this.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
@ 2020-11-19 03:13 Michael Paquier <michael@paquier.xyz>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 1 reply; 18+ messages in thread
From: Michael Paquier @ 2020-11-19 03:13 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>; Tom Lane <tgl@sss.pgh.pa.us>; Dmitry Dolgov <9erthalion6@gmail.com>; James Coleman <jtc331@gmail.com>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
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 quickly.patch.
>
> Sounds like a plan.
+1.
>> Now, when this code was written (d7318d43d, 2012), this was a LOG
>> message; it was demoted to DEBUG1 later (d8f15c95bec, 2015). I think it
>> would be fair to ... remove the message? Or go back to Simon's original
>> formulation from commit acac68b2bca, which had this message as DEBUG2
>> without any string formatting.
>
> I don't really have an opinion on this.
That still looks useful for debugging, so DEBUG1 sounds fine to me.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
@ 2020-11-19 03:39 Michael Paquier <michael@paquier.xyz>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 18+ messages in thread
From: Michael Paquier @ 2020-11-19 03:39 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>; Tom Lane <tgl@sss.pgh.pa.us>; Dmitry Dolgov <9erthalion6@gmail.com>; James Coleman <jtc331@gmail.com>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
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 lock tag using that.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
@ 2020-11-23 20:31 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 18+ messages in thread
From: Alvaro Herrera @ 2020-11-23 20:31 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Dmitry Dolgov <9erthalion6@gmail.com>; James Coleman <jtc331@gmail.com>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
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 encapsulate most of the
> logic that plays with the lock tag using that.
Good idea, done.
I also noticed that if we're going to accept a race (which BTW already
exists) we may as well simplify the code about it.
I think the attached is the final form of this.
Attachments:
0001-Don-t-hold-ProcArrayLock-longer-than-needed-in-rare-.patch (text/x-diff, 4.4K) download
From cab95d8813cd79adb7b2a1b5501714c2dd87bec2 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: Tue, 17 Nov 2020 21:09:22 -0300
Subject: [PATCH] Don't hold ProcArrayLock longer than needed in rare cases
While cancelling an autovacuum worker, we hold ProcArrayLock while
formatting a debugging log string. We can make this shorter by saving
the data we need to produce the message and doing the formatting outside
the locked region.
This isn't terribly critical, as it only occurs pretty rarely: when a
backend runs deadlock detection and it happens to be blocked by a
autovacuum running autovacuum. Still, there's no need to cause a hiccup
in ProcArrayLock processing, which can be very high-traffic in some
cases.
While at it, rework code so that we only print the string when it is
really going to be used, as suggested by Michael Paquier.
Discussion: https://postgr.es/m/20201118214127.GA3179@alvherre.pgsql
Reviewed-by: Michael Paquier <michael@paquier.xyz>
---
src/backend/storage/lmgr/proc.c | 63 ++++++++++++++++++++-------------
1 file changed, 38 insertions(+), 25 deletions(-)
diff --git a/src/backend/storage/lmgr/proc.c b/src/backend/storage/lmgr/proc.c
index d1738c65f5..dbfdd7b3c7 100644
--- a/src/backend/storage/lmgr/proc.c
+++ b/src/backend/storage/lmgr/proc.c
@@ -1311,40 +1311,58 @@ ProcSleep(LOCALLOCK *locallock, LockMethod lockMethodTable)
{
PGPROC *autovac = GetBlockingAutoVacuumPgproc();
uint8 statusFlags;
+ uint8 lockmethod_copy;
+ LOCKTAG locktag_copy;
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
+ /*
+ * Grab info we need, then release lock immediately. Note this
+ * coding means that there is a tiny chance that the process
+ * terminates its current transaction and starts a different one
+ * before we have a change to send the signal; the worst possible
+ * consequence is that a for-wraparound vacuum is cancelled. But
+ * that could happen in any case unless we were to do kill() with
+ * the lock held, which is much more undesirable.
+ */
+ LWLockAcquire(ProcArrayLock, LW_SHARED);
+ statusFlags = ProcGlobal->statusFlags[autovac->pgxactoff];
+ lockmethod_copy = lock->tag.locktag_lockmethodid;
+ locktag_copy = lock->tag;
+ LWLockRelease(ProcArrayLock);
/*
* Only do it if the worker is not working to protect against Xid
* wraparound.
*/
- statusFlags = ProcGlobal->statusFlags[autovac->pgxactoff];
if ((statusFlags & PROC_IS_AUTOVACUUM) &&
!(statusFlags & PROC_VACUUM_FOR_WRAPAROUND))
{
int pid = autovac->pid;
- StringInfoData locktagbuf;
- StringInfoData logbuf; /* errdetail for server log */
- initStringInfo(&locktagbuf);
- initStringInfo(&logbuf);
- DescribeLockTag(&locktagbuf, &lock->tag);
- appendStringInfo(&logbuf,
- _("Process %d waits for %s on %s."),
- MyProcPid,
- GetLockmodeName(lock->tag.locktag_lockmethodid,
- lockmode),
- locktagbuf.data);
+ /* report the case, if configured to do so */
+ if (log_min_messages <= DEBUG1 || client_min_messages <= DEBUG1)
+ {
+ StringInfoData locktagbuf;
+ StringInfoData logbuf; /* errdetail for server log */
- /* release lock as quickly as possible */
- LWLockRelease(ProcArrayLock);
+ initStringInfo(&locktagbuf);
+ initStringInfo(&logbuf);
+ DescribeLockTag(&locktagbuf, &locktag_copy);
+ appendStringInfo(&logbuf,
+ _("Process %d waits for %s on %s."),
+ MyProcPid,
+ GetLockmodeName(lockmethod_copy, lockmode),
+ locktagbuf.data);
+
+ ereport(DEBUG1,
+ (errmsg("sending cancel to blocking autovacuum PID %d",
+ pid),
+ errdetail_log("%s", logbuf.data)));
+
+ pfree(logbuf.data);
+ pfree(locktagbuf.data);
+ }
/* send the autovacuum worker Back to Old Kent Road */
- ereport(DEBUG1,
- (errmsg("sending cancel to blocking autovacuum PID %d",
- pid),
- errdetail_log("%s", logbuf.data)));
-
if (kill(pid, SIGINT) < 0)
{
/*
@@ -1362,12 +1380,7 @@ ProcSleep(LOCALLOCK *locallock, LockMethod lockMethodTable)
(errmsg("could not send signal to process %d: %m",
pid)));
}
-
- pfree(logbuf.data);
- pfree(locktagbuf.data);
}
- else
- LWLockRelease(ProcArrayLock);
/* prevent signal from being sent again more than once */
allow_autovacuum_cancel = false;
--
2.20.1
* Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
@ 2020-11-23 21:20 Tom Lane <tgl@sss.pgh.pa.us>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 18+ messages in thread
From: Tom Lane @ 2020-11-23 21:20 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Michael Paquier <michael@paquier.xyz>; Andres Freund <andres@anarazel.de>; Dmitry Dolgov <9erthalion6@gmail.com>; James Coleman <jtc331@gmail.com>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
Alvaro Herrera <alvherre@alvh.no-ip.org> 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 that's a good idea. It embeds knowledge here that
should not exist outside elog.c; moreover, I'm not entirely sure that
it's even correct, given the nonlinear ranking of log_min_messages.
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 less fragile way.
regards, tom lane
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
@ 2020-11-23 21:28 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 18+ messages in thread
From: Alvaro Herrera @ 2020-11-23 21:28 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Michael Paquier <michael@paquier.xyz>; Andres Freund <andres@anarazel.de>; Dmitry Dolgov <9erthalion6@gmail.com>; James Coleman <jtc331@gmail.com>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
On 2020-Nov-23, Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> 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 that's a good idea. It embeds knowledge here that
> should not exist outside elog.c; moreover, I'm not entirely sure that
> it's even correct, given the nonlinear ranking of log_min_messages.
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 less fragile way.
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
@ 2020-11-23 22:02 Tom Lane <tgl@sss.pgh.pa.us>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 18+ messages in thread
From: Tom Lane @ 2020-11-23 22:02 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Michael Paquier <michael@paquier.xyz>; Andres Freund <andres@anarazel.de>; Dmitry Dolgov <9erthalion6@gmail.com>; James Coleman <jtc331@gmail.com>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
Alvaro Herrera <alvherre@alvh.no-ip.org> 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 less fragile way.
I'll see about a patch for that.
regards, tom lane
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
@ 2020-11-23 22:10 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 18+ messages in thread
From: Alvaro Herrera @ 2020-11-23 22:10 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Michael Paquier <michael@paquier.xyz>; Andres Freund <andres@anarazel.de>; Dmitry Dolgov <9erthalion6@gmail.com>; James Coleman <jtc331@gmail.com>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
On 2020-Nov-23, Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> 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 less fragile way.
>
> I'll see about a patch for that.
Looking at that now ...
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
@ 2020-11-23 22:32 Tom Lane <tgl@sss.pgh.pa.us>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 18+ messages in thread
From: Tom Lane @ 2020-11-23 22:32 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Michael Paquier <michael@paquier.xyz>; Andres Freund <andres@anarazel.de>; Dmitry Dolgov <9erthalion6@gmail.com>; James Coleman <jtc331@gmail.com>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
Here's a draft patch.
regards, tom lane
Attachments:
hide-elog-level-knowledge.patch (text/x-diff, 6.0K) download
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
ShowTransactionState(const char *str)
{
/* skip work if message will definitely not be printed */
- if (log_min_messages <= DEBUG5 || client_min_messages <= DEBUG5)
+ if (message_level_is_interesting(DEBUG5))
ShowTransactionStateRec(str, CurrentTransactionState);
}
@@ -5371,7 +5371,6 @@ ShowTransactionStateRec(const char *str, TransactionState s)
if (s->parent)
ShowTransactionStateRec(str, s->parent);
- /* use ereport to suppress computation if msg will not be printed */
ereport(DEBUG5,
(errmsg_internal("%s(%d) name: %s; blockState: %s; state: %s, xid/subid/cid: %u/%u/%u%s%s",
str, s->nestingLevel,
diff --git a/src/backend/access/transam/xlogutils.c b/src/backend/access/transam/xlogutils.c
index 7e915bcadf..32a3099c1f 100644
--- a/src/backend/access/transam/xlogutils.c
+++ b/src/backend/access/transam/xlogutils.c
@@ -105,7 +105,7 @@ log_invalid_page(RelFileNode node, ForkNumber forkno, BlockNumber blkno,
* tracing of the cause (note the elog context mechanism will tell us
* something about the XLOG record that generated the reference).
*/
- if (log_min_messages <= DEBUG1 || client_min_messages <= DEBUG1)
+ if (message_level_is_interesting(DEBUG1))
report_invalid_page(DEBUG1, node, forkno, blkno, present);
if (invalid_page_tab == NULL)
@@ -159,7 +159,7 @@ forget_invalid_pages(RelFileNode node, ForkNumber forkno, BlockNumber minblkno)
hentry->key.forkno == forkno &&
hentry->key.blkno >= minblkno)
{
- if (log_min_messages <= DEBUG2 || client_min_messages <= DEBUG2)
+ if (message_level_is_interesting(DEBUG2))
{
char *path = relpathperm(hentry->key.node, forkno);
@@ -192,7 +192,7 @@ forget_invalid_pages_db(Oid dbid)
{
if (hentry->key.node.dbNode == dbid)
{
- if (log_min_messages <= DEBUG2 || client_min_messages <= DEBUG2)
+ if (message_level_is_interesting(DEBUG2))
{
char *path = relpathperm(hentry->key.node, hentry->key.forkno);
diff --git a/src/backend/catalog/dependency.c b/src/backend/catalog/dependency.c
index b0d037600e..245c2f4fc8 100644
--- a/src/backend/catalog/dependency.c
+++ b/src/backend/catalog/dependency.c
@@ -1146,15 +1146,9 @@ reportDependentObjects(const ObjectAddresses *targetObjects,
* If no error is to be thrown, and the msglevel is too low to be shown to
* either client or server log, there's no need to do any of the rest of
* the work.
- *
- * Note: this code doesn't know all there is to be known about elog
- * levels, but it works for NOTICE and DEBUG2, which are the only values
- * msglevel can currently have. We also assume we are running in a normal
- * operating environment.
*/
if (behavior == DROP_CASCADE &&
- msglevel < client_min_messages &&
- (msglevel < log_min_messages || log_min_messages == LOG))
+ !message_level_is_interesting(msglevel))
return;
/*
diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index babee386c4..87c3ea450e 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -1215,7 +1215,7 @@ ProcessWalSndrMessage(XLogRecPtr walEnd, TimestampTz sendTime)
walrcv->lastMsgReceiptTime = lastMsgReceiptTime;
SpinLockRelease(&walrcv->mutex);
- if (log_min_messages <= DEBUG2)
+ if (message_level_is_interesting(DEBUG2))
{
char *sendtime;
char *receipttime;
diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c
index 5d1b1a16be..2eb19ad293 100644
--- a/src/backend/replication/walsender.c
+++ b/src/backend/replication/walsender.c
@@ -1900,7 +1900,7 @@ ProcessStandbyReplyMessage(void)
replyTime = pq_getmsgint64(&reply_message);
replyRequested = pq_getmsgbyte(&reply_message);
- if (log_min_messages <= DEBUG2)
+ if (message_level_is_interesting(DEBUG2))
{
char *replyTimeStr;
@@ -2082,7 +2082,7 @@ ProcessStandbyHSFeedbackMessage(void)
feedbackCatalogXmin = pq_getmsgint(&reply_message, 4);
feedbackCatalogEpoch = pq_getmsgint(&reply_message, 4);
- if (log_min_messages <= DEBUG2)
+ if (message_level_is_interesting(DEBUG2))
{
char *replyTimeStr;
diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
index 1ba47c194b..04c2245338 100644
--- a/src/backend/utils/error/elog.c
+++ b/src/backend/utils/error/elog.c
@@ -600,6 +600,42 @@ errfinish(const char *filename, int lineno, const char *funcname)
CHECK_FOR_INTERRUPTS();
}
+/*
+ * message_level_is_interesting --- would ereport/elog do anything?
+ *
+ * Returns true if ereport/elog with this elevel will not be a no-op.
+ * This is useful to short-circuit any expensive preparatory work that
+ * might be needed for a logging message. There is no point in
+ * prepending this to a bare ereport/elog call, however.
+ */
+bool
+message_level_is_interesting(int elevel)
+{
+ bool output_to_server;
+ bool output_to_client;
+
+ /*
+ * Keep this in sync with the decision-making in errstart().
+ */
+ if (elevel >= ERROR)
+ return true;
+
+ output_to_server = is_log_level_output(elevel, log_min_messages);
+ if (output_to_server)
+ return true;
+
+ if (whereToSendOutput == DestRemote && elevel != LOG_SERVER_ONLY &&
+ !ClientAuthInProgress)
+ {
+ output_to_client = (elevel >= client_min_messages ||
+ elevel == INFO);
+ if (output_to_client)
+ return true;
+ }
+
+ return false;
+}
+
/*
* errcode --- add SQLSTATE error code to the current error
diff --git a/src/include/utils/elog.h b/src/include/utils/elog.h
index 1e09ee0541..de5bba0a4a 100644
--- a/src/include/utils/elog.h
+++ b/src/include/utils/elog.h
@@ -149,6 +149,8 @@
extern bool errstart(int elevel, const char *domain);
extern void errfinish(const char *filename, int lineno, const char *funcname);
+extern bool message_level_is_interesting(int elevel);
+
extern int errcode(int sqlerrcode);
extern int errcode_for_file_access(void);
* Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
@ 2020-11-23 22:38 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 18+ messages in thread
From: Alvaro Herrera @ 2020-11-23 22:38 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Michael Paquier <michael@paquier.xyz>; Andres Freund <andres@anarazel.de>; Dmitry Dolgov <9erthalion6@gmail.com>; James Coleman <jtc331@gmail.com>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
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.
Attachments:
interesting-msg.patch (text/x-diff, 8.5K) download
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
+++ b/src/backend/access/transam/xact.c
@@ -5344,7 +5344,7 @@ static void
ShowTransactionState(const char *str)
{
/* skip work if message will definitely not be printed */
- if (log_min_messages <= DEBUG5 || client_min_messages <= DEBUG5)
+ if (message_level_is_interesting(DEBUG5))
ShowTransactionStateRec(str, CurrentTransactionState);
}
diff --git a/src/backend/access/transam/xlogutils.c b/src/backend/access/transam/xlogutils.c
index 7e915bcadf..32a3099c1f 100644
--- a/src/backend/access/transam/xlogutils.c
+++ b/src/backend/access/transam/xlogutils.c
@@ -105,7 +105,7 @@ log_invalid_page(RelFileNode node, ForkNumber forkno, BlockNumber blkno,
* tracing of the cause (note the elog context mechanism will tell us
* something about the XLOG record that generated the reference).
*/
- if (log_min_messages <= DEBUG1 || client_min_messages <= DEBUG1)
+ if (message_level_is_interesting(DEBUG1))
report_invalid_page(DEBUG1, node, forkno, blkno, present);
if (invalid_page_tab == NULL)
@@ -159,7 +159,7 @@ forget_invalid_pages(RelFileNode node, ForkNumber forkno, BlockNumber minblkno)
hentry->key.forkno == forkno &&
hentry->key.blkno >= minblkno)
{
- if (log_min_messages <= DEBUG2 || client_min_messages <= DEBUG2)
+ if (message_level_is_interesting(DEBUG2))
{
char *path = relpathperm(hentry->key.node, forkno);
@@ -192,7 +192,7 @@ forget_invalid_pages_db(Oid dbid)
{
if (hentry->key.node.dbNode == dbid)
{
- if (log_min_messages <= DEBUG2 || client_min_messages <= DEBUG2)
+ if (message_level_is_interesting(DEBUG2))
{
char *path = relpathperm(hentry->key.node, hentry->key.forkno);
diff --git a/src/backend/catalog/dependency.c b/src/backend/catalog/dependency.c
index b0d037600e..0ad647ed9c 100644
--- a/src/backend/catalog/dependency.c
+++ b/src/backend/catalog/dependency.c
@@ -1146,15 +1146,8 @@ reportDependentObjects(const ObjectAddresses *targetObjects,
* If no error is to be thrown, and the msglevel is too low to be shown to
* either client or server log, there's no need to do any of the rest of
* the work.
- *
- * Note: this code doesn't know all there is to be known about elog
- * levels, but it works for NOTICE and DEBUG2, which are the only values
- * msglevel can currently have. We also assume we are running in a normal
- * operating environment.
*/
- if (behavior == DROP_CASCADE &&
- msglevel < client_min_messages &&
- (msglevel < log_min_messages || log_min_messages == LOG))
+ if (behavior == DROP_CASCADE && !message_level_is_interesting(msglevel))
return;
/*
diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index babee386c4..87c3ea450e 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -1215,7 +1215,7 @@ ProcessWalSndrMessage(XLogRecPtr walEnd, TimestampTz sendTime)
walrcv->lastMsgReceiptTime = lastMsgReceiptTime;
SpinLockRelease(&walrcv->mutex);
- if (log_min_messages <= DEBUG2)
+ if (message_level_is_interesting(DEBUG2))
{
char *sendtime;
char *receipttime;
diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c
index 5d1b1a16be..2eb19ad293 100644
--- a/src/backend/replication/walsender.c
+++ b/src/backend/replication/walsender.c
@@ -1900,7 +1900,7 @@ ProcessStandbyReplyMessage(void)
replyTime = pq_getmsgint64(&reply_message);
replyRequested = pq_getmsgbyte(&reply_message);
- if (log_min_messages <= DEBUG2)
+ if (message_level_is_interesting(DEBUG2))
{
char *replyTimeStr;
@@ -2082,7 +2082,7 @@ ProcessStandbyHSFeedbackMessage(void)
feedbackCatalogXmin = pq_getmsgint(&reply_message, 4);
feedbackCatalogEpoch = pq_getmsgint(&reply_message, 4);
- if (log_min_messages <= DEBUG2)
+ if (message_level_is_interesting(DEBUG2))
{
char *replyTimeStr;
diff --git a/src/backend/storage/lmgr/proc.c b/src/backend/storage/lmgr/proc.c
index 40eac704dc..eb2309ed76 100644
--- a/src/backend/storage/lmgr/proc.c
+++ b/src/backend/storage/lmgr/proc.c
@@ -1341,22 +1341,25 @@ ProcSleep(LOCALLOCK *locallock, LockMethod lockMethodTable)
StringInfoData logbuf; /* errdetail for server log */
/* report the case, if configured to do so */
- initStringInfo(&locktagbuf);
- initStringInfo(&logbuf);
- DescribeLockTag(&locktagbuf, &locktag_copy);
- appendStringInfo(&logbuf,
- _("Process %d waits for %s on %s."),
- MyProcPid,
- GetLockmodeName(lockmethod_copy, lockmode),
- locktagbuf.data);
+ if (message_level_is_interesting(DEBUG1))
+ {
+ initStringInfo(&locktagbuf);
+ initStringInfo(&logbuf);
+ DescribeLockTag(&locktagbuf, &locktag_copy);
+ appendStringInfo(&logbuf,
+ _("Process %d waits for %s on %s."),
+ MyProcPid,
+ GetLockmodeName(lockmethod_copy, lockmode),
+ locktagbuf.data);
- ereport(DEBUG1,
- (errmsg("sending cancel to blocking autovacuum PID %d",
- pid),
- errdetail_log("%s", logbuf.data)));
+ ereport(DEBUG1,
+ (errmsg("sending cancel to blocking autovacuum PID %d",
+ pid),
+ errdetail_log("%s", logbuf.data)));
- pfree(logbuf.data);
- pfree(locktagbuf.data);
+ pfree(logbuf.data);
+ pfree(locktagbuf.data);
+ }
/* send the autovacuum worker Back to Old Kent Road */
if (kill(pid, SIGINT) < 0)
diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
index 1ba47c194b..aab27aa5aa 100644
--- a/src/backend/utils/error/elog.c
+++ b/src/backend/utils/error/elog.c
@@ -185,6 +185,7 @@ static void send_message_to_frontend(ErrorData *edata);
static const char *error_severity(int elevel);
static void append_with_tabs(StringInfo buf, const char *str);
static bool is_log_level_output(int elevel, int log_min_level);
+static bool is_log_level_output_client(int elevel, int client_min_level);
/*
@@ -293,20 +294,7 @@ errstart(int elevel, const char *domain)
output_to_server = is_log_level_output(elevel, log_min_messages);
/* Determine whether message is enabled for client output */
- if (whereToSendOutput == DestRemote && elevel != LOG_SERVER_ONLY)
- {
- /*
- * client_min_messages is honored only after we complete the
- * authentication handshake. This is required both for security
- * reasons and because many clients can't handle NOTICE messages
- * during authentication.
- */
- if (ClientAuthInProgress)
- output_to_client = (elevel >= ERROR);
- else
- output_to_client = (elevel >= client_min_messages ||
- elevel == INFO);
- }
+ output_to_client = is_log_level_output_client(elevel, client_min_messages);
/* Skip processing effort if non-error message will not be output */
if (elevel < ERROR && !output_to_server && !output_to_client)
@@ -3521,6 +3509,42 @@ is_log_level_output(int elevel, int log_min_level)
return false;
}
+/*
+ * is_log_level_output_client -- is elevel logical >= client_min_level?
+ */
+static bool
+is_log_level_output_client(int elevel, int client_min_level)
+{
+ if (whereToSendOutput == DestRemote && elevel != LOG_SERVER_ONLY)
+ {
+ /*
+ * client_min_level (client_min_messages) is honored only after we
+ * complete the authentication handshake. This is required both for
+ * security reasons and because many clients can't handle NOTICE
+ * messages during authentication.
+ */
+ if (ClientAuthInProgress)
+ return elevel >= ERROR;
+ else
+ return elevel >= client_min_level || elevel == INFO;
+ }
+
+ return false;
+}
+
+/*
+ * Return whether a message of the given elevel would be printed.
+ *
+ * This can be used to skip formatting effort outside of ereport() calls.
+ */
+bool
+message_level_is_interesting(int elevel)
+{
+ return
+ is_log_level_output(elevel, log_min_messages) ||
+ is_log_level_output_client(elevel, client_min_messages);
+}
+
/*
* Adjust the level of a recovery-related message per trace_recovery_messages.
*
diff --git a/src/include/utils/elog.h b/src/include/utils/elog.h
index 1e09ee0541..4049456eab 100644
--- a/src/include/utils/elog.h
+++ b/src/include/utils/elog.h
@@ -393,6 +393,9 @@ extern void pg_re_throw(void) pg_attribute_noreturn();
extern char *GetErrorContextStack(void);
+/* allow skipping formatting messages that won't be emitted */
+extern bool message_level_is_interesting(int elevel);
+
/* Hook for intercepting messages before they are sent to the server log */
typedef void (*emit_log_hook_type) (ErrorData *edata);
extern PGDLLIMPORT emit_log_hook_type emit_log_hook;
* Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
@ 2020-11-23 22:41 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
1 sibling, 1 reply; 18+ messages in thread
From: Alvaro Herrera @ 2020-11-23 22:41 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Michael Paquier <michael@paquier.xyz>; Andres Freund <andres@anarazel.de>; Dmitry Dolgov <9erthalion6@gmail.com>; James Coleman <jtc331@gmail.com>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
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 avoid the
duplicate code with some additional contortions but this changes so
rarely that it's probably not worth the trouble.
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
@ 2020-11-23 22:45 Tom Lane <tgl@sss.pgh.pa.us>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
1 sibling, 1 reply; 18+ messages in thread
From: Tom Lane @ 2020-11-23 22:45 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Michael Paquier <michael@paquier.xyz>; Andres Freund <andres@anarazel.de>; Dmitry Dolgov <9erthalion6@gmail.com>; James Coleman <jtc331@gmail.com>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
Alvaro Herrera <alvherre@alvh.no-ip.org> 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
and client_min_messages.
I think it's important to have the explicit check for elevel >= ERROR.
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.
Shall I press forward with this, or do you want to?
regards, tom lane
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
@ 2020-11-23 22:48 Tom Lane <tgl@sss.pgh.pa.us>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 0 replies; 18+ messages in thread
From: Tom Lane @ 2020-11-23 22:48 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Michael Paquier <michael@paquier.xyz>; Andres Freund <andres@anarazel.de>; Dmitry Dolgov <9erthalion6@gmail.com>; James Coleman <jtc331@gmail.com>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
Alvaro Herrera <alvherre@alvh.no-ip.org> 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 adding that factorization, but marking the function
inline to avoid adding overhead. Most of elog.c predates our use of
inline, so it wasn't considered when this code was written.
regards, tom lane
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
@ 2020-11-23 23:02 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 18+ messages in thread
From: Alvaro Herrera @ 2020-11-23 23:02 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Michael Paquier <michael@paquier.xyz>; Andres Freund <andres@anarazel.de>; Dmitry Dolgov <9erthalion6@gmail.com>; James Coleman <jtc331@gmail.com>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
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 it's important to have the explicit check for elevel >= ERROR.
> 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 (don't) have any other ideas.
> Shall I press forward with this, or do you want to?
Please feel free to go ahead, including the change to ProcSleep.
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
@ 2020-11-23 23:13 Tom Lane <tgl@sss.pgh.pa.us>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 2 replies; 18+ messages in thread
From: Tom Lane @ 2020-11-23 23:13 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Michael Paquier <michael@paquier.xyz>; Andres Freund <andres@anarazel.de>; Dmitry Dolgov <9erthalion6@gmail.com>; James Coleman <jtc331@gmail.com>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
Alvaro Herrera <alvherre@alvh.no-ip.org> 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 (don't) have any other ideas.
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()".
>> Shall I press forward with this, or do you want to?
> Please feel free to go ahead, including the change to ProcSleep.
Will do.
regards, tom lane
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
@ 2020-11-24 02:03 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 18+ messages in thread
From: Alvaro Herrera @ 2020-11-24 02:03 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Michael Paquier <michael@paquier.xyz>; Andres Freund <andres@anarazel.de>; Dmitry Dolgov <9erthalion6@gmail.com>; James Coleman <jtc331@gmail.com>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
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!
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
@ 2020-11-24 02:04 Michael Paquier <michael@paquier.xyz>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 18+ messages in thread
From: Michael Paquier @ 2020-11-24 02:04 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>; Andres Freund <andres@anarazel.de>; Dmitry Dolgov <9erthalion6@gmail.com>; James Coleman <jtc331@gmail.com>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
On Mon, Nov 23, 2020 at 06:13:17PM -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>> Please feel free to go ahead, including the change to ProcSleep.
>
> Will do.
Thank you both for 450c823 and 789b938.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 18+ messages in thread
end of thread, other threads:[~2020-11-24 02:04 UTC | newest]
Thread overview: 18+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-11-18 21:41 "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait) Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-11-18 22:48 ` Andres Freund <andres@anarazel.de>
2020-11-19 03:13 ` Michael Paquier <michael@paquier.xyz>
2020-11-19 03:39 ` Michael Paquier <michael@paquier.xyz>
2020-11-23 20:31 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-11-23 21:20 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-11-23 21:28 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-11-23 22:02 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-11-23 22:10 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-11-23 22:32 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-11-23 22:38 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-11-23 22:41 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-11-23 22:48 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-11-23 22:45 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-11-23 23:02 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-11-23 23:13 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-11-24 02:03 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-11-24 02:04 ` Michael Paquier <michael@paquier.xyz>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox