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 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 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 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);
> > >
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
> 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
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
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
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
>
> +--- 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,
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 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
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 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
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
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
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
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)
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
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
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
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
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
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 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 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
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:
> >
> > **
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,
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 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
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
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
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
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
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 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 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
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 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
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 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()
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:
> 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
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
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 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
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, 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
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 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
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 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
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 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 ".
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 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
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
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
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.
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
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;
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 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 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
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 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
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 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
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:
> ---
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 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
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 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
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
č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
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 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
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 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 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 Fri, 21 Feb 2025 at 03:50, Israel Barth Rubio wrote:
>
> There are some failures on compiler warnings and Windows jobs that
> seem unrelated with this patch.
>
> Besides that, there were failures when executing `010_links.pl` in the
> Linux autoconf jobs. As discussed in a side chat with Euler
On Thu, Feb 27, 2025 at 12:24 AM Peter Geoghegan wrote:
>
> On Wed, Feb 26, 2025 at 5:16 PM Tomas Vondra wrote:
> > Oh, I forgot about that. I guess if the theory is the commit might be
> > causing this, and it's been already reverted, I should just restart the
> > instance, so that it tests with
Thank Alvaro for the fixup patch.
On Fri, Feb 21, 2025 at 11:43 AM Alvaro Herrera
wrote:
> Hello,
>
> Thanks!
>
> I noticed a typo 'constrint' in several places; fixed in the attached.
>
> I discovered that this sequence, taken from added regression tests,
>
> CREATE TABLE notnull_tbl1 (a int
On Wed, Feb 5, 2025 at 4:44 AM Nathan Bossart wrote:
> [v2]
I started looking just at 0001, and it seems like a fairly
straightforward rearrangement. I found this comment quite hard to
read:
+ * 'found_objs' should be a fully qualified list of objects to process, as
+ * returned by a previous ca
On 2025-02-27 12:09:46 +0900, Michael Paquier wrote:
> I suspect that there would be cases where a single stats kind should be able
> to handle both transactional and non-transactional flush cases. Splitting
> that across two stats kinds would lead to a lot of duplication.
Agreed. Table stats wil
On Thu, Feb 27, 2025 at 11:19 AM Thomas Munro wrote:
> On Wed, Feb 26, 2025 at 10:55 PM Andres Freund wrote:
> > I was working on expanding tests for AIO and as part of that wrote a test
> > for
> > temp tables -- our coverage is fairly awful, there were many times during
> > AIO
> > developmen
On 2025-02-27 11:19:55 +1300, Thomas Munro wrote:
> On Wed, Feb 26, 2025 at 10:55 PM Andres Freund wrote:
> > I was working on expanding tests for AIO and as part of that wrote a test
> > for
> > temp tables -- our coverage is fairly awful, there were many times during
> > AIO
> > development wh
Re-reviewed this patch: still compiles, tests pass, and does what it says
on the tin. +1
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
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
On Thu, Feb 27, 2025 at 4:50 AM vignesh C wrote:
> Few comments:
> 1) The new file 010_links.pl added should be included to meson.build also:
> 'tests': [
> 't/010_pg_basebackup.pl',
> 't/011_in_place_tablespace.pl',
> 't/020_pg_receivewal.pl',
> 't/030_pg_recvlogical.p
On Wed, 15 Jan 2025 at 13:21, jian he wrote:
>
> hi.
>
> around src/bin/pg_dump/pg_dump.c line 1117
> right after "ropt->no_comments = dopt.no_comments;"
> we also need add
> ropt->no_policies = dopt.no_policies;
> ?
>
> overall looks good to me.
> The tests seem wrong per
> https://cirrus-ci.
Hi,
This function is currently not covered by any tests. The proposed
patch fixes this.
--
Best regards,
Aleksander Alekseev
v1-0001-Cover-POSITION-bytea-bytea-with-tests.patch
Description: Binary data
I tried to implement the idea (4). This is the patch.
But, there is a problem. See, when we release lock and call
RememberSyncRequest() and acquire it again,
CompactCheckpointerRequestQueue() may be called and the state of the
request array may be changed. Of course, we can recheck num_requests af
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 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
1 - 100 of 133 matches
Mail list logo
