pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #17561: Server crashes on executing row() with very long argument list
9+ messages / 5 participants
[nested] [flat]
Commits from this thread:
2022-08-01 d947a8bd56 83f1793d60 5d280bc893 51d8b52fcf d54fc7e676 331f8b851c adc3ae6eb3 Check maximum number of columns in function RTEs, too.
2022-07-29 d79f00e821 8dea18372f e6a48014df 8df167baa7 ba2002d02c fd96d14d95 e6e804aa27 In transformRowExpr(), check for too many columns in the row.
* BUG #17561: Server crashes on executing row() with very long argument list
@ 2022-07-29 09:14 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 2 replies; 9+ messages in thread
From: PG Bug reporting form @ 2022-07-29 09:14 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: kyzevan23@mail.ru
The following bug has been logged on the website:
Bug reference: 17561
Logged by: Egor Chindyaskin
Email address: kyzevan23@mail.ru
PostgreSQL version: 14.4
Operating system: Ubuntu 22.04
Description:
When executing the following query:
(echo "SELECT row("; for ((i=1;i<100001;i++)); do echo "'$i',$i,"; done;
echo "'0',0);"; ) | psql
I got server crash with the following backtrace
Core was generated by `postgres: egorchin egorchin [local] SELECT
'.
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementation (no_tid=0, signo=6,
threadid=139924478532480) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0 __pthread_kill_implementation (no_tid=0, signo=6,
threadid=139924478532480) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=139924478532480) at
./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=139924478532480, signo=signo@entry=6) at
./nptl/pthread_kill.c:89
#3 0x00007f42b4dad476 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#4 0x00007f42b4d937f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x0000557e1694f850 in ExceptionalCondition
(conditionName=conditionName@entry=0x557e169b2e62 "attributeNumber >= 1",
errorType=errorType@entry=0x557e169b0e7f "BadArgument",
fileName=fileName@entry=0x557e169b2d7c "tupdesc.c",
lineNumber=lineNumber@entry=598) at assert.c:69
#6 0x0000557e1642790a in TupleDescInitEntry
(desc=desc@entry=0x7f42a4c8b050,
attributeNumber=attributeNumber@entry=-32768,
attributeName=attributeName@entry=0x0, oidtypeid=23, typmod=typmod@entry=-1,
attdim=attdim@entry=0)
at tupdesc.c:598
#7 0x0000557e1664c509 in ExecTypeFromExprList (exprList=0x7f42a7830cf0) at
execTuples.c:2009
#8 0x0000557e1662e8ad in ExecInitExprRec (node=node@entry=0x7f42a7830c40,
state=state@entry=0x557e17ab7dc8, resv=resv@entry=0x557e17ab7dd0,
resnull=resnull@entry=0x557e17ab7dcd) at execExpr.c:1915
#9 0x0000557e1662cd36 in ExecInitExprInternal
(node=node@entry=0x7f42a7830c40, parent=parent@entry=0x0,
ext_params=ext_params@entry=0x0, caseval=caseval@entry=0x0,
casenull=casenull@entry=0x0) at execExpr.c:114
#10 0x0000557e1662cda0 in ExecInitExpr (node=node@entry=0x7f42a7830c40,
parent=parent@entry=0x0) at execExpr.c:162
#11 0x0000557e1672b2aa in evaluate_expr (expr=expr@entry=0x7f42a7830c40,
result_type=2249, result_typmod=result_typmod@entry=-1,
result_collation=result_collation@entry=0) at clauses.c:4890
#12 0x0000557e1672c45f in eval_const_expressions_mutator
(node=0x7f42a7830c40, context=<optimized out>) at clauses.c:3152
#13 0x0000557e166b9717 in expression_tree_mutator (node=0x7f42a7830588,
mutator=mutator@entry=0x557e1672b4f8 <eval_const_expressions_mutator>,
context=context@entry=0x7ffe21d656a0) at nodeFuncs.c:3343
#14 0x0000557e1672dab9 in simplify_function (funcid=3155, result_type=114,
result_typmod=-1, result_collid=result_collid@entry=0,
input_collid=input_collid@entry=0, args_p=args_p@entry=0x7ffe21d654a0,
funcvariadic=false,
process_args=true, allow_non_const=true, context=0x7ffe21d656a0) at
clauses.c:3976
#15 0x0000557e1672b77a in eval_const_expressions_mutator
(node=0x7f42a7830948, context=0x7ffe21d656a0) at clauses.c:2481
#16 0x0000557e166b94cd in expression_tree_mutator
(node=node@entry=0x7f42a78309a0, mutator=mutator@entry=0x557e1672b4f8
<eval_const_expressions_mutator>, context=context@entry=0x7ffe21d656a0) at
nodeFuncs.c:3258
#17 0x0000557e1672cbcd in eval_const_expressions_mutator
(node=0x7f42a78309a0, context=0x7ffe21d656a0) at clauses.c:3604
#18 0x0000557e166b9717 in expression_tree_mutator
(node=node@entry=0x7f42a78309f8, mutator=mutator@entry=0x557e1672b4f8
<eval_const_expressions_mutator>, context=context@entry=0x7ffe21d656a0) at
nodeFuncs.c:3343
#19 0x0000557e1672cbcd in eval_const_expressions_mutator
(node=0x7f42a78309f8, context=context@entry=0x7ffe21d656a0) at
clauses.c:3604
#20 0x0000557e1672cdaa in eval_const_expressions
(root=root@entry=0x557e179ce3f8, node=<optimized out>) at clauses.c:2162
#21 0x0000557e1670b211 in preprocess_expression
(root=root@entry=0x557e179ce3f8, expr=<optimized out>, kind=kind@entry=1) at
planner.c:1124
#22 0x0000557e167140a2 in subquery_planner (glob=glob@entry=0x557e179cec50,
parse=parse@entry=0x7f42a9fb2838, parent_root=parent_root@entry=0x0,
hasRecursion=hasRecursion@entry=false,
tuple_fraction=tuple_fraction@entry=0)
at planner.c:792
#23 0x0000557e16714da6 in standard_planner (parse=0x7f42a9fb2838,
query_string=<optimized out>, cursorOptions=2048, boundParams=<optimized
out>) at planner.c:406
#24 0x0000557e1671535b in planner (parse=parse@entry=0x7f42a9fb2838,
query_string=query_string@entry=0x7f42aace4050 "SELECT
row_to_json(row(\n'1',1,\n'2',2,\n'3',3,\n'4',4,\n'5',5,\n'6',6,\n'7',7,\n'8',8,\n'9',9,\n'10',10,\n'11',11,\n'12',12,\n'13',13,\n'14',14,\n'15',15,\n'16',16,\n'17',17,\n'18',18,\n'19',19,\n'20',20,\n'21',21,\n'22',"...,
cursorOptions=cursorOptions@entry=2048, boundParams=boundParams@entry=0x0)
at planner.c:277
#25 0x0000557e16804c20 in pg_plan_query
(querytree=querytree@entry=0x7f42a9fb2838,
query_string=query_string@entry=0x7f42aace4050 "SELECT
row_to_json(row(\n'1',1,\n'2',2,\n'3',3,\n'4',4,\n'5',5,\n'6',6,\n'7',7,\n'8',8,\n'9',9,\n'10',10,\n'11',11,\n'12',12,\n'13',13,\n'14',14,\n'15',15,\n'16',16,\n'17',17,\n'18',18,\n'19',19,\n'20',20,\n'21',21,\n'22',"...,
cursorOptions=cursorOptions@entry=2048, boundParams=boundParams@entry=0x0)
at postgres.c:883
#26 0x0000557e16804cdd in pg_plan_queries (querytrees=0x7f42a7830aa8,
query_string=query_string@entry=0x7f42aace4050 "SELECT
row_to_json(row(\n'1',1,\n'2',2,\n'3',3,\n'4',4,\n'5',5,\n'6',6,\n'7',7,\n'8',8,\n'9',9,\n'10',10,\n'11',11,\n'12',12,\n'13',13,\n'14',14,\n'15',15,\n'16',16,\n'17',17,\n'18',18,\n'19',19,\n'20',20,\n'21',21,\n'22',"...,
cursorOptions=cursorOptions@entry=2048, boundParams=boundParams@entry=0x0)
at postgres.c:975
#27 0x0000557e168051c1 in exec_simple_query (
query_string=query_string@entry=0x7f42aace4050 "SELECT
row_to_json(row(\n'1',1,\n'2',2,\n'3',3,\n'4',4,\n'5',5,\n'6',6,\n'7',7,\n'8',8,\n'9',9,\n'10',10,\n'11',11,\n'12',12,\n'13',13,\n'14',14,\n'15',15,\n'16',16,\n'17',17,\n'18',18,\n'19',19,\n'20',20,\n'21',21,\n'22',"...)
at postgres.c:1169
#28 0x0000557e1680711f in PostgresMain (dbname=<optimized out>,
username=<optimized out>) at postgres.c:4544
#29 0x0000557e1675a808 in BackendRun (port=port@entry=0x557e179f9f20) at
postmaster.c:4504
#30 0x0000557e1675d887 in BackendStartup (port=port@entry=0x557e179f9f20) at
postmaster.c:4232
#31 0x0000557e1675dac0 in ServerLoop () at postmaster.c:1806
#32 0x0000557e1675f08f in PostmasterMain (argc=argc@entry=3,
argv=argv@entry=0x557e179c8370) at postmaster.c:1478
#33 0x0000557e1669e9b5 in main (argc=3, argv=0x557e179c8370) at main.c:202
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: BUG #17561: Server crashes on executing row() with very long argument list
@ 2022-07-29 09:56 Francisco Olarte <folarte@peoplecall.com>
parent: PG Bug reporting form <noreply@postgresql.org>
1 sibling, 0 replies; 9+ messages in thread
From: Francisco Olarte @ 2022-07-29 09:56 UTC (permalink / raw)
To: kyzevan23@mail.ru; pgsql-bugs@lists.postgresql.org
Egor:
On Fri, 29 Jul 2022 at 11:42, PG Bug reporting form
<noreply@postgresql.org> wrote:
...
Your query generating script.
> When executing the following query:
> (echo "SELECT row("; for ((i=1;i<100001;i++)); do echo "'$i',$i,"; done;
> echo "'0',0);"; ) | psql
> I got server crash with the following backtrace
.. Does not seem to match the query in your BT...
.....
> query_string=query_string@entry=0x7f42aace4050 "SELECT
> row_to_json(row(\n'1',1,\n'2',2,\n'3',3,\n'4',4,\n'5',5,\n'6',6,\n'7',7,\n'8',8,\n'9',9,\n'10',10,\n'11',11,\n'12',12,\n'13',13,\n'14',14,\n'15',15,\n'16',16,\n'17',17,\n'18',18,\n'19',19,\n'20',20,\n'21',21,\n'22',"...,
Although it seems it the extra row_to_json should not matter.
FOS.
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: BUG #17561: Server crashes on executing row() with very long argument list
@ 2022-07-29 10:14 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: PG Bug reporting form <noreply@postgresql.org>
1 sibling, 2 replies; 9+ messages in thread
From: Alvaro Herrera @ 2022-07-29 10:14 UTC (permalink / raw)
To: kyzevan23@mail.ru; pgsql-bugs@lists.postgresql.org
On 2022-Jul-29, PG Bug reporting form wrote:
> When executing the following query:
> (echo "SELECT row("; for ((i=1;i<100001;i++)); do echo "'$i',$i,"; done;
> echo "'0',0);"; ) | psql
> I got server crash with the following backtrace
...
> #5 0x0000557e1694f850 in ExceptionalCondition
> (conditionName=conditionName@entry=0x557e169b2e62 "attributeNumber >= 1",
> errorType=errorType@entry=0x557e169b0e7f "BadArgument",
> fileName=fileName@entry=0x557e169b2d7c "tupdesc.c",
> lineNumber=lineNumber@entry=598) at assert.c:69
> #6 0x0000557e1642790a in TupleDescInitEntry
> (desc=desc@entry=0x7f42a4c8b050,
> attributeNumber=attributeNumber@entry=-32768,
> attributeName=attributeName@entry=0x0, oidtypeid=23, typmod=typmod@entry=-1,
> attdim=attdim@entry=0)
> at tupdesc.c:598
> #7 0x0000557e1664c509 in ExecTypeFromExprList (exprList=0x7f42a7830cf0) at
> execTuples.c:2009
Hah, of course. I suppose we'd need something like this ... haven't
looked for other problem spots.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
Attachments:
overflow.patch (text/x-diff, 513B) download
diff --git a/src/backend/executor/execTuples.c b/src/backend/executor/execTuples.c
index 06ac253ea0..798a7e8518 100644
--- a/src/backend/executor/execTuples.c
+++ b/src/backend/executor/execTuples.c
@@ -2016,6 +2016,12 @@ ExecTypeFromExprList(List *exprList)
cur_resno,
exprCollation(e));
cur_resno++;
+
+ /* prevent overflow */
+ if (cur_resno >= MaxAttrNumber)
+ ereport(ERROR,
+ (errcode(ERRCODE_TOO_MANY_COLUMNS),
+ errmsg("too many attributes")));
}
return typeInfo;
* Re: BUG #17561: Server crashes on executing row() with very long argument list
@ 2022-07-29 10:58 Richard Guo <guofenglinux@gmail.com>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
1 sibling, 0 replies; 9+ messages in thread
From: Richard Guo @ 2022-07-29 10:58 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: kyzevan23@mail.ru, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Fri, Jul 29, 2022 at 6:14 PM Alvaro Herrera <alvherre@alvh.no-ip.org>
wrote:
> Hah, of course. I suppose we'd need something like this ... haven't
> looked for other problem spots.
Yeah, that's what we need to do. I think the check condition should be
something like:
if (cur_resno - 1 > MaxAttrNumber)
Thanks
Richard
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: BUG #17561: Server crashes on executing row() with very long argument list
@ 2022-07-29 13:55 Tom Lane <tgl@sss.pgh.pa.us>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
1 sibling, 2 replies; 9+ messages in thread
From: Tom Lane @ 2022-07-29 13:55 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: kyzevan23@mail.ru; pgsql-bugs@lists.postgresql.org
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2022-Jul-29, PG Bug reporting form wrote:
>> When executing the following query:
>> (echo "SELECT row("; for ((i=1;i<100001;i++)); do echo "'$i',$i,"; done;
>> echo "'0',0);"; ) | psql
>> I got server crash with the following backtrace
> Hah, of course. I suppose we'd need something like this ... haven't
> looked for other problem spots.
I think the parser should've prevented this. It's in charge of
rejecting overlength SELECT lists, for example. Also, the limit
probably needs to be just MaxTupleAttributeNumber.
regards, tom lane
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: BUG #17561: Server crashes on executing row() with very long argument list
@ 2022-07-29 14:40 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 9+ messages in thread
From: Tom Lane @ 2022-07-29 14:40 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: kyzevan23@mail.ru; pgsql-bugs@lists.postgresql.org
I wrote:
> I think the parser should've prevented this. It's in charge of
> rejecting overlength SELECT lists, for example. Also, the limit
> probably needs to be just MaxTupleAttributeNumber.
Concretely, about as attached.
In the existing code, if you just supply 10000 or so columns you
reach this error in heaptuple.c:
if (numberOfAttributes > MaxTupleAttributeNumber)
ereport(ERROR,
(errcode(ERRCODE_TOO_MANY_COLUMNS),
errmsg("number of columns (%d) exceeds limit (%d)",
numberOfAttributes, MaxTupleAttributeNumber)));
I borrowed the errcode from that, but the wording from parse_node.c:
if (pstate->p_next_resno - 1 > MaxTupleAttributeNumber)
ereport(ERROR,
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
errmsg("target lists can have at most %d entries",
MaxTupleAttributeNumber)));
I'm a bit inclined to adjust parse_node.c to also use TOO_MANY_COLUMNS
(54011) instead of the generic PROGRAM_LIMIT_EXCEEDED (54000).
regards, tom lane
Attachments:
prevent-too-many-cols-in-ROW-expr.patch (text/x-diff, 836B) download
diff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_expr.c
index 9f567f4bf4..059cb7097c 100644
--- a/src/backend/parser/parse_expr.c
+++ b/src/backend/parser/parse_expr.c
@@ -2140,6 +2140,14 @@ transformRowExpr(ParseState *pstate, RowExpr *r, bool allowDefault)
newr->args = transformExpressionList(pstate, r->args,
pstate->p_expr_kind, allowDefault);
+ /* Disallow more columns than will fit in a tuple */
+ if (list_length(newr->args) > MaxTupleAttributeNumber)
+ ereport(ERROR,
+ (errcode(ERRCODE_TOO_MANY_COLUMNS),
+ errmsg("ROW expressions can have at most %d entries",
+ MaxTupleAttributeNumber),
+ parser_errposition(pstate, r->location)));
+
/* Barring later casting, we consider the type RECORD */
newr->row_typeid = RECORDOID;
newr->row_format = COERCE_IMPLICIT_CAST;
* Re: BUG #17561: Server crashes on executing row() with very long argument list
@ 2022-07-29 15:47 Richard Guo <guofenglinux@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 9+ messages in thread
From: Richard Guo @ 2022-07-29 15:47 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>; kyzevan23@mail.ru, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Fri, Jul 29, 2022 at 9:56 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > On 2022-Jul-29, PG Bug reporting form wrote:
> >> When executing the following query:
> >> (echo "SELECT row("; for ((i=1;i<100001;i++)); do echo "'$i',$i,"; done;
> >> echo "'0',0);"; ) | psql
> >> I got server crash with the following backtrace
>
> > Hah, of course. I suppose we'd need something like this ... haven't
> > looked for other problem spots.
>
> I think the parser should've prevented this. It's in charge of
> rejecting overlength SELECT lists, for example. Also, the limit
> probably needs to be just MaxTupleAttributeNumber.
At the very least we cannot exceed MaxAttrNumber, so that we can
reference any columns with an AttrNumber (int16). But if there are more
than MaxTupleAttributeNumber columns, we would end up error out when
constructing the tuple in heap_form_tuple().
Thanks
Richard
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: BUG #17561: Server crashes on executing row() with very long argument list
@ 2022-07-29 16:24 Richard Guo <guofenglinux@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 9+ messages in thread
From: Richard Guo @ 2022-07-29 16:24 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>; kyzevan23@mail.ru, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Fri, Jul 29, 2022 at 10:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
> > I think the parser should've prevented this. It's in charge of
> > rejecting overlength SELECT lists, for example. Also, the limit
> > probably needs to be just MaxTupleAttributeNumber.
>
> Concretely, about as attached.
>
> In the existing code, if you just supply 10000 or so columns you
> reach this error in heaptuple.c:
>
> if (numberOfAttributes > MaxTupleAttributeNumber)
> ereport(ERROR,
> (errcode(ERRCODE_TOO_MANY_COLUMNS),
> errmsg("number of columns (%d) exceeds limit (%d)",
> numberOfAttributes, MaxTupleAttributeNumber)));
>
> I borrowed the errcode from that, but the wording from parse_node.c:
>
> if (pstate->p_next_resno - 1 > MaxTupleAttributeNumber)
> ereport(ERROR,
> (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
> errmsg("target lists can have at most %d entries",
> MaxTupleAttributeNumber)));
>
> I'm a bit inclined to adjust parse_node.c to also use TOO_MANY_COLUMNS
> (54011) instead of the generic PROGRAM_LIMIT_EXCEEDED (54000).
The patch looks good to me. Just wondering if there are any other types
of expressions that need to check for MaxTupleAttributeNumber in
parse_expr.c.
Thanks
Richard
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: BUG #17561: Server crashes on executing row() with very long argument list
@ 2022-07-29 16:57 Tom Lane <tgl@sss.pgh.pa.us>
parent: Richard Guo <guofenglinux@gmail.com>
0 siblings, 0 replies; 9+ messages in thread
From: Tom Lane @ 2022-07-29 16:57 UTC (permalink / raw)
To: Richard Guo <guofenglinux@gmail.com>; +Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>; kyzevan23@mail.ru, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Richard Guo <guofenglinux@gmail.com> writes:
> The patch looks good to me. Just wondering if there are any other types
> of expressions that need to check for MaxTupleAttributeNumber in
> parse_expr.c.
As far as I can think, sub-SELECTs and ROW constructs are the only
SQL that can produce composites of non-pre-determined types.
For constructs producing named composite types, the limit on the
number of columns in a table should take care of it.
What I'm more troubled by is whether there are any ways to produce
a wide tuple that don't come through either the parser or a table
definition. Not sure what that could look like, other than C code
randomly constructing a RowExpr or some such.
regards, tom lane
^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2022-07-29 16:57 UTC | newest]
Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-07-29 09:14 BUG #17561: Server crashes on executing row() with very long argument list PG Bug reporting form <noreply@postgresql.org>
2022-07-29 09:56 ` Francisco Olarte <folarte@peoplecall.com>
2022-07-29 10:14 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2022-07-29 10:58 ` Richard Guo <guofenglinux@gmail.com>
2022-07-29 13:55 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-07-29 14:40 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-07-29 16:24 ` Richard Guo <guofenglinux@gmail.com>
2022-07-29 16:57 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-07-29 15:47 ` Richard Guo <guofenglinux@gmail.com>
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