public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v3 08/10] ci: switch tasks to debugoptimized build
10+ messages / 5 participants
[nested] [flat]
* [PATCH v3 08/10] ci: switch tasks to debugoptimized build
@ 2023-08-08 00:27 Andres Freund <[email protected]>
0 siblings, 0 replies; 10+ messages in thread
From: Andres Freund @ 2023-08-08 00:27 UTC (permalink / raw)
In aggregate the CI tasks burn a lot of cpu hours. Compared to that easy to
read backtraces aren't as important. Still use -ggdb where appropriate, as
that does make backtraces more reliable, particularly in the face of
optimization.
Author:
Reviewed-by:
Discussion: https://postgr.es/m/
Backpatch:
---
.cirrus.tasks.yml | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/.cirrus.tasks.yml b/.cirrus.tasks.yml
index e137769850d..d1730ce08a8 100644
--- a/.cirrus.tasks.yml
+++ b/.cirrus.tasks.yml
@@ -136,7 +136,7 @@ task:
CCACHE_DIR: /tmp/ccache_dir
CPPFLAGS: -DRELCACHE_FORCE_RELEASE -DCOPY_PARSE_PLAN_TREES -DWRITE_READ_PARSE_PLAN_TREES -DRAW_EXPRESSION_COVERAGE_TEST -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS
- CFLAGS: -Og -ggdb
+ CFLAGS: -ggdb
<<: *freebsd_task_template
@@ -171,7 +171,7 @@ task:
configure_script: |
su postgres <<-EOF
meson setup \
- --buildtype=debug \
+ --buildtype=debugoptimized \
-Dcassert=true -Duuid=bsd -Dtcl_version=tcl86 -Ddtrace=auto \
-DPG_TEST_EXTRA="$PG_TEST_EXTRA" \
-Dextra_lib_dirs=/usr/local/lib -Dextra_include_dirs=/usr/local/include/ \
@@ -266,7 +266,7 @@ task:
ASAN_OPTIONS: print_stacktrace=1:disable_coredump=0:abort_on_error=1:detect_leaks=0
# SANITIZER_FLAGS is set in the tasks below
- CFLAGS: -Og -ggdb -fno-sanitize-recover=all $SANITIZER_FLAGS
+ CFLAGS: -ggdb -fno-sanitize-recover=all $SANITIZER_FLAGS
CXXFLAGS: $CFLAGS
LDFLAGS: $SANITIZER_FLAGS
CC: ccache gcc
@@ -356,7 +356,7 @@ task:
configure_script: |
su postgres <<-EOF
meson setup \
- --buildtype=debug \
+ --buildtype=debugoptimized \
-Dcassert=true \
${LINUX_MESON_FEATURES} \
-DPG_TEST_EXTRA="$PG_TEST_EXTRA" \
@@ -369,7 +369,7 @@ task:
su postgres <<-EOF
export CC='ccache gcc -m32'
meson setup \
- --buildtype=debug \
+ --buildtype=debugoptimized \
-Dcassert=true \
${LINUX_MESON_FEATURES} \
-Dllvm=disabled \
@@ -427,8 +427,8 @@ task:
CC: ccache cc
CXX: ccache c++
- CFLAGS: -Og -ggdb
- CXXFLAGS: -Og -ggdb
+ CFLAGS: -ggdb
+ CXXFLAGS: -ggdb
<<: *macos_task_template
@@ -479,7 +479,7 @@ task:
configure_script: |
export PKG_CONFIG_PATH="/opt/local/lib/pkgconfig/"
meson setup \
- --buildtype=debug \
+ --buildtype=debugoptimized \
-Dextra_include_dirs=/opt/local/include \
-Dextra_lib_dirs=/opt/local/lib \
-Dcassert=true \
--
2.38.0
--uh2yukyzfvojbe2k
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v3-0009-ci-windows-Disabling-write-cache-flushing-during-.patch"
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] LockAcquireExtended improvement
@ 2024-03-12 03:11 Jingxian Li <[email protected]>
2024-03-12 13:33 ` Re: [PATCH] LockAcquireExtended improvement Robert Haas <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Jingxian Li @ 2024-03-12 03:11 UTC (permalink / raw)
To: robertmhaas <[email protected]>; +Cc: andres <[email protected]>; PostgreSQL Hackers <[email protected]>
Hello Robert,
On 2024/3/8 1:02, Robert Haas wrote:
>
> But instead of just complaining, I decided to try writing a version of
> the patch that seemed acceptable to me. Here it is. I took a different
> approach than you. Instead of splitting up ProcSleep(), I just passed
> down the dontWait flag to WaitOnLock() and ProcSleep(). In
> LockAcquireExtended(), I moved the existing code that handles giving
> up in the don't-wait case from before the call to ProcSleep() to
> afterward. As far as I can see, the major way this could be wrong is
> if calling ProcSleep() with dontWait = true and having it fail to
> acquire the lock changes the state in some way that makes the cleanup
> code that I moved incorrect. I don't *think* that's the case, but I
> might be wrong.
>
> What do you think of this version?
Your version changes less code than mine by pushing the nowait flag down
into ProcSleep(). This looks fine in general, except for a little advice,
which I don't think there is necessary to add 'waiting' suffix to the
process name in function WaitOnLock with dontwait being true, as follows:
--- a/src/backend/storage/lmgr/lock.c
+++ b/src/backend/storage/lmgr/lock.c
@@ -1801,8 +1801,12 @@ WaitOnLock(LOCALLOCK *locallock, ResourceOwner owner, bool dontWait)
LOCK_PRINT("WaitOnLock: sleeping on lock",
locallock->lock, locallock->tag.mode);
- /* adjust the process title to indicate that it's waiting */
- set_ps_display_suffix("waiting");
+ if (!dontWait)
+ {
+ /* adjust the process title to indicate that it's waiting */
+ set_ps_display_suffix("waiting");
+ }
+
awaitedLock = locallock;
awaitedOwner = owner;
@@ -1855,9 +1859,12 @@ WaitOnLock(LOCALLOCK *locallock, ResourceOwner owner, bool dontWait)
{
/* In this path, awaitedLock remains set until LockErrorCleanup */
- /* reset ps display to remove the suffix */
- set_ps_display_remove_suffix();
-
+ if (!dontWait)
+ {
+ /* reset ps display to remove the suffix */
+ set_ps_display_remove_suffix();
+ }
+
/* and propagate the error */
PG_RE_THROW();
}
@@ -1865,8 +1872,11 @@ WaitOnLock(LOCALLOCK *locallock, ResourceOwner owner, bool dontWait)
awaitedLock = NULL;
- /* reset ps display to remove the suffix */
- set_ps_display_remove_suffix();
+ if (!dontWait)
+ {
+ /* reset ps display to remove the suffix */
+ set_ps_display_remove_suffix();
+ }
LOCK_PRINT("WaitOnLock: wakeup on lock",
locallock->lock, locallock->tag.mode);
--
Jingxian Li
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] LockAcquireExtended improvement
2024-03-12 03:11 Re: [PATCH] LockAcquireExtended improvement Jingxian Li <[email protected]>
@ 2024-03-12 13:33 ` Robert Haas <[email protected]>
2024-03-14 13:15 ` Re: [PATCH] LockAcquireExtended improvement Robert Haas <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Robert Haas @ 2024-03-12 13:33 UTC (permalink / raw)
To: Jingxian Li <[email protected]>; +Cc: andres <[email protected]>; PostgreSQL Hackers <[email protected]>
On Mon, Mar 11, 2024 at 11:11 PM Jingxian Li <[email protected]> wrote:
> Your version changes less code than mine by pushing the nowait flag down
> into ProcSleep(). This looks fine in general, except for a little advice,
> which I don't think there is necessary to add 'waiting' suffix to the
> process name in function WaitOnLock with dontwait being true, as follows:
That could be done, but in my opinion it's not necessary. The waiting
suffix will appear only very briefly, and probably only in relatively
rare cases. It doesn't seem worth adding code to avoid it.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] LockAcquireExtended improvement
2024-03-12 03:11 Re: [PATCH] LockAcquireExtended improvement Jingxian Li <[email protected]>
2024-03-12 13:33 ` Re: [PATCH] LockAcquireExtended improvement Robert Haas <[email protected]>
@ 2024-03-14 13:15 ` Robert Haas <[email protected]>
2024-03-27 02:14 ` Re: [PATCH] LockAcquireExtended improvement Will Mortensen <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Robert Haas @ 2024-03-14 13:15 UTC (permalink / raw)
To: Jingxian Li <[email protected]>; +Cc: andres <[email protected]>; PostgreSQL Hackers <[email protected]>
On Tue, Mar 12, 2024 at 9:33 AM Robert Haas <[email protected]> wrote:
> On Mon, Mar 11, 2024 at 11:11 PM Jingxian Li <[email protected]> wrote:
> > Your version changes less code than mine by pushing the nowait flag down
> > into ProcSleep(). This looks fine in general, except for a little advice,
> > which I don't think there is necessary to add 'waiting' suffix to the
> > process name in function WaitOnLock with dontwait being true, as follows:
>
> That could be done, but in my opinion it's not necessary. The waiting
> suffix will appear only very briefly, and probably only in relatively
> rare cases. It doesn't seem worth adding code to avoid it.
Seeing no further discussion, I have committed my version of this
patch, with your test case.
Thanks for pursuing this improvement!
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] LockAcquireExtended improvement
2024-03-12 03:11 Re: [PATCH] LockAcquireExtended improvement Jingxian Li <[email protected]>
2024-03-12 13:33 ` Re: [PATCH] LockAcquireExtended improvement Robert Haas <[email protected]>
2024-03-14 13:15 ` Re: [PATCH] LockAcquireExtended improvement Robert Haas <[email protected]>
@ 2024-03-27 02:14 ` Will Mortensen <[email protected]>
2024-05-18 06:38 ` Re: [PATCH] LockAcquireExtended improvement Will Mortensen <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Will Mortensen @ 2024-03-27 02:14 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Jingxian Li <[email protected]>; andres <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Mar 14, 2024 at 1:15 PM Robert Haas <[email protected]> wrote:
> Seeing no further discussion, I have committed my version of this
> patch, with your test case.
This comment on ProcSleep() seems to have the values of dontWait
backward (double negatives are tricky):
* Result: PROC_WAIT_STATUS_OK if we acquired the lock,
PROC_WAIT_STATUS_ERROR
* if not (if dontWait = true, this is a deadlock; if dontWait = false, we
* would have had to wait).
Also there's a minor typo in a comment in LockAcquireExtended():
* Check the proclock entry status. If dontWait = true, this is an
* expected case; otherwise, it will open happen if something in the
* ipc communication doesn't work correctly.
"open" should be "only".
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] LockAcquireExtended improvement
2024-03-12 03:11 Re: [PATCH] LockAcquireExtended improvement Jingxian Li <[email protected]>
2024-03-12 13:33 ` Re: [PATCH] LockAcquireExtended improvement Robert Haas <[email protected]>
2024-03-14 13:15 ` Re: [PATCH] LockAcquireExtended improvement Robert Haas <[email protected]>
2024-03-27 02:14 ` Re: [PATCH] LockAcquireExtended improvement Will Mortensen <[email protected]>
@ 2024-05-18 06:38 ` Will Mortensen <[email protected]>
2024-05-18 09:10 ` Re: [PATCH] LockAcquireExtended improvement Jingxian Li <[email protected]>
2024-05-18 11:37 ` Re: [PATCH] LockAcquireExtended improvement Michael Paquier <[email protected]>
0 siblings, 2 replies; 10+ messages in thread
From: Will Mortensen @ 2024-05-18 06:38 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Jingxian Li <[email protected]>; andres <[email protected]>; PostgreSQL Hackers <[email protected]>
On Tue, Mar 26, 2024 at 7:14 PM Will Mortensen <[email protected]> wrote:
> This comment on ProcSleep() seems to have the values of dontWait
> backward (double negatives are tricky):
>
> * Result: PROC_WAIT_STATUS_OK if we acquired the lock,
> PROC_WAIT_STATUS_ERROR
> * if not (if dontWait = true, this is a deadlock; if dontWait = false, we
> * would have had to wait).
>
> Also there's a minor typo in a comment in LockAcquireExtended():
>
> * Check the proclock entry status. If dontWait = true, this is an
> * expected case; otherwise, it will open happen if something in the
> * ipc communication doesn't work correctly.
>
> "open" should be "only".
Here's a patch fixing those typos.
Attachments:
[application/octet-stream] v1-0001-Fix-typos-from-LOCK-NOWAIT-improvement.patch (1.6K, ../../CAMpnoC7uymaewKschMUy5703xfi31ivjZiFKyurjQ=MWqLnP-Q@mail.gmail.com/2-v1-0001-Fix-typos-from-LOCK-NOWAIT-improvement.patch)
download | inline diff:
From b1183a287f882ba32ebeba3271f1eb682423c449 Mon Sep 17 00:00:00 2001
From: Will Mortensen <[email protected]>
Date: Fri, 17 May 2024 23:32:47 -0700
Subject: [PATCH v1 1/1] Fix typos from LOCK NOWAIT improvement
(namely 2346df6fc373df9c5ab944eebecf7d3036d727de)
---
src/backend/storage/lmgr/lock.c | 2 +-
src/backend/storage/lmgr/proc.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c
index 9e4ddf7225..f68c595c8a 100644
--- a/src/backend/storage/lmgr/lock.c
+++ b/src/backend/storage/lmgr/lock.c
@@ -1060,7 +1060,7 @@ LockAcquireExtended(const LOCKTAG *locktag,
/*
* Check the proclock entry status. If dontWait = true, this is an
- * expected case; otherwise, it will open happen if something in the
+ * expected case; otherwise, it will only happen if something in the
* ipc communication doesn't work correctly.
*/
if (!(proclock->holdMask & LOCKBIT_ON(lockmode)))
diff --git a/src/backend/storage/lmgr/proc.c b/src/backend/storage/lmgr/proc.c
index a2900b6014..ce29da9012 100644
--- a/src/backend/storage/lmgr/proc.c
+++ b/src/backend/storage/lmgr/proc.c
@@ -1054,8 +1054,8 @@ AuxiliaryPidGetProc(int pid)
* at exit.
*
* Result: PROC_WAIT_STATUS_OK if we acquired the lock, PROC_WAIT_STATUS_ERROR
- * if not (if dontWait = true, this is a deadlock; if dontWait = false, we
- * would have had to wait).
+ * if not (if dontWait = true, we would have had to wait; if dontWait = false,
+ * this is a deadlock).
*
* ASSUME: that no one will fiddle with the queue until after
* we release the partition lock.
--
2.34.1
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] LockAcquireExtended improvement
2024-03-12 03:11 Re: [PATCH] LockAcquireExtended improvement Jingxian Li <[email protected]>
2024-03-12 13:33 ` Re: [PATCH] LockAcquireExtended improvement Robert Haas <[email protected]>
2024-03-14 13:15 ` Re: [PATCH] LockAcquireExtended improvement Robert Haas <[email protected]>
2024-03-27 02:14 ` Re: [PATCH] LockAcquireExtended improvement Will Mortensen <[email protected]>
2024-05-18 06:38 ` Re: [PATCH] LockAcquireExtended improvement Will Mortensen <[email protected]>
@ 2024-05-18 09:10 ` Jingxian Li <[email protected]>
2024-05-23 04:58 ` Re: [PATCH] LockAcquireExtended improvement Michael Paquier <[email protected]>
1 sibling, 1 reply; 10+ messages in thread
From: Jingxian Li @ 2024-05-18 09:10 UTC (permalink / raw)
To: Will Mortensen <[email protected]>; robertmhaas <[email protected]>; +Cc: andres <[email protected]>; PostgreSQL Hackers <[email protected]>
On 2024/5/18 14:38, Will Mortensen wrote:
> On Tue, Mar 26, 2024 at 7:14 PM Will Mortensen <[email protected]> wrote:
>> This comment on ProcSleep() seems to have the values of dontWait
>> backward (double negatives are tricky):
>>
>> * Result: PROC_WAIT_STATUS_OK if we acquired the lock,
>> PROC_WAIT_STATUS_ERROR
>> * if not (if dontWait = true, this is a deadlock; if dontWait = false, we
>> * would have had to wait).
>>
>> Also there's a minor typo in a comment in LockAcquireExtended():
>>
>> * Check the proclock entry status. If dontWait = true, this is an
>> * expected case; otherwise, it will open happen if something in the
>> * ipc communication doesn't work correctly.
>>
>> "open" should be "only".
>
> Here's a patch fixing those typos.
Nice catch! The patch looks good to me.
--
Jingxian Li
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] LockAcquireExtended improvement
2024-03-12 03:11 Re: [PATCH] LockAcquireExtended improvement Jingxian Li <[email protected]>
2024-03-12 13:33 ` Re: [PATCH] LockAcquireExtended improvement Robert Haas <[email protected]>
2024-03-14 13:15 ` Re: [PATCH] LockAcquireExtended improvement Robert Haas <[email protected]>
2024-03-27 02:14 ` Re: [PATCH] LockAcquireExtended improvement Will Mortensen <[email protected]>
2024-05-18 06:38 ` Re: [PATCH] LockAcquireExtended improvement Will Mortensen <[email protected]>
2024-05-18 09:10 ` Re: [PATCH] LockAcquireExtended improvement Jingxian Li <[email protected]>
@ 2024-05-23 04:58 ` Michael Paquier <[email protected]>
2024-05-23 05:21 ` Re: [PATCH] LockAcquireExtended improvement Will Mortensen <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Michael Paquier @ 2024-05-23 04:58 UTC (permalink / raw)
To: Jingxian Li <[email protected]>; +Cc: Will Mortensen <[email protected]>; robertmhaas <[email protected]>; andres <[email protected]>; PostgreSQL Hackers <[email protected]>
On Sat, May 18, 2024 at 05:10:38PM +0800, Jingxian Li wrote:
> Nice catch! The patch looks good to me.
And fixed that as well.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] LockAcquireExtended improvement
2024-03-12 03:11 Re: [PATCH] LockAcquireExtended improvement Jingxian Li <[email protected]>
2024-03-12 13:33 ` Re: [PATCH] LockAcquireExtended improvement Robert Haas <[email protected]>
2024-03-14 13:15 ` Re: [PATCH] LockAcquireExtended improvement Robert Haas <[email protected]>
2024-03-27 02:14 ` Re: [PATCH] LockAcquireExtended improvement Will Mortensen <[email protected]>
2024-05-18 06:38 ` Re: [PATCH] LockAcquireExtended improvement Will Mortensen <[email protected]>
2024-05-18 09:10 ` Re: [PATCH] LockAcquireExtended improvement Jingxian Li <[email protected]>
2024-05-23 04:58 ` Re: [PATCH] LockAcquireExtended improvement Michael Paquier <[email protected]>
@ 2024-05-23 05:21 ` Will Mortensen <[email protected]>
0 siblings, 0 replies; 10+ messages in thread
From: Will Mortensen @ 2024-05-23 05:21 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Jingxian Li <[email protected]>; robertmhaas <[email protected]>; andres <[email protected]>; PostgreSQL Hackers <[email protected]>
Thanks! :-)
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] LockAcquireExtended improvement
2024-03-12 03:11 Re: [PATCH] LockAcquireExtended improvement Jingxian Li <[email protected]>
2024-03-12 13:33 ` Re: [PATCH] LockAcquireExtended improvement Robert Haas <[email protected]>
2024-03-14 13:15 ` Re: [PATCH] LockAcquireExtended improvement Robert Haas <[email protected]>
2024-03-27 02:14 ` Re: [PATCH] LockAcquireExtended improvement Will Mortensen <[email protected]>
2024-05-18 06:38 ` Re: [PATCH] LockAcquireExtended improvement Will Mortensen <[email protected]>
@ 2024-05-18 11:37 ` Michael Paquier <[email protected]>
1 sibling, 0 replies; 10+ messages in thread
From: Michael Paquier @ 2024-05-18 11:37 UTC (permalink / raw)
To: Will Mortensen <[email protected]>; +Cc: Robert Haas <[email protected]>; Jingxian Li <[email protected]>; andres <[email protected]>; PostgreSQL Hackers <[email protected]>
On Fri, May 17, 2024 at 11:38:35PM -0700, Will Mortensen wrote:
> On Tue, Mar 26, 2024 at 7:14 PM Will Mortensen <[email protected]> wrote:
>> This comment on ProcSleep() seems to have the values of dontWait
>> backward (double negatives are tricky):
>>
>> * Result: PROC_WAIT_STATUS_OK if we acquired the lock,
>> PROC_WAIT_STATUS_ERROR
>> * if not (if dontWait = true, this is a deadlock; if dontWait = false, we
>> * would have had to wait).
>>
>> Also there's a minor typo in a comment in LockAcquireExtended():
>>
>> * Check the proclock entry status. If dontWait = true, this is an
>> * expected case; otherwise, it will open happen if something in the
>> * ipc communication doesn't work correctly.
>>
>> "open" should be "only".
>
> Here's a patch fixing those typos.
Perhaps, this, err.. Should not have been named "dontWait" but
"doWait" ;)
Anyway, this goes way back in time and it is deep in the stack
(LockAcquireExtended, etc.) so it is too late to change: the patch
should be OK as it is.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2024-05-23 05:21 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-08-08 00:27 [PATCH v3 08/10] ci: switch tasks to debugoptimized build Andres Freund <[email protected]>
2024-03-12 03:11 Re: [PATCH] LockAcquireExtended improvement Jingxian Li <[email protected]>
2024-03-12 13:33 ` Re: [PATCH] LockAcquireExtended improvement Robert Haas <[email protected]>
2024-03-14 13:15 ` Re: [PATCH] LockAcquireExtended improvement Robert Haas <[email protected]>
2024-03-27 02:14 ` Re: [PATCH] LockAcquireExtended improvement Will Mortensen <[email protected]>
2024-05-18 06:38 ` Re: [PATCH] LockAcquireExtended improvement Will Mortensen <[email protected]>
2024-05-18 09:10 ` Re: [PATCH] LockAcquireExtended improvement Jingxian Li <[email protected]>
2024-05-23 04:58 ` Re: [PATCH] LockAcquireExtended improvement Michael Paquier <[email protected]>
2024-05-23 05:21 ` Re: [PATCH] LockAcquireExtended improvement Will Mortensen <[email protected]>
2024-05-18 11:37 ` Re: [PATCH] LockAcquireExtended improvement Michael Paquier <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox