On Tue, Nov 4, 2025 at 5:23 PM shveta malik wrote:
>
> >
> > I have addressed the above comments in patch v21.
> >
>
> Thank You. Please find a few comments:
>
> 1)
> + fparams.slot_names = slot_names = NIL;
>
> I think it is not needed to set slot_names to NIL.
>
> 2)
> -WAIT_EVENT_REPLICATIO
On 11/5/25 12:01, David Rowley wrote:
On Tue, 4 Nov 2025 at 21:25, Mats Kindahl wrote:
Here is an updated patch that I checked manually for unnecessary
whitespace changes.
Thanks for updating the patch.
There is one such case affected by this patch, and there the buffer
pointer is copied to a
On 10/25/25 4:03 AM, Bryan Green wrote:
Attached is a patch adding two new functions for generating DDL to
recreate roles: pg_get_role_ddl() and pg_get_role_ddl_statements().
It is no longer apply to the latest code. Could you rebase this?
These functions return the CREATE ROLE statement a
On Thu, Nov 6, 2025 at 3:44 AM Masahiko Sawada wrote:
>
> >
> > I suggest that we should prohibit using tableoid in COPY WHERE clauses
> > for the time being. I don't know if there would be a way to make them
> > work correctly at all, but most likely not in a backpatchable way anyway.
> >
> > I
On Wed, Nov 5, 2025 at 7:00 PM John Naylor wrote:
>
> being empty. Whenever we find one, we acquire a lock on the parent and child
> -page, re-check that the child page is still empty. Then, we remove the
> +page, then re-check that the child page is still empty. Then, we remove the
> downlink a
On Thursday, October 30, 2025 7:01 AM Masahiko Sawada
wrote:
>
> On Mon, Oct 27, 2025 at 5:22 AM Pradeep Kumar
> wrote:
> >
> > Hi All,
> > In this thread they proposed fix_concurrent_slot_xmin_update.patch will
> solve this assert failure. After applying this patch I execute
> pg_sync_replicat
On 11/5/2025 11:05 PM, Michael Paquier wrote:
> On Tue, Oct 28, 2025 at 09:42:11AM -0500, Bryan Green wrote:
>> I found two related bugs in PostgreSQL's Windows port that prevent files
>> from exceeding 2GB. While unlikely to affect most installations (default 1GB
>> segments), the code is objectiv
Hi,
On Mon, Nov 03, 2025 at 07:47:28AM +, Bertrand Drouvot wrote:
> I think the way it is done in the attached makes sense, it:
>
> - introduces PG_DEPRECATED()
> - provides a use case on how to use it (i.e using a version that is currently
> in the future)
> - ensures that XLogRecPtrIsInvali
Thanks Vaibhav, Tushar and Andrew for the review and testing.
On Mon, 3 Nov 2025 at 17:30, Vaibhav Dalvi
wrote:
>
> Hi Mahendra,
>
> I have a few more review comments regarding the patch:
>
> 1. Is the following change in `src/bin/pg_dump/connectdb.c` intentional?
>
> ```
> --- a/src/bin/pg_dump/
On Thu, 6 Nov 2025 at 10:10, Amit Kapila wrote:
>
> On Thu, Nov 6, 2025 at 8:00 AM Shinya Kato wrote:
> >
> >
> > I discovered that the sequence sync worker fails for sequences
> > containing single quotes.
> > ---
> > 2025-11-06 10:22:50.335 JST [1096008] ERROR: could not fetch sequence
> > inf
Greetings,
I've discovered that PostgreSQL on Windows has a handle inheritance
problem that prevents clean restarts after the postmaster is killed
while child processes are running.
The issue is that Windows handles (files, sockets, pipes, shared memory)
are inheritable by default. When backends
On Tue, Oct 28, 2025 at 09:42:11AM -0500, Bryan Green wrote:
> I found two related bugs in PostgreSQL's Windows port that prevent files
> from exceeding 2GB. While unlikely to affect most installations (default 1GB
> segments), the code is objectively wrong and worth fixing.
>
> The first bug is a
On Thu, Nov 6, 2025 at 8:00 AM Shinya Kato wrote:
>
>
> I discovered that the sequence sync worker fails for sequences
> containing single quotes.
> ---
> 2025-11-06 10:22:50.335 JST [1096008] ERROR: could not fetch sequence
> information from the publisher: ERROR: syntax error at or near
> "quo
On Thu, Nov 6, 2025 at 7:18 AM Peter Smith wrote:
>
> On Wed, Nov 5, 2025 at 3:42 PM Shubham Khanna
> wrote:
> >
> > On Mon, Nov 3, 2025 at 12:55 PM Peter Smith wrote:
> > >
> > > Hi Shubham.
> > >
> > > A comment about the v17-0001.
> > >
> > > ==
> > > 1.
> > > + if (check_publication_exis
On Sat, Nov 1, 2025 at 8:25 PM Etsuro Fujita wrote:
> While working on a patch to add more test coverage for EPQ testing
> posted right before, I noticed $SUBJECT:
>
> /*
> * If an FDW or custom scan provider has replaced the join with a
> * scan, there are mu
On Sat, Nov 1, 2025 at 8:18 PM Etsuro Fujita wrote:
> In [1] it was pointed out that there is no test coverage for
> postgresRecheckForeignScan. So I would like to propose to add test
> cases to cover that function (and related core functions like
> ForeignRecheck), as promised in that thread. P
On Wed, 5 Nov 2025 at 22:44, David Rowley wrote:
>
> On Wed, 5 Nov 2025 at 18:26, David Rowley wrote:
> > I'm considering restricting that code Path to where the
> > path->parent->reloptkind != RELOPT_UPPER_REL.
>
> I couldn't think of anything better, so here's a patch to that effect.
I've push
On Wed, Nov 5, 2025 at 1:19 PM Paul A Jungwirth
wrote:
> Here are fixes to a few typos I found in the GiST README.
the child might have migrated as a result of concurrent splits of the
-parent, gistFindCorrectParent() is used to find the parent page.
+parent, so gistFindCorrectParent() is used t
On Mon, Nov 3, 2025 at 7:22 PM Dean Rasheed wrote:
>
> Yeah, reading through the text on that page in more detail, there are
> a number of other omissions, or places that aren't quite fully
> correct, so I've gone through those and attempted to improve things.
>
> Also, I think it would be better
On Wed, Nov 5, 2025 at 5:28 PM Amit Kapila wrote:
> I have pushed the 0001 after making minor adjustments in tests and at
> a few other places. Kindly rebase and send the remaining patches.
I discovered that the sequence sync worker fails for sequences
containing single quotes.
---
2025-11-06 10:
On Thu, 6 Nov 2025 at 00:01, David Rowley wrote:
> I can push this tomorrow morning UTC+13. I'll leave it til then in
> case anyone else has any comments.
I found a few more cases that could get the same treatment and also
included the check_publications() one mentioned by Chao.
I did end up rem
Hi,
On Thu, Oct 16, 2025 at 6:32 PM wenhui qiu wrote:
>
> HI Xuneng Zhou
>
> > - /* Unlock and release buffer */
> > - LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
> > - ReleaseBuffer(buffer);
> > + UnlockReleaseBuffer(buffer);
> > }
> The previous suggestion to keep it was based on the fact that the
On Wed, Nov 5, 2025 at 3:42 PM Shubham Khanna
wrote:
>
> On Mon, Nov 3, 2025 at 12:55 PM Peter Smith wrote:
> >
> > Hi Shubham.
> >
> > A comment about the v17-0001.
> >
> > ==
> > 1.
> > + if (check_publication_exists(conn, dbinfo[i].pubname, dbinfo[i].dbname))
> > + {
> > + /* Reuse existin
Hi Vignesh,
Some review comments for patch v20251105-0001 (stats counter)
==
General.
1.
It was not obvious to me this counter is actually counting. Both the
commit message and the docs say it counts "errors" during sequence
synchronization. AFAIK the sequencesync worker processes sequences
> On Nov 5, 2025, at 21:58, Karina Litskevich
> wrote:
>
>
>
> I'm attaching these changes as a separate patch just in case. You can
> squash them if you like. Not sure what to do with the commitfest entry.
> Should I change it back to Needs review?
>
> Best regards,
> Karina Litskevich
>
Hi John,
Thank you for reviewing and bringing this up regarding checksum architecture.
On Tue, Oct 28, 2025 at 7:50 PM John Naylor wrote:
>
> On Fri, Oct 24, 2025 at 2:49 PM Andrew Kim wrote:
> > The function signatures (pg_checksum_block, pg_checksum_page) remain
> > identical, and checksum_im
> On Nov 5, 2025, at 23:12, Fujii Masao wrote:
>
> On Wed, Oct 29, 2025 at 1:00 AM Fujii Masao wrote:
>>
>> On Mon, Oct 27, 2025 at 6:13 PM Fujii Masao wrote:
>>> One approach to address this issue is to keep calling PQgetResult() until
>>> it returns NULL, and then check the connection sta
> On Nov 6, 2025, at 01:51, Arseniy Mukhin wrote:
>
> On Wed, Nov 5, 2025 at 12:22 PM Chao Li wrote:
>>
>>
>>
>>> On Nov 2, 2025, at 04:41, Arseniy Mukhin
>>> wrote:
>>>
>>> This condition seems to be redundant. I would say it should always be
>>> true, otherwise it would mean that some
On Wed, Nov 05, 2025 at 07:38:23AM -0600, Bryan Green wrote:
> Thanks for the quick turnaround and for including both Xuneng and me.
I owe you one here for noticing the issue quickly. The buildfarm
took some time to reproduce the failure and we have a minor release
coming next week. It would be
>
> The above result shows type casts using functions which cannot be error
> safe.
> Money type related casts still can not be error safe.
>
> Cast from circle to polygon cannot be error safe because the associated
> cast
> function (pg_cast.castfunc) is written in SQL
> (see src/backend/catalog/s
On Tue Nov 4, 2025 at 9:16 PM -03, David Rowley wrote:
> On Wed, 5 Nov 2025 at 08:51, Matheus Alcantara
> wrote:
>>
>> On Mon Nov 3, 2025 at 7:47 PM -03, David Rowley wrote:
>> > Are you sure you've not got something else in your branch? It applies
>> > ok here, and the CFbot isn't complaining ei
On Wed, Nov 5, 2025 at 3:06 AM Peter Eisentraut wrote:
>
> I think the COPY FROM WHERE clause is handling the tableoid column in a
> way that is inconsistent with its usual definition.
>
> Consider a partitioning hierarchy like
>
> DROP TABLE IF EXISTS xp;
>
> CREATE TABLE xp (a int, b int) PARTIT
Philip Alger writes:
> I am attaching v3.
This patch will cause psql's \d to fail hard against any pre-v19
server. That's not acceptable. Note the comment at the top of
describe.c:
* Support for the various \d ("describe") commands. Note that the current
* expectation is that all functions
On Wed Nov 5, 2025 at 9:59 AM -03, Heikki Linnakangas wrote:
>> In case of an error on TransactionIdDidCommit() I think that we will
>> have the same behavior as we advance the "current" position before of
>> DidCommit call the PG_FINALLY block will set the backend position past
>> the failing noti
On Wed, Nov 5, 2025 at 3:43 AM Peter Eisentraut wrote:
>
> On 04.11.25 12:43, jian he wrote:
> >>> generated column allow tableoid system column reference, COPY WHERE
> >>> clause also
> >>> allow tableoid column reference, should be fine.
> >>>
> >
> > for virtual generated column, adding
> > ``
On Wed, Nov 5, 2025 at 12:21 PM Heikki Linnakangas wrote:
>
> On 04/11/2025 16:40, Arseniy Mukhin wrote:
> > It seems that 0002 handles errors during NotifyMyFrontEnd a little
> > differently.
> >
> > With master, in case of a failure during NotifyMyFrontEnd, the
> > listener's position in PG_FIN
On Wed, Nov 5, 2025 at 12:22 PM Chao Li wrote:
>
>
>
> > On Nov 2, 2025, at 04:41, Arseniy Mukhin
> > wrote:
> >
> > This condition seems to be redundant. I would say it should always be
> > true, otherwise it would mean that somebody allowed the listener to
> > skip our notification.
>
> Hi Ars
I am attaching v3.
I changed the name of the function that prints out the trigger using the \d
command (below) from `pg_get_triggerdef_compact` to
`pg_get_triggerdef_string`, which matches the index naming convention for a
similar function.
postgres=# \d child3
>Table "public.chil
On 04.11.25 20:32, Andrew Dunstan wrote:
Over at [1] Vaibhav complained that the patch was deleting a line
following one of the case branches for handling command line options in
pg_restore.c, and said this was not pertinent to the patch. That's
reasonable, but it made me look into $subject a b
Hi Chao,
> > I think this is a mis-use of PRETTYFLAG_SCHEMA that is for printing
> schema-qualified names but omitting schema.
> >
> > Yes, this is to omit the schema because the functions is used to print
> out the triggers when using \d in psql, The current practice isn't to print
> out a schem
Jacob Champion writes:
> On Tue, Nov 4, 2025 at 5:19 PM Tom Lane wrote:
>> Assuming that works for Emmanuel, we could wrap it in a
>> pg_disable_sanitizer_instrumentation macro, or just use it
>> as-is. I don't have a strong preference --- any thoughts?
> No preference on my end. (If a second p
On Tue, Nov 4, 2025 at 11:12 AM Paul A Jungwirth
wrote:
> Back to Postgres, you can get "desired" results IN READ COMMITTED by
> explicitly locking rows (with SELECT FOR UPDATE) just before
> updating/deleting them. Since you acquire the lock before the
> update/delete starts, there can be no new
On Tue, Nov 4, 2025 at 5:19 PM Tom Lane wrote:
> Hah, thanks for the research! For me, this stops the failure
> (on RHEL9 with clang version 19.1.7):
Awesome!
> Assuming that works for Emmanuel, we could wrap it in a
> pg_disable_sanitizer_instrumentation macro, or just use it
> as-is. I don't
On 30.10.25 07:02, Paul A Jungwirth wrote:
On Tue, Oct 28, 2025 at 3:49 AM Peter Eisentraut wrote:
On 24.10.25 19:08, Paul A Jungwirth wrote:
The first 3 doc patches all apply to features that we released in v18,
so it would be nice to get those reviewed/merged soon if possible.
I have looke
On 30/10/2025 18:17, Maxim Orlov wrote:
PFA v20 returns to using actual 64-bit offsets for on-disk SLRU
segments.
Fortunately, now that I've separated reading and writing offsets into
different functions, switching from one implementation to another is
easy to do.
Here's a quick overview of the
On Wed, Oct 29, 2025 at 1:00 AM Fujii Masao wrote:
>
> On Mon, Oct 27, 2025 at 6:13 PM Fujii Masao wrote:
> > One approach to address this issue is to keep calling PQgetResult() until
> > it returns NULL, and then check the connection status when
> > getSQLErrorStatus()
> > determines the error
On Wed, 5 Nov 2025 at 15:11, shveta malik wrote:
>
> Please find a few comments on 003 patch (seqsync_error_count)
>
> 1)
> + /*
> + * Report the worker failed during either sequence synchronization or
> + * table synchronization or apply.
> + */
>
> Shall we tweak it slightly to:
> Report the wor
> On Nov 5, 2025, at 19:01, David Rowley wrote:
>
> It's not your fault, but check_publications_origin_tables() looks like
> a mess. It seems like excessive use of additional code just to avoid
> two separate ereport() calls. Might be worth a follow-up patch to
> clean that up.
>
> The patch
Hi Daniel,
I took a look at the patch again, focusing mostly on the docs and
comments. I think the code is OK, I haven't noticed anything serious.
testing
---
I'm running the TAP tests - so far it looks fine, I've done 2000
iterations of the "single" test, now running ~2000 iterations of th
> When this parameter is set to 'startup' or 'consistency', what happens
> if replication begins early and the startup process fails to replay
> a WAL record—say, due to corruption—before reaching the replication
> start point? In that case, the standby might fail to recover correctly
> because of
Hi,
On Wed, Nov 5, 2025 at 5:51 PM Alexander Korotkov wrote:
>
> Hi!
>
> On Mon, Nov 3, 2025 at 5:13 PM Andres Freund wrote:
> > On 2025-11-03 16:06:58 +0100, Álvaro Herrera wrote:
> > > On 2025-Nov-03, Alexander Korotkov wrote:
> > >
> > > > I'd like to give this subject another chance for pg19
I wrote:
>
> On Thu, Oct 30, 2025 at 4:31 PM Fujii Masao wrote:
> >
> > I also noticed another issue in the io_max_combine_limit docs.
> > Since its context is PGC_POSTMASTER, shouldn't the following
> > description be updated to say "This parameter can only be set at server
> > start"?
> >
> >
On Wed, 5 Nov 2025 at 18:10, Amit Kapila wrote:
>
> On Wed, Nov 5, 2025 at 5:57 PM vignesh C wrote:
> >
> > On Wed, 5 Nov 2025 at 13:58, Amit Kapila wrote:
> > >
> > > On Mon, Nov 3, 2025 at 8:46 PM vignesh C wrote:
> > > >
> > > > The attached v20251103 patch has the changes for the same.
> >
On 04/11/2025 21:41, Tom Lane wrote:
> 0001 is mostly what I had in mind, except that I do not think
> collectDependenciesFromExpr should perform
> eliminate_duplicate_dependencies; it should be explicitly documented
> that the caller should do that before recording the dependencies.
> This appro
On 11/5/2025 1:55 AM, Michael Paquier wrote:
> On Wed, Nov 05, 2025 at 03:30:30PM +0800, Xuneng Zhou wrote:
>> On Wed, Nov 5, 2025 at 2:50 PM Michael Paquier wrote:
>>> Timing issue then, the buildfarm has not been complaining on this one
>>> AFAIK, there have been no recoveryCheck failures report
Hi Mahendra,
Here are a few more comments following my review of the patch:
### 1\. Incorrect Comment for `-g` (globals-only) Option
The comment for the `-g` case in the code states that it restores the
`global.dat` file. However, in the non-text dump output, I only see the
following files: `dat
On 05/11/2025 14:40, Matheus Alcantara wrote:
On Wed Nov 5, 2025 at 6:21 AM -03, Heikki Linnakangas wrote:
On 04/11/2025 16:40, Arseniy Mukhin wrote:
If we want to preserve the previous behavior, maybe we could use a new
local position while copying notifications and only advance the
"current"
On Wed Nov 5, 2025 at 6:21 AM -03, Heikki Linnakangas wrote:
> On 04/11/2025 16:40, Arseniy Mukhin wrote:
>> It seems that 0002 handles errors during NotifyMyFrontEnd a little
>> differently.
>>
>> With master, in case of a failure during NotifyMyFrontEnd, the
>> listener's position in PG_FINALLY
On Wed, Nov 5, 2025 at 5:57 PM vignesh C wrote:
>
> On Wed, 5 Nov 2025 at 13:58, Amit Kapila wrote:
> >
> > On Mon, Nov 3, 2025 at 8:46 PM vignesh C wrote:
> > >
> > > The attached v20251103 patch has the changes for the same.
> > >
> >
> > I have pushed the 0001 after making minor adjustments i
On Wed, 5 Nov 2025 at 13:58, Amit Kapila wrote:
>
> On Mon, Nov 3, 2025 at 8:46 PM vignesh C wrote:
> >
> > The attached v20251103 patch has the changes for the same.
> >
>
> I have pushed the 0001 after making minor adjustments in tests and at
> a few other places. Kindly rebase and send the rem
On 20/06/2025 18:45, Maxim Orlov wrote:
Hi!
I've noticed two bugs reported [0] and [1] which are both related to the
wraparound of mxid and
mxoff. Problems for mxid and mxoff are minor, as they require hitting
the exact overflow limit to
occur. But it's better to correct it.
I included a tes
Thanks Álvaro for the review comments on v4!
PFA, v5 patch set. I have included all your review comments.
Regards,
Nishant Sharma.
EDB, Pune.
https://www.enterprisedb.com
v5-0001-Supporting-changes-for-pg_get_tablespace_ddl-func.patch
Description: Binary data
v5-0002-Adds-pg_get_tablespace_d
On 04.11.25 12:43, jian he wrote:
generated column allow tableoid system column reference, COPY WHERE clause also
allow tableoid column reference, should be fine.
for virtual generated column, adding
``whereClause = expand_generated_columns_in_expr(whereClause, rel, 1);``
should be able to so
On 05.11.25 12:13, Kirill Reshke wrote:
Looks like this issue is currently discussed at [0]. Should we
continue here or there?
[0]https://www.postgresql.org/message-id/
CACJufxHGGc25a2m%2B3Dezfctuykn51n5k3FJK6w3KSqfSFc5gvQ%40mail.gmail.com
I'm aware of that thread. I started this new thread
On Wed, 5 Nov 2025 at 16:06, Peter Eisentraut wrote:
>
> I think the COPY FROM WHERE clause is handling the tableoid column in a
> way that is inconsistent with its usual definition.
>
> Consider a partitioning hierarchy like
>
> DROP TABLE IF EXISTS xp;
>
> CREATE TABLE xp (a int, b int) PARTITIO
I think the COPY FROM WHERE clause is handling the tableoid column in a
way that is inconsistent with its usual definition.
Consider a partitioning hierarchy like
DROP TABLE IF EXISTS xp;
CREATE TABLE xp (a int, b int) PARTITION BY LIST (a);
CREATE TABLE xp1 PARTITION OF xp FOR VALUES IN (1);
On Tue, 4 Nov 2025 at 21:25, Mats Kindahl wrote:
> Here is an updated patch that I checked manually for unnecessary
> whitespace changes.
Thanks for updating the patch.
> There is one such case affected by this patch, and there the buffer
> pointer is copied to another variable and then returned
On Mon, Oct 6, 2025 at 6:46 PM Vitaly Davydov wrote:
> There is one subtle thing. Once, the operation of restart_lsn assignment is
> not
> an atomic, the following scenario may happen theoretically:
> 1. Read GetRedoRecPtr() in the backend (ReplicationSlotReserveWal)
> 2. Assign a new redo LSN in
Hi,
On Wed, Nov 5, 2025 at 3:56 PM Michael Paquier wrote:
>
> On Wed, Nov 05, 2025 at 03:30:30PM +0800, Xuneng Zhou wrote:
> > On Wed, Nov 5, 2025 at 2:50 PM Michael Paquier wrote:
> >> Timing issue then, the buildfarm has not been complaining on this one
> >> AFAIK, there have been no recoveryC
Hi!
On Mon, Nov 3, 2025 at 5:13 PM Andres Freund wrote:
> On 2025-11-03 16:06:58 +0100, Álvaro Herrera wrote:
> > On 2025-Nov-03, Alexander Korotkov wrote:
> >
> > > I'd like to give this subject another chance for pg19. I'm going to
> > > push this if no objections.
> >
> > Sure. I don't under
On Wed, 5 Nov 2025 at 18:26, David Rowley wrote:
> I'm considering restricting that code Path to where the
> path->parent->reloptkind != RELOPT_UPPER_REL.
I couldn't think of anything better, so here's a patch to that effect.
David
v1-0001-Fix-UNION-planner-estimate_num_groups-with-varno-.patc
Please find a few comments on 003 patch (seqsync_error_count)
1)
+ /*
+ * Report the worker failed during either sequence synchronization or
+ * table synchronization or apply.
+ */
Shall we tweak it slightly to:
Report the worker failed during sequence synchronization, table
synchronization, or
> On Nov 5, 2025, at 04:56, Philip Alger wrote:
>
> Hi Chao,
>
> +/*
> + * pg_get_triggerdef_compact
> + * Returns trigger definition in a compact, single-line format
> without
> + * schema qualification designed for the psql \d command.
> + */
> +Datum
> +pg_get_trig
> On Nov 2, 2025, at 04:41, Arseniy Mukhin wrote:
>
> This condition seems to be redundant. I would say it should always be
> true, otherwise it would mean that somebody allowed the listener to
> skip our notification.
Hi Arseniy,
Did you read the example I explained in my previous email?
B
On 04/11/2025 16:40, Arseniy Mukhin wrote:
It seems that 0002 handles errors during NotifyMyFrontEnd a little differently.
With master, in case of a failure during NotifyMyFrontEnd, the
listener's position in PG_FINALLY is set to the beginning of the next
notification, since we advance the "curr
> On Nov 4, 2025, at 02:40, Tom Lane wrote:
>
> Chao Li writes:
>>> On Nov 3, 2025, at 04:56, Tom Lane wrote:
>>> PFA v3, rebased over 8a27d418f, no substantive changes whatever.
>
>> I am on vacation this week, I only find a hour in the evening and did an
>> eyeball review without actuall
On Wed, Nov 5, 2025 at 1:11 PM Robert Treat wrote:
> >
> >
> > + printf(_(" --index[=INDEX] repack following an
> > index\n"));
> > should it be
> > + printf(_("--index[=INDEX] repack following an
> > index\n"));
> > ?
> >
>
> I believe thi
On Mon, Nov 3, 2025 at 8:46 PM vignesh C wrote:
>
> The attached v20251103 patch has the changes for the same.
>
I have pushed the 0001 after making minor adjustments in tests and at
a few other places. Kindly rebase and send the remaining patches.
--
With Regards,
Amit Kapila.
On 2025-Nov-05, Nishant Sharma wrote:
> My reasons why I thought only name form was sufficient:-
> 1. The use case that I had in my mind for this get DDL function was
> getting covered with name as its parameter. As we are creating DDL
> and name will be part of it. Hence using it as input to our
Hello Tom,
05.11.2025 03:34, Tom Lane wrote:
Alexander Lakhin writes:
I've just discovered that that function __ubsan_default_options() is
incompatible with -fsanitize=hwaddress:
$ tmp_install/usr/local/pgsql/bin/postgres
Segmentation fault
Hi Alexander, I wonder if you can still reproduce th
80 matches
Mail list logo
