Hi Nathan,
V2 overall looks good to me. I just got a question and a few nit comments.
> On Dec 1, 2025, at 23:29, Nathan Bossart wrote:
>
> --
> nathan
>
1 - dsa.c
```
+size_t
+dsa_get_total_size_from_handle(dsa_handle handle)
+{
+ size_t size;
+ boolalready_
On 26/11/2025 10:20, Heikki Linnakangas wrote:
On 25/11/2025 22:51, Peter Geoghegan wrote:
In short, I think that we need to track something like
BtreeCheckState.previncompletesplit, but for half-dead pages. And then
actually use that within bt_child_highkey_check, to avoid spurious
false-positi
On 12/1/25 21:10, Corey Huinker wrote:
> Threads like [1] and [2] have gotten me thinking that there may be some
> value in storing statistics about joins.
>
> For the sake of argument, assume a table t1 with a column t2id which
> references the pk of table t2 that has columns t2.t2id, t2c1, t2c2,
On Mon, Dec 1, 2025 at 3:28 PM Andres Freund wrote:
>
> > I noticed that the BUF_STATE_GET_REFCOUNT and BUF_STATE_GET_USAGECOUNT
> > macros cast the return value to a uint32. We won't use the extra bits
> > but we did bother to keep the macro result sized to the field width
> > before so keeping i
On Wed, Sep 24, 2025 at 6:03 PM Tom Lane wrote:
> Aside from the const issue, something I don't really like at the
> coding level is the use of an "allroots" list. One reason is that
> it's partially redundant with the adjacent "subroots" list, but
> a bigger one is that we have transient roots t
Hi,
On 2025-11-21 12:52:38 -0500, Melanie Plageman wrote:
> > 0004: Use 64bit atomics for BufferDesc.state - at this point nothing uses
> > the
> > additional bits yet, though. Some annoying reformatting required to avoid
> > long lines.
>
> I noticed that the BUF_STATE_GET_REFCOUNT and BUF_STAT
Threads like [1] and [2] have gotten me thinking that there may be some
value in storing statistics about joins.
For the sake of argument, assume a table t1 with a column t2id which
references the pk of table t2 that has columns t2.t2id, t2c1, t2c2, t2c3.
In such a situation I can envision the fol
Hello hackers,
Please take a look at the November report on buildfarm failures:
# SELECT br, COUNT(*) FROM failures WHERE dt >= '2025-11-01' AND
dt < '2025-12-01' GROUP BY br;
REL_13_STABLE: 8
REL_14_STABLE: 10
REL_15_STABLE: 4
REL_16_STABLE: 11
REL_17_STABLE: 14
REL_18_STABLE: 22
master: 104
--
Hi,
On 2025-12-01 11:25:13 -0600, Nathan Bossart wrote:
> This file has over 22,000 lines and is too large to be included in GitHub's
> code search results [0]. It appears to have been given its current form in
> 2002 by commit 71dc300. Previously, it was named command.c, which dates
> back to t
On Sat, Nov 1, 2025 at 6:28 PM Tom Lane wrote:
> If people are dead set against double-quoting, I think the only way
> forward is to not include operator names in the generated index names.
> I do not think that's a better way personally, but I seem to be
> outvoted. Here's a v2 that does it like
On 2025-Dec-01, Tom Lane wrote:
> I didn't do any math about it, but that's got to be a far faster rate
> of expansion than the overall PG code base. Maybe partitioning is
> largely to blame? Perhaps analyzing what functionality got added
> here in the past dozen or so years would yield some ide
On Wed, Oct 22, 2025 at 12:27 PM Tom Lane wrote:
> Our shiny new version of Coverity kvetches about
> FreePageBtreeInsertInternal:
>
> *** CID 1667414: (OVERRUN)
> /srv/coverity/git/pgsql-git/postgresql/src/backend/utils/mmgr/freepage.c: 908
> in FreePageBtreeInsertInternal(
On Mon, Dec 1, 2025, at 3:18 PM, Álvaro Herrera wrote:
> My first thought would be to move code that deals with catalog changes
> to files in catalog/. Also a couple of functions related to tablespaces
> could be perhaps be moved to commands/tablespace.c.
>
As Tom said partitioning has a big chun
=?utf-8?Q?=C3=81lvaro?= Herrera writes:
> On 2025-Dec-01, Nathan Bossart wrote:
>> This file has over 22,000 lines and is too large to be included in GitHub's
>> code search results [0]. It appears to have been given its current form in
>> 2002 by commit 71dc300. Previously, it was named command
On 2025-Dec-01, Nathan Bossart wrote:
> This file has over 22,000 lines and is too large to be included in GitHub's
> code search results [0]. It appears to have been given its current form in
> 2002 by commit 71dc300. Previously, it was named command.c, which dates
> back to the 80s. Is it tim
On Thu, Nov 27, 2025 at 4:13 AM Bertrand Drouvot
wrote:
> This function is already exercised with the tests added in f2464997644c so
> that
> looks ok to me.
>
> Maybe Jacob or Andrew have some thoughts to share?
Ooh, blast from the past! You've found my very first Postgres review.
I do not reme
On Fri, Nov 28, 2025 at 12:41 AM Peter Eisentraut wrote:
> I test this once in a while and fix the issues that I find. But it's
> very picky and you will find difficult to fix problems like the fact
> that the signedness of enums is implementation-defined, and so the only
> portable fix there wou
On Mon, Nov 24, 2025 at 9:46 PM Bertrand Drouvot
wrote:
> I think that even with the cast in place, it's good to check the type of data.
> Not for the line that follows (i.e: "data += sizeof(uint32) * 2") but to check
> that the cast makes sense and does not hide "wrong" pointer manipulation.
>Fr
This file has over 22,000 lines and is too large to be included in GitHub's
code search results [0]. It appears to have been given its current form in
2002 by commit 71dc300. Previously, it was named command.c, which dates
back to the 80s. Is it time to split it into a few different files,
simil
On Mon, Dec 1, 2025 at 6:36 PM tushar wrote:
>
>
> On Thu, Nov 27, 2025 at 2:49 PM Mahendra Singh Thalor
> wrote:
>
>>
>> Fixed. Here, I am attaching an updated patch for the review and testing.
>>
>
> Thanks Mahendra, please refer this scenario where restoring the
> dump(database contain tables
On Fri, Nov 21, 2025 at 12:14 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Thursday, November 20, 2025 6:44 PM Amit Kapila
> wrote:
> >
> > On Thu, Nov 20, 2025 at 4:07 PM Zhijie Hou (Fujitsu)
> >
> > wrote:
> > >
> > > On Thursday, November 20, 2025 4:26 PM Vitaly Davydov
> > wrote:
> > >
> > > >
>
On Tue, Nov 25, 2025 at 10:46 AM Álvaro Herrera wrote:
> > Only thing I don't like about this is that the JSON you need for
> > debugging might be after the useless padding. Attached is a patch that
> > does things more surgically, tested against Python 3.6, and I'm
> > running it through the CI n
On Sun, 30 Nov 2025 at 23:57, Jelte Fennema-Nio wrote:
> On Sat, 15 Nov 2025 at 14:05, Magnus Hagander wrote:
> > If it was restricted to only show those that had actually submitted into
> it would've probably been considered OK - but at the time it was not
> considered to be worth the effort to
On Mon, Dec 01, 2025 at 10:58:55AM -0500, Robert Haas wrote:
> The patch itself LGTM. I did a casual review only and did not attempt
> to verify that it works properly, but I like both the idea and the
> execution.
Thanks for reviewing. Once Rahila is happy with the patch, I will commit
it.
--
On 12/1/25 02:23, Peter Geoghegan wrote:
> On Mon, Nov 10, 2025 at 6:59 PM Peter Geoghegan wrote:
>> The new tentative plan is to cut scope by focussing on switching over
>> to the new index AM + table AM interface from the patch in the short
>> term, for Postgres 19.
>
> Attached patch makes the
On 24.07.24 19:48, Tom Lane wrote:
Peter Eisentraut writes:
This is basically the textbook example of aliasing violation, isn't it?
Wouldn't it be just as simple to do
memcpy(&file_crc, &disk_state, sizeof(file_crc));
+1. Also, it seems thoroughly bizarre to me that this case is handled
b
Hi,
Generally speaking, build the heap by tuplesort_heap_build() is O(n) while
tuplesort_heap_insert() is
O(n log n), so the former is better.
I'm not sure why tuplesort_heap_build() is worse than tuplesort_heap_insert()
when handling random
data sometimes, maybe my test method is wrong? Any id
On Mon, Dec 1, 2025 at 10:29 AM Nathan Bossart wrote:
> > 4. Since, with this change, the size column will show memory allocation
> > regardless of whether it is currently mapped in the local process, I
> > think it would be helpful to add a boolean column to display the mapped
> > status as a fut
On Thu, Nov 27, 2025 at 01:51:39PM +0530, Rahila Syed wrote:
> Thank you for this improvement. I think it will be very helpful to have
> the ability to report dsa and dshash memory sizes.
Thanks for reviewing!
> 1. As a result of this change, the following comment in
> pg_get_dsm_registry_allocat
> On 1 Dec 2025, at 17:40, Heikki Linnakangas wrote:
>
> All of those conflicts were pretty straightforward to handle, but it's
> enough code churn for silly mistakes to slip in, especially when the TAP
> test didn't apply. So if you have a chance, please help to review and
> test each of t
On Mon, 1 Dec 2025 at 14:45, Bertrand Drouvot
wrote:
> Thoughts?
I think the hashtable creation API in postgres is so terrible that it
actively discourages usage. At Citus we definitely had the problem
that we would use Lists for cases where a hashtable was preferable
perf wise, just because the
Hi,
Thanks for having looked at it!
On Sun, Nov 23, 2025 at 12:27:08PM +0800, Chao Li wrote:
>
> As long as compile passes, that proves the removal of the unused fields is
> safe.
Most of the time, but not always, see [1].
[1]:
https://www.postgresql.org/message-id/aS2b3LoUypW1/Gdz%40ip-10-9
Hi Filip,
I am also proposing the introduction of a new GUC
variable for setting PQ_RECV_BUFFER_SIZE
in the first patch.
thanks a lot; this allows configuration for all
connections to a database, and so should fit our needs
while not changing any behaviour in the default case.
And the secon
Hi hackers,
Currently to create a hash table we do things like:
A) create a struct, say:
typedef struct SeenRelsEntry
{
Oid rel_id;
int list_index;
} SeenRelsEntry;
where the first member is the hash key, and then later:
B)
ctl.keysize = sizeof(Oid);
ctl.entrysize = sizeof(Se
po 1. 12. 2025 v 13:45 odesílatel Aleksander Alekseev <
[email protected]> napsal:
> Hi,
>
> > I am not sure if there are some authorities who specified some generic
> template of meson.build for extensions.
> > [...]
> > but now, there is zero support for meson for extension from Postgres
On Thu, Nov 27, 2025 at 2:49 PM Mahendra Singh Thalor
wrote:
>
> Fixed. Here, I am attaching an updated patch for the review and testing.
>
Thanks Mahendra, please refer this scenario where restoring the
dump(database contain tablespace) throwing an error
*Steps to reproduce *
initdb (./initdb
Hi,
> I am not sure if there are some authorities who specified some generic
> template of meson.build for extensions.
> [...]
> but now, there is zero support for meson for extension from Postgres side.
contrib/*/meson.build seem quite generic and quite supported.
Or perhaps I don't quite unde
On 30/11/2025 14:15, Andrey Borodin wrote:
On 29 Nov 2025, at 00:51, Heikki Linnakangas wrote:
I didn't understand why the 'kill9' and 'poll_start' stuff is
needed. We have plenty of tests that kill the server with regular
"$node->stop('immediate')", and restart the server normally. The
checkpo
On Mon, Dec 1, 2025 at 2:23 PM Maxim Orlov wrote:
>
>
>
> On Fri, 28 Nov 2025 at 16:17, Ashutosh Bapat
> wrote:
>>
>> One more thing,
>> An UPDATE waits for FOR SHARE query to finish, and vice versa. In my
>> experiments I didn't see an UPDATE creating a multi-xact. Why do we
>> have UPDATEs in
po 1. 12. 2025 v 12:48 odesílatel Aleksander Alekseev <
[email protected]> napsal:
> Hi Pavel,
>
> > But when you use autotools for extensions, then you still should to
> maintain it.
>
> True, but the problem can be decomposed into two parts - maintaining
> for the core and maintaining for
>> On Nov 27, 2025, at 11:10, Tatsuo Ishii wrote:
>>
>> Hi Chao,
>>
>> Any comment on this?
>>
13 - 0005 - nodeWindowAgg.c
```
static
int
do_pattern_match(char *pattern, char *encoded_str, int len)
{
static regex_t *regcache = NULL;
static regex_t preg;
>
One trivial comment:
+logical replication slots. The system automatically
increases the
+effective WAL level to logical when
creating the first
+logical replication slot, and decreases it back to
replica
+when dropping the last logical replication slot. The current
On Tue, Nov 25, 2025 at 8:30 AM jian he wrote:
>
> On Mon, Nov 24, 2025 at 11:38 AM Amul Sul wrote:
> >
> > [...]
> +static inline float8
> +float8_div_safe(const float8 val1, const float8 val2, struct Node *escontext)
>
> but we can change float8_div to:
>
> static inline float8
> float8_div(con
On Mon, Dec 1, 2025 at 12:32 PM Michael Paquier wrote:
>
> On Fri, Nov 28, 2025 at 09:46:43AM +0530, Amul Sul wrote:
> > I have attached patch 0002 that renames it. I also updated patch 0001
> > to accommodate Amit's comment suggestions.
>
> Thanks, applied this one after more tweaks. Regarding 0
Hi Pavel,
> But when you use autotools for extensions, then you still should to maintain
> it.
True, but the problem can be decomposed into two parts - maintaining
for the core and maintaining for the extensions. At least core
developers won't have to check if another patch compiles with
Autotoo
Hello!
On Sun, Nov 30, 2025 at 6:26 PM Mihail Nikalayeu
wrote:
> I think it is better to implement something in isolationtester to
> natively support the case from [0] (in such case we don't need NOTICE
> on .pre-invalidate-catalog-snapshot-end).
I think I have implemented a better solution - wi
Hi all,
This patch is an update after reworking the “checkpoint reason” changes as
a standalone patch, separate from the pg_stat_checkpointer additions as
suggested [1]. I applied the patch on a clean tree and verified that the
logging changes work as expected under different workloads. I am attac
On Fri, Nov 28, 2025 at 6:06 AM Peter Smith wrote:
>
> Some review comments for v8-0001.
Thank Peter, yes these all make sense and will fix in next version
along with other comments by Vignesh/Shveta and Amit, except one
comment
> 9.
> +-- ok - conflict_log_table should not be published with ALL
po 1. 12. 2025 v 11:42 odesílatel Aleksander Alekseev <
[email protected]> napsal:
> Hi Pavel,
>
> >> No, there is currently no agreed schedule for this.
> >
> > almost all extensions has not meson support still
>
> Extensions shouldn't necessarily be built using the same build system
> as
Hello, Antonin!
On Mon, Dec 1, 2025 at 11:29 AM Antonin Houska wrote:
> With logical replication, we cannot really use multiple snapshots as Mihail is
> proposing elsewhere in the thread, because the logical decoding system only
> generates the snapshot for non-catalog tables once (LR uses that s
Dear Tomas,
Thanks for seeing the thread and sorry for late response.
I had a PostgreSQL conference in Japan.
> However, the patch seems fairly large (~80kB, although a fair bit of
> that is comments). Would it be possible to split it into smaller chunks?
> Is there some "minimal patch", which co
Hi Pavel,
>> No, there is currently no agreed schedule for this.
>
> almost all extensions has not meson support still
Extensions shouldn't necessarily be built using the same build system
as the PG core. I can build PG using Meson and then install a 3rd
party extension using `make install && mak
On Mon, Dec 1, 2025 at 3:12 PM Amit Kapila wrote:
>
> On Mon, Dec 1, 2025 at 2:58 PM shveta malik wrote:
> >
> > On Mon, Dec 1, 2025 at 2:04 PM Dilip Kumar wrote:
> > >
> > > On Mon, Dec 1, 2025 at 1:57 PM shveta malik
> > > wrote:
> > > >
> > > > Since there is a concern that multiple rows fo
Hannu Krosing wrote:
> On Fri, Nov 28, 2025 at 6:58 PM Hannu Krosing wrote:
> >
> > On Fri, Nov 28, 2025 at 5:58 PM Matthias van de Meent
> > wrote:
> > >
> > ...
> > > I'm a bit worried, though, that LR may lose updates due to commit
> > > order differences between WAL and PGPROC. I don't know
po 1. 12. 2025 v 11:06 odesílatel Peter Eisentraut
napsal:
> On 01.12.25 09:47, Aleksander Alekseev wrote:
> > Quick and somewhat related question: if Meson support was added in PG
> > 16, does this mean that Autotools will be supported up to and
> > including PG 20?
>
> No, there is currently no
On 01.12.25 09:47, Aleksander Alekseev wrote:
Quick and somewhat related question: if Meson support was added in PG
16, does this mean that Autotools will be supported up to and
including PG 20?
No, there is currently no agreed schedule for this.
On Mon, Dec 1, 2025 at 2:58 PM shveta malik wrote:
>
> On Mon, Dec 1, 2025 at 2:04 PM Dilip Kumar wrote:
> >
> > On Mon, Dec 1, 2025 at 1:57 PM shveta malik wrote:
> > >
> > > Since there is a concern that multiple rows for
> > > multiple_unique_conflicts can cause data-bloat, it made me rethink
On Mon, Dec 1, 2025 at 2:04 PM Dilip Kumar wrote:
>
> On Mon, Dec 1, 2025 at 1:57 PM shveta malik wrote:
> >
> > On Thu, Nov 13, 2025 at 9:17 PM Dilip Kumar wrote:
> > >
> > > On Thu, Nov 13, 2025 at 2:39 PM shveta malik
> > > wrote:
> > > >
> > > > > Few observations related to publication.
>
Hi,
+1 on Tom's point about BEFORE UPDATE triggers.
I also noticed that in execReplication.c, ExecSimpleRelationUpdate() passes
CMD_INSERT to ExecConstraints():
ExecConstraints(CMD_INSERT, resultRelInfo, slot, estate);
I think this should be CMD_UPDATE?
Regards,
Yuan Li(carol)
-邮件原件-
发件
On Mon, Dec 1, 2025 at 11:48 AM Masahiko Sawada wrote:
>
> On Thu, Nov 27, 2025 at 11:00 PM shveta malik wrote:
> >
> > On Thu, Nov 27, 2025 at 4:33 PM shveta malik wrote:
> > >
> > > A few more comments:
> > >
> > >
> > > 10)
> > > +# Promote standby3, increasing effective_wal_level to 'logical
Subject: Re: PoC: Simplify recovery after dropping a table by LOGGING the
restore LSN
Hi all,
I've implemented an improved version of this feature that addresses
Kirill's concern about logging the wrong LSN [1].
The key difference: instead of logging WAL insert pointer at lock time,
this patch l
Matthias van de Meent wrote:
> I'm a bit worried, though, that LR may lose updates due to commit
> order differences between WAL and PGPROC. I don't know how that's
> handled in logical decoding, and can't find much literature about it
> in the repo either.
Can you please give me an example of t
On Mon, Dec 1, 2025 at 11:40 AM Masahiko Sawada wrote:
>
>
> > 11)
> > my ($result, $stdout, $stderr) = $standby4->psql('postgres',
> > qq[select pg_logical_slot_get_changes('standby4_slot', null, null)]);
> > like(
> > $stderr,
> > qr/ERROR: logical decoding on standby requires "effective_wal_le
On Fri, 28 Nov 2025 at 16:17, Ashutosh Bapat
wrote:
> One more thing,
> An UPDATE waits for FOR SHARE query to finish, and vice versa. In my
> experiments I didn't see an UPDATE creating a multi-xact. Why do we
> have UPDATEs in the load created by the test? Am I missing something?
As far as I
Hi hackers,
Quick and somewhat related question: if Meson support was added in PG
16, does this mean that Autotools will be supported up to and
including PG 20?
--
Best regards,
Aleksander Alekseev
On Mon, Dec 1, 2025 at 11:29 AM Masahiko Sawada wrote:
>
> On Thu, Nov 27, 2025 at 3:51 AM shveta malik wrote:
> >
> > On Thu, Nov 27, 2025 at 2:32 AM Masahiko Sawada
> > wrote:
> > >
> > >
> > > I've squashed all fixup patches and attached the updated patch.
> > >
> >
> > Thanks for test resul
On Mon, Dec 1, 2025 at 1:57 PM shveta malik wrote:
>
> On Thu, Nov 13, 2025 at 9:17 PM Dilip Kumar wrote:
> >
> > On Thu, Nov 13, 2025 at 2:39 PM shveta malik wrote:
> > >
> > > > Few observations related to publication.
> > > > --
> >
> > Thanks Shveta, for testing a
On Thu, Nov 13, 2025 at 9:17 PM Dilip Kumar wrote:
>
> On Thu, Nov 13, 2025 at 2:39 PM shveta malik wrote:
> >
> > > Few observations related to publication.
> > > --
>
> Thanks Shveta, for testing and sharing your thoughts. IMHO for
> conflict log tables it should be
On Fri, Nov 28, 2025 at 2:32 PM shveta malik wrote:
>
> On Thu, Nov 27, 2025 at 5:50 PM Dilip Kumar wrote:
> >
> >
> > I have fixed all these comments and also the comments of 0002, now I
> > feel we can actually merge 0001 and 0002, so I have merged both of
> > them.
> >
> > Now pending work sta
On Fri, Nov 28, 2025 at 12:24 PM vignesh C wrote:
>
> On Thu, 27 Nov 2025 at 17:50, Dilip Kumar wrote:
> >
> > On Thu, Nov 27, 2025 at 6:30 AM Peter Smith wrote:
> >
> > I have fixed all these comments and also the comments of 0002, now I
> > feel we can actually merge 0001 and 0002, so I have m
Hi,
On Mon, Dec 01, 2025 at 11:05:19AM +0530, Soumya S Murali wrote:
> > On Fri, Nov 28, 2025 at 10:23:54AM +0530, Soumya S Murali wrote:
> > I am still not convinced of the usefulness of those changes to
> > pg_stat_checkpointer, but some feedback on the patch:
>
> According to my understanding,
Attached is the patch set rebased on current master. I have split the
patch into two parts: 0001 teaches eval_const_expressions to simplify
COALESCE arguments using NOT NULL constraints, and 0002 teaches
expr_is_nonnullable to handle COALESCE expressions.
In addition, 0003 is a WIP patch that ext
72 matches
Mail list logo
