public inbox for [email protected]
help / color / mirror / Atom feedRe: When IMMUTABLE is not.
10+ messages / 6 participants
[nested] [flat]
* Re: When IMMUTABLE is not.
@ 2023-06-15 13:58 [email protected]
2023-06-15 14:06 ` Re: When IMMUTABLE is not. Yura Sokolov <[email protected]>
2023-06-15 14:10 ` Re: When IMMUTABLE is not. Tom Lane <[email protected]>
2023-06-15 14:16 ` Re: When IMMUTABLE is not. [email protected]
0 siblings, 3 replies; 10+ messages in thread
From: [email protected] @ 2023-06-15 13:58 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Yura Sokolov <[email protected]>; [email protected]
On 2023-06-15 09:21, Tom Lane wrote:
> Yura Sokolov <[email protected]> writes:
>> not enough to be sure function doesn't manipulate data.
>
> Of course not. It is the user's responsibility to mark functions
> properly.
And also, isn't it the case that IMMUTABLE should mark a function,
not merely that "doesn't manipulate data", but whose return value
doesn't depend in any way on data (outside its own arguments)?
The practice among PLs of choosing an SPI readonly flag based on
the IMMUTABLE/STABLE/VOLATILE declaration seems to be a sort of
peculiar heuristic, not something inherent in what that declaration
means to the optimizer. (And also influences what snapshot the
function is looking at, and therefore what it can see, which has
also struck me more as a tacked-on effect than something inherent
in the declaration's meaning.)
Regards,
-Chap
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: When IMMUTABLE is not.
2023-06-15 13:58 Re: When IMMUTABLE is not. [email protected]
@ 2023-06-15 14:06 ` Yura Sokolov <[email protected]>
2 siblings, 0 replies; 10+ messages in thread
From: Yura Sokolov @ 2023-06-15 14:06 UTC (permalink / raw)
To: [email protected]; Tom Lane <[email protected]>; +Cc: [email protected]
15.06.2023 16:58, [email protected] пишет:
> On 2023-06-15 09:21, Tom Lane wrote:
>> Yura Sokolov <[email protected]> writes:
>>> not enough to be sure function doesn't manipulate data.
>>
>> Of course not. It is the user's responsibility to mark functions
>> properly.
>
> And also, isn't it the case that IMMUTABLE should mark a function,
> not merely that "doesn't manipulate data", but whose return value
> doesn't depend in any way on data (outside its own arguments)?
>
> The practice among PLs of choosing an SPI readonly flag based on
> the IMMUTABLE/STABLE/VOLATILE declaration seems to be a sort of
> peculiar heuristic, not something inherent in what that declaration
> means to the optimizer. (And also influences what snapshot the
> function is looking at, and therefore what it can see, which has
> also struck me more as a tacked-on effect than something inherent
> in the declaration's meaning.)
Documentation disagrees:
https://www.postgresql.org/docs/current/sql-createfunction.html#:~:text=IMMUTABLE%0ASTABLE%0AVOLATIL...
> |IMMUTABLE|indicates that the function cannot modify the database and
always returns the same result when given the same argument values
> |STABLE|indicates that the function cannot modify the database, and
that within a single table scan it will consistently return the same
result for the same argument values, but that its result could change
across SQL statements.
> |VOLATILE|indicates that the function value can change even within a
single table scan, so no optimizations can be made... But note that any
function that has side-effects must be classified volatile, even if its
result is quite predictable, to prevent calls from being optimized away
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: When IMMUTABLE is not.
2023-06-15 13:58 Re: When IMMUTABLE is not. [email protected]
@ 2023-06-15 14:10 ` Tom Lane <[email protected]>
2 siblings, 0 replies; 10+ messages in thread
From: Tom Lane @ 2023-06-15 14:10 UTC (permalink / raw)
To: [email protected]; +Cc: Yura Sokolov <[email protected]>; [email protected]
[email protected] writes:
> And also, isn't it the case that IMMUTABLE should mark a function,
> not merely that "doesn't manipulate data", but whose return value
> doesn't depend in any way on data (outside its own arguments)?
Right. We can't realistically enforce that either, so it's
up to the user.
> The practice among PLs of choosing an SPI readonly flag based on
> the IMMUTABLE/STABLE/VOLATILE declaration seems to be a sort of
> peculiar heuristic, not something inherent in what that declaration
> means to the optimizer. (And also influences what snapshot the
> function is looking at, and therefore what it can see, which has
> also struck me more as a tacked-on effect than something inherent
> in the declaration's meaning.)
Well, it is a bit odd at first sight, but these properties play
together well. See
https://www.postgresql.org/docs/current/xfunc-volatility.html
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: When IMMUTABLE is not.
2023-06-15 13:58 Re: When IMMUTABLE is not. [email protected]
@ 2023-06-15 14:16 ` [email protected]
2023-06-15 14:19 ` Re: When IMMUTABLE is not. David G. Johnston <[email protected]>
2 siblings, 1 reply; 10+ messages in thread
From: [email protected] @ 2023-06-15 14:16 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Yura Sokolov <[email protected]>; [email protected]
On 2023-06-15 09:58, [email protected] wrote:
> also influences what snapshot the
> function is looking at, and therefore what it can see, which has
> also struck me more as a tacked-on effect than something inherent
> in the declaration's meaning.
I just re-read that and realized I should anticipate the obvious
response "but how can it matter what the function can see, if
it's IMMUTABLE and depends on no data?".
So, I ran into the effect while working on PL/Java, where the
code of a function isn't all found in pg_proc.prosrc; that just
indicates what code has to be fetched from sqlj.jar_entry.
So one could take a strict view that "no PL/Java function should
ever be marked IMMUTABLE" because every one depends on fetching
something (once, at least).
But on the other hand, it would seem punctilious to say that
f(int x, int y) { return x + y; } isn't IMMUTABLE, only because
it depends on a fetch /of its own implementation/, and overall
its behavior is better described by marking it IMMUTABLE.
Regards,
-Chap
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: When IMMUTABLE is not.
2023-06-15 13:58 Re: When IMMUTABLE is not. [email protected]
2023-06-15 14:16 ` Re: When IMMUTABLE is not. [email protected]
@ 2023-06-15 14:19 ` David G. Johnston <[email protected]>
2023-06-15 14:25 ` Re: When IMMUTABLE is not. [email protected]
2023-06-15 14:49 ` Re: When IMMUTABLE is not. Tom Lane <[email protected]>
0 siblings, 2 replies; 10+ messages in thread
From: David G. Johnston @ 2023-06-15 14:19 UTC (permalink / raw)
To: [email protected] <[email protected]>; +Cc: Tom Lane <[email protected]>; Yura Sokolov <[email protected]>; [email protected] <[email protected]>
On Thursday, June 15, 2023, <[email protected]> wrote:
>
> So one could take a strict view that "no PL/Java function should
> ever be marked IMMUTABLE" because every one depends on fetching
> something (once, at least).
>
The failure to find and execute the function code itself is not a failure
mode that these markers need be concerned with. Assuming one can execute
the function an immutable function will give the same answer for the same
input for all time.
David J.
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: When IMMUTABLE is not.
2023-06-15 13:58 Re: When IMMUTABLE is not. [email protected]
2023-06-15 14:16 ` Re: When IMMUTABLE is not. [email protected]
2023-06-15 14:19 ` Re: When IMMUTABLE is not. David G. Johnston <[email protected]>
@ 2023-06-15 14:25 ` [email protected]
1 sibling, 0 replies; 10+ messages in thread
From: [email protected] @ 2023-06-15 14:25 UTC (permalink / raw)
To: David G. Johnston <[email protected]>; +Cc: Tom Lane <[email protected]>; Yura Sokolov <[email protected]>; [email protected]
On 2023-06-15 10:19, David G. Johnston wrote:
> The failure to find and execute the function code itself is not a
> failure
> mode that these markers need be concerned with. Assuming one can
> execute
> the function an immutable function will give the same answer for the
> same
> input for all time.
That was the view I ultimately took, and just made PL/Java suppress that
SPI readonly flag when going to look for the function code.
Until that change, you could run into the not-uncommon situation
where you've just loaded a jar of new functions and try to use them
in the same transaction, and hey presto, the VOLATILE ones all work,
and the IMMUTABLE ones aren't there yet.
Regards,
-Chap
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: When IMMUTABLE is not.
2023-06-15 13:58 Re: When IMMUTABLE is not. [email protected]
2023-06-15 14:16 ` Re: When IMMUTABLE is not. [email protected]
2023-06-15 14:19 ` Re: When IMMUTABLE is not. David G. Johnston <[email protected]>
@ 2023-06-15 14:49 ` Tom Lane <[email protected]>
2023-06-15 14:55 ` Re: When IMMUTABLE is not. Isaac Morland <[email protected]>
2023-06-15 16:33 ` Re: When IMMUTABLE is not. Yura Sokolov <[email protected]>
1 sibling, 2 replies; 10+ messages in thread
From: Tom Lane @ 2023-06-15 14:49 UTC (permalink / raw)
To: David G. Johnston <[email protected]>; +Cc: [email protected] <[email protected]>; Yura Sokolov <[email protected]>; [email protected] <[email protected]>
"David G. Johnston" <[email protected]> writes:
> The failure to find and execute the function code itself is not a failure
> mode that these markers need be concerned with. Assuming one can execute
> the function an immutable function will give the same answer for the same
> input for all time.
The viewpoint taken in the docs I mentioned is that an IMMUTABLE
marker is a promise from the user to the system about the behavior
of a function. While the system does provide a few simple tools
to catch obvious errors and to make it easier to write functions
that obey such promises, it's mostly on the user to get it right.
In particular, we've never enforced that an immutable function can't
call non-immutable functions. While that would seem like a good idea
in the abstract, we've intentionally not tried to do it. (I'm pretty
sure there is more than one round of previous discussions of the point
in the archives, although locating relevant threads seems hard.)
One reason not to is that polymorphic functions have to be marked
with worst-case volatility labels. There are plenty of examples of
functions that are stable for some input types and immutable for
others (array_to_string, for instance); but the marking system can't
represent that so we have to label them stable. Enforcing that a
user-defined immutable function can't use such a function might
just break things for no gain.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: When IMMUTABLE is not.
2023-06-15 13:58 Re: When IMMUTABLE is not. [email protected]
2023-06-15 14:16 ` Re: When IMMUTABLE is not. [email protected]
2023-06-15 14:19 ` Re: When IMMUTABLE is not. David G. Johnston <[email protected]>
2023-06-15 14:49 ` Re: When IMMUTABLE is not. Tom Lane <[email protected]>
@ 2023-06-15 14:55 ` Isaac Morland <[email protected]>
1 sibling, 0 replies; 10+ messages in thread
From: Isaac Morland @ 2023-06-15 14:55 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: David G. Johnston <[email protected]>; [email protected] <[email protected]>; Yura Sokolov <[email protected]>; [email protected] <[email protected]>
On Thu, 15 Jun 2023 at 10:49, Tom Lane <[email protected]> wrote:
In particular, we've never enforced that an immutable function can't
> call non-immutable functions. While that would seem like a good idea
> in the abstract, we've intentionally not tried to do it. (I'm pretty
> sure there is more than one round of previous discussions of the point
> in the archives, although locating relevant threads seems hard.)
> One reason not to is that polymorphic functions have to be marked
> with worst-case volatility labels. There are plenty of examples of
> functions that are stable for some input types and immutable for
> others (array_to_string, for instance); but the marking system can't
> represent that so we have to label them stable. Enforcing that a
> user-defined immutable function can't use such a function might
> just break things for no gain.
>
More sophisticated type systems (which I am *not* volunteering to graft
onto Postgres) can handle some of this, but even Haskell has
unsafePerformIO. The current policy is both wise and practical.
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: When IMMUTABLE is not.
2023-06-15 13:58 Re: When IMMUTABLE is not. [email protected]
2023-06-15 14:16 ` Re: When IMMUTABLE is not. [email protected]
2023-06-15 14:19 ` Re: When IMMUTABLE is not. David G. Johnston <[email protected]>
2023-06-15 14:49 ` Re: When IMMUTABLE is not. Tom Lane <[email protected]>
@ 2023-06-15 16:33 ` Yura Sokolov <[email protected]>
1 sibling, 0 replies; 10+ messages in thread
From: Yura Sokolov @ 2023-06-15 16:33 UTC (permalink / raw)
To: Tom Lane <[email protected]>; David G. Johnston <[email protected]>; +Cc: [email protected] <[email protected]>; [email protected] <[email protected]>
15.06.2023 17:49, Tom Lane пишет:
> "David G. Johnston" <[email protected]> writes:
>> The failure to find and execute the function code itself is not a failure
>> mode that these markers need be concerned with. Assuming one can execute
>> the function an immutable function will give the same answer for the same
>> input for all time.
> The viewpoint taken in the docs I mentioned is that an IMMUTABLE
> marker is a promise from the user to the system about the behavior
> of a function. While the system does provide a few simple tools
> to catch obvious errors and to make it easier to write functions
> that obey such promises, it's mostly on the user to get it right.
>
> In particular, we've never enforced that an immutable function can't
> call non-immutable functions. While that would seem like a good idea
> in the abstract, we've intentionally not tried to do it. (I'm pretty
> sure there is more than one round of previous discussions of the point
> in the archives, although locating relevant threads seems hard.)
> One reason not to is that polymorphic functions have to be marked
> with worst-case volatility labels. There are plenty of examples of
> functions that are stable for some input types and immutable for
> others (array_to_string, for instance); but the marking system can't
> represent that so we have to label them stable. Enforcing that a
> user-defined immutable function can't use such a function might
> just break things for no gain.
"Stable vs Immutable" is much lesser problem compared to "ReadOnly vs
Volatile".
Executing fairly read-only function more times than necessary (or less
times),
doesn't modify data in unexpecting way.
But executing immutable/stable function, that occasionally modifies
data, could
lead to different unexpected effects due to optimizer decided to call
them more
or less times than query assumes.
Some vulnerabilities were present due to user defined functions used in
index
definitions started to modify data. If "read-only" execution were forced
in index
operations, those issues couldn't happen.
> it's mostly on the user to get it right.
It is really bad premise. Users does strange things and aren't expected
to be
professionals who really understand whole PostgreSQL internals.
And it is strange to hear it at the same time we don't allow users to do
query hints
since "optimizer does better" :-D
Ok, I'd go and cool myself. Certainly I don't get some point.
^ permalink raw reply [nested|flat] 10+ messages in thread
* [PATCH v52 04/10] Fix a few problems in index build progress reporting.
@ 2026-03-27 15:50 Álvaro Herrera <[email protected]>
0 siblings, 0 replies; 10+ messages in thread
From: Álvaro Herrera @ 2026-03-27 15:50 UTC (permalink / raw)
First, index_build() should not update the progress when being driven by
REPACK, because the progress reporting infractructure cannot handle status of
two commands at the same time. So far, REPACK with the CONCURRENTLY option
neglected this problem altogether, but even the existing REPACK wasn't
consistent enough: even if the 'progress' variable in repack_index() was
false, it didn't pass the value to index_build().
Second, REPACK (CONCURRENTLY) should not set PROGRESS_REPACK_PHASE to
PROGRESS_REPACK_PHASE_FINAL_CLEANUP in rebuild_relation() because it calls
finish_heap_swap() anyway (via rebuild_relation_finish_concurrent()), which
does the same thing.
---
src/backend/bootstrap/bootstrap.c | 2 +-
src/backend/catalog/heap.c | 3 ++-
src/backend/catalog/index.c | 22 ++++++++++++++++++----
src/backend/catalog/toasting.c | 3 ++-
src/backend/commands/indexcmds.c | 1 +
src/include/catalog/index.h | 4 +++-
6 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/src/backend/bootstrap/bootstrap.c b/src/backend/bootstrap/bootstrap.c
index 38ef683d4c7..60fb7051830 100644
--- a/src/backend/bootstrap/bootstrap.c
+++ b/src/backend/bootstrap/bootstrap.c
@@ -1183,7 +1183,7 @@ build_indices(void)
heap = table_open(ILHead->il_heap, NoLock);
ind = index_open(ILHead->il_ind, NoLock);
- index_build(heap, ind, ILHead->il_info, false, false);
+ index_build(heap, ind, ILHead->il_info, false, false, false);
index_close(ind, NoLock);
table_close(heap, NoLock);
diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c
index 5748aa9a1a9..ae6b7cda3dd 100644
--- a/src/backend/catalog/heap.c
+++ b/src/backend/catalog/heap.c
@@ -3570,7 +3570,8 @@ RelationTruncateIndexes(Relation heapRelation)
/* Initialize the index and rebuild */
/* Note: we do not need to re-establish pkey setting */
- index_build(heapRelation, currentIndex, indexInfo, true, false);
+ index_build(heapRelation, currentIndex, indexInfo, true, false,
+ true);
/* We're done with this index */
index_close(currentIndex, NoLock);
diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c
index e418d67e8e4..4b8ed2c7660 100644
--- a/src/backend/catalog/index.c
+++ b/src/backend/catalog/index.c
@@ -715,6 +715,9 @@ UpdateIndexRelation(Oid indexoid,
* already exists.
* INDEX_CREATE_PARTITIONED:
* create a partitioned index (table must be partitioned)
+ * INDEX_CREATE_REPORT_PROGRESS:
+ * update the backend's progress information during index build.
+
* constr_flags: flags passed to index_constraint_create
* (only if INDEX_CREATE_ADD_CONSTRAINT is set)
* allow_system_table_mods: allow table to be a system catalog
@@ -760,6 +763,7 @@ index_create(Relation heapRelation,
bool invalid = (flags & INDEX_CREATE_INVALID) != 0;
bool concurrent = (flags & INDEX_CREATE_CONCURRENT) != 0;
bool partitioned = (flags & INDEX_CREATE_PARTITIONED) != 0;
+ bool progress = (flags & INDEX_CREATE_REPORT_PROGRESS) != 0;
char relkind;
TransactionId relfrozenxid;
MultiXactId relminmxid;
@@ -1276,7 +1280,8 @@ index_create(Relation heapRelation,
}
else
{
- index_build(heapRelation, indexRelation, indexInfo, false, true);
+ index_build(heapRelation, indexRelation, indexInfo, false, true,
+ progress);
}
/*
@@ -1448,6 +1453,12 @@ index_create_copy(Relation heapRelation, bool concurrently,
stattargets[i].isnull = isnull;
}
+ /*
+ * Note: The current callers do not need INDEX_CREATE_REPORT_PROGRESS. If
+ * 'concurrently' is true, there is no build at all. Otherwise the index
+ * build is a sub-command of REPACK. The current infrastructure does not
+ * allow two commands to report their progress at the same time.
+ */
if (concurrently)
flags = INDEX_CREATE_SKIP_BUILD | INDEX_CREATE_CONCURRENT;
@@ -1538,7 +1549,7 @@ index_concurrently_build(Oid heapRelationId,
indexInfo->ii_BrokenHotChain = false;
/* Now build the index */
- index_build(heapRel, indexRelation, indexInfo, false, true);
+ index_build(heapRel, indexRelation, indexInfo, false, true, true);
/* Roll back any GUC changes executed by index functions */
AtEOXact_GUC(false, save_nestlevel);
@@ -3009,6 +3020,7 @@ index_update_stats(Relation rel,
*
* isreindex indicates we are recreating a previously-existing index.
* parallel indicates if parallelism may be useful.
+ * progress indicates if the backend should update its progress info.
*
* Note: before Postgres 8.2, the passed-in heap and index Relations
* were automatically closed by this routine. This is no longer the case.
@@ -3019,7 +3031,8 @@ index_build(Relation heapRelation,
Relation indexRelation,
IndexInfo *indexInfo,
bool isreindex,
- bool parallel)
+ bool parallel,
+ bool progress)
{
IndexBuildResult *stats;
Oid save_userid;
@@ -3070,6 +3083,7 @@ index_build(Relation heapRelation,
RestrictSearchPath();
/* Set up initial progress report status */
+ if (progress)
{
const int progress_index[] = {
PROGRESS_CREATEIDX_PHASE,
@@ -3827,7 +3841,7 @@ reindex_index(const ReindexStmt *stmt, Oid indexId,
/* Initialize the index and rebuild */
/* Note: we do not need to re-establish pkey setting */
- index_build(heapRelation, iRel, indexInfo, true, true);
+ index_build(heapRelation, iRel, indexInfo, true, true, progress);
/* Re-allow use of target index */
ResetReindexProcessing();
diff --git a/src/backend/catalog/toasting.c b/src/backend/catalog/toasting.c
index 4aa52a4bd25..51b27a8c71c 100644
--- a/src/backend/catalog/toasting.c
+++ b/src/backend/catalog/toasting.c
@@ -332,7 +332,8 @@ create_toast_table(Relation rel, Oid toastOid, Oid toastIndexOid,
BTREE_AM_OID,
rel->rd_rel->reltablespace,
collationIds, opclassIds, NULL, coloptions, NULL, (Datum) 0,
- INDEX_CREATE_IS_PRIMARY, 0, true, true, NULL);
+ INDEX_CREATE_IS_PRIMARY | INDEX_CREATE_REPORT_PROGRESS, 0,
+ true, true, NULL);
table_close(toast_rel, NoLock);
diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands/indexcmds.c
index cba379810c7..932924c13e0 100644
--- a/src/backend/commands/indexcmds.c
+++ b/src/backend/commands/indexcmds.c
@@ -1231,6 +1231,7 @@ DefineIndex(ParseState *pstate,
flags |= INDEX_CREATE_PARTITIONED;
if (stmt->primary)
flags |= INDEX_CREATE_IS_PRIMARY;
+ flags |= INDEX_CREATE_REPORT_PROGRESS;
/*
* If the table is partitioned, and recursion was declined but partitions
diff --git a/src/include/catalog/index.h b/src/include/catalog/index.h
index ed9e4c37d27..7ebe4f0bd87 100644
--- a/src/include/catalog/index.h
+++ b/src/include/catalog/index.h
@@ -71,6 +71,7 @@ extern void index_check_primary_key(Relation heapRel,
#define INDEX_CREATE_IF_NOT_EXISTS (1 << 4)
#define INDEX_CREATE_PARTITIONED (1 << 5)
#define INDEX_CREATE_INVALID (1 << 6)
+#define INDEX_CREATE_REPORT_PROGRESS (1 << 7)
extern Oid index_create(Relation heapRelation,
const char *indexRelationName,
@@ -148,7 +149,8 @@ extern void index_build(Relation heapRelation,
Relation indexRelation,
IndexInfo *indexInfo,
bool isreindex,
- bool parallel);
+ bool parallel,
+ bool progress);
extern void validate_index(Oid heapId, Oid indexId, Snapshot snapshot);
--
2.47.3
--gp2pyozrd5pweboh
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v52-0005-invert-meaning-of-index_create-flag-bit.patch"
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2026-03-27 15:50 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-06-15 13:58 Re: When IMMUTABLE is not. [email protected]
2023-06-15 14:06 ` Yura Sokolov <[email protected]>
2023-06-15 14:10 ` Tom Lane <[email protected]>
2023-06-15 14:16 ` [email protected]
2023-06-15 14:19 ` David G. Johnston <[email protected]>
2023-06-15 14:25 ` [email protected]
2023-06-15 14:49 ` Tom Lane <[email protected]>
2023-06-15 14:55 ` Isaac Morland <[email protected]>
2023-06-15 16:33 ` Yura Sokolov <[email protected]>
2026-03-27 15:50 [PATCH v52 04/10] Fix a few problems in index build progress reporting. Álvaro Herrera <[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