Hi Amit and Euler,
Thank you both for all your advice. Here comes my first implementation of
INHERIT in the attached v2 patch.
On Wed, Dec 17, 2025 at 8:11 AM Euler Taveira wrote:
> I wondering if we use INHERIT as default. The main advantage is usability
> as Chao
> Li already mentioned. Is t
Hi,
On Tue, Dec 16, 2025 at 10:22:06AM +, Bertrand Drouvot wrote:
> In the attached
PFA a mandatory rebase due to f4e797171ea.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
>From bd285932cbe23ef9e70916269b6be
On Tue, Dec 16, 2025 at 6:38 PM Anthonin Bonnefoy
wrote:
>
> [...]
> The patch fixes the issue by moving smgr_cached_nblocks updates in mdtruncate
> and only updating the cached value if truncate was successful.
>
Thanks for detailed reproducible steps, I can see the reported issue
and proposed
Hi,
On Tue, 16 Dec 2025 at 23:53, Andrew Dunstan wrote:
>
>
> On 2025-12-08 Mo 3:12 AM, Bilal Yavuz wrote:
>
> Hi,
>
> On Mon, 1 Dec 2025 at 06:33, Ashutosh Bapat
> wrote:
>
> On Sun, Nov 30, 2025 at 11:39 PM Andrew Dunstan wrote:
>
> On 2025-11-27 Th 5:19 AM, Nazir Bilal Yavuz wrote:
>
> Hi,
>
Hi,
Here is a completely different idea. This may solve the immediate
problem re the replication of the Conflict Log Table (CLT) at least...
0. AFAIK, anything named with a "pg_" prefix generally means that the
named thing is intended for PG internal use, right?
1. So, the CLT should be automati
On 13.12.25 01:41, Sami Imseih wrote:
Thanks for the updates!
- Less fwrite() and fread(), more read_chunk() and write_chunk(). We
are exposing these APIs, let's use them.
oops. That totally slipped my mind :( sorry about that.
- The callbacks are renamed, to be more generic: "finish" for
Hi Amit,
> Oops, forgot an #include. Fixed in the attached.
>
>
Thank you for the updated patch and the detailed commit message. You have
explained the problem
quite well and the changes look good to me.
I would just add one more comment, which I have attached as a separate
patch with this emai
Hi,
current, v7 the DOC changes:
+
+INCLUDING PARAMETERS
+
+
+ All table parameters, such as the storage
parameter
+ settings of the source table, will be copied. For table storage
+ parameters, see
+ below for more information.
Sami, Jelte, thank you for looking into this.
On Sat, 13 Dec 2025 at 18:48, Sami Imseih wrote:
>
> ```
> \portal name [max_rows]
>
> -- prepare the statements
> select from mytab limit $1 \parse p1
>
> -- bind/execute the statement, optionally to a portal
> \bind_named p1 10 \portal portalname \
Hi All,
The core issue,as you said,is that OAuth validators can add custom
validation logic,but they can't define their own authentication-related
parameters in pg_hba.conf,where they naturally belong.Because of
that,validator-specific config ends up pushed into postgresql.conf via
GUCs,which feel
On Wed, Dec 17, 2025 at 9:52 AM Andres Freund wrote:
>
> On 2025-12-17 09:19:57 +0530, Dilip Kumar wrote:
> > On Tue, Dec 16, 2025 at 11:15 PM Andres Freund wrote:
> > > Actually, wouldn't a table-level property be completely inappropriate for
> > > that? Imagine one publication that's used for
> This deserves a comment, at least.
How about adding this comment:
We keep recently searched entries at the front of the list, so we should call
dlist_push_tail() here.
--
Regards,
ChangAo Chen
Hi Chao,
On Thu, Dec 11, 2025 at 3:09 PM Chao Li wrote:
>
> Hi, Ashutosh,
>
> I just quickly went through the patch. Obviously I need more time to fully
> understand the patch, I will do a deep review today. In the meantime, I just
> caught a nit issue.
>
Thanks for your review.
> > On Dec 11
On Tue, Dec 16, 2025 at 2:50 PM Shlok Kyal wrote:
>
> I have also addressed the remaining comments and attached the latest patch.
>
Thanks. A few comments:
1)
+ if (!set_top && puballtables)
+ set_top = !list_member_oid(aexceptpubids, puboid);
In GetTopMostAncestorInPublication(), we have made
Hi all,
On Tue, Dec 16, 2025 at 3:18 AM Melanie Plageman
wrote:
>
> On Mon, Dec 15, 2025 at 4:36 AM Soumya S Murali
> wrote:
> >
> > With reference to the last patches (v11) I received [1] and while reviewing
> > Melanie’s latest feedback, I understood that PageSetBatchChecksumInplace()
> > is
On Thu, Nov 13, 2025 at 5:41 PM Álvaro Herrera wrote:
>
>
> > @@ -15658,10 +15658,19 @@ ATPostAlterTypeParse(Oid oldId, Oid oldRelId, Oid
> > refRelId, char *cmd,
> > querytree_list = list_concat(querytree_list,
> > afterStmts);
> > }
> > else i
On Wed, Dec 17, 2025 at 9:49 AM Michael Paquier wrote:
>
> On Sat, Dec 13, 2025 at 01:34:47PM -0600, Naga Appani wrote:
> > Documentation changes:
> > - Removed the NULL-return discussion from func-info.sgml, as the
> > statistics are now always available.
> > - Updated maintenance.sgml to clari
Hello Noah,
17.12.2025 05:23, Noah Misch wrote:
I pushed the patch bundle to v17-v14. Thanks for the reviews! The
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dragonet&dt=2025-12-17%2001%3A34%3A36
"double free or corruption (!prev)" likely witnessed a defect in how I
back-patched th
Hi all,
On Tue, Dec 16, 2025 at 3:20 AM Melanie Plageman
wrote:
>
> On Mon, Dec 8, 2025 at 2:14 AM Soumya S Murali
> wrote:
> >
> > Here I made some changes in the logic of the function that only returns a
> > real LSN when the buffer actually needs a WAL flush. If the buffer is not
> > perman
On Wed, 17 Dec 2025 at 00:54, Noah Misch wrote:
>
> On Tue, Dec 16, 2025 at 05:22:36PM +0530, vignesh C wrote:
> > On Tue, 16 Dec 2025 at 00:00, Noah Misch wrote:
> > > On Mon, Dec 15, 2025 at 11:35:35PM +0530, vignesh C wrote:
> > > > This issue has started failing after commit:
> > > > commit 0
On Tue, Dec 16, 2025 at 10:33 AM shveta malik wrote:
> The OID check may be unreliable, as mentioned in the comment. I tested
> this by dropping and recreating information_schema, and observed that
> after recreation it became eligible for publication because its relid
> no longer falls under Fir
Hi,
On 2025-12-17 09:19:57 +0530, Dilip Kumar wrote:
> On Tue, Dec 16, 2025 at 11:15 PM Andres Freund wrote:
> > Actually, wouldn't a table-level property be completely inappropriate for
> > that? Imagine one publication that's used for HA (or major version upgrade)
> > and doesn't use a conflic
On Sat, Dec 13, 2025 at 01:34:47PM -0600, Naga Appani wrote:
> Documentation changes:
> - Removed the NULL-return discussion from func-info.sgml, as the
> statistics are now always available.
> - Updated maintenance.sgml to clarify that exceeding the historical
> 2^32 member limit no longer cau
On Sat, Dec 13, 2025 at 12:07:35PM +0700, Andrey Rudometov wrote:
> A patch with my approach to replacement is in attachments
> (to be applied after yours).
>
> p.s. I wonder why this builds at all - as far as I have tried, using
> BE in FE usually leads to a ton of compilation errors or, at least
On Tue, Dec 16, 2025 at 11:15 PM Andres Freund wrote:
>
> Hi,
>
> On 2025-12-16 11:28:11 -0500, Andres Freund wrote:
> > On 2025-12-16 21:19:21 +0530, Dilip Kumar wrote:
> > > 2) As suggested by Amit Kpila [2], for the upcoming Conflict Log Table
> > > feature, we need a clean way to exclude these
On Tue, Dec 16, 2025 at 04:25:37PM +0530, Nitin Jadhav wrote:
> it seems reasonable to align the checkpoint‑record‑missing case as well.
> The existing PANIC dates back to an era before online backups and archive
> recovery existed, when external manipulation of WAL was not expected and
> such cond
On Tue, Dec 16, 2025 at 9:58 PM Andres Freund wrote:
>
> Hi,
>
> On 2025-12-16 21:19:21 +0530, Dilip Kumar wrote:
> > Motivation
> >
> > 1) The check is performed frequently in the logical decoding path
> > (e.g., in pgoutput_change and pgoutput_truncate). Moving this to a
> > cached cata
On Wed, Dec 17, 2025 at 11:12:46AM +0800, cca5507 wrote:
> Although this does not affect correctness, I'd like to propose a
> patch to fix it.
That's an interesting point.
Indeed, the code bothers putting a fresh matching entry at the
beginning of a bucket, and the code does the opposite when mov
On Fri, Dec 12, 2025 at 09:48:48AM -0800, Paul A Jungwirth wrote:
> On Thu, Dec 11, 2025 at 4:24 PM Noah Misch wrote:
> > On Thu, Dec 04, 2025 at 04:19:02PM -0800, Noah Misch wrote:
> > > Thanks for the review.
> >
> > > The attached version doesn't need a comprehensive re-review, but I'd
> > > pa
Hi,
Although this does not affect correctness, I'd like to propose a patch to fix
it.
--
Regards,
ChangAo Chen
v1-0001-Fix-unexpected-reversal-of-the-list-during-rehash.patch
Description: Binary data
Robert Haas writes:
> On Tue, Dec 16, 2025 at 4:49 PM Tom Lane wrote:
>> ... Therefore, there can be at most one of these
>> operations in flight at a time, so you don't need any dynamic data
>> structure. A simple static variable remembering a not-yet-reparented
>> context would do it.
> Oh, y
On Tue, Dec 16, 2025 at 09:55:09AM -0500, Andres Freund wrote:
> On 2025-12-16 09:45:34 +, Bertrand Drouvot wrote:
>> But, we can't do the same for pgstat_report_analyze() because
>> pgstat_should_count_relation()
>> can modify the relation through pgstat_assoc_relation(). So I'm inclined to
>
On Wed, Dec 17, 2025 at 10:40 AM Nathan Bossart
wrote:
> Hm. I think the USE_LLVM_BACKPORT_SECTION_MEMORY_MANAGER thing might need
> work, too. We don't have any Windows buildfarm machines with LLVM enabled,
> but IIUC it should be possible. Perhaps we can add that to unicorn.
The LLVM code ha
On Tue, Dec 16, 2025 at 4:49 PM Tom Lane wrote:
> Alternatively: I don't see any really good reason for a check_hook
> to be setting other GUCs, in fact it's probably a seriously bad idea.
> (It's a *check* hook, it's not supposed to be causing any
> side-effects.) Therefore, there can be at most
On Tue, Dec 16, 2025, at 7:12 AM, Amit Kapila wrote:
> On Mon, Dec 15, 2025 at 12:44 PM Chao Li wrote:
>>
>> From this perspective, when a new partition is created, it should
>> automatically inherit the parent’s RI. With that behavior, a “FORCE” option
>> would rarely be needed, because having
On Tue, Dec 16, 2025 at 04:55:28PM +0900, Michael Paquier wrote:
> Yeah, these could be removed. I am wondering why 0eb23285a257 did not
> bother, but that's no big deal one way or another, just less code at
> the end of the day.
And applied a patch to remove this code from InjectionPointAttach()
On Tue, Dec 16, 2025 at 04:02:53PM +0200, Heikki Linnakangas wrote:
>> doc/src/sgml/ecpg.sgml:strncpy(name_buf, v.sqlname.data,
>> v.sqlname.length);
>> doc/src/sgml/ecpg.sgml-name_buf[v.sqlname.length] = '\0';
>> --
>> doc/src/sgml/ecpg.sgml:strncpy(name_bu
On Fri, Dec 12, 2025 at 12:33 PM Gyan Sreejith wrote:
>
> Thanks for the feedback, Peter.
>
> I am currently working on the SGML docs update, and will promptly get back
> with an update.
>
> For your second point, currently, all output goes directly to the console. I
> thought it made more sense
On Tue, Dec 16, 2025, at 6:34 AM, Amit Kapila wrote:
>
> Prohibiting all commands sounds too restrictive in all cases (FOR ALL
> TABLES, FOR TABLE, etc.). It would be better if we can disallow
> creating a publication when the user explicitly adds such a relation
> in a FOR TABLE publication, other
Sorry for missing this thread!
On Tue, Dec 2, 2025 at 5:06 AM Zsolt Parragi wrote:
> 1. Configuration for OAuth validation ends up split across two
> locations: issuer/scope and a few other parameters are defined in
> pg_hba.conf, while custom parameters must be set in postgresql.conf.
Yeah. (Th
On Tue, Dec 16, 2025 at 5:44 PM Daniel Gustafsson wrote:
> > On 16 Dec 2025, at 23:03, Corey Huinker wrote:
>
> > One thing I have noticed is the usage of PQExpBuffer in situations where
> the query has no optional parts and no string interpolation.
>
> - res = ExecuteSqlQuery(fout, query-
> On 16 Dec 2025, at 23:03, Corey Huinker wrote:
> One thing I have noticed is the usage of PQExpBuffer in situations where the
> query has no optional parts and no string interpolation.
- res = ExecuteSqlQuery(fout, query->data, PGRES_TUPLES_OK);
+ res = ExecuteSqlQuery(fout,
+
Hi,
On 2025-12-16 15:40:45 -0600, Nathan Bossart wrote:
> On Tue, Dec 16, 2025 at 12:07:34PM -0600, Nathan Bossart wrote:
> > Here's what I have staged for commit. I searched around for anything else
> > that might be missing, and I only found a couple of small things. First,
> > there are some
I've been looking at ways to reorganize and/or clean up pg_dump.c.
One thing I have noticed is the usage of PQExpBuffer in situations where
the query has no optional parts and no string interpolation.
Attached is a patch to replace those usages with the string literal itself.
There are still a fe
Hello, Heikki!
On Tue, Dec 16, 2025 at 2:43 PM Heikki Linnakangas wrote:
> Firstly, I think the STIR approach is the right approach at the high
> level. I don't like the logical decoding idea, for the reasons Matthias
> and Mikhail already mentioned. Maybe there's some synergy with REPACK,
> but
Hello, RobertI’ve created a small test that reproduces the issue. With the proposed fix applied, the test passes, and the reconstruction behaves as expected.I’m attaching the test for review. Please let me know if this looks OK or if you would like it changed.Regards,Oleg
0001-Test-the-correctness
Robert Haas writes:
> Another idea is to just keep track of which contexts need to be
> deleted if we error out. Let's say that when we create a temporary
> check-hook context, we add it to a linked list, similar to
> guc_stack_list, but each element of the list is just a memory context
> pointer
Sorry for the noise.
I discovered that this patch originated in another thread [0], so I spent
some time updating the attributions. Please let me know if there are any
inaccuracies.
On Tue, Dec 16, 2025 at 12:07:34PM -0600, Nathan Bossart wrote:
> Here's what I have staged for commit. I searche
The thread about tablecmds.c being too large for some code inspection
tooling got me thinking about ways to improve the second worst offender:
pg_dump.c.
Those investigations of mine haven't yet revealed a way to split the file
that I find effective, let alone helpful. However, it has shown me a f
On Tue, 2025-12-16 at 12:04 -0800, Jeff Davis wrote:
> Probably a smaller case would do, but I think it requires page splits
> to hit the bug. 0004 fixes the bug.
Because it's a clear bug, I elected to backport 0004 to v18, where the
casefolding APIs were introduced. It's a bug before that as well
On Mon, Dec 15, 2025 at 1:03 AM Bryan Green wrote:
> TLDR; There is a possibility of GUCs using contexts that do not reset;
> combined with a small window of opportunity this would lead to a leak
> given correct timing. We could accept the leak risk, only allow extra
> data as a context for PGC_US
On Tue, Dec 16, 2025 at 7:39 PM Chao Li wrote:
>
>
>
> > On Dec 15, 2025, at 08:25, Peter Smith wrote:
> >
> > On Fri, Dec 12, 2025 at 12:32 PM Chao Li wrote:
> >>
> >>
> >>
> >>> On Dec 12, 2025, at 07:12, Jacob Champion
> >>> wrote:
> >>>
> >>> On Thu, Dec 11, 2025 at 12:22 PM Peter Smith
On 2025-12-08 Mo 3:12 AM, Bilal Yavuz wrote:
Hi,
On Mon, 1 Dec 2025 at 06:33, Ashutosh Bapat
wrote:
On Sun, Nov 30, 2025 at 11:39 PM Andrew Dunstan wrote:
On 2025-11-27 Th 5:19 AM, Nazir Bilal Yavuz wrote:
Hi,
On Sat, 22 Nov 2025 at 01:16, Andrew Dunstan wrote:
Committed
Here is a small
On Tue, Dec 16, 2025 at 1:15 AM Ajit Awekar wrote:
> >What I meant that we can already implement a background process that
> >watches active (oauth) connections, and either:
>
> >Revalidates tokens periodically using introspection APIs
>
> +1 as this will offload validation logic to a dedicated b
On Tue, Dec 16, 2025 at 12:05 AM Zsolt Parragi
wrote:
> a. The user presses the "logout everywhere" button
> b. The users permissions change
> c. The user is deactivated (e.g. employee termination)
> d. A security check invalidates the user's session
>
> From these four, I think graceful logout/co
On Tue, 2025-12-16 at 09:32 +0800, Chao Li wrote:
> I have re-reviewed 0003-0005 last week, they all look good to me.
>
> I have no comment on backport 0003.
Committed 0003 and backported to 14.
Committing 0004 also. For the archives, the bug in that case is:
-- generate some randomly-cased n
On Mon, Dec 15, 2025 at 1:50 PM Jelte Fennema-Nio wrote:
> What metadata
> are you worried about changing mid transaction that could mess stuff
> up? The primary one I can imagine is the username
The HBA inputs can't be allowed to change; that's not what I'm worried about.
The system_user might
On Tue, Dec 16, 2025 at 05:22:36PM +0530, vignesh C wrote:
> On Tue, 16 Dec 2025 at 00:00, Noah Misch wrote:
> > On Mon, Dec 15, 2025 at 11:35:35PM +0530, vignesh C wrote:
> > > This issue has started failing after commit:
> > > commit 0decd5e89db9f5edb9b27351082f0d74aae7a9b6
> > > Sort dump objec
On Sun, Dec 14, 2025 at 3:13 AM Jonathan Gonzalez V.
wrote:
> > Okay, that's good to know. But I'm still missing how the end user (a
> > human) trusts that magic CA within the browser or device they use to
> > finish the actual flow?
>
> More than the end user "trusting" a "magic" CA, it's about w
On Fri, Dec 12, 2025 at 3:05 AM Zsolt Parragi wrote:
> I implemented a simple patch based on the above suggestion
> (PGOAUTHDEBUG=UNSAFE:http...).
Thank you!
> I added the new functions into a common source file which gets
> included in both the oauth module and libpq. I'm not entirely happy
> a
On Tue, Dec 16, 2025 at 3:06 AM Chao Li wrote:
> I guess you meant to say “larger (or greater) than” instead of “rather than”.
Yes, thanks.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Dec 16, 2025 at 08:23:19AM -0500, Greg Burd wrote:
> On Mon, Dec 15, 2025, at 6:08 PM, Andres Freund wrote:
>> LGTM
>
> LGTM, thanks everyone.
Here's what I have staged for commit. I searched around for anything else
that might be missing, and I only found a couple of small things. Firs
Re: Tomas Vondra
> 1) right after opening a connection, I get this
>
> test=# select numa_node, count(*) from pg_buffercache_numa group by 1;
> numa_node | count
> ---+---
> 0 | 290
> -2 | 32478
Does that mean that the "touch all pages" logic is missing in some
cod
Hi,
On 2025-12-16 11:28:11 -0500, Andres Freund wrote:
> On 2025-12-16 21:19:21 +0530, Dilip Kumar wrote:
> > 2) As suggested by Amit Kpila [2], for the upcoming Conflict Log Table
> > feature, we need a clean way to exclude these internal conflict log
> > tables from publication. A catalog flag a
On Wed, Dec 10, 2025 at 3:03 AM Jeevan Chalke
wrote:
> Although I was unable to reproduce the reported issue, a review of the code
> flow confirms that to maintain consistency with all other Parallel Query
> memory allocations, the context should be switched to TopTransactionContext.
> This cha
Thanks for the review!
On Tue, Dec 16, 2025 at 11:39 AM Srinath Reddy Sadipiralla
wrote:
>
>> While working on a patch to set the VM in the same WAL record as
>> pruning and freezing [1], I discovered we have no test coverage of the
>> case where vacuum phase I sets the VM but no modifications ar
Hi Melanie,
On Wed, Dec 10, 2025 at 11:21 PM Melanie Plageman
wrote:
> Hi,
>
> While working on a patch to set the VM in the same WAL record as
> pruning and freezing [1], I discovered we have no test coverage of the
> case where vacuum phase I sets the VM but no modifications are made to
> the
Hi,
On 2025-12-16 21:19:21 +0530, Dilip Kumar wrote:
> Motivation
>
> 1) The check is performed frequently in the logical decoding path
> (e.g., in pgoutput_change and pgoutput_truncate). Moving this to a
> cached catalog attribute in pg_class allows for a simple check.
You could solve t
On Tue, Dec 16, 2025 at 7:18 AM Peter Eisentraut wrote:
>
> You are not modifying deadoffsets in prune_freeze_setup(), but you are
> assigning its address to a pointer variable that is not const-qualified,
> and so it could be used to modify it later on.
>
> A caller to prune_freeze_setup() that s
On Thu, Dec 11, 2025 at 5:37 PM Chao Li wrote:
>
> > On Dec 11, 2025, at 22:59, Melanie Plageman
> > wrote:
> >
> > The reason PruneFreezeResult is passed into prune_freeze_setup() is
> > that we save a pointer to the deadoffsets array in the PruneState
> > instead of having a copy of the whole
Hello hackers,
I would like to propose an improvement to the way PostgreSQL
determines if a relation is eligible for logical replication.
Currently, this check is performed dynamically via
is_publishable_class(), which relies on hard-coded OID checks and
relkind. As noted in the existing comments
Hi,
On 2025-12-16 16:33:17 +0900, Michael Paquier wrote:
> On Mon, Dec 15, 2025 at 12:48:25PM -0500, Andres Freund wrote:
> > I don't think this is true as stated. Two reasons:
> >
> > 1) This afaict guarantees that the relfilenode will not clash with oids, but
> >it does *NOT* guarantee that
Hello,
On Wed, Oct 22, 2025 at 11:58 AM Kirill Reshke wrote:
>
> > 1) There are several typos in verify_gist.c:
> >
> > downlinks -> downlink (header comment)
> > discrepencies -> discrepancies
> > Correctess -> Correctness
> > hande -> handle
> > Initaliaze -> Initialize
> > numbmer -> num
On 12.12.25 10:53, Michael Paquier wrote:
On Thu, Dec 11, 2025 at 11:43:27AM -0500, Tom Lane wrote:
And before that, you'd have to get consensus that sizeof(*var) *is*
the preferred style. I for one don't like it a bit. IMO what it
mostly accomplishes is to remove a cue as to what we are alloc
On 12/16/25 15:48, Christoph Berg wrote:
> Re: To Tomas Vondra
>> I've managed to reproduce it once, running this loop on
>> 18-as-of-today. It errored out after a few 100 iterations:
>>
>> while psql -c 'SELECT COUNT(*) >= 0 AS ok FROM pg_shmem_allocations_numa';
>> do :; done
>>
>> 2025-12-16 11
On 8/23/21 10:15 AM, 蔡梦娟(玊于) wrote:
Hi, all
Recently, I got a problem that the startup process of standby is stuck and
keeps in a waiting state. The backtrace of startup process shows that it is
waiting for a backend process which conflicts with recovery processing to exit,
the guc parameter
Hi,
On 2025-12-16 09:45:34 +, Bertrand Drouvot wrote:
> On Tue, Dec 16, 2025 at 04:39:05PM +0900, Michael Paquier wrote:
> > On Tue, Dec 16, 2025 at 06:49:13AM +, Bertrand Drouvot wrote:
> > > While working on relfilenode statistics, Andres suggested that we pass
> > > the Relation
> > >
Re: To Tomas Vondra
> I've managed to reproduce it once, running this loop on
> 18-as-of-today. It errored out after a few 100 iterations:
>
> while psql -c 'SELECT COUNT(*) >= 0 AS ok FROM pg_shmem_allocations_numa'; do
> :; done
>
> 2025-12-16 11:49:35.982 UTC [621807] myon@postgres ERROR: in
Hi,
On Tue, Dec 16, 2025 at 8:51 PM Heikki Linnakangas wrote:
>
> On 16/12/2025 15:05, Daniil Davydov wrote:
> > I think that it will be useful for temp buffers :
> > 1) We allocate them lazily and never try to free them.
> > 2) Some users are very active in working with temporary tables, and as
On 16/12/2025 13:16, Dagfinn Ilmari Mannsåker wrote:
A quick grep reveals a bunch of strncpy() calls followed by a '\0'
assignment that could be replaced with strlcpy():
$ rg -A1 strncpy|rg -B1 "= '0';"
src/interfaces/libpq/fe-secure-openssl.c: strncpy(buf,
conn->sslpassword,
Hi,
I enabled GSSAPI on Windows CI by using dependencies from Dave Page's
winpgbuild repository [1]. The problem is that Kerberos compilation
does not generate the 'krb5-config' executable on Windows but we
expect it while setting up KDC. Because of that, 'kerberos/001_auth'
and 'libpq/005_negotia
On 16/12/2025 15:05, Daniil Davydov wrote:
Hi,
Commit [1] introduced a new memory context suitable for situations when we
should allocate a large amount of memory with no need to free or reallocate it.
I think that it will be useful for temp buffers :
1) We allocate them lazily and never try to
Didn't know which part of this thread to quote and reply to, so I'll
comment on the whole thing. This is a mix of a summary of the ideas
already discussed, and a new proposal.
Firstly, I think the STIR approach is the right approach at the high
level. I don't like the logical decoding idea, fo
> On Dec 16, 2025, at 17:45, Bertrand Drouvot
> wrote:
>
> Hi,
>
> On Tue, Dec 16, 2025 at 04:39:05PM +0900, Michael Paquier wrote:
>> On Tue, Dec 16, 2025 at 06:49:13AM +, Bertrand Drouvot wrote:
>>> While working on relfilenode statistics, Andres suggested that we pass the
>>> Relatio
Hello Amit,
Yes, That's my understanding as well.
> The behavior should be the same for both partition and inherited tables.
I'm planning to tackle partition tables in the follow-up patch. What do you
think?
Thanks,
Arun
On Tue, 16 Dec 2025 at 15:04, Amit Kapila wrote:
> On Tue, Dec 16, 2025
On Mon, Dec 15, 2025, at 6:08 PM, Andres Freund wrote:
> On December 15, 2025 6:00:47 PM EST, Nathan Bossart
> wrote:
>>Done.
>
> LGTM
> --
Good morning Nathan, Andres,
Thanks again to both of you for your help with this work. With the v11 patch
on HEAD (b39013b7b1b) I was able to configur
Re: Tomas Vondra
> Hmmm, strange. -2 is ENOENT, which should mean this:
>
>-ENOENT
> The page is not present.
>
> But what does "not present" mean in this context? And why would that be
> only intermittent? Presumably this is still running in Docker, so maybe
> it's another
Hi,
On restart, a replica can fail with an 'unexpected data beyond EOF in block
x of relation T/D/R' error. This happened on a PG17.7 and I've been able to
reproduce it on PG 18. This can happen under the following circumstances:
- A relation has a size of 400 blocks.
- Blocks 201 to 400 are em
Hi,
Commit [1] introduced a new memory context suitable for situations when we
should allocate a large amount of memory with no need to free or reallocate it.
I think that it will be useful for temp buffers :
1) We allocate them lazily and never try to free them.
2) Some users are very active in
On Tue, Dec 16, 2025 at 12:51 PM jian he wrote:
>
> hi.
>
> Following the addition of error position support to ComputePartitionAttrs in
> [0], we can extend this feature to ComputeIndexAttrs.
>
> Both partition keys and indexes support expressions and share a 32-column
> limit, CREATE INDEX can b
Hi,
This patch adds a new regression test covering the behavior of aggregate
functions when handling NULL values, including COUNT, COUNT(*) and AVG
on non-empty and empty relations.
The test was implemented using the pg_regress framework and follows the
existing regression testing conventions.
F
On Mon, Dec 15, 2025, at 5:32 PM, Andres Freund wrote:
> Hi,
>
> On 2025-12-15 15:38:49 -0600, Nathan Bossart wrote:
>> +++ b/meson.build
>> @@ -2523,7 +2523,8 @@ int main(void)
>> }
>> '''
>>
>> - if cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd
>> without -march=arm
On Mon, Dec 15, 2025, at 4:38 PM, Nathan Bossart wrote:
> On Mon, Dec 15, 2025 at 12:27:25PM -0500, Greg Burd wrote:
>> Got it, fixed in v9.
>
> I tried to rearrange the s_lock.h changes to make it more obvious what is
> specific to AArch64. WDYT?
Hey Nathan, thanks for taking another look and
On 05.12.25 15:46, Jelte Fennema-Nio wrote:
Calling copyObject fails in C++ with an error like in most setups:
error: use of undeclared identifier 'typeof'; did you mean 'typeid'
This is due to the C compiler supporting used to compile postgres
supporting typeof, but that function actually not
On 15.12.25 22:05, Melanie Plageman wrote:
On Sat, Dec 13, 2025 at 8:59 AM Peter Eisentraut wrote:
On 20.11.25 18:19, Melanie Plageman wrote:
+ prstate->deadoffsets = (OffsetNumber *) presult->deadoffsets;
In your patch
v22-0001-Split-heap_page_prune_and_freeze-into-helpers.patch, the
a
Hi Miłosz and Sergey!
Thanks a lot for reviewing this patch!
> On 9 Dec 2025, at 23:54, Miłosz Bieniek wrote:
>
> Hi,
> Together with Sergey we did a review and found a few things that need fixing:
>
> - `contrib/amcheck/amcheck--1.5--1.6.sql:14` - missing space after comma
Fixed.
> - `verif
On Tue, 16 Dec 2025 at 00:00, Noah Misch wrote:
>
> On Mon, Dec 15, 2025 at 11:35:35PM +0530, vignesh C wrote:
> > While verifying upgrade of subscriber instance, I noticed pg_dump
> > crash caused by incomplete sorting logic for DO_SUBSCRIPTION_REL
> > objects in DOTypeNameCompare(). When multipl
Michael Paquier writes:
> On Tue, Dec 16, 2025 at 03:08:25PM +0800, Chao Li wrote:
>> Given that, I agree we should remove the redundant assignments to
>> keep the code clearer and consistent.
>
> Yeah, these could be removed. I am wondering why 0eb23285a257 did not
> bother, but that's no big
Hi,
When we search catalog cache, we move the searched tuple to the front of the
list:
```
/*
* We found a match in the cache. Move it to the front of the
list
* for its hashbucket, in order to speed subsequent searches.
(The
Hi,
While working on [1], we discussed whether the redo-record-missing error
should be a PANIC or a FATAL. We concluded that FATAL is more appropriate,
as it is more appropriate for the current situation and achieves the
intended behavior and also it is consistent with the backup_label path,
which
1 - 100 of 125 matches
Mail list logo
