On Wed, 2025-04-02 at 15:23 -0400, Tom Lane wrote:
> Fujii Masao writes:
> > Filtering log messages by SQLSTATE might be useful for some users,
> > but I'm unsure if it should belong in the core. There are also other
> > potential filtering needs, such as by application name, client host,
> > data
It occurred to me that we will also want to have NOT NULL NOT ENFORCED
constraints eventually. As we have discussed elsewhere, the NOT
ENFORCED state is closely related to the NOT VALID state. So that
should probably be considered in the design here.
Reading up on this again now, I'm confuse
On 2025-Apr-03, Peter Eisentraut wrote:
> It occurred to me that we will also want to have NOT NULL NOT ENFORCED
> constraints eventually. As we have discussed elsewhere, the NOT
> ENFORCED state is closely related to the NOT VALID state. So that
> should probably be considered in the design her
Hi,
On Thu, Apr 03, 2025 at 09:25:02AM +0530, vignesh C wrote:
> On Mon, 31 Mar 2025 at 18:35, Bertrand Drouvot
> wrote:
> >
> Couple of suggestions:
Thanks for looking at it!
> 1) I felt we can include a similar verification for one of the logical
> replication tests too:
> +# Wait for the wal
On 11.03.25 11:42, Peter Eisentraut wrote:
Here is an updated patch that works more along those lines. It adds a
pg_upgrade option --update-checksums, which activates the code to
rewrite the checksums. You must specify this option if the source and
target clusters have different checksum sett
On Thu, Apr 3, 2025 at 2:24 AM Alvaro Herrera wrote:
>
> create table singlepp (id bigint default 1) partition by list (id);
> alter table singlepp add constraint dummy_constr not null id not valid;
> create table singlepp_1 (id bigint default 1);
> alter table singlepp_1 add constraint dummy_cons
On 2025-Apr-03, Ashutosh Bapat wrote:
> Looks like the problem is in the test itself as pointed out by Jeff in
> [1]. PFA patch fixing the test and enabling statistics back.
Thanks, pushed.
> A note about variable name changes and introduction of new variables.
> We run step 2 between 1 and 3 so
Hi,
On Thu, Apr 03, 2025 at 09:01:43AM +0200, Jakub Wartak wrote:
> On Wed, Apr 2, 2025 at 6:40 PM Tomas Vondra wrote:
>
> Hi Tomas,
>
> > OK, so you agree the commit messages are complete / correct?
>
> Yes.
Not 100% sure on my side.
=== v21-0002
Says:
"
This introduces three new functio
On Thu, 3 Apr 2025 at 09:07, Peter Smith wrote:
>
> Hi,
>
> I was away for the last few weeks when this feature got committed, so
> I missed the chance to post my comments earlier.
>
> It seems the final SGML docs are mostly from this [1] suggestion, but
> I think there are one or two more improve
HI Srirama
It's getting close to code freeze. Any updates from your end?
Thanks
On Tue, Mar 18, 2025 at 12:58 AM Srirama Kucherlapati
wrote:
> Hi Team,
>
> Here are the updates on the meson on AIX. Our team had pushed the fixes
> meson github here …
>
>
>
> https://github.com/mesonbuild
Hello,
The recent commit 2da74d8d640 added the following new messages:
+ libpq_append_conn_error(conn, "could not open ssl keylog file
%s: %s",
+ libpq_append_conn_error(conn, "could not write to ssl keylog
file %s: %s
However, I believe our convention is to quote f
On Fri, 4 Apr 2025 at 00:34, David Rowley wrote:
> I've attached 2 patches, which I think addresses most of this, aside
> from the last point.
>
> These do need more work. I've just attached what I have so far before
> I head off for the day. I am planning on running some performance
> tests tomor
On Fri, Apr 4, 2025 at 10:41 AM Peter Smith wrote:
>
> My point is, if it is deemed useful for a user to know if a *single*
> conflict was caused by an INSERT or by an UPDATE, then why is it not
> equally useful to know if *multiple* conflicts were caused by an
> INSERT or by an UPDATE?
>
The rea
On 03/04/2025 6:50 pm, Aleksander Alekseev wrote:
Hi,
... and it is claimed that autovacuum will never be triggered in order
to set hint bits, assuming we never modify the table again.
Actually I waited a bit and got a better EXPLAIN:
```
Index Only Scan using humidity_idx on humidity (c
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 31 Mar 2025 10:05:34 -0700,
"David G. Johnston" wrote:
> The CopyFromInFunc API allows for each attribute to somehow
> have its I/O format individualized. But I don't see how that is prac
On Thu, Apr 3, 2025 at 8:33 PM Peter Eisentraut
wrote:
> On 03.04.25 10:07, Alvaro Herrera wrote:
> > The new flag is there for quick access by get_relation_info. We could
> > easily not have it otherwise, because clients don't need it, but its
> > lack would probably make planning measurably sl
On Mon, Aug 12, 2024 at 9:25 PM cca5507 wrote:
>
> Hi,
>
> I refactor the code and fix the git apply warning according to [1].
>
> Here are the new version patches.
>
I've investigated the reported issue and reviewed the patch. IIUC to
fix this issue, what we need to do is to track catalog-change
Hi,
On Thu, Apr 03, 2025 at 08:53:57PM +0200, Tomas Vondra wrote:
> On 4/3/25 15:12, Jakub Wartak wrote:
> > On Thu, Apr 3, 2025 at 1:52 PM Tomas Vondra wrote:
> >
> >> ...
> >>
> >> So unless someone can demonstrate a use case where this would matter,
> >> I'd not worry about it too much.
> >
On Thu, Apr 3, 2025 at 5:52 PM Ashutosh Bapat
wrote:
>
> Hi,
> I tested the "not enforced" constraint feature extensively today
> especially the cases of partitioned table. Everything seems to be
> working fine.
>
> While doing that, I found that foreign_key.sql does not have a test to
> make sure
Dear Fujii-san,
> I've pushed the patches. Thanks!
This is a closing post. I confirmed at least one BF animal for each version
have been run and said OK. IIUC there are no threads to be forked.
Thanks for pushing!
Best regards,
Hayato Kuroda
FUJITSU LIMITED
On 04/04/2025 01:11, Tom Lane wrote:
So that's a long laundry list and we haven't even dug hard.
Is it worth it? If you feel like doing the legwork then
I'm willing to support the project, but I really wonder if
we shouldn't cut our losses and just remove the module.
(I hesitate now to look at
Hi.
Em qua., 2 de abr. de 2025 às 08:58, Andres Freund
escreveu:
> Hi,
>
> I've pushed fixes for 1) and 2) and am working on 3).
>
Coverity has one report about this.
CID 1596092: (#1 of 1): Uninitialized scalar variable (UNINIT)
13. uninit_use_in_call: Using uninitialized value result_one. Fie
Hackers,
"call " works. Obviously it was a trivial case.
But "select " does nothing.
Worse, "select pg_stat_st" has no clue. I was looking for ... _reset
It's not that difficult to add, I am suggesting that we use the same
logic as \df at that point?
Is there any such support for th
On Wed, Apr 2, 2025 at 11:57 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Michael,
>
> > Maybe we don't need a short option at all for this, at least initially?
>
> Indeed, updated.
Thank you for updating the patch. Here are some minor comments:
The --two-phase can be specified with
Alexander Lakhin writes:
> I've discovered that starting from 0dca5d68d, the following query:
> CREATE FUNCTION f(x anyelement) RETURNS anyarray AS '' LANGUAGE SQL;
> SELECT f(0);
> triggers:
> TRAP: failed Assert("fcache->func->rettype == VOIDOID"), File: "functions.c",
> Line: 1737, PID: 37847
Em qui., 3 de abr. de 2025 às 15:35, Andres Freund
escreveu:
> Hi,
>
> On 2025-04-03 13:46:39 -0300, Ranier Vilela wrote:
> > Em qua., 2 de abr. de 2025 às 08:58, Andres Freund
> > escreveu:
> >
> > > Hi,
> > >
> > > I've pushed fixes for 1) and 2) and am working on 3).
> > >
> > Coverity has on
On Thu, Apr 3, 2025 at 11:17 AM Heikki Linnakangas wrote:
>
> I had a quick look at this. Looks good overall, some small remarks:
Thanks for taking a look!
> v12-0001-Autoprewarm-global-objects-separately.patch
>
> > Instead, modify apw_load_buffers() to prewarm the shared objects in one
> > inv
On Thu, Apr 3, 2025 at 1:32 AM torikoshia wrote:
> I think tracking execution progress involves more challenges to solve
> compared to simply outputting the plan.
> For this reason, I believe an incremental approach -- first completing
> the basic plan output functionality in this thread and then
Hi,
On 2025-04-03 13:46:39 -0300, Ranier Vilela wrote:
> Em qua., 2 de abr. de 2025 às 08:58, Andres Freund
> escreveu:
>
> > Hi,
> >
> > I've pushed fixes for 1) and 2) and am working on 3).
> >
> Coverity has one report about this.
>
> CID 1596092: (#1 of 1): Uninitialized scalar variable (UN
On 2025-Mar-11, Bernd Helmle wrote:
> Please find attached v4 of this patch. I added the following changes:
>
> - Check for non-supported characters in the salt like passlib does.
> - Check for reserved tokens when parsing the salt string (i find this
> very strict, but it covers the cases Japin
On 4/3/25 15:12, Jakub Wartak wrote:
> On Thu, Apr 3, 2025 at 1:52 PM Tomas Vondra wrote:
>
>> ...
>>
>> So unless someone can demonstrate a use case where this would matter,
>> I'd not worry about it too much.
>
> OK, fine for me - just 3 cols for pg_buffercache_numa is fine for me,
> it's just
Hi
čt 3. 4. 2025 v 20:17 odesílatel Tom Lane napsal:
> Kirk Wolak writes:
> > But "select " does nothing.
>
> What would you have it offer? Every single column and function name
> in the database? Seems unlikely to be very helpful.
>
> postgres=# select count(distinct attname) from pg_attri
> Interestingly it takes unusually long for my toy database:
> There is nothing in between these two lines.
>
> To my humble knowledge, CHECKOINT shouldn't set hint bits and should
> take that long. At this point I don't know what's going on.
>
>From what I can tell in your example, you ran the m
On Wed, Apr 2, 2025 at 12:43 PM Álvaro Herrera wrote:
> I'm just saying that this is the reason to have the field be last in the
> struct.
Right. And I'm just saying that I don't think that it would take very
much effort to change it. That aspect isn't performance critical.
--
Peter Geoghegan
On Thu, Apr 3, 2025 at 4:37 PM Sami Imseih wrote:
>
> From what I can tell in your example, you ran the manual vacuum ( session 1)
> while you had an open transaction (session 2), so vacuum could not remove
> the dead tuples or update the visibility map. Once you committed session 2,
> autovacuum
On Wed, Mar 12, 2025 at 11:03:41AM +0100, Andreas Karlsson wrote:
> On 3/12/25 12:48 AM, Noah Misch wrote:
> > Overall, in the absence of objections, I will queue a task to back-patch the
> > non-postgres_fdw portion of commit d3c5f37 to v13-v16.
Pushed (e.g. v16 has commit 82a8f0f). Only v16 had
Dmitrii Bondar writes:
> [ v6-0001-Triggers-test-fix-with-the-invalid-cache-in-refin.patch ]
I spent a little bit of time looking over this patch. My first
instinct was "we can't really change the recommended method of
installing these triggers" --- but that would only matter if we
thought there
On 17.03.25 19:54, Jeff Davis wrote:
On Thu, 2025-03-13 at 14:49 +0100, Peter Eisentraut wrote:
I think these test result changes are incorrect. AFAICT, nothing has
changed in the upstream data that would explain such a change.
I didn't get such test differences in my original patch. Did you
On Wed, 2025-04-02 at 21:26 -0500, Nathan Bossart wrote:
> Okay, here is an updated patch set.
> * Besides custom format calling WriteToc() twice to update the data
> offsets, tar format ... even if it did, the worst case is that
> the
> content of restore.sql (which isn't used by pg_restore
Andrei Lepikhov writes:
> Rebase on current master.
I started to look at v5, and was immediately put off by the fact
that its documentation of the new support request type consists of
precisely zero words. You have the wrong idea of what is required
when adding a support request. The specificat
Hi,
On 2025-04-03 10:20:09 +0200, Alvaro Herrera wrote:
> On 2025-Apr-03, Ashutosh Bapat wrote:
>
> > Looks like the problem is in the test itself as pointed out by Jeff in
> > [1]. PFA patch fixing the test and enabling statistics back.
>
> Thanks, pushed.
Since then the pg_upgrade tests have be
On Thu, Apr 03, 2025 at 02:19:43PM -0400, Andres Freund wrote:
> 4b)
>
> That's not all though, after getting past this failure, I see uninitialized
> memory errors for reads into temporary buffers:
>
> ==3334031== VALGRINDERROR-BEGIN
> ==3334031== Conditional jump or move depends on uninitialise
On 2025-04-01 Tu 1:59 AM, Mahendra Singh Thalor wrote:
On Mon, 31 Mar 2025 at 23:43, Álvaro Herrera wrote:
Hi
FWIW I don't think the on_exit_nicely business is in final shape just
yet. We're doing something super strange and novel about keeping track
of an array index, so that we can modify
> On 3 Apr 2025, at 20:02, Jacob Champion
> wrote:
>
> On Tue, Mar 18, 2025 at 9:09 PM Thomas Munro wrote:
>> All pushed (wasn't sure if Daniel was going to but once I got tangled
>> up in all that kqueue stuff he probably quite reasonably assumed that
>> I would :-)).
>
> Attached are two mor
Dear Amit, Bertrand,
> The other idea to simplify the changes for backbranches:
> sub reactive_slots_change_hfs_and_wait_for_xmins
> {
> ...
> + my ($slot_prefix, $hsf, $invalidated, $needs_active_slot) = @_;
>
> # create the logical slots
> - create_logical_slots($node_standby, $slot_prefix)
Hi hackers,
Sometime ago I investigated slow query performance case of one customer
and noticed that index-only scan has made a lot of heap fetches.
-> Index Only Scan using ix_client_objects_vendor_object_id on
client_objects client_objects_1 (cost=0.56..2.78 rows=1 width=0) (actual
time=0
Hello Tom,
02.04.2025 21:09, Tom Lane wrote:
Since feature freeze is fast approaching, I did a tiny bit more
cosmetic work on this patchset and then pushed it. (There's still
plenty of time for adjustments if you have further comments.)
I've discovered that starting from 0dca5d68d, the follow
Thanks for reviewing.
On Thu, Apr 03, 2025 at 03:23:40PM -0700, Jeff Davis wrote:
> This simplifies commit a0a4601765. I'd break out that simplification as
> a separate commit to make it easier to understand what happened.
Done.
> In patch 0003, there are quite a few static function-scoped vari
m.litsa...@postgrespro.ru writes:
>> What does this patch give on aglobal scale? Does it save much memory or
>> increase performance? How many times?
> This patch makes the code semantically more correct and we don't lose
> anything. It is obviously not about performance or memory optimisation.
On Fri, Apr 4, 2025 at 1:02 AM Alexander Korotkov wrote:
> I've got an off-list bug report from Alexander Lakhin involving a
> placeholder variable. Alena and Andrei proposed a fix. It is fairly
> simple: we just shouldn't remove PHVs during self-join elimination, as
> they might still be refere
Dear Sawada-san,
> Thank you for updating the patch. Here are some minor comments:
>
> The --two-phase can be specified with
> --create-slot to enable decoding of prepared
> transactions.
> +Also, --falover can be specified with
> +--create-slot to create replica
> Thanks for looking, I plan to commit this over the weekend unless there are
> objections.
LGTM.
Raghuveer
On Tue, Apr 1, 2025 at 1:38 PM vignesh C wrote:
>
> On Tue, 1 Apr 2025 at 06:31, jian he wrote:
> >
> > On Mon, Mar 31, 2025 at 4:05 PM Kirill Reshke
> > wrote:
> >
> > Thanks for doing the benchmark.
>
> Few comments to improve the comments, error message and remove
> redundant assignment:
> 1
Hi, Vitaly!
On Mon, Mar 3, 2025 at 5:12 PM Vitaly Davydov wrote:
> The slot data is flushed to the disk at the beginning of checkpoint. If
> an existing slot is advanced in the middle of checkpoint execution, its
> advanced restart LSN is taken to calculate the oldest LSN for WAL
> segments remov
> On 3 Apr 2025, at 16:13, Heikki Linnakangas wrote:
>
> Committed
Cool! Thank you!!!
Best regards, Andrey Borodin.
On Sat, Mar 22, 2025 at 7:26 PM vignesh C wrote:
>
> Hi,
>
> Currently, error reports for database, publication, subscription, and
> replication slots do not include the option name. This has been
> addressed by including the option name in the error messages, ensuring
> consistency similar to rem
On 2025/04/04 12:06, Hayato Kuroda (Fujitsu) wrote:
Dear Fujii-san,
I think this fix should be backpatched to all supported versions.
Since the issue you found and the one I found seem different,
I'd prefer committing them separately.
I have no objections.
I've pushed the patches. Thanks
On Fri, 4 Apr 2025 at 09:36, Amit Kapila wrote:
>
> A few comments:
> *
> pg_createsubscriber.exe -D ..\..\data_standby -d db1 -d db2 -d db1
> --publication pub1 --publication pub1 -P "dbname=postgres port=5432"
> -p 5444 --dry-run
> pg_createsubscriber: error: database "db1" specified more than o
Hi,
On Thu, Apr 03, 2025 at 03:23:31PM +0530, vignesh C wrote:
> Can we add it to one of the subscription tests, such as 001_rep_changes.pl?
Yeah that sounds like a good place for it. Done in the attached.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amaz
Kirk Wolak writes:
> But "select " does nothing.
What would you have it offer? Every single column and function name
in the database? Seems unlikely to be very helpful.
postgres=# select count(distinct attname) from pg_attribute;
count
---
1218
(1 row)
postgres=# select count(distin
01.04.2025 21:48, Shlok Kyal пишет:
On Fri, 28 Mar 2025 at 16:35, Álvaro Herrera wrote:
On 2025-Mar-28, Shlok Kyal wrote:
On Mon, 24 Mar 2025 at 21:17, Álvaro Herrera wrote:
Also, surely we should document this restriction in the SGML docs
somewhere.
I have added comment in create_publicat
On Fri, Dec 20, 2024 at 1:23 PM Amit Langote wrote:
> We discussed $subject at [1] and [2] and I'd like to continue that
> work with the hope to commit some part of it for v18.
I did not get a chance to do any further work on this in this cycle,
but plan to start working on it after beta release,
> On 2 Apr 2025, at 03:36, Peifeng Qiu wrote:
> A major downside is the need to modify catalog table
> pg_user_mapping. So we can't apply this change to existing
> installation of prior stable versions.
A feature like this would never be considered for backpatching anyways so
that's not really a
On Thu, 20 Mar 2025 at 18:09, Ajin Cherian wrote:
>
> On Thu, Mar 13, 2025 at 5:49 PM Ajin Cherian wrote:
> >
> > Moving this patch to the next CF as this patch needs more design level
> > inputs which may not be feasible in this CF but do continue to review
> > the patch.
> >
> > regards,
> > Aj
Hi.
Per Coverity.
CID 1596094: (#1 of 1): Structurally dead code (UNREACHABLE)
unreachable: Since the loop increment i++; is unreachable, the loop body
will never execute more than once.
The code of the function *pqGetNegotiateProtocolVersion3* is a little
confusing.
I believe that the Coverity
On 4/3/25 10:23, Bertrand Drouvot wrote:
> Hi,
>
> On Thu, Apr 03, 2025 at 09:01:43AM +0200, Jakub Wartak wrote:
>> On Wed, Apr 2, 2025 at 6:40 PM Tomas Vondra wrote:
>>
>> Hi Tomas,
>>
>>> OK, so you agree the commit messages are complete / correct?
>>
>> Yes.
>
> Not 100% sure on my side.
>
rebased heapam.c and heapam_handler.c
best regards,
Ranier Vilela
v1-heapam_set_tuple_block_once.patch
Description: Binary data
v1-heapam_handler_set_tuple_block_once.patch
Description: Binary data
On Wed, Apr 2, 2025 at 2:35 AM George MacKerron
wrote:
> I was very pleased to see the sslrootcert=system connection option added
> in Postgres 16 (I even blogged about it:
> https://neon.tech/blog/avoid-mitm-attacks-with-psql-postgres-16). But
> sslrootcert=system has not been widely supported b
On 2025/04/03 12:15, Hayato Kuroda (Fujitsu) wrote:
Dear hackers,
Cluster.pm defines a function slot()which requires a slot_name as a key
and returns attributes of the given slot, as a hash-ref. ISTM, the hash
does not contain 'slot_name'.
However, I found that some codes access it by using
On Thu, Apr 3, 2025 at 2:20 PM vignesh C wrote:
>
> On Thu, 3 Apr 2025 at 09:07, Peter Smith wrote:
> >
> > Hi,
> >
> > I was away for the last few weeks when this feature got committed, so
> > I missed the chance to post my comments earlier.
> >
> > It seems the final SGML docs are mostly from t
On Thu, Apr 3, 2025 at 12:29 PM Bertrand Drouvot
wrote:
>
> On Thu, Apr 03, 2025 at 05:34:10AM +, Hayato Kuroda (Fujitsu) wrote:
> > Dear Bertrand, Amit,
> >
> > > > I do prefer v5-PG17-2 as it is "closer" to HEAD. That said, I think
> > > > that we should
> > > > keep the slots active and on
Hi Jakub,
On Thu, Apr 03, 2025 at 02:36:57PM +0200, Jakub Wartak wrote:
> On Thu, Apr 3, 2025 at 10:23 AM Bertrand Drouvot
> wrote:
> Right, we could also put it as a limitation. I would be happy to leave
> it as it must be a rare condition, but Tomas stated he's not.
>
> > Also maybe we should
On Thu, Apr 3, 2025 at 2:15 PM Tomas Vondra wrote:
> Ah, OK. Jakub, can you correct (and double-check) this in the next
> version of the patch?
Done.
> > About v21-0002:
> >
> > === 1
> >
> > I can see that the pg_buffercache_init_entries() helper comments are added
> > in
> > v21-0003 but I t
> On 3 Apr 2025, at 11:41, Daniel Gustafsson wrote:
>
> org.openssl.winstore isn't by OpenSSL defined as the default even on Windows,
> but a future version might change that.
Right — there’s definitely an argument that OpenSSL should in future make it
possible to have this be the default via a
Re: George MacKerron
> (3) Any other ideas?
I'm not a fan of "security by adding more connection parameters".
What are the chances of making "use the system/os default CA store"
the default? "sslmode=require" would then already actually "require" a
certificate if I'm reading the docs right. This
On 22.03.25 22:22, Andrew Jackson wrote:
Apologies, forgot to attach the patch in the prior email.
On Sat, Mar 22, 2025 at 4:10 PM Andrew Jackson
mailto:andrewjackson...@gmail.com>> wrote:
Currently the LDAP usage in fe-connect.c does not explicitly set the
protocol version to v3. Thi
Peter Eisentraut writes:
> Here is a slightly polished version of this patch. I added an error
> message, and changed the return code, but it's a bit confusing which one
> might be the right one.
I'm kind of -0.5 on declaring the variable as "const", because none of
our existing calls of ldap_
Hi Wenhui Qiu,
May I know the freeze dates.
We are nearly ready to deliver the patch. Currently, we have compiled the
source using Meson and are investigating one test case issue. Once we pinpoint
the cause, we will send you the patch. Notably, this test case behaves
differently on AIX, opting fo
On Thu, 3 Apr 2025 at 12:54, Bertrand Drouvot
wrote:
>
> Hi,
>
> On Thu, Apr 03, 2025 at 09:25:02AM +0530, vignesh C wrote:
> > On Mon, 31 Mar 2025 at 18:35, Bertrand Drouvot
> > wrote:
> > >
> > Couple of suggestions:
>
> Thanks for looking at it!
>
> > 1) I felt we can include a similar verific
On 03/04/2025 14:29, Daniel Gustafsson wrote:
On 2 Apr 2025, at 15:48, Heikki Linnakangas wrote:
And committed, with minor a bunch more little cleanups.
0001 in commit 09be39112654 seems to have missed (omitted?) adding the HAVE_
macros to pg_config.h.in, which doesn't matter as of now sinc
On 02/04/2025 22:41, Heikki Linnakangas wrote:
On 02/04/2025 20:18, Heikki Linnakangas wrote:
So I added it for the btree opfamily too, and moved the function to
rangetypes.c since it's not just for gist anymore. I Ccmmitted that
part, and will start looking more closely at the remaining btree_
> On 2 Apr 2025, at 15:48, Heikki Linnakangas wrote:
> And committed, with minor a bunch more little cleanups.
0001 in commit 09be39112654 seems to have missed (omitted?) adding the HAVE_
macros to pg_config.h.in, which doesn't matter as of now since they're not used
but it will be in the way fo
On Tue, 25 Mar 2025 at 06:49, Tom Lane wrote:
> I finally made some time to look at this patchset, and I'm pretty
> disappointed, because after 35 versions I'd expect to see something
> that looks close to committable. This doesn't really. I like the
> basic idea of taking child EC members out o
On 2025/04/03 17:53, jian he wrote:
On Wed, Apr 2, 2025 at 11:20 PM Fujii Masao wrote:
if (!RelationIsPopulated(rel))
ereport(ERROR,
errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot copy from unpopulate
On 4/3/25 09:01, Jakub Wartak wrote:
> On Wed, Apr 2, 2025 at 6:40 PM Tomas Vondra wrote:
>
> Hi Tomas,
>
>> OK, so you agree the commit messages are complete / correct?
>
> Yes.
>
>> OK. FWIW if you disagree with some of my proposed changes, feel free to
>> push back. I'm sure some may be mor
On 03/04/2025 14:55, Ranier Vilela wrote:
Hi.
Per Coverity.
CID 1596094: (#1 of 1): Structurally dead code (UNREACHABLE)
unreachable: Since the loop increment i++; is unreachable, the loop body
will never execute more than once.
That is true, and I think we should just silence it. The loop i
On Thu, Apr 3, 2025 at 1:52 PM Tomas Vondra wrote:
> On 4/3/25 09:01, Jakub Wartak wrote:
> > On Wed, Apr 2, 2025 at 6:40 PM Tomas Vondra wrote:
Hi Tomas,
Here's v23 attached (had to rework it because the you sent v22 just
the moment you I wanted to send it) Change include:
- your review shoul
On 03/04/2025 17:31, Melanie Plageman wrote:
Attached v12 fixes a bug Bilal found off-list in 0002 related to
handling invalid blocks.
I had a quick look at this. Looks good overall, some small remarks:
v12-0001-Autoprewarm-global-objects-separately.patch
Instead, modify apw_load_buffers() t
On 03/04/2025 18:00, Bernd Helmle wrote:
Note that the original coding was by Christoph Heiss and i picked up
his work and rewrote/fixed especially the part with the direct use of
sortsupport functions and many other issues spotted by testing and by
Andrey.
Sorry Christoph I missed you in the c
On 2025/04/03 23:04, Yugo NAGATA wrote:
On Wed, 2 Apr 2025 02:35:35 +0900
Fujii Masao wrote:
On 2025/01/23 19:22, Yugo NAGATA wrote:
On Wed, 22 Jan 2025 13:30:17 +0100
Laurenz Albe wrote:
On Fri, 2024-09-13 at 16:18 +0900, Yugo Nagata wrote:
I've attached a updated patch. The test is
On Wed, Apr 2, 2025 at 11:39 AM Richard Guo wrote:
> The change looks good to me. I plan to push it soon, barring any
> objections.
Pushed.
Thanks
Richard
On Thu, Apr 3, 2025 at 5:18 PM Alena Rybakina wrote:
> Okay, I agree with you.
Good. I've reflected this limitation in comments and the commit
message. Also, I've adjust regression tests by removing excessive
ones and adding more important cases. I'm going to push this if no
objections.
-
Hi Konstantin,
> But the problem can be quite easily reproduced. We can just populate table
> with some data with some other transaction with assigned XID active.
> Then explicitly vacuum this tables or wait until autovacuum does it.
> At this moment table has no more dead or inserted tuples so a
> On 3 Apr 2025, at 03:21, Jacob Champion
> wrote:
>
> On Wed, Apr 2, 2025 at 7:15 AM George MacKerron
> wrote:
>>> But happily, I don’t think we need to choose. Can’t we just use the Windows
>>> system store if neither of the relevant environment variables is set?
The env vars are only over
On Thu, Apr 3, 2025 at 4:31 PM jian he wrote:
>
> hi.
>
> in src/bin/pg_dump/pg_dump.c
> within function dumpTableSchema:
> there are two occurrences of:
> print_notnull = (tbinfo->notnull_constrs[j] != NULL &&
> (tbinfo->notnull_islocal[j]
On Tue, Apr 1, 2025 at 10:17 PM Tomas Vondra wrote:
>
> Hi,
>
> I've spent a bit of time reviewing this. In general I haven't found
> anything I'd call a bug, but here's a couple comments for v18 ... Most
> of this is in separate "review" commits, with a couple exceptions.
Hi, thank you very much
Am Mittwoch, dem 02.04.2025 um 22:41 +0300 schrieb Heikki Linnakangas:
> * The stuff to save the FmgrInfo for gbt_enum_sortsupport() was
> broken.
> It saved the address of FmgrInfo struct that was allocated in a local
> variable, on the stack, in SortSupport->ssup-extra, and expected it
> to
> b
On 03.04.25 10:07, Alvaro Herrera wrote:
The new flag is there for quick access by get_relation_info. We could
easily not have it otherwise, because clients don't need it, but its
lack would probably make planning measurably slower because it'd have to
do syscache access for every single not-nul
Hi,
On 2025-04-03 13:45:01 +, Srirama Kucherlapati wrote:
> We are nearly ready to deliver the patch. Currently, we have compiled the
> source using Meson and are investigating one test case issue. Once we pinpoint
> the cause, we will send you the patch. Notably, this test case behaves
> diff
On 02.04.2025 19:39, Alena Rybakina wrote:
I see that I need to add a walker that, when traversing the tree,
determines whether there are conditions under which pull-up is
impossible - the presence of
volatility of functions and other restrictions, and leave the
transformation for the var o
1 - 100 of 109 matches
Mail list logo
