On Wed, Nov 5, 2025 at 10:59 PM Karina Litskevich
wrote:
> * trace_connection_negotiation
>It is not documented at all. Should it be fixed?
Since other developer parameters like trace_* are already documented,
it seems good to also add trace_connection_negotiation to the docs.
I noticed that
On Fri, 7 Nov 2025 at 07:50, jian he wrote:
>
> hi.
>
> in transformJsonFuncExpr:
>
> path_spec = transformExprRecurse(pstate, func->pathspec);
> path_spec = coerce_to_target_type(pstate, path_spec, exprType(path_spec),
> JSONPATHOID, -1,
>
Hi,
On Thu, Nov 06, 2025 at 08:48:11PM +0100, Álvaro Herrera wrote:
> On 2025-Nov-06, Bertrand Drouvot wrote:
>
> > I see, I would have introduced XLogRecPtrIsInvalid() on the back branches
> > only
> > if there is a need to (a bugfix that would make use of it). But yeah, I
> > agree
> > that w
Hi Shlok.
Some questions for the patch v25-0002 (EXCEPT tables)
==
doc/src/sgml/ref/alter_publication.sgml
1.
+ALTER PUBLICATION name
ADD ALL TABLES [ EXCEPT [ TABLE ] ( exception_object [, ... ] ) ]
You can do both ADD/SET the , so really there
should be an ADD/SET ALL TABLES command as we
Hello Bryan,
I reviewed your patch and found one potential issue, please check it.
In pg_get_role_ddl_internal, the variable rolname is assigned from
NameStr(roleform->rolname) (line 588), which means it points directly into the
tuple returned from pg_authid. After constructing the initial CREA
On Thu, Nov 6, 2025 at 8:05 PM Amit Kapila wrote:
>
> On Fri, Nov 7, 2025 at 8:30 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Friday, November 7, 2025 2:36 AM Masahiko Sawada
> > wrote:
> > > On Thu, Nov 6, 2025 at 2:36 AM Amit Kapila
> > > wrote:
> > > >
> > > > Good point. This can happen wh
On Sat, 30 Aug 2025 at 05:32, Cary Huang wrote:
>
> > The workers are ending their scan early because
> > heap_getnextslot_tidrange() returns false on the first call from the
> > parallel worker.
> Yes, the previous v9 patch missed setting node->trss_mintid and
> node->trss_maxtid, causing the
On Thu, 6 Nov 2025 at 16:07, Amit Kapila wrote:
>
> On Thu, Nov 6, 2025 at 10:48 AM vignesh C wrote:
> >
> > The patch also includes the change for buildfarm failure at [1].
> > [1] -
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2025-11-05%2010%3A30%3A15
> >
> > The attac
On Wed, Oct 22, 2025 at 10:45 AM jian he
wrote:
> hi.
>
> The previous discussion mentioned using built-in typed tables for the
> error saving table.
> It's doable.
>
> first create an build-in composite type in system_functions.sql:
> CREATE TYPE copy_error_saving AS(
> useridoid,
>
On Thu, 06 Nov 2025 at 18:53, Ajin Cherian wrote:
> 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 need
Hi,
> I conducted several benchmark tests on this patch, and here are some
> observations:
>
> 1) Workloads & settings
> # Workload MIXED - Realistic mix of DDL and DML
> create_mixed_workload() {
> local ROOT="$1"
> cat >"$ROOT/mixed_ddl.sql" <<'SQL'
> -- DDL workload (catalog changes)
> DO $
Hi Chao,
On Thu, Nov 6, 2025 at 8:53 PM Chao Li wrote:
>
> I just reviewed the patch and got a couple of comments:
>
> 1 - 0001
> ```
> +* Create semaphores. This is done here because of a now-non-existent
> +* dependency between spinlocks, which were required for shared memory
>
On Fri, Nov 7, 2025 at 8:30 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Friday, November 7, 2025 2:36 AM Masahiko Sawada
> wrote:
> > On Thu, Nov 6, 2025 at 2:36 AM Amit Kapila
> > wrote:
> > >
> > > Good point. This can happen when the last slot is invalidated or dropped.
> >
> > After the last slot
Hi Shlok.
This is a general comment about the content of these patches.
IIUC, the v25* patches currently are currently arranged like this:
0001
- New command ALTER PUBLICATION pubname RESET;
0002
- Add new command: ALTER PUBLICATION pub_name ADD ALL TABLES;
- Enhance existing CREATE and the new
Hi Shlok.
Here are some review comments for the patch v25-0001 (RESET).
I belatedly saw that you said this is a rebase *only*, so does not yet
address any of the earlier review comments [1]. Anyway, below are a
few more comments that I did not report previously.
==
Commit message
1.
This pa
On 11/7/25 12:20 AM, Bryan Green wrote:
The rebased patch is attached.
Thanks,
Currently, we have the "CREATE USER" command. Should we consider
outputting users with the "LOGIN" attribute as "CREATE USER"?
Otherwise, it might look a little strange.
postgres=# CREATE USER testuser;
CREA
On Fri, Nov 07, 2025 at 03:56:07PM +1300, Thomas Munro wrote:
> On Fri, Nov 7, 2025 at 3:13 PM Michael Paquier wrote:
>> There is a cc.sizeof(), which I guess should be enough to report the
>> size of off_t, and fail if we try a size larger than 4GB for the
>> segment file when a 4-byte off_t is d
On Friday, November 7, 2025 2:36 AM Masahiko Sawada
wrote:
> On Thu, Nov 6, 2025 at 2:36 AM Amit Kapila
> wrote:
> >
> > On Thu, Nov 6, 2025 at 12:03 PM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > On Thursday, October 30, 2025 7:01 AM Masahiko Sawada
> wrote:
> > > >
> > > >
> > > > Also, I th
On Fri, Nov 7, 2025 at 3:13 PM Michael Paquier wrote:
> There is a cc.sizeof(), which I guess should be enough to report the
> size of off_t, and fail if we try a size larger than 4GB for the
> segment file when a 4-byte off_t is detected.
(It's signed per POSIX and on Windows so I assume you mea
hi.
in transformJsonFuncExpr:
path_spec = transformExprRecurse(pstate, func->pathspec);
path_spec = coerce_to_target_type(pstate, path_spec, exprType(path_spec),
JSONPATHOID, -1,
COERCION_EXPLICIT, COERCE_IMPLICIT
On Fri, Nov 7, 2025 at 3:13 AM Bryan Green wrote:
> The reason to still do this patch and clean up the handle inheritance
> mess is that there are states (suspended state, infinite loop, spinlock
> hold, whatever) that a process can be in that keeps it from processing
> the event. We don't need t
On Fri, Nov 07, 2025 at 02:45:32PM +1300, Thomas Munro wrote:
> Only MinGW + meson. MinGW + configure has 32-bit off_t as far as I
> can tell because we do:
>
> if test "$PORTNAME" != "win32"; then
>AC_SYS_LARGEFILE
> ...
>
> I don't personally know of any current Unix without LFS, they just
On Fri, Nov 7, 2025 at 2:35 PM Bryan Green wrote:
> If you agree, and I think you do, I will implement the SOCK_CLOEXEC
> abstraction and the socket_set_cloexec helper for this. My bug fix will
> be the first user.
+1
Thanks for working on all this stuff.
> I also need to handle the handles fo
On Fri, Nov 7, 2025 at 11:29 AM Michael Paquier wrote:
> On Thu, Nov 06, 2025 at 11:17:52AM -0600, Bryan Green wrote:
> > Latest patch attached that includes these code paths.
>
> That feels OK for me. Thomas, do you have a different view on the
> matter for HEAD? Like long, I would just switch
On 11/6/25 19:03, Thomas Munro wrote:
On Fri, Nov 7, 2025 at 7:53 AM Bryan Green wrote:
The socket fix adds WSA_FLAG_NO_HANDLE_INHERIT to WSASocket() in
pgwin32_socket(), and calls SetHandleInformation() in
BackendInitialize() to mark the inherited client socket non-inheritable.
The latter is n
On Thu, Nov 6, 2025 at 4:08 PM Manni Wood
wrote:
>
>
> On Wed, Nov 5, 2025 at 5:54 AM Nishant Sharma <
> [email protected]> wrote:
>
>> Thanks Álvaro for the review comments on v4!
>>
>> PFA, v5 patch set. I have included all your review comments.
>>
>>
>> Regards,
>> Nishant Sharma
On 11/6/25 11:45, Andres Freund wrote:
Hi,
On 2025-11-06 11:17:52 -0600, Bryan Green wrote:
From d3f7543a35b3b72a7069188302cbfc7e4de9120b Mon Sep 17 00:00:00 2001
From: Bryan Green
Date: Thu, 6 Nov 2025 10:56:02 -0600
Subject: [PATCH] Fix Windows file I/O to support files larger than 2GB
Co
On Fri, Nov 7, 2025 at 7:53 AM Bryan Green wrote:
> > The socket fix adds WSA_FLAG_NO_HANDLE_INHERIT to WSASocket() in
> > pgwin32_socket(), and calls SetHandleInformation() in
> > BackendInitialize() to mark the inherited client socket non-inheritable.
> > The latter is needed because handles pas
On Thu, Nov 6, 2025 at 9:00 AM Chao Li wrote:
>
>
>
> > 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
> On Nov 7, 2025, at 00:38, Fujii Masao wrote:
>
> On Thu, Nov 6, 2025 at 8:38 AM Chao Li wrote:
>> I just eyeball reviewed v20 and got a doubt:
>
> Thanks for the review!
>
>
>> +static void
>> +discardAvailableResults(CState *st)
>> +{
>> + PGresult *res = NULL;
>> +
>> + f
On Fri Oct 31, 2025 at 4:02 PM -03, I wrote:
> It's showing a bit complicated to decide at runtime if we should use the
> COPY or INSERT for batch insert into a foreign table. Perhaps we could
> add a new option on CREATE FOREIGN TABLE to enable this usage or not? We
> could document the performanc
On Mon, Aug 11, 2025 at 10:00 AM Kirill Reshke wrote:
> On Mon, 11 Aug 2025 at 14:53, jian he wrote:
> > On Thu, Aug 7, 2025 at 7:35 AM Robert Treat wrote:
> > >
> > > + if (rel->rd_rel->relkind == RELKIND_RELATION &&
> > > + cmdcon->is_enforced &&
> > > + !currcon->conenforced)
> > >
>
Hi, Alexander!
Thank you again for the attention to this patch!
> Could you, please, also comment change from check for
AllowCascadeReplication() to StandbyWithCascadeReplication()? Do you
think this is beneficial and saves us from sending the notifications
when they are useless?
The origi
On Fri, 7 Nov 2025 at 11:21, Sami Imseih wrote:
> Also, I am thinking about another sorting strategy based on average
> autovacuum/autoanalyze time per table. The idea is to sort ascending by
> the greater of the two averages, so workers process quicker tables first
> instead of all workers potent
On Thu, Nov 06, 2025 at 07:58:55AM +0900, Michael Paquier wrote:
> 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 annoying to release something with a
> known instability, at le
On Thu, Nov 06, 2025 at 11:17:52AM -0600, Bryan Green wrote:
> On 11/5/2025 11:05 PM, Michael Paquier wrote:
>> It seems to me that a couple of extra code paths should be handled in
>> the first patch, and I have spotted three of them. None of them are
>> critical as they are related to WAL segmen
Thanks for the ideas on improving the test!
I am still trying to see how useful this type of testing is,
but I will share what I have done.
> I wonder if it would be more realistic to throttle the work simulation
> to a certain speed with pgbench -R rather than having it go flat out.
good point
On Thu, Nov 06, 2025 at 11:10:00PM +1300, Thomas Munro wrote:
> Observing that mess, I kinda wonder what would happen if we just used
> a big hammer to redefine off_t to be __int64 ourselves. On the face
> of it, it sounds like an inherently bad idea that could bite you when
> interacting with lib
On Thu, Nov 06, 2025 at 12:45:30PM -0500, Andres Freund wrote:
> Could we add a testcase that actually exercises at least some of the
> codepaths? We presumably wouldn't want to actually write that much data, but
> it shouldn't be hard to write portable code to create a file with holes...
With som
On Wed, Nov 5, 2025 at 5:54 AM Nishant Sharma <
[email protected]> wrote:
> 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
>
The BSD build was
Hi,
The organizing team for 2026.pgconf.dev is making some changes to the
way that we organize things on Tuesday. One aspect of this is that,
instead of, for example, having one big developer meeting covering
various topics, we want to have more focused developer meetings on
specific topics. In ge
On Thu, 2025-10-16 at 15:46 +0200, Peter Eisentraut wrote:
> If it's a variant of PG_UNICODE_FAST, then it ought to be called
> PG_UNICODE_FAST_CI or similar. Otherwise, one would expect it to be
> a
> variant of PG_UNICODE (if that existed, but there is also UNICODE).
>
> But that name is also
On Fri, 7 Nov 2025 at 01:47, Mats Kindahl wrote:
> > I agree with Amit that there doesn't seem to be a need to free
> > pubnames.data. We're already leaking publist, for instance. This is
> > okay since we only call these functions during DDL, which in general is
> > not sensitive to leaks.
>
>
Hi Tom,
> 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 in this file will succ
On Fri, 7 Nov 2025 at 07:33, Peter Eisentraut wrote:
>
> On 06.11.25 12:46, David Rowley wrote:
> > 0002: MemSet / MemSetAligned macros. It's probably about time someone
> > made these disappear, but that's likely for another thread with more
> > research than I'd like to do here. I replaced "long
On 2025-Nov-06, Bertrand Drouvot wrote:
> I see, I would have introduced XLogRecPtrIsInvalid() on the back branches only
> if there is a need to (a bugfix that would make use of it). But yeah, I agree
> that would add extra "unnecessary" work, so done as you suggested in the
> attached. I checked
On 11/5/2025 11:06 PM, Bryan Green wrote:
> 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, s
On Thu, Nov 6, 2025 at 2:36 AM Amit Kapila wrote:
>
> On Thu, Nov 6, 2025 at 12:03 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Thursday, October 30, 2025 7:01 AM Masahiko Sawada
> > wrote:
> > >
> > >
> > > Also, I think it's worth considering the idea Robert shared before[1]:
> > >
> > > ---
>
On 06.11.25 12:46, David Rowley wrote:
0002: MemSet / MemSetAligned macros. It's probably about time someone
made these disappear, but that's likely for another thread with more
research than I'd like to do here. I replaced "long" with "Size". I
also considered "uintptr_t", but after some reading
On 06.11.25 13:17, Heikki Linnakangas wrote:
@@ -476,7 +476,7 @@ CatCachePrintStats(int code, Datum arg)
if (cache->cc_ntup == 0 && cache->cc_searches == 0)
continue; /* don't print unused caches */
- elog(DEBUG2, "catcache %s/%u: %d tup, %ld srch, %ld+%ld
Hi,
On 2025-11-06 11:17:52 -0600, Bryan Green wrote:
> From d3f7543a35b3b72a7069188302cbfc7e4de9120b Mon Sep 17 00:00:00 2001
> From: Bryan Green
> Date: Thu, 6 Nov 2025 10:56:02 -0600
> Subject: [PATCH] Fix Windows file I/O to support files larger than 2GB
Could we add a testcase that actually
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
On 2025-Nov-06, Rafia Sabih wrote:
> I am seeing following warning,
>
> In file included from specscanner.c:11:
> In file included from ../../../src/include/postgres_fe.h:28:
> ../../../src/include/c.h:113:9: warning: 'pg_restrict' macro redefined
> [-Wmacro-redefined]
> 113 | #define pg_restri
Hi,
On Fri, Oct 31, 2025 at 6:08 AM Masahiko Sawada wrote:
>
> On Thu, Oct 30, 2025 at 9:21 AM Xuneng Zhou wrote:
> >
> > Hi,
> >
> > On Wed, Oct 29, 2025 at 8:17 PM Xuneng Zhou wrote:
> > >
> > > Hi,
> > >
> > > On Sat, Oct 25, 2025 at 2:36 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On
I am seeing following warning,
In file included from specscanner.c:11:
In file included from ../../../src/include/postgres_fe.h:28:
../../../src/include/c.h:113:9: warning: 'pg_restrict' macro redefined
[-Wmacro-redefined]
113 | #define pg_restrict restrict
| ^
../../../src/include
On Thu, Nov 6, 2025 at 8:38 AM Chao Li wrote:
> I just eyeball reviewed v20 and got a doubt:
Thanks for the review!
> +static void
> +discardAvailableResults(CState *st)
> +{
> + PGresult *res = NULL;
> +
> + for (;;)
> + {
> + res = PQgetResult(st->con);
> +
>
On 2025-Nov-04, Tom Lane wrote:
> =?utf-8?Q?=C3=81lvaro?= Herrera writes:
> > On 2025-Nov-03, Tom Lane wrote:
> >> Agreed that the set of \pset options has bloated to the point where
> >> that presentation is unreadable.
>
> > How about this?
>
> WFM.
Thanks, pushed.
--
Álvaro Herrera
On 11/6/2025 1:20 AM, Quan Zongliang wrote:
>
>
> 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 th
On 2025-Nov-06, Euler Taveira wrote:
> +Valid values are a comma-separated list of
> backendtype:level
> +and a single level. The list allows it to use
> +different levels per backend type. Only the single
> level
> +is mandatory (order does not matter) and it is
Hello Vaibhav,
I wonder why is Subscription->publications a list of String rather than
a list of C strings. That's something you'd see in a Node structure,
but Subscription is not a node, so this seems wasteful and pointless.
This is of course not the fault of your patch, but the fact that your
p
Hi,
While hacking on a patch to "inline" the lock implementation of content locks
into storage/buffer/, I looked at the callers of UnlockBuffers() and compared
them to the callers of LWLockReleaseAll().
Somewhat disconcertingly, there are more callers of LWLockReleaseAll(),
without - afaict - ana
Thanks for reviewing this!
On Sun Nov 2, 2025 at 12:11 PM -03, Michael Banck wrote:
> On Mon, Sep 15, 2025 at 09:18:25PM -0300, Matheus Alcantara wrote:
>> postgres=# select * from pg_available_extensions;
>> name | default_version | installed_version | comment
>>
> On Aug 26, 2025, at 15:11, Ashutosh Bapat
> wrote:
>
> Hi Thomas,
>
> On Mon, Aug 25, 2025 at 3:11 PM Thomas Munro wrote:
>>
>> On Mon, Aug 25, 2025 at 9:10 PM Ashutosh Bapat
>> wrote:
>>> Is this change correct? Was there any reason to leave it like that in
>>> e25626677f8076eb3ce94586
On Thu, Nov 6, 2025 at 3:06 PM Heikki Linnakangas wrote:
>
> On 06/11/2025 13:20, Arseniy Mukhin wrote:
> > On Thu, Nov 6, 2025 at 1:05 PM Heikki Linnakangas wrote:
> >>
> >> On 05/11/2025 21:02, Matheus Alcantara wrote:
> >>> On Wed Nov 5, 2025 at 9:59 AM -03, Heikki Linnakangas wrote:
> > I
=?utf-8?Q?=C3=81lvaro?= Herrera writes:
> Yeah, I came across this a few weeks ago as well. I was thinking maybe
> we can expand the ereport() macro instead of duplicating things. It
> looks a bit ugly and I don't think we do it anywhere else ... I mean
> something like
> errstart(WARNING, NUL
Hi Hackers,
Please find the revised patch for the `pg_get_subscription_ddl()` function
attached.
Based on feedback, this version of the function now supports calling the
DDL retrieval
using either the subscription name or the OID, as shown in the examples
below:
```sql
postgres=# SELECT pg_get_s
On 11/6/2025 3:20 AM, Thomas Munro wrote:
> On Wed, Oct 29, 2025 at 3:42 AM Bryan Green wrote:
>> That said, I'm finding off_t used in many other places throughout the
>> codebase - buffile.c, various other file utilities such as backup and
>> archive, probably more. This is likely causing latent
On Thu, 2025-11-06 at 12:15 +0100, Florents Tselai wrote:
> > I don't get what users would need ago(interval) -> timestamp. That function
> > would
> > not make any sense since there is no equivalent to now() which returns
> > timestamp,
> > simply because a timestamp does not refer to any specif
Hi Euler,
I just reviewed the patch and got a few comments.
> On Nov 6, 2025, at 21:09, Euler Taveira wrote:
>
> On Sun, Oct 5, 2025, at 11:18 AM, Euler Taveira wrote:
>> This new patch contains the following changes:
>>
>> - patch was rebased
>> - use commit dbf8cfb4f02
>> - use some GUC memo
On 11/6/2025 7:43 AM, Thomas Munro wrote:
> On Sat, Nov 1, 2025 at 6:16 AM Bryan Green wrote:
>> Hello,
>
> Catching up with all your emails, and I must say it's great to see
> some solid investigation of PostgreSQL-on-Windows problems. There are
> ... more.
>
>> Commit 1da569ca1f (March 2023)
Hi,
On Thu, Nov 06, 2025 at 10:06:13AM +0100, Álvaro Herrera wrote:
> On 2025-Nov-06, Bertrand Drouvot wrote:
>
> > Subject: [PATCH v5 1/4] Introduce XLogRecPtrIsValid() and replace
> > XLogRecPtrIsInvalid() calls
>
> > XLogRecPtrIsInvalid() is inconsistent with the affirmative form of other
>
On 2025-11-05 We 11:41 AM, Peter Eisentraut wrote:
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. Tha
On 11/6/2025 6:46 AM, Thomas Munro wrote:
> On Tue, Nov 4, 2025 at 4:12 AM Bryan Green wrote:
>> Current approaches (inherited event handles, shared memory flags) depend
>> on the postmaster running code during exit. A segfault or kill bypasses
>> all of that.
>
> Huh. I thought PostmasterHandle
On Tue, Nov 4, 2025 at 10:21 PM Tomas Vondra wrote:
Hi Tomas,
> > 0007a: pg_buffercache_pgproc returns pgproc_ptr and fastpath_ptr in
> > bigint and not hex? I've wanted to adjust that to TEXTOID, but instead
> > I've thought it is going to be simpler to use to_hex() -- see 0009
> > attached.
>
On Sat, Nov 1, 2025 at 6:16 AM Bryan Green wrote:
> Hello,
Catching up with all your emails, and I must say it's great to see
some solid investigation of PostgreSQL-on-Windows problems. There are
... more.
> Commit 1da569ca1f (March 2023) added O_CLOEXEC to many call sites
> throughout the back
On 05.11.25 19:19, Masahiko Sawada wrote:
Attached is my proposed patch. I kept it similar to the recently
committed fix in commit ba99c9491c4. Note that we also need to consider
whole-row references, as that patch did.
Here are some minor comments for the proposed patch:
+
On Sun, Oct 5, 2025, at 11:18 AM, Euler Taveira wrote:
> This new patch contains the following changes:
>
> - patch was rebased
> - use commit dbf8cfb4f02
> - use some GUC memory allocation functions
> - avoid one memory allocation (suggested by Japin Li)
> - rename backend type: logger -> syslogge
On Thu, Nov 6, 2025 at 6:16 PM Heikki Linnakangas wrote:
>
> On 31/10/2025 19:11, Heikki Linnakangas wrote:
> > On 26/08/2025 10:11, Ashutosh Bapat wrote:
> >> On Mon, Aug 25, 2025 at 3:11 PM Thomas Munro
> >> wrote:
> >>>
> >>> On Mon, Aug 25, 2025 at 9:10 PM Ashutosh Bapat
> >>> wrote:
>
On 11/6/25 13:40, Álvaro Herrera wrote:
On 2025-Nov-06, Mats Kindahl wrote:
Attached is a proposal that instead of building error message and hints
dynamically, it will use ereport() directly and as a result does not have to
allocate the error message strings and error message hints dynamically
On Tue, Nov 4, 2025 at 4:12 AM Bryan Green wrote:
> Current approaches (inherited event handles, shared memory flags) depend
> on the postmaster running code during exit. A segfault or kill bypasses
> all of that.
Huh. I thought PostmasterHandle should be signalled by the kernel,
not by any code
On 31/10/2025 19:11, Heikki Linnakangas wrote:
On 26/08/2025 10:11, Ashutosh Bapat wrote:
On Mon, Aug 25, 2025 at 3:11 PM Thomas Munro
wrote:
On Mon, Aug 25, 2025 at 9:10 PM Ashutosh Bapat
wrote:
Is this change correct? Was there any reason to leave it like that in
e25626677f8076eb3ce945861
On 2025-Nov-06, Mats Kindahl wrote:
> Attached is a proposal that instead of building error message and hints
> dynamically, it will use ereport() directly and as a result does not have to
> allocate the error message strings and error message hints dynamically and
> these can be removed.
LGTM, t
On 11/6/25 13:09, Amit Kapila wrote:
On Thu, Nov 6, 2025 at 5:24 PM David Rowley wrote:
On Fri, 7 Nov 2025 at 00:38, Mats Kindahl wrote:
As discussed in [1] the functions check_publications_origin_tables() and
check_publications_origin_sequences() are building error messages using
dynamically
On 06/11/2025 13:46, David Rowley wrote:
I've attached a couple of patches to get the ball rolling.
Thanks!
0001: CATCACHE_STATS is using signed longs as counters for cache
hits/misses etc. I've changed this to uint64 rather than int64 as I
didn't see the need to have a signed type to count t
On Thu, Nov 6, 2025 at 5:24 PM David Rowley wrote:
>
> On Fri, 7 Nov 2025 at 00:38, Mats Kindahl wrote:
> > As discussed in [1] the functions check_publications_origin_tables() and
> > check_publications_origin_sequences() are building error messages using
> > dynamically allocated StringInfo ins
On 06/11/2025 13:20, Arseniy Mukhin wrote:
On Thu, Nov 6, 2025 at 1:05 PM Heikki Linnakangas wrote:
On 05/11/2025 21:02, Matheus Alcantara wrote:
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 be
On Fri, 7 Nov 2025 at 00:38, Mats Kindahl wrote:
> As discussed in [1] the functions check_publications_origin_tables() and
> check_publications_origin_sequences() are building error messages using
> dynamically allocated StringInfo instances only to avoid duplicating a
> call of ereport().
Looks
I was playing around with the following imperfect regex to try and get
an idea of how many "long" usages we have.
git grep -E "^\s*(static)?\s*(unsigned)?\s*long\b" -- '*.c' '*.h' | wc -l
REL_13_STABLE -> 486
REL_14_STABLE -> 482
REL_15_STABLE -> 476
REL_16_STABLE -> 485
REL_17_STABLE -> 449
REL_
Hi all,
As discussed in [1] the functions check_publications_origin_tables() and
check_publications_origin_sequences() are building error messages using
dynamically allocated StringInfo instances only to avoid duplicating a
call of ereport().
Attached is a proposal that instead of building e
Thanks for reviewing!
On 06/11/2025 12:24, Álvaro Herrera wrote:
I've been studying the code for freezing of items at vacuum-truncate
time, and one thing that jumps at me is that perhaps we ought to be more
proactive in freezing items immediately as they are processed. We can
do that for any tr
On Fri, 7 Nov 2025 at 00:24, Álvaro Herrera wrote:
> Yeah, I came across this a few weeks ago as well. I was thinking maybe
> we can expand the ereport() macro instead of duplicating things. It
> looks a bit ugly and I don't think we do it anywhere else ... I mean
> something like
>
> errstart(
On Thu, Nov 6, 2025 at 1:05 PM Heikki Linnakangas wrote:
>
> On 05/11/2025 21:02, Matheus Alcantara wrote:
> > 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 "cur
> On 6 Nov 2025, at 10:37 AM, Andreas Karlsson wrote:
>
> On 11/4/25 6:55 AM, Laurenz Albe wrote:
>> Moreover, a good percentage of the users would instead need ago(interval) ->
>> timestamp.
>
> I don't get what users would need ago(interval) -> timestamp. That function
> would not make any
On Thu, Nov 6, 2025 at 10:48 AM vignesh C wrote:
>
> The patch also includes the change for buildfarm failure at [1].
> [1] -
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2025-11-05%2010%3A30%3A15
>
> The attached v2 version patch has the changes for the same.
>
Thanks for
On Thu, Nov 6, 2025 at 12:03 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Thursday, October 30, 2025 7:01 AM Masahiko Sawada
> wrote:
> >
> >
> > Also, I think it's worth considering the idea Robert shared before[1]:
> >
> > ---
> > But what about just surgically preventing that?
> > ProcArraySetReplic
On 2025-Nov-06, Mats Kindahl wrote:
> On 11/5/25 12: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
> >
Hello,
I've been studying the code for freezing of items at vacuum-truncate
time, and one thing that jumps at me is that perhaps we ought to be more
proactive in freezing items immediately as they are processed. We can
do that for any transactions that precede RecentXmin, because by that
point, e
On 2025-Nov-05, Matheus Alcantara wrote:
> My only concern with making these errors FATAL is that if a notification
> entry causes a different, recoverable error, all subsequent messages
> will be lost. This is because if backend die and the user open a new
> connection and execute LISTEN on the c
On Thu, Nov 6, 2025 at 10:20 PM Thomas Munro wrote:
> The only system left with narrow off_t is Windows.
By the way, that's not always true: Meson + MinGW have a 64-bit off_t
on Windows, because meson decides to set -D_FIILE_OFFSET_BITS=64 for
all C compilers except msvc[1] (only other exclusion
On 05/11/2025 21:02, Matheus Alcantara wrote:
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 b
1 - 100 of 107 matches
Mail list logo
