On 3/23/25 20:10, Tom Lane wrote:
Andrei Lepikhov writes:
On 3/22/25 23:49, Tom Lane wrote:
* It is not clear to me what permission restrictions we should put
on pg_get_loaded_modules, ...
I vote for the idea of stripping the full path to just a filename.
Works for me. v7 attached does i
On Sun, Mar 23, 2025 at 3:10 PM Tom Lane wrote:
> I think this version is ready to commit, if there are not objections
> to the decisions mentioned above.
It looks reasonable to me. I am a bit worried that using PG_VERSION as
the version string is going to feel like the wrong thing at some
stage,
Hi,
I did a review on v3 of the patch. I see there's been some minor changes
in v4 - I haven't tried to adjust my review, but I assume most of my
comments still apply.
Most of my suggestions are about formatting and/or readability. Some of
the likes (e.g. the pointer arithmetics) got so long pgin
В письме от понедельник, 24 марта 2025 г. 17:48:25 MSK пользователь Robert
Haas написал:
> On Mon, Mar 24, 2025 at 10:43 AM Nathan Bossart
>
> wrote:
> > Overall, the biggest reason I didn't proceed with the enum is because it
> > felt like it was making it the user's problem. Rather than just
For the sake of discussion, here is what the enum approach would look like.
--
nathan
>From f108e6c7e07c4148f097fbfd612cf79db60c5acd Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 24 Mar 2025 12:46:26 -0500
Subject: [PATCH 1/1] change vacuum_truncate relopt to enum
---
src/backend/ac
David Rowley writes:
> ... The main
> thing I'd like to understand here is if there's not enough time to get
> the entire patch set committed, is there much benefit to just having
> the EquivalenceMember index stuff in by itself without the
> RestrictInfo changes.
I finally made some time to look
В письме от понедельник, 24 марта 2025 г. 20:37:50 MSK пользователь David G.
Johnston написал:
> My main concern when first seeing this was adding an integer to every
> single option in the entire system for something that is going to be zero
> 99.9% of the time. A bit bloated but not directly i
On Mon, Mar 24, 2025 at 12:29 PM Alvaro Herrera wrote:
> > Again, I'm not 100% positive that changing the Boolean column to a
> > three-valued column is the right way forward, but it does have the
> > advantage of saving a byte, and the width of system catalog tables has
> > been a periodic concer
В письме от понедельник, 24 марта 2025 г. 20:48:29 MSK пользователь Nathan
Bossart написал:
> For the sake of discussion, here is what the enum approach would look like.
In my point of view this solution is much-much better: it achieves all goals,
has no drawbacks, and do not change reloption e
On Mon, Mar 24, 2025 at 06:34:45PM +0700, John Naylor wrote:
> On Sat, Mar 22, 2025 at 10:42 AM Nathan Bossart
> wrote:
>> * 0002 introduces the Neon implementation, which conveniently doesn't need
>> configure-time checks or function pointers. I noticed that some
>> compilers (e.g., Apple cl
В письме от понедельник, 24 марта 2025 г. 23:04:39 MSK пользователь Nathan
Bossart написал:
> > We can have isset_offset, but then we have redesign all options with
> > custom unset behavior to use it, instead of unreachable default value.
> > This will make it consistent then.
>
> I don't see an
On Sun, Mar 23, 2025 at 9:43 PM Michael Paquier wrote:
> So I've applied the patch for now, to start with
> something.
>
Thanks for committing that, I think that's a great starting point for 18!
Ideally we can also land the jumble funcs work in the other thread to allow
extensions to re-use the
> Hi! I started reviewing it and noticed that your code repeated this
> cycle maybe it would be better to put it in a separate function, for
> example in the form of a name like "analyze_stmts"?
>
> or is it possible to create a macro for them?
Perhaps it may be better to stick this all in a macro
Hi,
Please find the attached updated and rebased patch.
I have added a test in the test_dsa module that uses a function
to create a dsa area. This function is called after
the resowner->releasing is set to true, using an injection point.
Thank you,
Rahila Syed
v2-0001-Prevent-the-error-on-creat
On 2025-03-24 00:08, Fujii Masao wrote:
Do you also think the errhint message is unnecessary?
I agree with your idea to add a description of the overflowed
subtransaction in the manual, but I'm not sure all users will be able
to find it.
Some people may not understand what needs to be done to
On 3/23/25 17:43, Heikki Linnakangas wrote:
> On 21/03/2025 17:16, Andres Freund wrote:
>> Am I right in understanding that the only scenario (when in
>> STANDBY_SNAPSHOT_READY), where ExpireOldKnownAssignedTransactionIds()
>> would
>> "legally" remove a transaction, rather than the commit / abo
On Mon, Mar 24, 2025, at 12:54 PM, Tom Lane wrote:
> Robert Haas writes:
> > It looks reasonable to me. I am a bit worried that using PG_VERSION as
> > the version string is going to feel like the wrong thing at some
> > stage, but I can't really say why, and I think it's better to do
> > somethin
On Mon, Mar 24, 2025 at 12:14 PM Melanie Plageman
wrote:
>
> This is the patch I intend to commit to fix this assuming my CI passes
> and there are no objections.
And pushed in aea916fe555a3
- Melanie
> On Mon, Mar 24, 2025 at 02:36:05PM -0500, Sami Imseih wrote:
> >> Ideally we can also land the jumble funcs work in the other thread
> >> to allow extensions to re-use the
> >> in-core logic for jumbling expressions found in plan node trees.
> >
> > IIUC, there should be a refactor I am working o
Dear hackers,
> I've pushed the patches. Thanks!
This is a closing post. Fujii-san has pushed patches and no BF failures till
now.
This patch does not modify the synopsis part, but it is intentional.
Per [1], we would discuss the manner for documentations in another thread.
I've closed the CF e
On Tue, 25 Mar 2025 at 11:15, Tom Lane wrote:
> FWIW, I share these doubts about whether these values are useful
> enough to include in the default EXPLAIN output. My main beef
> with them though is that they are basically numbers derived along
> the way to producing a cost estimate, and I don't
On Mon, Mar 24, 2025 at 10:35:41PM +0300, Nikolay Shaplov wrote:
> We can have isset_offset, but then we have redesign all options with
> custom unset behavior to use it, instead of unreachable default value.
> This will make it consistent then.
I don't see any reason why we are compelled to redes
On Mon, Mar 24, 2025 at 2:45 PM Nathan Bossart wrote:
> * I don't think this matches the parse_bool() behavior exactly. For
> example, parse_bool() appears to accept inputs like "t" to mean "true".
> This is also probably not a huge deal.
It's not great. We allow t/f in most places and some
On Fri, Mar 21, 2025 at 08:54:55AM -0700, David G. Johnston wrote:
> I'm still partial to mine but yours probably fits the overall style of the
> codebase better.
Committed with some light edits.
--
nathan
On Sun, Mar 23, 2025 at 10:13 AM Andres Freund wrote:
>
> Hi,
>
> On 2025-03-23 01:45:35 -0700, Masahiko Sawada wrote:
> > Another idea is that parallel workers don't exit phase 1 until it
> > consumes all pinned buffers in the queue, even if the memory usage of
> > TidStore exceeds the limit.
>
>
On Tue, Mar 25, 2025 at 11:55 AM Andres Freund wrote:
> If a callback may sometimes need to block, it can still opt into
> READ_STREAM_USE_BATCHING, by submitting all staged IO before blocking.
>
> The hardest part is to explain the flag. Here's my current attempt:
>
> /* ---
> * Opt-in to using
On Mon, Mar 24, 2025 at 3:15 PM Tom Lane wrote:
> FWIW, I share these doubts about whether these values are useful
> enough to include in the default EXPLAIN output. My main beef
> with them though is that they are basically numbers derived along
> the way to producing a cost estimate, and I don
> So your idea to use the relation name in eref while skipping the
> column list looks kind of promising. Per se the attached. Thoughts?
I feel really uneasy about this behavior becoming the default.
I can bet there are some users which run common queries across
different schemas ( e.g. multi-te
Hi,
On 2025-03-23 09:32:48 -0700, Noah Misch wrote:
> Another candidate description string:
>
> AIO_COMPLETED_SHARED "Waiting for another process to complete IO."
I liked that one and adopted it.
> > A more minimal change would be to narrow AIO_IO_URING_COMPLETION to
> > "execution" or someth
On Thu, Mar 20, 2025 at 09:58:37PM -0400, Andres Freund wrote:
> Subject: [PATCH v2.11 09/27] bufmgr: Implement AIO read support
[I checked that v2.12 doesn't invalidate these review comments, but I didn't
technically rebase the review onto v2.12's line numbers.]
> static void
> TerminateBuffer
On Tue, Mar 11, 2025 at 5:39 AM Andy Fan wrote:
> Currently when a query needs some parallel workers, postmaster spawns
> some backend for this query and when the work is done, the backend
> exit. there are some wastage here, e.g. syscache, relcache, smgr cache,
> vfd cache and fork/exit syscall
Dear hackers,
While reading the code, I found $SUBJECT. It says:
```
/*
* Publication relation/schema map syscache invalidation callback
*
* Called for invalidations on pg_publication and pg_namespace.
*/
static void
rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
```
Dear Vignesh,
> 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 remove option.
Confirmed all error reporting in
On Fri, 21 Mar 2025 at 16:44, Nisha Moond wrote:
>
> On Fri, Mar 21, 2025 at 3:38 PM Amit Kapila wrote:
> >
> > On Fri, Mar 21, 2025 at 1:48 PM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > On Fri, Mar 21, 2025 at 12:50 PM Nisha Moond wrote:
> > >
> > > > Thanks, Hou-san, for the review and fix pa
On Mon, Mar 24, 2025 at 09:03:11PM +0300, Nikolay Shaplov wrote:
> В письме от понедельник, 24 марта 2025 г. 20:48:29 MSK пользователь Nathan
> Bossart написал:
>
>> For the sake of discussion, here is what the enum approach would look like.
>
> In my point of view this solution is much-much bet
В письме от понедельник, 24 марта 2025 г. 21:45:27 MSK пользователь Nathan
Bossart написал:
> * We'd need to decide what to say on the documentation side. My first
> instinct is that we should just leave it as "boolean" because otherwise
> we're going to describe something that sounds an awfu
В письме от понедельник, 24 марта 2025 г. 22:26:17 MSK пользователь Nathan
Bossart написал:
> > And second general idea: changing engine is bad, at least when you can
> > manage without changing it.
>
> You have asserted this a couple of times without providing any reasons why.
> I know of no ge
> Ideally we can also land the jumble funcs work in the other thread to allow
> extensions to re-use the
> in-core logic for jumbling expressions found in plan node trees.
IIUC, there should be a refactor I am working on at this moment to make that
possible [0]
>> > FWIW, Lukas did start a Wiki
On Mon, Mar 24, 2025 at 1:16 PM Peter Eisentraut wrote:
>
> On 21.03.25 19:24, Matheus Alcantara wrote:
> > On Fri, Mar 21, 2025 at 1:28 PM Jacob Champion
> > wrote:
> >>
> >> Great, thank you! Looking over v10, I think I've run out of feedback
> >> at this point. Marked Ready for Committer.
> >
Oh, one other thing: pg_getnameinfo_all is perfectly capable of
dealing with a Unix-socket address, so I think you should drop
the tests on ss_family and let pg_getnameinfo_all be in charge
of producing "[local]" for that case.
regards, tom lane
Hi,
On 2025-03-25 13:07:49 +1300, Thomas Munro wrote:
> On Tue, Mar 25, 2025 at 11:55 AM Andres Freund wrote:
> > #define READ_STREAM_USE_BATCHING 0x08
>
> +1
>
> I wonder if something more like READ_STREAM_CALLBACK_BATCHMODE_AWARE
> would be better, to highlight that you are making a declarati
On Wed, Mar 19, 2025 at 6:25 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Wed, 19 Mar 2025 17:49:49 -0700,
> "David G. Johnston" wrote:
>
> >> And could someone help (take over if possible) writing a
> >> document for
On Sat, 1 Mar 2025 at 04:35, Jeff Davis wrote:
>
> On Mon, 2024-12-16 at 20:05 -0800, Jeff Davis wrote:
> > On Wed, 2024-10-30 at 08:08 -0700, Jeff Davis wrote:
> >
>
> Rebased v14.
>
> The approach has changed multiple times. It starte off with more in-
> core code, but in response to review feed
Sami Imseih writes:
> For example, I have seen users add comments to SQLs to differentiate
> similar SQLs coming from different tenants. This patch makes this no longer a
> somewhat decent workaround to overcome the fact that pg_stat_statements
> does not track schemas or search path.
Well, the
Hi,
On 2025-03-24 17:45:37 -0700, Noah Misch wrote:
> (We may be due for a test mode that does smgrreleaseall() at every
> CHECK_FOR_INTERRUPTS()?)
I suspect we are. I'm a bit afraid of even trying...
...
It's extremely slow - but at least the main regression as well as the aio tests
pass!
>
> select * from foo s1;
> select * from foo s2;
ah, thanks for pointing this out. Not as good of a workaround as
a comment since one must change aliases, but at least there is
a workaround...
> As against this, there is probably also a set of people who would
> *like* identical queries on identic
On Sat, Mar 8, 2025 at 7:21 AM Andres Freund wrote:
>
> FWIW, I am fairly certain that any non-toy algorithm that requires a full
> memory barrier instead of just an acquire in case of a CAS failure is chock
> full of concurrency bugs.
Yeah -- off the top of my head, I can think of only two CAS p
Hi,
On 2025-03-24 19:20:37 -0700, Noah Misch wrote:
> On Thu, Mar 20, 2025 at 09:58:37PM -0400, Andres Freund wrote:
> > static void
> > TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint32 set_flag_bits,
> > - bool forget_owner)
> > +
On Tue, Mar 25, 2025 at 8:51 AM vignesh C wrote:
>
> On Fri, 21 Mar 2025 at 16:44, Nisha Moond wrote:
> >
> > On Fri, Mar 21, 2025 at 3:38 PM Amit Kapila wrote:
> > >
> > > On Fri, Mar 21, 2025 at 1:48 PM Zhijie Hou (Fujitsu)
> > > wrote:
> > > >
> > > > On Fri, Mar 21, 2025 at 12:50 PM Nisha M
Sami Imseih writes:
> I agree that some may want stats to merge for the same tables,
> and others may not. I will suggest this with some hesitation, but why not
> make this behavior configurable via a GUC?
> We recently introduced query_id_squash_values for controlling
> the merge of an IN list, m
> Sami Imseih writes:
> > I agree that some may want stats to merge for the same tables,
> > and others may not. I will suggest this with some hesitation, but why not
> > make this behavior configurable via a GUC?
> > We recently introduced query_id_squash_values for controlling
> > the merge of a
Hi Kuroda-san,
On Mon, Mar 24, 2025 at 04:54:21AM +, Hayato Kuroda (Fujitsu) wrote:
> > So, I'm not sure I like the idea that much, but thinking out loud: I wonder
> > if
> > we could bypass the "active" slot checks in 16 and 17 and use injection
> > points as
> > proposed as of 18 (as we ne
On Mon, Mar 24, 2025 at 04:41:35PM +0100, Christoph Berg wrote:
> Re: Michael Paquier
>> +++ b/src/backend/nodes/queryjumblefuncs.c
>> @@ -33,6 +33,7 @@
>> #include "postgres.h"
>>
>> #include "access/transam.h"
>> +#include "catalog/namespace.h"
>
> No longer needed.
Indeed.
>> +++ b/contri
On Mon, Mar 24, 2025 at 09:38:35PM -0500, Sami Imseih wrote:
> > select * from foo s1;
> > select * from foo s2;
>
> ah, thanks for pointing this out. Not as good of a workaround as
> a comment since one must change aliases, but at least there is
> a workaround...
Exactly. Like Tom I'm not reall
On Mon, Mar 24, 2025 at 10:30:59PM -0500, Sami Imseih wrote:
>> Sami Imseih writes:
>>> I agree that some may want stats to merge for the same tables,
>>> and others may not. I will suggest this with some hesitation, but why not
>>> make this behavior configurable via a GUC?
>>> We recently introd
On Mon, Mar 24, 2025 at 11:45 AM Nathan Bossart
wrote:
> On Mon, Mar 24, 2025 at 09:03:11PM +0300, Nikolay Shaplov wrote:
> > В письме от понедельник, 24 марта 2025 г. 20:48:29 MSK пользователь
> Nathan
> > Bossart написал:
> >
> >> For the sake of discussion, here is what the enum approach would
On 2025-Mar-24, Robert Haas wrote:
> I mean, maybe there's an argument that some changes are more
> disruptive than others. For instance, if removing attndims would force
> drivers to run extra more complicated queries to learn whether a
> certain type is an array type, one could argue that taking
On Mon, Mar 24, 2025 at 9:08 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Mon, Mar 24, 2025 at 9:00 AM Álvaro Herrera
> wrote:
>
>> Hello
>>
>> I don't understand why this shouldn't work exactly like
>> vacuum_index_cleanup (cf. vacuum_rel lines 2170ff). That would require
>> n
"David G. Johnston" writes:
> In discussing vacuum_truncate_set it occurs to me there is no SQL way for
> someone to easily view the current setting (or unset status) of a
> reloption. Seems like we could modify SHOW to cover this use case.
That seems like a pretty awful idea; for starters, ther
On Mon, Mar 24, 2025 at 5:42 AM Nikolay Shaplov wrote:
> В письме от понедельник, 24 марта 2025 г. 15:27:35 MSK пользователь
> Nikolay
> Shaplov написал:
>
> > PS. I've just looked at code for vacuum_index_cleanup it has very same
> > logic, just replace "auto" with anything you like, and uses en
On Mon, Mar 24, 2025 at 05:00:51PM +0100, Álvaro Herrera wrote:
> I don't understand why this shouldn't work exactly like
> vacuum_index_cleanup (cf. vacuum_rel lines 2170ff). That would require
> no new mechanism.
I explained my reasons for not proceeding with that approach upthread [0].
I don'
Hello
I don't understand why this shouldn't work exactly like
vacuum_index_cleanup (cf. vacuum_rel lines 2170ff). That would require
no new mechanism.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Java is clearly an example of money oriented programming" (A.
В письме от понедельник, 24 марта 2025 г. 19:00:51 MSK пользователь Álvaro
Herrera написал:
> I don't understand why this shouldn't work exactly like
> vacuum_index_cleanup (cf. vacuum_rel lines 2170ff). That would require
> no new mechanism.
In my opinion it should.
"no new mechanism" is goo
On Wed, Mar 19, 2025 at 3:31 PM Ashutosh Bapat
wrote:
> On Wed, Mar 19, 2025 at 8:22 AM Amit Langote wrote:
> > Yes, those were with pwj=off. FTR, numbers I get with pwj=on.
> >
> > 3-way:
> >
> > nparts master patched %change
> > 0 38.407 34.675 -9.717
> > 16 69.3
On Sat, Mar 22, 2025 at 11:40 AM Jelte Fennema-Nio
wrote:
> On Tue, 25 Feb 2025 at 17:11, Nathan Bossart
> wrote:
> >
> > On Tue, Feb 25, 2025 at 04:42:37PM +0100, Magnus Hagander wrote:
> > > Thanks goes to both you and the previous responders - I did manage to
> mute
> > > this thread away an
On 24/03/2025 16:56, Tomas Vondra wrote:
On 3/23/25 17:43, Heikki Linnakangas wrote:
On 21/03/2025 17:16, Andres Freund wrote:
Am I right in understanding that the only scenario (when in
STANDBY_SNAPSHOT_READY), where ExpireOldKnownAssignedTransactionIds()
would
"legally" remove a transaction
On Mon, Mar 24, 2025 at 8:26 AM Robert Haas wrote:
> On Mon, Mar 24, 2025 at 11:12 AM Nikolay Shaplov wrote:
> > Nobody would guess that
> >
> > ALTER TABLE test SET (vacuum_truncate=false);
> > means "off"
> >
> > and
> > ALTER TABLE test RESET (vacuum_truncate);
> > means "system_default"
> >
Hi,
On 2025-03-23 17:29:39 -0700, Noah Misch wrote:
> commit 247ce06b wrote:
> > + pgaio_io_reopen(ioh);
> > +
> > + /*
> > +* To be able to exercise the reopen-fails path, allow
> > injection
> > +* points to trigger a f
"=?UTF-8?B?6LW15bqt5rW3KOW6reeroCk=?=" writes:
> The testing query (more than 1000 condition after in clause):
> UPDATE test SET migrate_account_batch_id = 'newtest2' WHERE (id, store_id) IN
> (xxx);
As you've discovered, this is a lousy way to write such a query.
You'd get a better result by pu
Re: Michael Paquier
> So your idea to use the relation name in eref while skipping the
> column list looks kind of promising. Per se the attached. Thoughts?
Makes sense to me, thanks for digging into it.
> +++ b/src/backend/nodes/queryjumblefuncs.c
> @@ -33,6 +33,7 @@
> #include "postgres.h"
>
В письме от понедельник, 24 марта 2025 г. 18:25:44 MSK пользователь Robert
Haas написал:
> > and
> > ALTER TABLE test RESET (vacuum_truncate);
> > means "system_default"
> >
> > This will lead to a lot of confusion.
>
> I agree that this confuses people,
Though a bit more, I think that as a use
In discussing vacuum_truncate_set it occurs to me there is no SQL way for
someone to easily view the current setting (or unset status) of a
reloption. Seems like we could modify SHOW to cover this use case. It is
mostly redundant with \d+ which already distinguishes unset and set options
by displ
One thing that bothers me a bit about this is that there's no single
code comment where this restriction it documented in full; in fact it
doesn't seem documented anywhere, only in the commit message.
I think check_foreign_tables() is a good place to add an explanatory
comment; other places can re
On 2025/03/24 23:18, torikoshia wrote:
On 2025-03-24 00:08, Fujii Masao wrote:
Do you also think the errhint message is unnecessary?
I agree with your idea to add a description of the overflowed subtransaction in
the manual, but I'm not sure all users will be able to find it.
Some people m
Robert Haas writes:
> It looks reasonable to me. I am a bit worried that using PG_VERSION as
> the version string is going to feel like the wrong thing at some
> stage, but I can't really say why, and I think it's better to do
> something now and maybe have to revise it later than to do nothing no
On 2025/03/24 11:21, Hayato Kuroda (Fujitsu) wrote:
Dear Fujii-san,
I've updated the commit messages for both patches and also revised
the code comments in the 0002 patch. The updated patches are attached.
Unless there are any objections, I'm thinking to commit them.
Thanks for updating t
On Mon, Mar 24, 2025 at 8:45 AM Nikolay Shaplov wrote:
> > but I don't think it's more
> > confusing here than for other vacuum reloptions. I have seen people
> > try to unset vacuum reloptions by using SET to configure them to the
> > default value rather than by using RESET to remove them. But
On 21/03/2025 17:16, Andres Freund wrote:
Am I right in understanding that the only scenario (when in
STANDBY_SNAPSHOT_READY), where ExpireOldKnownAssignedTransactionIds() would
"legally" remove a transaction, rather than the commit / abort records doing
so, is if the primary crash-restarted whil
On Sun, Mar 23, 2025 at 1:27 PM Melanie Plageman
wrote:
>
> Perhaps it is better I just fix it since ripping out the skip fetch
> optimization has to be backported and even though that will look very
> different on master than on backbranches, I wonder if people will look
> for a "clean" commit on
On 21.03.25 19:24, Matheus Alcantara wrote:
On Fri, Mar 21, 2025 at 1:28 PM Jacob Champion
wrote:
Great, thank you! Looking over v10, I think I've run out of feedback
at this point. Marked Ready for Committer.
Thanks for all the effort reviewing this patch!
I have committed the 0003 patch
Hi,
On 2025-03-23 01:45:35 -0700, Masahiko Sawada wrote:
> Another idea is that parallel workers don't exit phase 1 until it
> consumes all pinned buffers in the queue, even if the memory usage of
> TidStore exceeds the limit.
Yes, that seems a quite reasonable approach to me.
> It would need t
Hi,
It seems that Aidar's email ended up as another thread [1]. I am
copy-pasting mail and answer here to keep the discussion in this
thread.
On Sun, 23 Mar 2025 at 22:16, Aidar Imamov wrote:
>
> I agree with most of what Joseph said. However, I would like to add some
> comments.
>
> At the mome
Hi,
On 2025-03-24 13:41:17 +0300, Yura Sokolov wrote:
> 21.03.2025 19:33, Andres Freund wrote:
> > I'd also like to know a bit more about the motivation here - I can easily
> > believe that you hit contention around the shared inval queue, but I find it
> > somewhat hard to believe that a spinlock
On Mon, Mar 24, 2025 at 5:40 PM Daniel Gustafsson wrote:
>
> > With this patch, we are doing something unprecedented (at least
> > AFAIK); allowing command arguments defaults to be configurable through
> > a psql variable (as against an environment variable). I admit that
> > configurable through
On Mon, Mar 24, 2025 at 11:54 AM Tom Lane wrote:
> If somebody thinks of a better idea and is willing to do the legwork
> to make it happen, we can surely change to something else later on.
> Or invent another field with different semantics, or whatever.
Yeah, my thoughts exactly.
--
Robert Haa
В письме от понедельник, 24 марта 2025 г. 15:27:35 MSK пользователь Nikolay
Shaplov написал:
> PS. I've just looked at code for vacuum_index_cleanup it has very same
> logic, just replace "auto" with anything you like, and uses enum.
> Grep for StdRdOptIndexCleanupValues for more info
I thought
On Mon, Mar 24, 2025 at 1:27 PM Nikolay Shaplov wrote:
> > > You've just changed the whole engine, for what is seems to be an
> > > exceptional case, that can be solved via existing means.
> > I have not changed the whole engine. I have added an optional integer
> > field to a single struct.
>
>
On Mon, Mar 24, 2025 at 03:27:35PM +0300, Nikolay Shaplov wrote:
> I would suggest to use enum here to achieve same goal, or add some "trilean"
> data type that can be "true/false/unset"
I did first try making the vacuum_truncate reloption an enum, but I didn't
proceed with that approach for a co
В письме от понедельник, 24 марта 2025 г. 17:43:38 MSK пользователь Nathan
Bossart написал:
> * vacuum_truncate is already a Boolean reloption,
Yes, I guess schema update would be best solution here.
> so switching it to an
> enum would require enumerating all possible values accepted by
>
В письме от понедельник, 24 марта 2025 г. 19:41:27 MSK пользователь Nathan
Bossart написал:
> But more importantly, it allows
> us to more closely match the behavior of the existing reloptions with GUCs,
> and it prevents type mismatches (e.g., the reloption is an enum but the GUC
> is a Boolean).
Alexander Korotkov писал(а) 2025-03-24 11:49:
On Mon, Mar 24, 2025 at 9:07 AM Alexander Pyhalov
wrote:
Alexander Korotkov писал(а) 2025-03-24 04:21:
> Hi, Alexander!
>
> On Tue, Mar 18, 2025 at 6:04 PM Alexander Pyhalov
> wrote:
>> This shouldn't. When semi-join is found below left/right join,
On Mon, Mar 24, 2025 at 09:40:24AM -0700, David G. Johnston wrote:
> So, given the precedent of vacuum_index_cleanup and the above, we should
> turn this into an enum that accepts all existing boolean literal inputs and
> also has a undocumented "unset" default value that the user is not allowed
>
В письме от понедельник, 24 марта 2025 г. 19:58:38 MSK пользователь Nathan
Bossart написал:
> On Mon, Mar 24, 2025 at 09:40:24AM -0700, David G. Johnston wrote:
> > So, given the precedent of vacuum_index_cleanup and the above, we should
> > turn this into an enum that accepts all existing boolean
On Fri, Mar 21, 2025 at 2:04 PM Alvaro Herrera wrote:
> In several of the cases that I checked, the application just tests the
> returned value for boolean truth. If we change the column from boolean
> to char, they would stop working properly because both the 't' and the
> 'f' char values would
On Mon, Mar 24, 2025 at 07:53:43PM +0300, Nikolay Shaplov wrote:
> You've just changed the whole engine, for what is seems to be an exceptional
> case, that can be solved via existing means.
I have not changed the whole engine. I have added an optional integer
field to a single struct.
--
nath
В письме от понедельник, 24 марта 2025 г. 20:09:23 MSK пользователь Nathan
Bossart написал:
> > You've just changed the whole engine, for what is seems to be an
> > exceptional case, that can be solved via existing means.
> I have not changed the whole engine. I have added an optional integer
>
On 2025/03/23 23:00, Alexander Lakhin wrote:
Hello hackers,
A recent buildfarm failure [1] with the following diagnostics:
72/72 postgresql:postgres_fdw-running / postgres_fdw-running/regress
ERROR 19.04s exit status 1
postgres_fdw-running/regress/results/postgres_f
On Mon, Mar 24, 2025 at 10:43 AM Nathan Bossart
wrote:
> Overall, the biggest reason I didn't proceed with the enum is because it
> felt like it was making it the user's problem. Rather than just teaching
> our code how to determine if a reloption was explicitly set, we'd be
> introducing unneces
On Thu, 20 Mar 2025 at 23:39, Mahendra Singh Thalor
wrote:
>
> On Thu, 30 Jan 2025 at 16:47, Srinath Reddy wrote:
> >
> >
> >
> > On Wed, Jan 29, 2025 at 9:55 PM Mahendra Singh Thalor <
mahi6...@gmail.com> wrote:
> >>
> >> Hi,
> >> While doing some testing with pg_dumpall, I noticed one weird
beh
On Mon, Mar 24, 2025 at 9:41 AM Nathan Bossart
wrote:
> TBH I'm not understanding the pushback for adding a way to determine
> whether the storage parameter is actually set. It's very simple, and it
> seems like it could be useful elsewhere.
IMO this is superior to using sentinel values for th
1 - 100 of 170 matches
Mail list logo
