On Tue, 2025-02-25 at 11:11 +0530, Ashutosh Bapat wrote:
> So the dumped statistics are not restored exactly. The reason for
> this
> is the table statistics is dumped before dumping ALTER TABLE ... ADD
> CONSTRAINT command which changes the statistics. I think all the
> pg_restore_relation_stats()
On Wed, Feb 26, 2025 at 01:48:47PM +0200, Alexander Korotkov wrote:
> Thank you for offering the help. Updated version of patch is attached
> (I've added one memory barrier there just in case). I would
> appreciate if you could run it on batta, hachi or similar hardware.
Doing a revert of the re
Hi
čt 27. 2. 2025 v 21:45 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > čt 27. 2. 2025 v 20:52 odesílatel Tom Lane napsal:
> >> So taken together, our results are all over the map, anywhere
> >> from 7% speedup to 7% slowdown. My usual rule of thumb is that
>
> > Where do you see 7%
On Sat, 22 Feb 2025 at 03:51, Mark Dilger wrote:
>
>
>
> > On Feb 21, 2025, at 12:50 PM, Mark Dilger
> > wrote:
> >
> > Could one of the patch authors take a look?
>
> I turned the TAP test which triggers the error into a regression test that
> does likewise, for ease of stepping through the te
Attached a v6 with O_NOFOLLOW removed, I noticed that it failed on
windows. Please let me know if I should do this in any other way that
is portable across platforms.
Thanks
On Thu, Feb 27, 2025 at 11:39 PM Abhishek Chanda
wrote:
>
> Thanks for the review, Daniel. Please find v5 of this patch at
On Thu, 2025-02-27 at 21:35 -0600, Nathan Bossart wrote:
> I spent some time on this one today. A couple of notes:
>
> * Since the reloption is a Boolean, there isn't a good way to tell whether
> it is actually set for the table or if it just inherited the default
> value. This is important
> For now, I think it makes sense to keep postgres_fdw_get_connections()
> aligned with the current implementation. Otherwise, explaining what
> remote_backend_pid = NULL means could be confusing, especially since
> pipeline mode isn't supported yet in postgres_fdw.
Make sense. I have created a pa
Hi,
On Thu, Feb 27, 2025 at 05:55:19PM -0500, Melanie Plageman wrote:
> On Thu, Feb 27, 2025 at 11:30 AM Andres Freund wrote:
> >
> > On 2025-02-27 11:08:04 -0500, Melanie Plageman wrote:
> >
> > > However, since that is a bigger project (with more refactoring, etc),
> > > he suggested that we ch
Hi All,
Thank you so much for the feedback.
> I don't think "another extension might use it someday" makes a very strong
> case,
> particularly for something that requires a new dependency.
The x86-simdsort library is an optional dependency in Postgres. Also the new
list sort implementation
Alexandra Wang writes:
> I’ve attached a patch that removes this unnecessary Sort node for
> B-tree-compatible indexes.
This does not look right at all. You can't just ignore the opfamily
etc. while deciding whether two pathkeys represent the same sort
ordering, as you did in create_mergejoin_pl
Dear Amit,
> I understand that we may not have a clear use case for this to work in
> single-user mode. But how will we define the boundary in similar
> cases? I mean, we should have some rule for such exposed functions,
> and it should be followed uniformly. Now, if one needs a bigger or
> comple
On Thu, Feb 27, 2025 at 1:29 PM Hayato Kuroda (Fujitsu)
wrote:
>
> >
> > Which other functions do we see similar restrictions? I checked
> > "sequence manipulation functions" (1), and "Transaction ID and
> > Snapshot Information Functions" (2) but couldn't see similar
> > restrictions.
> >
> > (1)
On Wed, Feb 26, 2025 at 09:48:50AM +, Bertrand Drouvot wrote:
> Yeah I think that makes sense, done that way in the attached.
>
> Speaking about physical walsender, I moved the test to 001_stream_rep.pl
> instead
> (would also fail without the fix).
Hmm. I was doing some more checks with th
Hi,
On Thu, Feb 27, 2025 at 11:08:04AM -0500, Melanie Plageman wrote:
> I was just talking to Andres off-list and he mentioned that the volume
> of log_connections messages added in recent releases can really be a
> problem for users. He said ideally we would emit one message which
> consolidated
Thanks for the review, Daniel. Please find v5 of this patch attached.
I tried to bump up the minimum OpenBSD version in installation.sgml,
do I need to add this anywhere else? Please let me know if this needs
anything else.
Thanks
On Thu, Feb 20, 2025 at 4:25 PM Daniel Gustafsson wrote:
>
> > On
On Fri, Feb 28, 2025 at 12:23 AM Alexandra Wang
wrote:
> While reviewing Mark Dilger’s patch series "Index AM API cleanup" [1],
> I noticed some unexpected plan diffs when running the xtree and treeb
> test modules. Specifically, an additional Sort node appears on top of
> an Index Only Scan, even
Hello hackers,
While reviewing Mark Dilger’s patch series "Index AM API cleanup" [1],
I noticed some unexpected plan diffs when running the xtree and treeb
test modules. Specifically, an additional Sort node appears on top of
an Index Only Scan, even when the index key and sort key are the same.
F
On Thu, 13 Feb 2025 at 14:01, Jeff Davis wrote:
> Attached a new patchset that doesn't change the API for
> ExecCopySlotMinimalTuple(). Instead, I'm using
> ExecFetchSlotMinimalTuple(), which avoids the extra memcpy if the slot
> is TTSOpsMinimalTuple, which is what HashAgg uses. I separated out t
Hi,
On Thu, Feb 27, 2025 at 11:14:56AM -0500, Andres Freund wrote:
> I don't think the timing overhead is a relevant factor here - compared to the
> fork of a new connection or performing authentication the cost of taking a few
> timestamps is neglegible. A timestamp costs 10s to 100s of cycles, a
On Thu, Feb 27, 2025 at 04:56:05PM +, Dave Page wrote:
> Per some brief discussion on the core list, the attached patch updates the
> licence preamble to more accurately reflect the use of Postgres vs.
> PostgreSQL (see https://www.postgresql.org/about/policies/project-name/ for
> background fr
On Feb 28, 2025 at 02:27 +0800, David G. Johnston ,
wrote:
> On Thu, Feb 6, 2025 at 8:04 AM Zhang Mingli wrote:
> > On Feb 6, 2025 at 10:49 +0800, David G. Johnston
> > , wrote:
> > >
> > > Yes, and when it does it is doing so in lieu of an error, and thus it is
> > > not returning the value of
On Thu, Feb 27, 2025 at 4:48 PM Álvaro Herrera wrote:
>
> On 2025-Feb-27, Amul Sul wrote:
>
> > Attached is the rebased patch set against the latest master head,
> > which also includes a *new* refactoring patch (0001). In this patch,
> > I’ve re-added ATExecAlterChildConstr(), which is required f
On Thu, Feb 27, 2025 at 10:01 PM Corey Huinker
wrote:
> +--- error: relation is wrong type
>> +SELECT pg_catalog.pg_restore_relation_stats(
>> +'relation', 0::oid,
>> +'relpages', 17::integer,
>> +'reltuples', 400.0::real,
>> +'relallvisible', 4::integer);
>>
>> Wh
On Mon, Jan 27, 2025 at 1:55 AM Laurenz Albe wrote:
>
> On Thu, 2025-01-23 at 22:33 -0800, Gurjeet Singh wrote:
> > > > I am also wondering if having an autovacuum setting to control it would
> > > > be
> > > > a good idea for a feature.
> > >
> > > I'm all for that.
> >
> > Please see attached a
I know I'm coming late to this, but I would like us to rethink having
statistics dumped by default. I was caught by this today, as I was doing
two dumps in a row, but the output changed between runs solely because the
stats got updated. It got me thinking about all the use cases of pg_dump
I've see
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 27 Feb 2025 15:24:26 -0800,
Masahiko Sawada wrote:
> Pushed the 0001 patch.
Thanks!
> Regarding the 0002 patch, I realized we stopped exposing
> NextCopyFromRawFields() function:
>
> --- a/src/incl
On Tue, Feb 18, 2025 at 01:56:09PM -0600, Nathan Bossart wrote:
> On Mon, Jan 27, 2025 at 03:38:39PM -0500, Robert Haas wrote:
>> Also, how sure are we that turning this off globally is a solid idea?
>> Off-hand, it doesn't sound that bad: there are probably situations in
>> which autovacuum never
On Fri, Feb 28, 2025 at 5:10 AM Masahiko Sawada wrote:
>
> On Thu, Feb 27, 2025 at 12:52 AM Amit Kapila wrote:
> >
> > On Thu, Feb 27, 2025 at 10:47 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Feb 25, 2025 at 7:33 PM Amit Kapila
> > > wrote:
> > > >
> > > > AFAICU, InvalidateObsoleteRep
>
> +--- error: relation is wrong type
> +SELECT pg_catalog.pg_restore_relation_stats(
> +'relation', 0::oid,
> +'relpages', 17::integer,
> +'reltuples', 400.0::real,
> +'relallvisible', 4::integer);
>
> Why do you need to specify all the stats (relpages, reltuples,
On Fri, Feb 28, 2025 at 2:29 PM Thomas Munro wrote:
> On Fri, Feb 28, 2025 at 11:58 AM Melanie Plageman
> wrote:
> > On Thu, Feb 27, 2025 at 1:08 PM Tom Lane wrote:
> > > I wonder if it'd be a good idea to add something like
> > >
> > > Assert(stream->distance == 1);
> > >
On Thu, Feb 27, 2025 at 07:47:09AM +, Bertrand Drouvot wrote:
> That's how I did it initially but decided to move it to pgstat_backend.c. The
> reason was that it's fully linked to "per backend" stats and that there is
> no SQL api on top of it (while I think that's the case for almost all the
On Sat, Feb 8, 2025 at 8:47 AM Michail Nikolaev
wrote:
> Just some commit messages + few cleanups.
I'm worried about this:
+These longer pin lifetimes can cause buffer exhaustion with messages like "no
+unpinned buffers available" when the index has many pages that have similar
+ordering; but fu
Masahiko,
I have combined the gen_random_uuid() and uuidv4() into a single row, as
you suggested. Please find the v5 patch, which has been squashed into a
single commit.
Best regards,
Andy Alsup
On Thu, Feb 27, 2025 at 5:02 PM Masahiko Sawada
wrote:
> On Thu, Feb 27, 2025 at 1:26 PM Andy Alsup
On Thu, Feb 27, 2025 at 3:42 PM Robert Haas wrote:
> +1 for having some instrumentation. I do not agree with Tom that these
> are numbers that only Peter Geoghegan and 2-3 other people will ever
> understand. I grant that it's not going to make sense to everyone, but
> the number of people to whic
On Fri, Feb 28, 2025 at 11:58 AM Melanie Plageman
wrote:
> On Thu, Feb 27, 2025 at 1:08 PM Tom Lane wrote:
> > I wonder if it'd be a good idea to add something like
> >
> > Assert(stream->distance == 1);
> > Assert(stream->pending_read_nblocks == 0);
> >
On Thu, Feb 27, 2025 at 12:14 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Monday, February 24, 2025 5:50 PM Amit Kapila
> wrote:
> >
> > On Wed, Dec 11, 2024 at 12:37 PM Masahiko Sawada
> > wrote:
> > >
> > > I confirmed that the proposed patch fixes these issues. I have one
> > > question about the
On Thu, Feb 27, 2025 at 11:30 AM Andres Freund wrote:
>
> On 2025-02-27 11:08:04 -0500, Melanie Plageman wrote:
>
> > However, since that is a bigger project (with more refactoring, etc),
> > he suggested that we change log_connections to a GUC_LIST
> > (ConfigureNamesString) with options like "no
On Thu, Feb 27, 2025 at 10:23:31AM -0300, Ranier Vilela wrote:
> Yeah, I also think it would look good like this.
It's the least confusing option, indeed. I've reduced a bit the diffs
and done that down to v16 for the pg_upgrade part where this exists.
Double-checking the tree, it does not seem
On Tue, Feb 18, 2025 at 12:49 PM Ryo Kanbayashi
wrote:
>
> On Thu, Feb 13, 2025 at 10:49 PM Fujii Masao
> wrote:
> >
> >
> >
> > On 2025/02/06 8:57, Ryo Kanbayashi wrote:
> > > On Wed, Feb 5, 2025 at 9:31 PM Ryo Kanbayashi
> > > wrote:
> > >>
> > >> Hi hackers,
> > >>
> > >> When I wrote patch
On Thu, 2025-02-27 at 17:04 -0500, Tom Lane wrote:
> Given that nobody's complained about this for twenty-plus years,
> I can't get excited about adding complexity to do either thing.
I had in mind some refactoring in this area, which ideally would not
add complexity. It might provide some nice be
David Rowley writes:
> On Fri, 28 Feb 2025 at 07:42, Jeff Davis wrote:
>> My first reaction is that it's not right because the costing for the
>> plan is completely bogus with a different work_mem. It would make more
>> sense to me if we either (a) enforced work_mem as it was at the time of
>> pl
On Thu, Feb 27, 2025 at 12:52 AM Amit Kapila wrote:
>
> On Thu, Feb 27, 2025 at 10:47 AM Masahiko Sawada
> wrote:
> >
> > On Tue, Feb 25, 2025 at 7:33 PM Amit Kapila wrote:
> > >
> > > AFAICU, InvalidateObsoleteReplicationSlots() is not serialized with
> > > this operation. So, isn't it possibl
On Wed, Feb 26, 2025 at 9:19 PM Corey Huinker wrote:
>>>
>>> +1, let's shorten those queries. The coast is probably pretty
>>> clear now if you want to go do that.
>>
>>
>> On it.
So, I started reviewing this and my original thought about shortening
the queries testing pg_restore_relation_stats(
On Tue, Feb 25, 2025 at 6:08 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Tue, 25 Feb 2025 17:14:43 -0800,
> Masahiko Sawada wrote:
>
> > I've attached updated patches.
>
> Thanks.
>
> I found one more missing last ".
Hello hackers,
On Thu, Feb 27, 2025 at 9:46 AM Alexandra Wang
wrote:
> Summary of changes:
>
> v8-0001 through v8-0005:
> Refactoring and preparatory steps for the actual implementation.
>
> v8-0006 (Implement read-only dot notation for JSONB):
> I removed the vars field (introduced in v7) from
On Thu, Feb 27, 2025 at 1:08 PM Tom Lane wrote:
>
> I wonder if it'd be a good idea to add something like
>
> Assert(stream->distance == 1);
> Assert(stream->pending_read_nblocks == 0);
> Assert(stream->per_buffer_data_size == 0);
> + A
Hi John,
Going back to your earlier comment:
> > > I'm not a fan of exposing these architecture-specific details to
> > > places that consult the capabilities. That requires things like
+#define PGCPUCAP_CRC32C pg_cpu_have(PG_CPU_FEATURE_SSE42)
> > Isn't that one thing currently pg_cpu_have(FE
On Thu, Feb 27, 2025 at 1:26 PM Andy Alsup wrote:
>
> I've submitted it for the up-coming commitfest. The link is:
> https://commitfest.postgresql.org/patch/5604/
> Thanks for all your help in reviewing these changes.
Thank you for the patch!
Regarding the 0001 patch, I think we can put uuidv4(
On Thu, Feb 27, 2025 at 4:12 PM Tom Lane wrote:
> +1, but how about explain_dr.h too? It doesn't seem though that
> we can avoid #include "executor/instrument.h" there, so it'd be
> a little asymmetrical. But the executor inclusion doesn't seem
> nearly as much almost-circular.
OK, here is v2.
On Fri, 28 Feb 2025 at 07:42, Jeff Davis wrote:
> https://www.postgresql.org/message-id/CAJVSvF6s1LgXF6KB2Cz68sHzk%2Bv%2BO_vmwEkaon%3DH8O9VcOr-tQ%40mail.gmail.com
>
> James pointed out something interesting, which is that a prepared
> statement enforces the work_mem limit at execution time, which
Robert Haas writes:
> OK, here is v2. One slightly unfortunate thing about this is that we
> end up with a line that is over 80 characters:
> extern DestReceiver *CreateExplainSerializeDestReceiver(struct
> ExplainState *es);
> Aside from perhaps shortening the function name, I don't see how to
I've submitted it for the up-coming commitfest. The link is:
https://commitfest.postgresql.org/patch/5604/
Thanks for all your help in reviewing these changes.
Best Regards,
Andy Alsup
On Thu, Feb 27, 2025 at 1:58 PM Laurenz Albe
wrote:
> On Wed, 2025-02-26 at 22:11 -0500, Andy Alsup wrote:
> >
Robert Haas writes:
> Nobody has beaten me to it, but I thought of one potential issue.
> Suppose that somebody has a foreign table that exists today with one
> of these properties set to the empty string. Such a foreign table is
> not usable for queries, because the queries won't make it past sca
On Wed, 2025-02-26 at 22:11 -0500, Andy Alsup wrote:
> Please find the latest patch files attached.
This is good to go. If you add it to the commitfest, I'm happy to
mark it "ready for committer".
Yours,
Laurenz Albe
On Thu, Feb 27, 2025 at 4:08 PM Tom Lane wrote:
> I was down on it to start with, on the grounds that it wasn't adding
> enough ease-of-use to justify even a relatively small amount of added
> code. I'm not sure that the dump-reload failure angle is much of a
> concern in reality, but I would hav
Robert Haas writes:
> On Thu, Feb 27, 2025 at 3:05 PM Tom Lane wrote:
>> Did you look at avoiding that with our standard trick of writing
>> detail-free struct declarations?
> OK, here's a patch that does that. Thoughts?
+1, but how about explain_dr.h too? It doesn't seem though that
we can av
On Thu, Feb 27, 2025 at 3:05 PM Tom Lane wrote:
> Robert Haas writes:
> > The thing that was bugging me a bit is that explain_format.h includes
> > explain.h.
>
> Yeah, I did not like that at all either -- it makes things a bit
> circular, and I fear IWYU is going to make stupid recommendations
>
On Tue, Feb 25, 2025 at 1:31 AM jian he wrote:
> hi.
> the thread "Statistics Import and Export" is quite hot.
> so a new thread for some minor issue i found.
>
>
> static int
> _tocEntryRequired(TocEntry *te, teSection curSection, ArchiveHandle *AH)
> {
>
> if (strcmp(te->desc, "STATISTICS D
Alexander Pyhalov writes:
> Now sql functions plans are actually saved. The most of it is a
> simplified version of plpgsql plan cache. Perhaps, I've missed
> something.
A couple of thoughts about v6:
* I don't think it's okay to just summarily do this:
/* It's stale;
Pavel Stehule writes:
> čt 27. 2. 2025 v 20:52 odesílatel Tom Lane napsal:
>> So taken together, our results are all over the map, anywhere
>> from 7% speedup to 7% slowdown. My usual rule of thumb is that
> Where do you see 7% speedup? Few lines up you wrote 0.7% faster.
Alexander got that on
On Mon, Feb 17, 2025 at 5:44 PM Peter Geoghegan wrote:
> I need more feedback about this. I don't understand your perspective here.
>
> If I commit the skip scan patch, but don't have something like this
> instrumentation in place, it seems quite likely that users will
> complain about how opaque
Robert Haas writes:
> The thing that was bugging me a bit is that explain_format.h includes
> explain.h.
Yeah, I did not like that at all either -- it makes things a bit
circular, and I fear IWYU is going to make stupid recommendations
like not including explain.h in explain.c.
Did you look at a
On Thu, Feb 27, 2025 at 1:42 PM Jeff Davis wrote:
> It would make more sense to me if we either (a) enforced work_mem as it
> was at the time of planning; or (b) replanned if executed with a different
> work_mem (similar to how we replan sometimes with different parameters).
>
Definitely (b).
B
čt 27. 2. 2025 v 20:52 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > čt 27. 2. 2025 v 13:25 odesílatel Alexander Pyhalov <
> > a.pyha...@postgrespro.ru> napsal:
> >>> Unfortunately, there is about 5% slowdown for inlined code, and for
> >>> just plpgsql code too.
>
> >> Hi. I've tried
Pavel Stehule writes:
> čt 27. 2. 2025 v 13:25 odesílatel Alexander Pyhalov <
> a.pyha...@postgrespro.ru> napsal:
>>> Unfortunately, there is about 5% slowdown for inlined code, and for
>>> just plpgsql code too.
>> Hi. I've tried to reproduce slowdown and couldn't.
> I'll try to get profiles.
On 2025-Feb-14, Ranier Vilela wrote:
> Attached is the prototype version v1.
> What do you think?
I think this is still a bit confused. The new function's comment says
"prepare the list of tables to ..." but what it really receives is a
list of _indexes_ (as evidenced by the fact that they're co
On Thu, Feb 27, 2025 at 2:21 PM Álvaro Herrera wrote:
> On 2025-Feb-27, Robert Haas wrote:
> > I see that the Redis-FDW test is failing; it will now need to include
> > "commands/explain_format.h" -- unless we something, of course.
>
> I wonder if it was really a useful idea to move the declarati
On 2025-Feb-27, Robert Haas wrote:
> I see that the Redis-FDW test is failing; it will now need to include
> "commands/explain_format.h" -- unless we something, of course.
I wonder if it was really a useful idea to move the declarations of
those functions from explain.h to the new explain_format
On Thu, Dec 19, 2024 at 8:29 AM Robert Haas wrote:
> Cool. I don't want to commit this right before my vacation but I'll
> look into it in the new year if nobody beats me to it.
Nobody has beaten me to it, but I thought of one potential issue.
Suppose that somebody has a foreign table that exists
As a part of this discussion:
https://www.postgresql.org/message-id/CAJVSvF6s1LgXF6KB2Cz68sHzk%2Bv%2BO_vmwEkaon%3DH8O9VcOr-tQ%40mail.gmail.com
James pointed out something interesting, which is that a prepared
statement enforces the work_mem limit at execution time, which might be
different from t
On Mon, Apr 22, 2024 at 2:20 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> Thoughts anyone?
>
> On Thu, Feb 1, 2024 at 3:47 PM David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>> Motivated by a recent complaint [1] I found the hostssl related material
>> in our docs quite v
On Mon, Feb 17, 2025 at 5:44 PM Peter Geoghegan wrote:
> I need more feedback about this. I don't understand your perspective here.
Attached is a version of the patch that will apply cleanly against
HEAD. (This is from v26 of my skip scan patch, which is why I've
skipped so many version numbers c
On Thu, Feb 27, 2025 at 1:24 PM Robert Haas wrote:
> Thanks for the quick response! I have committed these patches.
I recently did something similar myself when I moved all of the nbtree
preprocessing code into its own file.
The obvious downside is that it tends to make "git blame" much less
use
On Thu, Feb 6, 2025 at 8:04 AM Zhang Mingli wrote:
> On Feb 6, 2025 at 10:49 +0800, David G. Johnston <
> david.g.johns...@gmail.com>, wrote:
>
>
> Yes, and when it does it is doing so in lieu of an error, and thus it is
> not returning the value of the setting. It does not mean the value taken
On Tue, Feb 18, 2025 at 1:11 PM Peter Geoghegan wrote:
> On Tue, Feb 18, 2025 at 1:04 PM Robert Haas wrote:
> > I think in cases like this there is a tendency to want to achieve an
> > even split of the original file, but in practice I think that tends
> > not to be difficult to achieve. These tw
Ahmed,
Thank you for the review.
I'm a bit confused by the reports of apply and compile errors. I didn't
touch anything involving "varlist" and see no errors then or now in my
Meson ninja build. Nor does the CI report any.
On Fri, Feb 14, 2025 at 2:01 PM Ahmed Ashour wrote:
> Feedback:
> ---
Andres Freund writes:
> Ah, no, it isn't. But I still think the coverity alert and the patch don't
> make sense, as per the below:
Coverity's alert makes perfect sense if you posit that Coverity
doesn't assume that this read_stream_next_buffer call will
only be applied to a stream that has per_bu
On Thu, Feb 6, 2025 at 2:46 PM Daniel Gustafsson wrote:
> I'd be happy to help getting this in, do you have a suggested wording?
>
>
Thank you.
Attached.
David J.
From fc9768fa1de17529cddc3f3ac1fba208f7500083 Mon Sep 17 00:00:00 2001
From: "David G. Johnston"
Date: Thu, 27 Feb 2025 10:58:57 -0
Em qui., 27 de fev. de 2025 às 14:49, Andres Freund
escreveu:
> Hi,
>
> On 2025-02-27 12:44:24 -0500, Andres Freund wrote:
> > > CID 1592454: (#1 of 1): Explicit null dereferenced (FORWARD_NULL)
> > > 8. var_deref_op: Dereferencing null pointer per_buffer_data.
> >
> > That's exactly what the mes
On Wed, Feb 26, 2025 at 4:09 PM Jeff Davis wrote:
>
> My idea was that we'd attach work_mem to each Path node and Plan node
> at create time. For example, in create_agg_path() it could do:
>
> pathnode->path.node_work_mem = work_mem;
>
> And then add to copy_generic_path_info():
>
> dest->node
Hi,
On 2025-02-27 12:44:24 -0500, Andres Freund wrote:
> > CID 1592454: (#1 of 1): Explicit null dereferenced (FORWARD_NULL)
> > 8. var_deref_op: Dereferencing null pointer per_buffer_data.
>
> That's exactly what the messages you quoted are discussing, no?
Ah, no, it isn't. But I still think th
Hi,
On 2025-02-27 11:08:04 -0500, Melanie Plageman wrote:
> I was just talking to Andres off-list and he mentioned that the volume
> of log_connections messages added in recent releases can really be a
> problem for users.
For some added color: I've seen plenty systems where almost all the log vo
Hi,
On 2025-02-27 14:32:28 -0300, Ranier Vilela wrote:
> Hi.
>
> Em ter., 18 de fev. de 2025 às 11:31, Melanie Plageman <
> melanieplage...@gmail.com> escreveu:
>
> > On Sun, Feb 16, 2025 at 1:12 PM Tom Lane wrote:
> > >
> > > Thomas Munro writes:
> > > > Thanks! It's green again.
> > >
> > >
Hi.
Em ter., 18 de fev. de 2025 às 11:31, Melanie Plageman <
melanieplage...@gmail.com> escreveu:
> On Sun, Feb 16, 2025 at 1:12 PM Tom Lane wrote:
> >
> > Thomas Munro writes:
> > > Thanks! It's green again.
> >
> > The security team's Coverity instance complained about this patch:
> >
> > **
On Thu, Feb 27, 2025 at 11:14 AM Tom Lane wrote:
> Robert Haas writes:
> > But let's not make the mistake of saying "we're not going to move
> > things automatically because we want to find out if the authors are
> > still interested" and then getting really concerned when some stuff
> > doesn't
Per some brief discussion on the core list, the attached patch updates the
licence preamble to more accurately reflect the use of Postgres vs.
PostgreSQL (see https://www.postgresql.org/about/policies/project-name/ for
background from many years ago).
--
Dave Page
pgAdmin: https://www.pgadmin.org
On Mon, Feb 24, 2025 at 2:16 PM Robert Haas wrote:
> On Mon, Feb 24, 2025 at 12:12 PM Ilia Evdokimov
> wrote:
> > If no one is concerned about rows being a non-integer, then I support
> > this, as it's quite strange for the average rows to be an integer only
> > for me. If we go with this approac
Hi
čt 27. 2. 2025 v 16:33 odesílatel Gilles Darold napsal:
> Le 07/02/2025 à 23:00, Pavel Stehule a écrit :
> > Hi
> >
> > I rewrote this patch. Instead of enhancing the main SQL parser, it
> > does post parser checks of the parse tree.
> >
> > Now the patch is significantly less invasive (chang
Robert Haas writes:
> But let's not make the mistake of saying "we're not going to move
> things automatically because we want to find out if the authors are
> still interested" and then getting really concerned when some stuff
> doesn't get moved. That's missing the whole point.
+1. Having a si
Hi,
On 2025-02-27 06:50:41 +, Bertrand Drouvot wrote:
> On Wed, Feb 26, 2025 at 01:45:39PM -0500, Melanie Plageman wrote:
> > Thanks for the continued review!
> >
> > On Wed, Feb 26, 2025 at 2:41 AM Bertrand Drouvot
> > wrote:
> > >
> > > On Wed, Feb 26, 2025 at 01:46:19PM +0900, Fujii Masao
On Thu, Feb 27, 2025 at 1:50 AM Bertrand Drouvot
wrote:
>
> Agree. IIUC, I think that Fujii-san's idea was to extend log_connections with
> a new option "timing" (i.e move it from ConfigureNamesBool to say
> ConfigureNamesEnum with say on, off and timing?). I think that's a good idea.
>
> I just d
On Thu, Feb 27, 2025 at 12:17 AM Michael Paquier wrote:
> CF 2025-03 is to begin in more or less 48 hours, and we have still a
> grand total of 72 patches still listed in CF 2025-01:
> https://commitfest.postgresql.org/51/
>
> It's a good score, as 286 patches have been moved without doing any
> k
> It's also worth noting that pg_locks already has a full paragraph explaining
> inconsistencies, so in my opinion it's worth it at least mentioning something
> similar here for pg_stat_activity.
yes, that is a different consistency from the one I was referring to with
regards to a join between pg
"Daniel Verite" writes:
> Tom Lane wrote:
>> I got nerd-sniped by this question and spent some time looking into
>> it.
> Thank you for the patch! LGTM.
Thanks for reviewing! Pushed after a tiny bit more polishing.
regards, tom lane
Hello hackers,
I’ve fixed the compilation failure for hstore and updated the patches.
In this version, I’ve further cleaned up the code and added more
comments. I hope this helps!
Summary of changes:
v8-0001 through v8-0005:
Refactoring and preparatory steps for the actual implementation.
v8-00
Hi,
On Wed, Feb 26, 2025 at 09:38:20AM +0100, Jakub Wartak wrote:
> On Mon, Feb 24, 2025 at 3:06 PM Andres Freund wrote:
> >
> > Why is this done before we even have gotten -2 back? Even if we need it, it
> > seems like we ought to defer this until necessary.
>
> Not fixed yet: maybe we could ev
Le 07/02/2025 à 23:00, Pavel Stehule a écrit :
Hi
I rewrote this patch. Instead of enhancing the main SQL parser, it
does post parser checks of the parse tree.
Now the patch is significantly less invasive (changes are just in
plpgsql - mostly in grammar), and it is smaller (without regress t
Hi
út 25. 2. 2025 v 6:32 odesílatel Pavel Stehule
napsal:
> Hi
>
> po 24. 2. 2025 v 21:05 odesílatel Gilles Darold
> napsal:
>
>> Review:
>>
>> This patch claims to add SQL/PSM named arguments syntax to cursors and
>> this what it does exactly.
>>
>> It compiles without error with master curr
Hi,
On Thu, Feb 27, 2025 at 10:05:46AM +0100, Jakub Wartak wrote:
> On Wed, Feb 26, 2025 at 6:13 PM Bertrand Drouvot
> wrote:
> [..]
> > > Meanwhile v5 is attached with slight changes to try to make cfbot happy:
> >
> > Thanks for the updated version!
> >
> > FWIW, I had to do a few changes to ge
hi.
bug demo:
CREATE TABLE gtest20a (a int PRIMARY KEY, b int GENERATED ALWAYS AS (a
* 2) VIRTUAL);
ALTER TABLE gtest20a ADD COLUMN c float8 DEFAULT RANDOM() CHECK (b < 60);
ERROR: no generation expression found for column number 2 of table
"pg_temp_17306"
issue is that
in ATRewriteTable(Altere
1 - 100 of 133 matches
Mail list logo
