On Tue, 01 Jul 2025 at 11:13, John H wrote:
> Hi,
>
> I've attached an updated version of the patch against master with the changes
> suggested.
>
> On Tue, Nov 29, 2022 at 10:03 PM Michael Paquier wrote:
>>
>> On Thu, Oct 06, 2022 at 04:08:45PM +0900, Michael Paquier wrote:
>>>
>>> There may be
On Wed, Jul 2, 2025 at 10:22 AM Aya Iwata (Fujitsu)
wrote:
>
...
>
> > reloptions.c
> > --
> > - Changes that should be moved to the contrib module Why should in-core
> > reloptions know about this? See for example how "contrib/bloom" defined
> > reloptions.
>
> Thanks. We are stud
On Wed, Jul 2, 2025 at 3:34 AM Melanie Plageman
wrote:
>
> On Tue, Jul 1, 2025 at 12:01 AM Masahiko Sawada wrote:
> >
> > I've attached the updated patches for master and backbranches (v17 and
> > v18). Please review these patches.
>
> All look good to me. One nitpick that is up to you if you wan
Hi,
On Tue, Jul 01, 2025 at 07:46:30PM +0200, Tomas Vondra wrote:
> On 7/1/25 19:20, Bertrand Drouvot wrote:
> > Now it's just a matter of extracting the necessary pieces from
> > pg_buffercache_numa_pages()
> > so that:
> >
> > * the new view could make use of it
> > * the maintenance burden sh
Hi,
I encountered an invalid pointer access issue. Below are the steps to
reproduce the issue:
-- Create table
CREATE TABLE t1(c1 int, c2 int);
-- Create publications with each publication selecting a different column
CREATE PUBLICATION pub1 for TABLE t1(c1);
CREATE PUBLICATION pub2 for TABLE t1
On Mon, Jun 23, 2025 at 4:24 PM Shinya Kato wrote:
>
> On Wed, Jun 11, 2025 at 1:49 PM Shinya Kato wrote:
>>
>> On Thu, Jun 5, 2025 at 3:53 AM Sami Imseih wrote:
>>>
>>> > Approach 2:
>>> > - log_autovacuum_min_duration: Changed behavior, which controls only
>>> > autovacuum logging.
>>> > - log
On Sat, 21 Jun 2025 at 22:21, Tom Lane wrote:
>
> The attached patch does what was discussed in the pgsql-docs
> thread at [1], namely change the four-argument variants of
> width_bucket() to allow their first argument to be NaN,
> treating that value as larger than any non-NaN.
>
LGTM.
I note t
Hi,
On Tue, Jul 01, 2025 at 04:31:01PM +0200, Tomas Vondra wrote:
> On 7/1/25 15:45, Bertrand Drouvot wrote:
>
> I took a quick look on this,
Thanks for looking at it!
> and I doubt we want to change the schema of
> pg_buffercache like this. Adding columns is fine, but it seems rather
> wrong t
On Fri, Jun 27, 2025 at 5:35 PM Peter Geoghegan wrote:
> Attached is v4, which is largely just a polished version of v3. It has
> improved comments and more worked out commit messages. Plus the second
> patch (the row compare patch) now teaches _bt_first to fully rely on
> scan key requiredness ma
> On 1 Jul 2025, at 17:42, Tom Lane wrote:
> There are some minor typos in the proposed commit message, too.
It seems that my grasp of the english language went on holiday before I did.
The attached v9 is hopefully less terrible.
--
Daniel Gustafsson
v9-0001-pg_dump-Fix-compression-API-error
Hi,
I've attached an updated version of the patch against master with the changes
suggested.
On Tue, Nov 29, 2022 at 10:03 PM Michael Paquier wrote:
>
> On Thu, Oct 06, 2022 at 04:08:45PM +0900, Michael Paquier wrote:
>>
>> There may be something I am missing here, but there is no need to care
On 01/07/2025 19:37, Peter Geoghegan wrote:
On Fri, Jun 27, 2025 at 5:35 PM Peter Geoghegan wrote:
Attached is v4, which is largely just a polished version of v3. It has
improved comments and more worked out commit messages. Plus the second
patch (the row compare patch) now teaches _bt_first to
Michael Banck writes:
> please find attached the current patches required to get master built
> and the testsuites run on Debian's hurd-i386 port. I have not had the
> time to test the hurd-amd64 port in the same fashion, but will do so
> next.
Pushed, after some fooling with the comments and com
On Wed, 2025-06-11 at 12:15 -0700, Jeff Davis wrote:
> I changed this to a global_libc_locale that includes both LC_COLLATE
> and LC_CTYPE (from datcollate and datctype), in case an extension is
> relying on strcoll for some reason.
..
> This patch series, at least so far, is designed to have zer
On 7/1/25 16:24, Daniel Gustafsson wrote:
>> On 26 Jun 2025, at 20:01, Daniel Gustafsson wrote:
>>
>>> On 26 Jun 2025, at 15:33, Tom Lane wrote:
>>
>>> So on the whole I prefer the "void" approach. I'm not dead
>>> set on that though, it's just a niggling worry.
>>
>> I think the likelyhood o
> On 1 Jul 2025, at 17:11, Tomas Vondra wrote:
> On 7/1/25 16:24, Daniel Gustafsson wrote:
>> This version has been tested against v17 and v16 where it applies and passes
>> all tests (the latter isn't as assuring as it should be since there is a lack
>> of testcoverage).
>
> Could you elaborate
On Mon, Jun 30, 2025 at 03:37:08PM +0300, Sami Imseih wrote:
> rebased patch.
There were two extra pg_stat_statements_reset() calls added to
cursors.sql that were not necessary. I have also cut by one the
number of FETCH queries with the numbers, as it does not change the
coverage outcome, tweake
Hi,
On Tue, Jul 01, 2025 at 06:45:37PM +0200, Tomas Vondra wrote:
> On 7/1/25 18:34, Bertrand Drouvot wrote:
>
> But isn't the _numa view good enough for this? Sure, you need NUMA
> support for it, and it may take a fair amount of time, but how often you
> need to do such queries?
Not that often
On Tue, Jul 1, 2025 at 12:01 AM Masahiko Sawada wrote:
>
> I've attached the updated patches for master and backbranches (v17 and
> v18). Please review these patches.
All look good to me. One nitpick that is up to you if you want to
change: the comment
* Return the number of tuples deleted from
On Tue, Jul 1, 2025 at 2:03 PM Heikki Linnakangas wrote:
> I like how this makes row comparisons less special. To be honest I don't
> quite understand what the bug was, I'd have to dig much deeper into this
> to swap enough context into my memory for that.
If you're interested, I can provide you
Committed.
--
nathan
Hi,
This is a WIP version of a patch series I'm working on, adding some
basic NUMA awareness for a couple parts of our shared memory (shared
buffers, etc.). It's based on Andres' experimental patches he spoke
about at pgconf.eu 2024 [1], and while it's improved and polished in
various ways, it's s
Hi Jakub,
FYI I've posted my experimental NUMA patch series here:
https://www.postgresql.org/message-id/099b9433-2855-4f1b-b421-d078a5d82017%40vondra.me
I've considered posting it to this thread, but it seemed sufficiently
different to start a new thread.
regards
--
Tomas Vondra
Committed.
--
nathan
On Tue, Sep 10, 2024 at 11:49 AM Jacob Champion
wrote:
> I need to switch away from this for a bit.
"a bit"
In an effort to get this unstuck (and ideally solved during this
commitfest) here are my most recent thoughts:
> I agree that PQconsumeInput() needs to ensure that the transport
> buffers
On 7/1/25 18:34, Bertrand Drouvot wrote:
> Hi,
>
> On Tue, Jul 01, 2025 at 04:31:01PM +0200, Tomas Vondra wrote:
>> On 7/1/25 15:45, Bertrand Drouvot wrote:
>>
>> I took a quick look on this,
>
> Thanks for looking at it!
>
>> and I doubt we want to change the schema of
>> pg_buffercache like th
On 7/1/25 19:20, Bertrand Drouvot wrote:
> Hi,
>
> On Tue, Jul 01, 2025 at 06:45:37PM +0200, Tomas Vondra wrote:
>> On 7/1/25 18:34, Bertrand Drouvot wrote:
>>
>> But isn't the _numa view good enough for this? Sure, you need NUMA
>> support for it, and it may take a fair amount of time, but how of
Hi,
On Tue, Jul 01, 2025 at 12:41:50PM -0400, Tom Lane wrote:
> Michael Banck writes:
> > please find attached the current patches required to get master built
> > and the testsuites run on Debian's hurd-i386 port. I have not had the
> > time to test the hurd-amd64 port in the same fashion, but w
rebased
--
nathan
>From 90985d810f3bed653d3d73553e6236d1f7fb7154 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 28 Apr 2025 14:52:11 -0500
Subject: [PATCH v3 1/1] Teach pg_upgrade to handle in-place tablespaces.
Presently, pg_upgrade assumes that all non-default tablespaces
don't move
Arseniy Mukhin writes:
> I tried the patch and it compiles and works as expected. Several minor
> things I noticed:
Thanks for looking at it!
> 1) btree_gin.c
>case BTEqualStrategyNumber:
> if (cmp > 0)
> res = -1; /* keep scanning */
> else if (cmp
Michael Banck writes:
> On Tue, Jul 01, 2025 at 12:41:50PM -0400, Tom Lane wrote:
> | * If didn't define IOV_MAX, define our own. X/Open requires at
> | * least 16. (GNU Hurd apparently feel that they're not bound by X/Open,
> | * because they don't define this symbol at all.)
> I personally d
>> Perhaps we should think about removing this description, what do you think?
> I think it's a good topic for another patch/thread. Chances are it's not
> the only description that could be updated.
Sure, that could be taken up after this patch.
> That's what I mean. I think it should say
>
>
Daniel Gustafsson writes:
> In preparing for concluding this I've attached a v8 which is the patchset in
> v7
> squashed into a single commit with an attempt at a commit message.
Glancing through this, I observe a couple of minor typos:
+ * Returns number of bytes read (this might be less t
On 17.06.25 20:50, Dean Rasheed wrote:
On Tue, 17 Jun 2025 at 13:56, jian he wrote:
On Tue, Jun 17, 2025 at 7:42 PM Peter Eisentraut wrote:
However, I see your point that it contrasts with the attidentity code
just above.
Perhaps a way to resolve this would be to rewrite the comment someth
On Tue, Jul 1, 2025 at 1:15 AM Jelte Fennema-Nio wrote:
>
> Pretending that
> libpq is the "golden standard" for our protocol just seems plain wrong
> to me.
Not what I said. I'm saying that if a server implementation claims
Postgres compatibility but fails to talk to deployed versions of libpq
i
On Sat, Jun 28, 2025 at 11:44:52AM +0800, cca5507 wrote:
> If I understand correctly, this may break the basic principle:
>
> The aim is to build a snapshot that behaves the same as a
> freshly taken MVCC snapshot would have at the time the
> XLogRecord was generated.
Please note that we prefer
On Tue, Jul 01, 2025 at 10:01:37PM +0200, Michael Banck wrote:
> On Tue, Jul 01, 2025 at 12:41:50PM -0400, Tom Lane wrote:
>> Pushed, after some fooling with the comments and commit messages.
>
> Thanks! Also for back-patching them.
Catching up on this thread after-the-fact, specifically looking
On Fri, Jun 27, 2025 at 03:28:18PM +0300, Mikhail Gribkov wrote:
> Attached is the updated version of the patch with test additions.
Thanks for the updated versions. A bit more variance with the LZ4
levels, even if we cannot track everything, does not sound like a bad
thing to me for the server-s
Hi All,
The failover slots documentation [1] is good for PG - PG logical
replication, but the first two queries require pg_subscription which
may not be present in non-PG downstream. Somebody looking to setup
failover slots for non-PG subscriber may not find the page useful.
However, the third que
Hi,
On Thu, Apr 10, 2025 at 03:05:29PM +, Bertrand Drouvot wrote:
> Hi,
>
> On Thu, Apr 10, 2025 at 09:58:18AM -0500, Nathan Bossart wrote:
> > On Thu, Apr 10, 2025 at 03:35:24PM +0200, Tomas Vondra wrote:
> > > This seems like a good idea in principle, but at this point it has to
> > > wait
On 30/6/2025 09:26, Richard Guo wrote:
On Wed, May 28, 2025 at 6:28 PM Richard Guo wrote:
Yeah, this patchset is targeted for v19. Maybe we could be more
aggressive and have 0001 and 0002 in v18? (no chance for 0003 though)
This patchset does not apply anymore due to 2c0ed86d3. Here is a ne
Hi,
On 2025-06-26 13:07:49 +0800, Zhou, Zhiguo wrote:
> This patch addresses severe LWLock contention observed on high-core systems
> where hundreds of processors concurrently access frequently-shared locks.
> Specifically for ProcArrayLock (exhibiting 93.5% shared-mode acquires), we
> implement a
On Tue, Jul 1, 2025 at 4:23 PM Amit Kapila wrote:
>
> On Mon, Jun 30, 2025 at 3:24 PM Ashutosh Bapat
> wrote:
> >
> > Hi All,
> > In a recent logical replication issue, there were multiple replication
> > slots involved, each using a different publication. Thus the amount of
> > data that was rep
Hi,
On 2025-07-01 09:57:18 -0400, Andres Freund wrote:
> On 2025-06-26 13:07:49 +0800, Zhou, Zhiguo wrote:
> > This patch addresses severe LWLock contention observed on high-core systems
> > where hundreds of processors concurrently access frequently-shared locks.
> > Specifically for ProcArrayLoc
> On 26 Jun 2025, at 20:01, Daniel Gustafsson wrote:
>
>> On 26 Jun 2025, at 15:33, Tom Lane wrote:
>
>> So on the whole I prefer the "void" approach. I'm not dead
>> set on that though, it's just a niggling worry.
>
> I think the likelyhood of it being a problem in practice is pretty slim, b
John Naylor writes:
> On Tue, Jul 1, 2025 at 10:36 AM Tom Lane wrote:
>> Hmpfh. No objection to your patch, but I wonder why
>> "headerscheck --cplusplus" didn't find this? Can we get it
>> to do so?
> Good question, and it turns out it catches it just fine, but you have
> to configure with CP
On 6/26/2025 1:07 PM, Zhou, Zhiguo wrote:
Hi Hackers,
This patch addresses severe LWLock contention observed on high-core systems
where hundreds of processors concurrently access frequently-shared locks.
Specifically for ProcArrayLock (exhibiting 93.5% shared-mode acquires), we
implement a new
Hi Ashutosh,
Thanks for the patch.
Ashutosh Bapat , 30 Haz 2025 Pzt, 13:14
tarihinde şunu yazdı:
> The replica identity of a given table is not a property of
> publication, per say, so it's arguable whether it should be included
> in pg_publication_tables or not. But the output seems to be usefu
On 7/1/25 15:45, Bertrand Drouvot wrote:
> Hi,
>
> On Thu, Apr 10, 2025 at 03:05:29PM +, Bertrand Drouvot wrote:
>> Hi,
>>
>> On Thu, Apr 10, 2025 at 09:58:18AM -0500, Nathan Bossart wrote:
>>> On Thu, Apr 10, 2025 at 03:35:24PM +0200, Tomas Vondra wrote:
This seems like a good idea in pr
Hi,
Thanks for updating the patch and I've read
v17-0001-COPY-on_error-set_null.patch and here are some comments.
+COPY x from stdin (on_error set_null, reject_limit 2);
+ERROR: COPY REJECT_LIMIT requires ON_ERROR to be set to IGNORE
I understand that REJECT_LIMIT is out of scope for this
On Tue, Jul 1, 2025 at 10:57 PM Andrei Lepikhov wrote:
> I like the general idea of this work. But I wonder, why is a new hash
> table designed to store only the notnullattnums field? From the
> discussion, it is not apparent why not to cache all (or most of) the
> data needed for get_relation_inf
Hi hackers,
While working with `initdb`, I noticed that passing an empty string to the
`-U` option (e.g., `initdb -U ''`) causes it to fail with a misleading
error:
performing post-bootstrap initialization ... 2025-07-01 19:48:42.006 PDT
[14888] FATAL: role """ does not exist at character 72
2
Michael Paquier writes:
Hi,
> On Wed, Jul 02, 2025 at 12:38:01AM +, Andy Fan wrote:
>> However this is not true in BootstrapMode, this failure is masked by
>> default because TransactionTreeSetCommitTsData returns fast when
>> track_commit_timestamp is off.
>
> Agreed that there is no point
On Tue, Jul 1, 2025 at 7:56 PM Jianghua Yang wrote:
> Let me know if this approach seems reasonable or if you’d prefer we
> explicitly reject empty usernames with an error instead.
>
>
I'd rather we reject the ambiguous input.
David J.
HI
> 2.
> Perhaps decide_wal_file_action() could be defined in filemap.c.
> While this is unrelated to WAL logging, it could also contribute to
faster
> pg_rewind operations. Should we consider ignoring log files under PGDATA
> (e.g., those in the default log/ directory)?
Agree ，Usually the lo
On Wed, Jul 2, 2025 at 12:01 AM David G. Johnston
wrote:
> On Tue, Jul 1, 2025 at 8:31 PM Jianghua Yang wrote:
>>
>> git show 8e673801262c66af4a54837f63ff596407835c20
>>
>>
>> effective_user = get_id();
>>
>> - if (strlen(username) == 0)
>>
>> + if (!username)
>>
>>
On Mon, Jun 30, 2025 at 4:24 PM Yugo Nagata wrote:
>
>
> > > I have a few minor comment on the patch.
> > >
> > > + if (ival < 0)
> > > + ereport(ERROR,
> > > +
> > > (errcode(ERRCODE_INV
On 2025-07-01 14:20, Masahiko Sawada wrote:
On Thu, Jun 12, 2025 at 3:47 AM Masahiko Sawada
wrote:
On Tue, Jun 10, 2025 at 1:33 PM Nathan Bossart
wrote:
>
> On Tue, Jun 10, 2025 at 12:37:48PM -0700, Masahiko Sawada wrote:
> >> > (1) adds tab completion support for the REJECT_LIMIT option, w
On Tue, Jul 1, 2025 at 6:10 PM Zhijie Hou (Fujitsu) wrote:
> Here is V45 patch set.
With the main patch set now stable, I am summarizing the performance tests
conducted before for reference.
In earlier tests [1], we confirmed that in a pub-sub cluster with high workload
on the publisher (via pgbe
On Wed, Jun 18, 2025 at 02:13:27PM +0900, Michael Paquier wrote:
> v3 seems sensible here. Thanks for the updated patch.
I did a new pass over that. All the code blocks moved to the new file
are identical. However, it is really easy to miss the change in
bytea_string_agg_transfn() with the remo
Hi hackers,
While working on [1], I noticed an inconsistency in the pg_buffercache
documentation: ba2a3c2302f1 missed to add "the" before the pg_buffercache_numa()
function introduction.
PFA a tiny patch to add it for consistency purpose. Should be back-patched to
18 where pg_buffercache_numa() h
On Tue, Jul 1, 2025 at 1:17 PM Peter Smith wrote:
>
> On Sat, Jun 28, 2025 at 12:24 AM Timur Magomedov
> wrote:
> ...
> > Thanks for updates.
> > I was trying to move some code from Postgres core patch to contrib/vci.
> > Started with moving VCI options from StdRdOptions struct and
> > reloptions
On Fri, Jun 27, 2025 at 1:34 PM Fujii Masao wrote:
>
> > To do that, we need
> > 1. we checked that COMMENTS on policies, the TocEntry->tag begins with
> > "POLICY". which is true, see above code walk through.
> > 2. We also need to make sure that no other dumpComment call results in a
> > COMMENT
On Thu, Apr 10, 2025 at 7:36 PM Richard Guo wrote:
> On Wed, Apr 9, 2025 at 6:18 PM David Rowley wrote:
> > On Wed, 9 Apr 2025 at 18:48, Richard Guo wrote:
> > > Perhaps we could spend some planner cycles proving inner_unique for
> > > anti joins, so that Memoize nodes can be considered for them
On Thu, 26 Jun 2025 at 03:21, Aleksander Alekseev
wrote:
>
> Hi,
>
> > Ugh... Turns out it was a bug, there definitely should be a "New
> > patch" button on both the 19-1 and on the Drafts page. And there
> > was... but only if you were logged in as a staff user.
>
> There is now a "New patch" but
HI
> - if (!extra->inner_unique && (jointype == JOIN_SEMI ||
> - jointype == JOIN_ANTI))
> + if ((jointype == JOIN_SEMI || jointype == JOIN_ANTI) &&
> + !extra->inner_unique)
To be nitpicky, this change is meant to align with the earlier comment
modifications to improve code readability, right? Ev
We try to stick with plain text and inline/bottom replies here.
On Tue, Jul 1, 2025 at 8:31 PM Jianghua Yang wrote:
> git show 8e673801262c66af4a54837f63ff596407835c20
>
>
> effective_user = get_id();
>
> - if (strlen(username) == 0)
>
> + if (!username)
>
> u
On Tue, Jul 1, 2025 at 3:39 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Tue, Jul 1, 2025 at 5:07 PM Dilip Kumar wrote:
> >
> > On Tue, Jul 1, 2025 at 2:24 PM Amit Kapila wrote:
> > >
> > > On Tue, Jul 1, 2025 at 10:53 AM Dilip Kumar wrote:
> > > >
> > > > On Tue, Jul 1, 2025 at 10:31 AM Dilip Kumar
>
Hello hackers,
Please take a look at the June report on buildfarm failures:
# SELECT br, COUNT(*) FROM failures WHERE dt >= '2025-06-01' AND
dt < '2025-07-01' GROUP BY br;
REL_13_STABLE: 4
REL_14_STABLE: 3
REL_15_STABLE: 4
REL_16_STABLE: 6
REL_17_STABLE: 4
REL_18_STABLE: 1
master: 54
-- Total: 7
On Tue, Jul 1, 2025 at 7:12 PM Amit Langote wrote:
>
> Hi Dilip,
>
> Happy to see you working on this. It’s clear a lot of thought has
> gone into the design.
Thanks, Amit. And thanks for your comment.
> On Tue, Jul 1, 2025 at 6:27 PM Dilip Kumar wrote:
> > 6) Need to perform a performance t
On Mon, Jun 30, 2025 at 3:57 PM torikoshia wrote:
>
> >> ```
> >> scan_rel = table_open(scan_oid,
> >> AccessShareLock);
> >>
> >> CopyThisRelTo(cstate, scan_rel, cstate->rel,
> >> &processed);
> >>
> >> table_close(scan
Hi Tomas-san,
> > - Divide the patch more and more
> > - to allow committers to consider pros and cons and push one by one
> > - 15 patches is the maximum amount
> > - Separate features to some committable group
> >
>
> Yes. Both parts need to be divided into small (but meaningful) pieces.
Committed.
--
nathan
On Wed, Jul 02, 2025 at 12:38:01AM +, Andy Fan wrote:
> However this is not true in BootstrapMode, this failure is masked by
> default because TransactionTreeSetCommitTsData returns fast when
> track_commit_timestamp is off.
Agreed that there is no point in registering a commit timestamp in
th
Hi,
When working with the commit_ts module, I find the following issue:
After configure with --enable-cassert option, then initdb with:
initdb -D x2 -c track_commit_timestamp=on
Then we can get the following core dump:
0 in raise of /lib/x86_64-linux-gnu/libc.so.6
1 in abort of /lib/x86_64-
Hello hackers,
While updating an extension to support 18beta1, I stumbled on the removal
of `pg_attribute_noreturn()` in favor of `pg_noreturn`, which wasn't
mentioned in the release notes.
I've attached a patch for fixing this.
Best regards,
Steve Chavez
From 52c479141457ab9d7fee1a5ac8b3184a35c
git show 8e673801262c66af4a54837f63ff596407835c20
effective_user = get_id();
- if (strlen(username) == 0)
+ if (!username)
username = effective_user;
The previous code already intended to treat a missing username as falling
back to the system user.
The chec
Hi Fujita-san,
On Tue, Jul 1, 2025 at 11:55 AM Etsuro Fujita wrote:
>
> Hi,
>
> While working on something else, I noticed that while we disallow
> transition tables on foreign tables, we allow transition tables on
> partitioned tables with foreign-table partitions, which produces
> incorrect res
Hi, all
I've noticed an inconsistency in the LSN format printed by pg_waldump,
specifically concerning the lsn: and prev fields in the output.
$ pg_waldump /tmp/pgdata02/pg_wal/0001000A 2>/dev/null
|grep 'AB10260'
rmgr: XLOGlen (rec/tot):114/ 114, tx:
On Mon, Jun 30, 2025 at 3:21 PM Nisha Moond wrote:
>
> Please find the attached v20250630 patch set addressing above comments
> and other comments in [1],[2],[3] and [4].
Thanks for the patches. I am still in process of reviewing it but
please find few comments:
1)
+ if (pset.sversion >= 18)
On 18.06.25 11:46, Bertrand Drouvot wrote:
Hi,
On Tue, Jun 17, 2025 at 07:21:13AM +0200, Peter Eisentraut wrote:
On 12.06.25 08:26, jian he wrote:
in contrib/amcheck/verify_heapam.c, check_tuple
report_corruption(ctx,
psprintf("number of attributes %u exce
On Mon, 30 Jun 2025 18:32:47 +0700
Daniil Davydov <3daniss...@gmail.com> wrote:
> Hi,
>
> On Mon, Jun 30, 2025 at 3:47 PM Yugo Nagata wrote:
> >
> > On Fri, 27 Jun 2025 18:53:02 +0700
> > Daniil Davydov <3daniss...@gmail.com> wrote:
> > > This patch fixes postgres behavior if I first create a fu
Hi,
On Tue, Jul 1, 2025 at 5:47 PM Yugo Nagata wrote:
>
> On Mon, 30 Jun 2025 18:32:47 +0700
> Daniil Davydov <3daniss...@gmail.com> wrote:
>
> > On Mon, Jun 30, 2025 at 3:47 PM Yugo Nagata wrote:
> > >
> > > I agree with Tom Lane that the behavior is expected, although it would be
> > > better
rebased due to changes in 2e94721
--
Jim
From 1c6a9f73de9119beb0e251e9457b4e25d2e99ee4 Mon Sep 17 00:00:00 2001
From: Jim Jones
Date: Tue, 1 Jul 2025 09:37:09 +0200
Subject: [PATCH v9] Add XMLNamespaces option to XMLElement
This patch adds support for the scoped option XMLNamespaces in the
XMLE
> On 1 Jul 2025, at 09:33, Jelte Fennema-Nio wrote:
> I quite dislike the current topic system. Partially because it's
> impossible to filter by a topic (like you can now do with tags), but
> primarily because the actual available topics very often overlap, and
> a patch ends up in a random one.
On Mon, Jun 30, 2025 at 9:23 PM Tomas Vondra wrote:
>
> I wasn't suggesting to do "numactl --interleave=all". My argument was
> simply that doing numa_interleave_memory() has most of the same issues,
> because it's oblivious to what's stored in the shared memory. Sure, the
> fact that local memory
On Tue, Jul 1, 2025 at 2:24 PM Amit Kapila wrote:
>
> On Tue, Jul 1, 2025 at 10:53 AM Dilip Kumar wrote:
> >
> > On Tue, Jul 1, 2025 at 10:31 AM Dilip Kumar wrote:
> > >
> > > On Mon, Jun 30, 2025 at 6:59 PM Zhijie Hou (Fujitsu)
> > > wrote:
> > > >
> > > > On Mon, Jun 30, 2025 at 7:22 PM Amit
On Tue, Jul 1, 2025 at 10:53 AM Dilip Kumar wrote:
>
> On Tue, Jul 1, 2025 at 10:31 AM Dilip Kumar wrote:
> >
> > On Mon, Jun 30, 2025 at 6:59 PM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > On Mon, Jun 30, 2025 at 7:22 PM Amit Kapila wrote:
> > > >
> >
> > I was looking at 0001, it mostly looks
> On 29 Jun 2025, at 12:56, Peter Eisentraut wrote:
>
> On 27.06.25 11:15, Daniel Gustafsson wrote:
>>> On 26 Jun 2025, at 23:06, Daniel Gustafsson wrote:
>>> I'll propose changes for these comments in the morning when coffee has been
>>> had.
>> The attached moves to logging on stderr along wit
On Mon, 30 Jun 2025 at 22:20, Jacob Champion
wrote:
>
> On Mon, Jun 23, 2025 at 12:01 PM David G. Johnston
> wrote:
> >
> > Yes, categories, and give each category its own line in the table.
>
> I'm headed in the opposite direction. Let me elaborate with some very
> strong opinions about the exis
On 24.05.25 12:34, Florents Tselai wrote:
On 24 May 2025, at 12:24 PM, Álvaro Herrera wrote:
On 2025-May-24, Florents Tselai wrote:
I aggree with having more READMEs around the src tree.
It’s true that a lot of doc content found in VII. Internals is dev-oriented,
but imho it should be clos
On Fri, Mar 28, 2025 at 4:22 AM Tom Lane wrote:
>
> v3 needed to rebase over 55527368b. (I guess "git am" cannot
> tolerate any fuzz at all?) No changes of any significance
> whatsoever.
>
> regards, tom lane
>
Hi!
Thank you for working on this.
I tried the patch and i
On 16.01.25 06:38, Peter Smith wrote:
On Thu, Jan 16, 2025 at 3:26 PM Tom Lane wrote:
Peter Smith writes:
During some recent reviews, I came across some comments mentioning "toast" ...
TOAST is a PostgreSQL acronym for "The Oversized-Attribute Storage
Technique" [1].
It is indeed an acrony
Hi,
On Mon, 30 Jun 2025 at 18:01, Andres Freund wrote:
>
> Hi,
>
> On 2025-06-30 16:01:04 +0300, Nazir Bilal Yavuz wrote:
> > This patch aims to improve 027_stream_regress test's regression test
> > error reporting per Andres' suggestion [1].
>
> Thanks for working on that!
>
>
> One thing I don'
On Tue, 1 Jul 2025 at 00:23, Jacob Champion
wrote:
> when other people say "Postgres wire-compatible",
> they're talking about us.
Many people instead are talking about JDBC (Java) or the Npgsql (C#).
These are both much better implementations of the protocol than libpq
is IMO (e.g. libpq still c
On 2025-Jun-30, Nathan Bossart wrote:
> These functions have been around for a while, but commits 48b5aa3 and
> 15afb7d were only back-patched to v16. Any objections if I apply them
> down to v13 now?
None here.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"
On Mon, Jun 30, 2025 at 3:24 PM Ashutosh Bapat
wrote:
>
> Hi All,
> In a recent logical replication issue, there were multiple replication
> slots involved, each using a different publication. Thus the amount of
> data that was replicated through each slot was expected to be
> different. However,
On 04.06.25 08:15, Peter Eisentraut wrote:
On 03.06.25 06:51, Michael Paquier wrote:
Dropping VS 2015 and going up to VS 2019 brings other benefits,
__VA_ARGS__ coming in mind.
Yes, this was going to be my next step. As we're already talking about
it, here is my proposed patch.
For an expl
On Sun, 13 Apr 2025 at 17:40, Abhishek Chanda wrote:
>
> Thanks for the feedback, attached an updated patch that changes most
> of those "Did not find" messages to empty tables. I did not change two
> sets, listDbRoleSettings and listTables both have comments describing
> that these are deliberate
On 7/1/25 06:06, Bertrand Drouvot wrote:
> Hi,
>
> On Mon, Jun 30, 2025 at 08:56:43PM +0200, Tomas Vondra wrote:
>> In particular it now uses "chunking" instead of "batching". I believe
>> bathing is "combining multiple requests into a single one", but we're
>> doing exactly the opposite - split
1 - 100 of 104 matches
Mail list logo
