pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
13+ messages / 5 participants
[nested] [flat]
Commits from this thread:
2024-11-11 db22b90024 a6fa869cfa b242aba026 713b8546ab 247e7647f5 5411e82138 Fix arrays comparison in CompareOpclassOptions()
* BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
@ 2024-11-06 14:06 PG Bug reporting form <noreply@postgresql.org>
2024-11-06 17:08 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 13+ messages in thread
From: PG Bug reporting form @ 2024-11-06 14:06 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: nicolas.maus@bertelsmann.de
The following bug has been logged on the website:
Bug reference: 18692
Logged by: Nicolas Maus
Email address: nicolas.maus@bertelsmann.de
PostgreSQL version: 16.4
Operating system: SLES 15.5
Description:
When extending a varchar column with a gist index with a custom signal
length the Postgres server crashes with a segmentation fault.
Tested on 16.4 and 14.13 on SLES 15.5
How to reproduce:
create extension if not exists pg_trgm;
create table contains_trgm (trgm_column varchar(200));
-- important: this bug only occurs when a custom signal length (siglen=x) is
provided
create index gist_index on contains_trgm using gist (trgm_column
public.gist_trgm_ops (siglen=32));
-- will trigger segmentation fault (new column size must be bigger than old
one):
alter table contains_trgm alter column trgm_column type varchar(768);
Log output:
2024-11-06 14:55:09.806 CET : LOG: 00000: server process (PID 130312) was
terminated by signal 11: Segmentation fault
2024-11-06 14:55:09.806 CET : DETAIL: Failed process was running: alter
table contains_trgm alter column trgm_column type varchar(768);
2024-11-06 14:55:09.806 CET : LOCATION: LogChildExit, postmaster.c:3689
2024-11-06 14:55:09.807 CET : LOG: 00000: terminating any other active
server processes
2024-11-06 14:55:09.807 CET : LOCATION: HandleChildCrash,
postmaster.c:3490
2024-11-06 14:55:09.823 CET 172.28.110.149(56320) trigram_test ggdbpadm:
FATAL: 57P03: the database system is in recovery mode
2024-11-06 14:55:09.823 CET 172.28.110.149(56320) trigram_test ggdbpadm:
LOCATION: ProcessStartupPacket, postmaster.c:2358
2024-11-06 14:55:09.875 CET : LOG: 00000: all server processes
terminated; reinitializing
2024-11-06 14:55:09.875 CET : LOCATION: PostmasterStateMachine,
postmaster.c:3950
2024-11-06 14:55:09.947 CET : LOG: 00000: database system was
interrupted; last known up at 2024-11-06 14:52:20 CET
2024-11-06 14:55:09.947 CET : LOCATION: StartupXLOG, xlog.c:5113
2024-11-06 14:55:10.064 CET : LOG: 00000: database system was not
properly shut down; automatic recovery in progress
2024-11-06 14:55:10.064 CET : LOCATION: InitWalRecovery,
xlogrecovery.c:926
2024-11-06 14:55:10.072 CET : LOG: 00000: redo starts at 0/8C45FFF8
2024-11-06 14:55:10.072 CET : LOCATION: PerformWalRecovery,
xlogrecovery.c:1689
2024-11-06 14:55:10.110 CET : LOG: 00000: invalid record length at
0/8C8BFA20: expected at least 24, got 0
2024-11-06 14:55:10.110 CET : LOCATION: ReadRecord, xlogrecovery.c:3137
2024-11-06 14:55:10.113 CET : LOG: 00000: redo done at 0/8C8BF908 system
usage: CPU: user: 0.00 s, system: 0.01 s, elapsed: 0.04 s
2024-11-06 14:55:10.113 CET : LOCATION: PerformWalRecovery,
xlogrecovery.c:1827
2024-11-06 14:55:10.119 CET : LOG: 00000: checkpoint starting:
end-of-recovery immediate wait
2024-11-06 14:55:10.119 CET : LOCATION: LogCheckpointStart, xlog.c:6251
2024-11-06 14:55:10.181 CET : LOG: 00000: checkpoint complete: wrote 957
buffers (5.8%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.041 s,
sync=0.011 s, total=0.063 s; sync files=303, longest=0.005 s, average=0.001
s; distance=4478 kB, estimate=4478 kB; lsn=0/8C8BFA20, redo lsn=0/8C8BFA20
2024-11-06 14:55:10.181 CET : LOCATION: LogCheckpointEnd, xlog.c:6351
2024-11-06 14:55:10.337 CET : LOG: 00000: database system is ready to
accept connections
2024-11-06 14:55:10.337 CET : LOCATION: process_pm_child_exit,
postmaster.c:3110
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
2024-11-06 14:06 BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length PG Bug reporting form <noreply@postgresql.org>
@ 2024-11-06 17:08 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-06 17:14 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
0 siblings, 1 reply; 13+ messages in thread
From: Tom Lane @ 2024-11-06 17:08 UTC (permalink / raw)
To: nicolas.maus@bertelsmann.de; +Cc: Alexander Korotkov <aekorotkov@gmail.com>; pgsql-bugs@lists.postgresql.org
PG Bug reporting form <noreply@postgresql.org> writes:
> When extending a varchar column with a gist index with a custom signal
> length the Postgres server crashes with a segmentation fault.
What this shows is that CompareOpclassOptions has never been tested
at all except with null inputs. It's trying to call array_eq
without providing an FmgrInfo.
regards, tom lane
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
2024-11-06 14:06 BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length PG Bug reporting form <noreply@postgresql.org>
2024-11-06 17:08 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-06 17:14 ` Alexander Korotkov <aekorotkov@gmail.com>
2024-11-07 06:47 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tender Wang <tndrwang@gmail.com>
0 siblings, 1 reply; 13+ messages in thread
From: Alexander Korotkov @ 2024-11-06 17:14 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: nicolas.maus@bertelsmann.de; pgsql-bugs@lists.postgresql.org
On Wed, Nov 6, 2024 at 7:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> PG Bug reporting form <noreply@postgresql.org> writes:
> > When extending a varchar column with a gist index with a custom signal
> > length the Postgres server crashes with a segmentation fault.
>
> What this shows is that CompareOpclassOptions has never been tested
> at all except with null inputs. It's trying to call array_eq
> without providing an FmgrInfo.
Thank you for inviting me to the thread. I'm on and will provide a fix shortly.
------
Regards,
Alexander Korotkov
Supabase
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
2024-11-06 14:06 BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length PG Bug reporting form <noreply@postgresql.org>
2024-11-06 17:08 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-06 17:14 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
@ 2024-11-07 06:47 ` Tender Wang <tndrwang@gmail.com>
2024-11-07 23:28 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
0 siblings, 1 reply; 13+ messages in thread
From: Tender Wang @ 2024-11-07 06:47 UTC (permalink / raw)
To: Alexander Korotkov <aekorotkov@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; nicolas.maus@bertelsmann.de; pgsql-bugs@lists.postgresql.org
Hi all,
Alexander Korotkov <aekorotkov@gmail.com> 于2024年11月7日周四 01:15写道：
> On Wed, Nov 6, 2024 at 7:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > PG Bug reporting form <noreply@postgresql.org> writes:
> > > When extending a varchar column with a gist index with a custom signal
> > > length the Postgres server crashes with a segmentation fault.
> >
> > What this shows is that CompareOpclassOptions has never been tested
> > at all except with null inputs. It's trying to call array_eq
> > without providing an FmgrInfo.
>
>
Based on Tom's analysis, I provide a POC patch. I'm not sure if it is right
to use DEFAULT_COLLATION_OID in the patch.
--
Thanks,
Tender Wang
Attachments:
0001-Try-to-fix-array_eq-without-providing-FmgrInfo-issue.patch (application/octet-stream, 1.4K) download
From 0c725f3b912c79fcd4cd54e49a3d97278351fb09 Mon Sep 17 00:00:00 2001
From: Tender Wang <tndrwang@gmail.com>
Date: Thu, 7 Nov 2024 14:34:04 +0800
Subject: [PATCH] Try to fix array_eq without providing FmgrInfo issue.
---
src/backend/commands/indexcmds.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands/indexcmds.c
index 2f652463e3..8e61929ab9 100644
--- a/src/backend/commands/indexcmds.c
+++ b/src/backend/commands/indexcmds.c
@@ -29,6 +29,7 @@
#include "catalog/namespace.h"
#include "catalog/pg_am.h"
#include "catalog/pg_authid.h"
+#include "catalog/pg_collation.h"
#include "catalog/pg_constraint.h"
#include "catalog/pg_database.h"
#include "catalog/pg_inherits.h"
@@ -362,10 +363,12 @@ static bool
CompareOpclassOptions(const Datum *opts1, const Datum *opts2, int natts)
{
int i;
+ FmgrInfo fm;
if (!opts1 && !opts2)
return true;
+ fmgr_info(F_ARRAY_EQ, &fm);
for (i = 0; i < natts; i++)
{
Datum opt1 = opts1 ? opts1[i] : (Datum) 0;
@@ -382,7 +385,7 @@ CompareOpclassOptions(const Datum *opts1, const Datum *opts2, int natts)
return false;
/* Compare non-NULL text[] datums. */
- if (!DatumGetBool(DirectFunctionCall2(array_eq, opt1, opt2)))
+ if (!DatumGetBool(FunctionCall2Coll(&fm, DEFAULT_COLLATION_OID, opt1, opt2)))
return false;
}
--
2.25.1
* Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
2024-11-06 14:06 BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length PG Bug reporting form <noreply@postgresql.org>
2024-11-06 17:08 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-06 17:14 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-07 06:47 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tender Wang <tndrwang@gmail.com>
@ 2024-11-07 23:28 ` Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 02:05 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 13+ messages in thread
From: Alexander Korotkov @ 2024-11-07 23:28 UTC (permalink / raw)
To: Tender Wang <tndrwang@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; nicolas.maus@bertelsmann.de; pgsql-bugs@lists.postgresql.org
On Thu, Nov 7, 2024 at 8:47 AM Tender Wang <tndrwang@gmail.com> wrote:
> Alexander Korotkov <aekorotkov@gmail.com> 于2024年11月7日周四 01:15写道：
>> On Wed, Nov 6, 2024 at 7:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> > PG Bug reporting form <noreply@postgresql.org> writes:
>> > > When extending a varchar column with a gist index with a custom signal
>> > > length the Postgres server crashes with a segmentation fault.
>> >
>> > What this shows is that CompareOpclassOptions has never been tested
>> > at all except with null inputs. It's trying to call array_eq
>> > without providing an FmgrInfo.
>>
>
> Based on Tom's analysis, I provide a POC patch. I'm not sure if it is right
> to use DEFAULT_COLLATION_OID in the patch.
Thank you. But I'm not sure about DEFAULT_COLLATION_OID. The default
collation could threaten binary different text'es as the same.
However, they could still be different from opclass point of view.
So, I think it would be safer to do binary comparison of text'es.
Also, array_eq already assumes the order of elements to be the same.
Therefore, we can compare two text[] just with datumIsEqual().
Attached patch implements this.
I've added the check similar what is reported to pg_trgm regression
test. I also tried to produce the situation when
CompareOpclassOptions() returns false. However, I didn't manage to do
so. Currently, the only usage scenario writes oplcass options to a
query string using get_reloptions(), then parses this query and
reconstructs text[] using transformRelOptions(). AFAICS,
CompareOpclassOptions() should always return true in the current usage
scenario is our quoting/dequoting of strings works correctly.
------
Regards,
Alexander Korotkov
Supabase
Attachments:
v1-0001-Fix-arrays-comparison-in-CompareOpclassOptions.patch (application/octet-stream, 3.6K) download
From 25680283fe0c9ef21a640763b712f277a6ca0188 Mon Sep 17 00:00:00 2001
From: Alexander Korotkov <akorotkov@postgresql.org>
Date: Fri, 8 Nov 2024 00:23:00 +0200
Subject: [PATCH v1] Fix arrays comparison in CompareOpclassOptions()
The current code calls array_eq() without providing FmgrInfo. This commit
makes this check stricter and simpler using datumIsEqual(), which should be
fine the the current usage scenario.
Reported-by: Nicolas Maus
Discussion: https://postgr.es/m/18692-72ea398df3ec6712%40postgresql.org
---
contrib/pg_trgm/expected/pg_trgm.out | 3 +++
contrib/pg_trgm/sql/pg_trgm.sql | 4 ++++
src/backend/commands/indexcmds.c | 24 ++++++++++++++----------
3 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/contrib/pg_trgm/expected/pg_trgm.out b/contrib/pg_trgm/expected/pg_trgm.out
index ce4bf1d4e51..0b70d9de256 100644
--- a/contrib/pg_trgm/expected/pg_trgm.out
+++ b/contrib/pg_trgm/expected/pg_trgm.out
@@ -2372,6 +2372,9 @@ ERROR: value 2025 out of bounds for option "siglen"
DETAIL: Valid values are between "1" and "2024".
create index trgm_idx on test_trgm using gist (t gist_trgm_ops(siglen=2024));
set enable_seqscan=off;
+-- check index compatibility handling when opclass option is specified
+alter table test_trgm alter column t type varchar(768);
+alter table test_trgm alter column t type text;
select t,similarity(t,'qwertyu0988') as sml from test_trgm where t % 'qwertyu0988' order by sml desc, t;
t | sml
-------------+----------
diff --git a/contrib/pg_trgm/sql/pg_trgm.sql b/contrib/pg_trgm/sql/pg_trgm.sql
index 6a9da24d5a7..340c9891899 100644
--- a/contrib/pg_trgm/sql/pg_trgm.sql
+++ b/contrib/pg_trgm/sql/pg_trgm.sql
@@ -52,6 +52,10 @@ create index trgm_idx on test_trgm using gist (t gist_trgm_ops(siglen=2025));
create index trgm_idx on test_trgm using gist (t gist_trgm_ops(siglen=2024));
set enable_seqscan=off;
+-- check index compatibility handling when opclass option is specified
+alter table test_trgm alter column t type varchar(768);
+alter table test_trgm alter column t type text;
+
select t,similarity(t,'qwertyu0988') as sml from test_trgm where t % 'qwertyu0988' order by sml desc, t;
select t,similarity(t,'gwertyu0988') as sml from test_trgm where t % 'gwertyu0988' order by sml desc, t;
select t,similarity(t,'gwertyu1988') as sml from test_trgm where t % 'gwertyu1988' order by sml desc, t;
diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands/indexcmds.c
index 2f652463e3c..01fc89a638c 100644
--- a/src/backend/commands/indexcmds.c
+++ b/src/backend/commands/indexcmds.c
@@ -60,6 +60,7 @@
#include "storage/procarray.h"
#include "utils/acl.h"
#include "utils/builtins.h"
+#include "utils/datum.h"
#include "utils/fmgroids.h"
#include "utils/guc.h"
#include "utils/injection_point.h"
@@ -371,19 +372,22 @@ CompareOpclassOptions(const Datum *opts1, const Datum *opts2, int natts)
Datum opt1 = opts1 ? opts1[i] : (Datum) 0;
Datum opt2 = opts2 ? opts2[i] : (Datum) 0;
- if (opt1 == (Datum) 0)
+ if (opt1 && opt2)
{
- if (opt2 == (Datum) 0)
- continue;
- else
+ /*
+ * Compare non-NULL text[] datums. We are strict and require
+ * arrays to be binary same. This is fine with the current usage
+ * scenario involving get_reloptions(), then re-parsing and
+ * transformRelOptions().
+ */
+ if (!datumIsEqual(opts1[i], opts2[i], false, -1))
+ return false;
+ }
+ else
+ {
+ if (opt1 != opt2)
return false;
}
- else if (opt2 == (Datum) 0)
- return false;
-
- /* Compare non-NULL text[] datums. */
- if (!DatumGetBool(DirectFunctionCall2(array_eq, opt1, opt2)))
- return false;
}
return true;
--
2.39.5 (Apple Git-154)
* Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
2024-11-06 14:06 BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length PG Bug reporting form <noreply@postgresql.org>
2024-11-06 17:08 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-06 17:14 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-07 06:47 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tender Wang <tndrwang@gmail.com>
2024-11-07 23:28 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
@ 2024-11-08 02:05 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-08 02:22 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
0 siblings, 1 reply; 13+ messages in thread
From: Tom Lane @ 2024-11-08 02:05 UTC (permalink / raw)
To: Alexander Korotkov <aekorotkov@gmail.com>; +Cc: Tender Wang <tndrwang@gmail.com>; nicolas.maus@bertelsmann.de; pgsql-bugs@lists.postgresql.org
Alexander Korotkov <aekorotkov@gmail.com> writes:
> On Thu, Nov 7, 2024 at 8:47 AM Tender Wang <tndrwang@gmail.com> wrote:
>> Based on Tom's analysis, I provide a POC patch. I'm not sure if it is right
>> to use DEFAULT_COLLATION_OID in the patch.
> Thank you. But I'm not sure about DEFAULT_COLLATION_OID.
I don't quite trust that either. But since we only care about
equality, wouldn't it be OK to use C_COLLATION_OID?
> Therefore, we can compare two text[] just with datumIsEqual().
> Attached patch implements this.
I think this is nonsense. What about toasted datums, or even
just short-header ones? The one coming from an on-disk tuple
is pretty likely to be short-header for plausible sizes of
the options, but the one we just constructed in memory will
not be.
regards, tom lane
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
2024-11-06 14:06 BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length PG Bug reporting form <noreply@postgresql.org>
2024-11-06 17:08 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-06 17:14 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-07 06:47 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tender Wang <tndrwang@gmail.com>
2024-11-07 23:28 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 02:05 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-08 02:22 ` Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 02:26 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tender Wang <tndrwang@gmail.com>
2024-11-08 05:10 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 13+ messages in thread
From: Alexander Korotkov @ 2024-11-08 02:22 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Tender Wang <tndrwang@gmail.com>; nicolas.maus@bertelsmann.de; pgsql-bugs@lists.postgresql.org
On Fri, Nov 8, 2024 at 4:05 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alexander Korotkov <aekorotkov@gmail.com> writes:
> > On Thu, Nov 7, 2024 at 8:47 AM Tender Wang <tndrwang@gmail.com> wrote:
> >> Based on Tom's analysis, I provide a POC patch. I'm not sure if it is right
> >> to use DEFAULT_COLLATION_OID in the patch.
>
> > Thank you. But I'm not sure about DEFAULT_COLLATION_OID.
>
> I don't quite trust that either. But since we only care about
> equality, wouldn't it be OK to use C_COLLATION_OID?
>
> > Therefore, we can compare two text[] just with datumIsEqual().
> > Attached patch implements this.
>
> I think this is nonsense. What about toasted datums, or even
> just short-header ones? The one coming from an on-disk tuple
> is pretty likely to be short-header for plausible sizes of
> the options, but the one we just constructed in memory will
> not be.
You are correct. I quickly skim trough the sources and didn't find a
function which compares detoasted contents of Datums excluding
headers. So, yes, comparison using C-collation seems the most
reasonable option.
------
Regards,
Alexander Korotkov
Supabase
Attachments:
v2-0001-Fix-arrays-comparison-in-CompareOpclassOptions.patch (application/octet-stream, 3.7K) download
From 41b35d6ef50148d0e12cd3093b6d54f043ac5b6e Mon Sep 17 00:00:00 2001
From: Alexander Korotkov <akorotkov@postgresql.org>
Date: Fri, 8 Nov 2024 00:23:00 +0200
Subject: [PATCH v2] Fix arrays comparison in CompareOpclassOptions()
The current code calls array_eq() and does not provide FmgrInfo. This commit
provides initialization of FmgrInfo and uses C collation as the safe option
for text comparison because we don't know anything about the semantics of
opclass options.
Backpatch to 13, where opclass options were introduced.
Reported-by: Nicolas Maus
Discussion: https://postgr.es/m/18692-72ea398df3ec6712%40postgresql.org
Backpatch-through: 13
---
contrib/pg_trgm/expected/pg_trgm.out | 3 +++
contrib/pg_trgm/sql/pg_trgm.sql | 4 ++++
src/backend/commands/indexcmds.c | 11 +++++++++--
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/contrib/pg_trgm/expected/pg_trgm.out b/contrib/pg_trgm/expected/pg_trgm.out
index ce4bf1d4e51..0b70d9de256 100644
--- a/contrib/pg_trgm/expected/pg_trgm.out
+++ b/contrib/pg_trgm/expected/pg_trgm.out
@@ -2372,6 +2372,9 @@ ERROR: value 2025 out of bounds for option "siglen"
DETAIL: Valid values are between "1" and "2024".
create index trgm_idx on test_trgm using gist (t gist_trgm_ops(siglen=2024));
set enable_seqscan=off;
+-- check index compatibility handling when opclass option is specified
+alter table test_trgm alter column t type varchar(768);
+alter table test_trgm alter column t type text;
select t,similarity(t,'qwertyu0988') as sml from test_trgm where t % 'qwertyu0988' order by sml desc, t;
t | sml
-------------+----------
diff --git a/contrib/pg_trgm/sql/pg_trgm.sql b/contrib/pg_trgm/sql/pg_trgm.sql
index 6a9da24d5a7..340c9891899 100644
--- a/contrib/pg_trgm/sql/pg_trgm.sql
+++ b/contrib/pg_trgm/sql/pg_trgm.sql
@@ -52,6 +52,10 @@ create index trgm_idx on test_trgm using gist (t gist_trgm_ops(siglen=2025));
create index trgm_idx on test_trgm using gist (t gist_trgm_ops(siglen=2024));
set enable_seqscan=off;
+-- check index compatibility handling when opclass option is specified
+alter table test_trgm alter column t type varchar(768);
+alter table test_trgm alter column t type text;
+
select t,similarity(t,'qwertyu0988') as sml from test_trgm where t % 'qwertyu0988' order by sml desc, t;
select t,similarity(t,'gwertyu0988') as sml from test_trgm where t % 'gwertyu0988' order by sml desc, t;
select t,similarity(t,'gwertyu1988') as sml from test_trgm where t % 'gwertyu1988' order by sml desc, t;
diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands/indexcmds.c
index 2f652463e3c..d1134733c17 100644
--- a/src/backend/commands/indexcmds.c
+++ b/src/backend/commands/indexcmds.c
@@ -29,6 +29,7 @@
#include "catalog/namespace.h"
#include "catalog/pg_am.h"
#include "catalog/pg_authid.h"
+#include "catalog/pg_collation.h"
#include "catalog/pg_constraint.h"
#include "catalog/pg_database.h"
#include "catalog/pg_inherits.h"
@@ -362,10 +363,12 @@ static bool
CompareOpclassOptions(const Datum *opts1, const Datum *opts2, int natts)
{
int i;
+ FmgrInfo fm;
if (!opts1 && !opts2)
return true;
+ fmgr_info(F_ARRAY_EQ, &fm);
for (i = 0; i < natts; i++)
{
Datum opt1 = opts1 ? opts1[i] : (Datum) 0;
@@ -381,8 +384,12 @@ CompareOpclassOptions(const Datum *opts1, const Datum *opts2, int natts)
else if (opt2 == (Datum) 0)
return false;
- /* Compare non-NULL text[] datums. */
- if (!DatumGetBool(DirectFunctionCall2(array_eq, opt1, opt2)))
+ /*
+ * Compare non-NULL text[] datums. Use C collation to enforce binary
+ * equivalence of texts, because we don't know anything about the
+ * semantics of opclass options.
+ */
+ if (!DatumGetBool(FunctionCall2Coll(&fm, C_COLLATION_OID, opt1, opt2)))
return false;
}
--
2.39.5 (Apple Git-154)
* Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
2024-11-06 14:06 BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length PG Bug reporting form <noreply@postgresql.org>
2024-11-06 17:08 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-06 17:14 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-07 06:47 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tender Wang <tndrwang@gmail.com>
2024-11-07 23:28 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 02:05 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-08 02:22 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
@ 2024-11-08 02:26 ` Tender Wang <tndrwang@gmail.com>
1 sibling, 0 replies; 13+ messages in thread
From: Tender Wang @ 2024-11-08 02:26 UTC (permalink / raw)
To: Alexander Korotkov <aekorotkov@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; nicolas.maus@bertelsmann.de; pgsql-bugs@lists.postgresql.org
Alexander Korotkov <aekorotkov@gmail.com> 于2024年11月8日周五 10:22写道：
> On Fri, Nov 8, 2024 at 4:05 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Alexander Korotkov <aekorotkov@gmail.com> writes:
> > > On Thu, Nov 7, 2024 at 8:47 AM Tender Wang <tndrwang@gmail.com> wrote:
> > >> Based on Tom's analysis, I provide a POC patch. I'm not sure if it
> is right
> > >> to use DEFAULT_COLLATION_OID in the patch.
> >
> > > Thank you. But I'm not sure about DEFAULT_COLLATION_OID.
> >
> > I don't quite trust that either. But since we only care about
> > equality, wouldn't it be OK to use C_COLLATION_OID?
> >
> > > Therefore, we can compare two text[] just with datumIsEqual().
> > > Attached patch implements this.
> >
> > I think this is nonsense. What about toasted datums, or even
> > just short-header ones? The one coming from an on-disk tuple
> > is pretty likely to be short-header for plausible sizes of
> > the options, but the one we just constructed in memory will
> > not be.
>
> You are correct. I quickly skim trough the sources and didn't find a
> function which compares detoasted contents of Datums excluding
> headers. So, yes, comparison using C-collation seems the most
> reasonable option.
>
No objection from me.
--
Thanks,
Tender Wang
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
2024-11-06 14:06 BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length PG Bug reporting form <noreply@postgresql.org>
2024-11-06 17:08 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-06 17:14 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-07 06:47 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tender Wang <tndrwang@gmail.com>
2024-11-07 23:28 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 02:05 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-08 02:22 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
@ 2024-11-08 05:10 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-08 08:47 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
1 sibling, 1 reply; 13+ messages in thread
From: Tom Lane @ 2024-11-08 05:10 UTC (permalink / raw)
To: Alexander Korotkov <aekorotkov@gmail.com>; +Cc: Tender Wang <tndrwang@gmail.com>; nicolas.maus@bertelsmann.de; pgsql-bugs@lists.postgresql.org
Alexander Korotkov <aekorotkov@gmail.com> writes:
> On Fri, Nov 8, 2024 at 4:05 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think this is nonsense. What about toasted datums, or even
>> just short-header ones?
> You are correct. I quickly skim trough the sources and didn't find a
> function which compares detoasted contents of Datums excluding
> headers.
Right, there isn't one AFAIK. For context, datumIsEqual() is mainly
meant to support cases such as comparison of Const nodes in equal(),
where
a) false match is unacceptable, but false no-match will at worst
cause some performance loss;
b) the two inputs have probably come through similar paths (eg,
both are fresh from the parser, or both were on-disk), so that
any toasting effects will be the same.
Also
c) for many of the callers, it'd be unsafe to perform disk
access to allow accurate comparison of out-of-line values.
Problem (a) would be all right for this case, and (c) too,
but not so much (b).
You can certainly imagine writing a more aggressive routine
that can cope with detoasting, but I don't think we've yet
found a case where that seemed worth the trouble. Partial
solutions such as "cope with short-header but not compressed
values" have even narrower possible use-cases.
> So, yes, comparison using C-collation seems the most
> reasonable option.
WFM. But I'm concerned that you couldn't build a test case
where the comparison fails. Seems like we need one, in view
of this bug having escaped detection for so long.
regards, tom lane
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
2024-11-06 14:06 BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length PG Bug reporting form <noreply@postgresql.org>
2024-11-06 17:08 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-06 17:14 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-07 06:47 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tender Wang <tndrwang@gmail.com>
2024-11-07 23:28 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 02:05 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-08 02:22 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 05:10 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-08 08:47 ` Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 14:49 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 13+ messages in thread
From: Alexander Korotkov @ 2024-11-08 08:47 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Tender Wang <tndrwang@gmail.com>; nicolas.maus@bertelsmann.de; pgsql-bugs@lists.postgresql.org
On Fri, Nov 8, 2024 at 7:10 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alexander Korotkov <aekorotkov@gmail.com> writes:
> > So, yes, comparison using C-collation seems the most
> > reasonable option.
>
> WFM. But I'm concerned that you couldn't build a test case
> where the comparison fails. Seems like we need one, in view
> of this bug having escaped detection for so long.
AFAICS, the only use case of CheckIndexCompatible() is ALTER TYPE. In
that case we only serialize and deserialize opclass options without
any involvement of opclass or data type. So, with the current usage
scenario CompareOpclassOptions() is only a paranoid check, but
CheckIndexCompatible() has to do it due to its general semantic.
Thus, if we have to build a test case where CompareOpclassOptions()
fails, I guess we need to write a new module for src/test/modules,
which would call CheckIndexCompatible() under different circumstances.
------
Regards,
Alexander Korotkov
Supabase
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
2024-11-06 14:06 BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length PG Bug reporting form <noreply@postgresql.org>
2024-11-06 17:08 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-06 17:14 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-07 06:47 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tender Wang <tndrwang@gmail.com>
2024-11-07 23:28 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 02:05 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-08 02:22 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 05:10 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-08 08:47 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
@ 2024-11-08 14:49 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-08 20:29 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
0 siblings, 1 reply; 13+ messages in thread
From: Tom Lane @ 2024-11-08 14:49 UTC (permalink / raw)
To: Alexander Korotkov <aekorotkov@gmail.com>; +Cc: Tender Wang <tndrwang@gmail.com>; nicolas.maus@bertelsmann.de; pgsql-bugs@lists.postgresql.org
Alexander Korotkov <aekorotkov@gmail.com> writes:
> On Fri, Nov 8, 2024 at 7:10 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> WFM. But I'm concerned that you couldn't build a test case
>> where the comparison fails. Seems like we need one, in view
>> of this bug having escaped detection for so long.
> AFAICS, the only use case of CheckIndexCompatible() is ALTER TYPE. In
> that case we only serialize and deserialize opclass options without
> any involvement of opclass or data type. So, with the current usage
> scenario CompareOpclassOptions() is only a paranoid check, but
> CheckIndexCompatible() has to do it due to its general semantic.
OK. Well, let's settle for having a test case that at least runs
the code, even if only the success path is taken.
With the release freeze bearing down on us, do you want to wait
till after the releases to fix this? It seems non-urgent given
how long it took for anyone to notice.
regards, tom lane
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
2024-11-06 14:06 BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length PG Bug reporting form <noreply@postgresql.org>
2024-11-06 17:08 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-06 17:14 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-07 06:47 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tender Wang <tndrwang@gmail.com>
2024-11-07 23:28 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 02:05 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-08 02:22 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 05:10 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-08 08:47 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 14:49 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-08 20:29 ` Alexander Korotkov <aekorotkov@gmail.com>
2024-11-12 00:09 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 13+ messages in thread
From: Alexander Korotkov @ 2024-11-08 20:29 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Tender Wang <tndrwang@gmail.com>; nicolas.maus@bertelsmann.de; pgsql-bugs@lists.postgresql.org
On Fri, Nov 8, 2024 at 4:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alexander Korotkov <aekorotkov@gmail.com> writes:
> > On Fri, Nov 8, 2024 at 7:10 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> WFM. But I'm concerned that you couldn't build a test case
> >> where the comparison fails. Seems like we need one, in view
> >> of this bug having escaped detection for so long.
>
> > AFAICS, the only use case of CheckIndexCompatible() is ALTER TYPE. In
> > that case we only serialize and deserialize opclass options without
> > any involvement of opclass or data type. So, with the current usage
> > scenario CompareOpclassOptions() is only a paranoid check, but
> > CheckIndexCompatible() has to do it due to its general semantic.
>
> OK. Well, let's settle for having a test case that at least runs
> the code, even if only the success path is taken.
>
> With the release freeze bearing down on us, do you want to wait
> till after the releases to fix this? It seems non-urgent given
> how long it took for anyone to notice.
Thank you for noticing this. I also think there is no urgency. And I
will wait till the next release.
------
Regards,
Alexander Korotkov
Supabase
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
2024-11-06 14:06 BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length PG Bug reporting form <noreply@postgresql.org>
2024-11-06 17:08 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-06 17:14 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-07 06:47 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tender Wang <tndrwang@gmail.com>
2024-11-07 23:28 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 02:05 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-08 02:22 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 05:10 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-08 08:47 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 14:49 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Tom Lane <tgl@sss.pgh.pa.us>
2024-11-08 20:29 ` Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length Alexander Korotkov <aekorotkov@gmail.com>
@ 2024-11-12 00:09 ` Michael Paquier <michael@paquier.xyz>
0 siblings, 0 replies; 13+ messages in thread
From: Michael Paquier @ 2024-11-12 00:09 UTC (permalink / raw)
To: Alexander Korotkov <aekorotkov@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Tender Wang <tndrwang@gmail.com>; nicolas.maus@bertelsmann.de; pgsql-bugs@lists.postgresql.org
On Fri, Nov 08, 2024 at 10:29:20PM +0200, Alexander Korotkov wrote:
> Thank you for noticing this. I also think there is no urgency. And I
> will wait till the next release.
You have applied db22b900244d today, while only the stamp for the next
minor version has been applied. You should have waited until the
*tag* of the release is pushed, as we should keep a zero-activity
window in stable branches between the stamp and the tag to sort out
any potential issues that could be reported to packagers. This 24~48h
window is important.
Thanks.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 13+ messages in thread
end of thread, other threads:[~2024-11-12 00:09 UTC | newest]
Thread overview: 13+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-11-06 14:06 BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length PG Bug reporting form <noreply@postgresql.org>
2024-11-06 17:08 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-06 17:14 ` Alexander Korotkov <aekorotkov@gmail.com>
2024-11-07 06:47 ` Tender Wang <tndrwang@gmail.com>
2024-11-07 23:28 ` Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 02:05 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-08 02:22 ` Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 02:26 ` Tender Wang <tndrwang@gmail.com>
2024-11-08 05:10 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-08 08:47 ` Alexander Korotkov <aekorotkov@gmail.com>
2024-11-08 14:49 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-08 20:29 ` Alexander Korotkov <aekorotkov@gmail.com>
2024-11-12 00:09 ` 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