On 3/15/24 18:32, Michael Paquier wrote:
On Fri, Mar 15, 2024 at 06:23:15PM +1300, David Steele wrote:
Well, this is what we recommend in the docs, i.e. using bin mode to save
backup_label, so it seems OK to me.
Indeed, I didn't notice that this is actually documented, so what I
did took the
On Fri, Mar 15, 2024 at 06:23:15PM +1300, David Steele wrote:
> Well, this is what we recommend in the docs, i.e. using bin mode to save
> backup_label, so it seems OK to me.
Indeed, I didn't notice that this is actually documented, so what I
did took the right angle. French flair, perhaps..
--
On Fri, Mar 15, 2024 at 08:38:47AM +0900, Michael Paquier wrote:
> That's why these tests are not that easy, they can be racy. I've run
> the test 5~10 times in the CI this time to gain more confidence, and
> saw zero failures with the stability fixes in place including Windows.
> I've applied it
On 3/15/24 12:38, Michael Paquier wrote:
On Fri, Mar 15, 2024 at 09:40:38AM +1300, David Steele wrote:
Is the missing test in meson the reason we did not see test failures for
Windows in CI?
The test has to be listed in src/test/recovery/meson.build or the CI
would ignore it.
Right -- I
On Wed, Mar 13, 2024 at 9:38 AM Amit Kapila wrote:
>
> BTW, is XID the based parameter 'max_slot_xid_age' not have similarity
> with 'max_slot_wal_keep_size'? I think it will impact the rows we
> removed based on xid horizons. Don't we need to consider it while
> vacuum computing the xid horizons
On 14/3/2024 17:39, Alexander Korotkov wrote:
Thank you, Andrei. Looks like a very undesirable side effect. Do you
have any idea why it happens? Partition pruning should work correctly
for both transformed and non-transformed quals, why does
transformation hurt it?
Now we have the v23-0001-*
On Thu, Mar 14, 2024 at 7:58 PM Bharath Rupireddy
wrote:
>
> On Thu, Mar 14, 2024 at 12:24 PM Amit Kapila wrote:
> >
> > On Wed, Mar 13, 2024 at 9:24 PM Bharath Rupireddy
> > >
> > > Yes, there will be some sort of duplicity if we emit conflict_reason
> > > as a text field. However, I still
On Fri, Mar 15, 2024, at 1:14 AM, Amit Kapila wrote:
> I think node should mean instance for both physical and logical
> replication, otherwise, it would be confusing. We need both the usages
> as a particular publication/subscription is defined at the database
> level but the server on which we
On Fri, Mar 15, 2024 at 3:17 PM Masahiko Sawada
wrote:
>
> I resumed working on this item. I've attached the new version patch.
>
> I rebased the patch to the current HEAD and updated comments and
> commit messages. The patch is straightforward and I'm somewhat
> satisfied with it, but I'm
On Thu, Mar 14, 2024 at 7:51 PM Alvaro Herrera wrote:
>
> On 2024-Mar-14, Shlok Kyal wrote:
>
> > Andrew Atkinson wrote:
> >
> > > Anyway, hopefully these examples show “node” and “database” are
> > > mixed and perhaps others agree using one consistently might help the
> > > goals of the docs.
>
On Wed, Mar 13, 2024, at 10:09 AM, Shlok Kyal wrote:
> Added a top-up patch v28-0005 to fix this issue.
> I am not changing the version as v28-0001 to v28-0004 is the same as above.
Thanks for your review!
I'm posting a new patch (v29) that merges the previous patches (v28-0002 and
v28-0003). I
On Fri, 15 Mar 2024 at 15:27, Kyotaro Horiguchi wrote:
> I have considered only the two messages. Actually, buffile.c and md.c
> are already like that. The attached aligns the messages in
> pg_combinebackup.c and reconstruct.c with the precedents.
This looks like a worthy cause to make
On Thu, Mar 14, 2024 at 07:43:15PM -0400, Robert Haas wrote:
> On Thu, Mar 14, 2024 at 5:15 PM Maciek Sakrejda wrote:
> > It's not a security feature: it's a usability feature.
> >
> > It's a usability feature because, when Postgres configuration is
> > managed by an outside mechanism (e.g., as
On Thu, Mar 14, 2024 at 10:46:28PM -0400, Bruce Momjian wrote:
> > In the end, while I certainly don't mind improving the web page, I
> > think that a lot of what we're seeing here probably has to do with the
> > growing popularity and success of PostgreSQL. If you have more people
> > using your
On Thu, Mar 14, 2024 at 9:03 PM Masahiko Sawada wrote:
>
> On Thu, Mar 14, 2024 at 6:55 PM John Naylor wrote:
> >
> > On Thu, Mar 14, 2024 at 12:06 PM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Mar 14, 2024 at 1:29 PM John Naylor
> > > wrote:
> > > > Okay, here's an another idea: Change
On Thu, Mar 14, 2024 at 10:15:18AM -0400, Robert Haas wrote:
> I think that whatever we say here should focus on what we try to do or
> guarantee, not on what actions we think users ought to take, never
> mind must take. We can say that we try to avoid making any changes
> upon which an
At Thu, 14 Mar 2024 11:23:38 +0530, Amit Kapila wrote
in
> On Thu, Mar 14, 2024 at 9:58 AM Kyotaro Horiguchi
> wrote:
> >
> > While examining reorderbuffer.c, I found several typos. I'm not sure
> > if fixing them is worthwhile, but I've attached a fix just in case.
> >
>
> LGTM. I'll push
Thank you for the suggestions.
At Thu, 14 Mar 2024 13:45:41 +0100, Daniel Gustafsson wrote
in
> I've only skimmed this so far but +1 on keeping the messages the same where
> possible to reduce translation work. Adding a comment on the message where
> the
> casting is done to indicate that it
On Tue, 12 Mar 2024 at 23:57, Tomas Vondra
wrote:
> Attached is an updated version of the mempool patch, modifying all the
> memory contexts (not just AllocSet), including the bump context. And
> then also PDF with results from the two machines, comparing results
> without and with the mempool.
On Thu, Mar 14, 2024 at 04:00:10PM -0500, Nathan Bossart wrote:
> Separately, I suppose it's probably time to revert the temporary debugging
> code adding by commit 5ddf997. I can craft a patch for that, too.
As promised...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From
On Thu, Mar 14, 2024 at 10:28 AM Robert Haas wrote:
>
> On Wed, Oct 4, 2023 at 9:12 PM James Coleman wrote:
> > All right, attached is a v3 which attempts to fix the wrong
> > information with an economy of words. I may at some point submit a
> > separate patch that adds a broader pruning
Michael Paquier writes:
> Hmm. I am not sure how much protection this would offer, TBH. One
> thing that I find annoying with common/stringinfo.c as it is currently
> is that we have two exit() calls in the enlarge path, and it does not
> seem wise to me to spread that even more.
> My last
For me it seems that the LLVMRunPasses() call, new in
commit 76200e5ee469e4a9db5f9514b9d0c6a31b496bff
Author: Thomas Munro
Date: Wed Oct 18 22:15:54 2023 +1300
jit: Changes for LLVM 17.
is reaching code that segfaults inside libLLVM, specifically in
llvm::InlineFunction(llvm::CallBase&,
On Thu, Mar 14, 2024 at 10:56:46AM +0100, Daniel Gustafsson wrote:
> + /* don't allow destroys of read-only StringInfos */
> + Assert(str->maxlen != 0);
> Considering that StringInfo.c don't own the memory here I think it's warranted
> to turn this assert into an elog() to avoid the risk
On Fri, Mar 15, 2024 at 12:27 PM Daniel Gustafsson wrote:
> > On 14 Mar 2024, at 20:15, Pavel Stehule wrote:
>
> > build is ok, but regress tests fails with crash (it works without
> > -with-llvm)
>
> Can you post some details around this crash? It doesn't seem to be a
> combination we have
On Thu, Mar 14, 2024 at 5:15 PM Maciek Sakrejda wrote:
> It's not a security feature: it's a usability feature.
>
> It's a usability feature because, when Postgres configuration is
> managed by an outside mechanism (e.g., as in a Kubernetes
> environment), ALTER SYSTEM currently allows a
Hi, Daniel and Michael,
On Thu, Mar 14, 2024 at 09:32:55AM +0100, Daniel Gustafsson wrote:
> > On 14 Mar 2024, at 07:02, Tatsuro Yamada wrote:
> >> So, I created a patch to fix them.
> >
> > Thanks, applied.
>
> Oops. Thanks.
> --
> Michael
>
Thank you guys!
Regards,
Tatsuro Yamada
NTT Open
On Fri, Mar 15, 2024 at 09:40:38AM +1300, David Steele wrote:
> Is the missing test in meson the reason we did not see test failures for
> Windows in CI?
The test has to be listed in src/test/recovery/meson.build or the CI
would ignore it.
>> The second LOG is something that can be acted on.
> On 14 Mar 2024, at 20:15, Pavel Stehule wrote:
> build is ok, but regress tests fails with crash (it works without -with-llvm)
Can you post some details around this crash? It doesn't seem to be a
combination we have covered in the buildfarm.
--
Daniel Gustafsson
> On 14 Mar 2024, at 14:21, Robert Treat wrote:
> On Thu, Mar 14, 2024 at 8:21 AM Daniel Gustafsson wrote:
>> - canceling connection in psql wouldn't cancel
>> + canceling a connection in psql will not
>> cancel
>> Nitpickery (perhaps motivated by english not being my first language),
Michael Paquier writes:
> On Thu, Mar 14, 2024 at 06:19:38PM -0400, Tom Lane wrote:
>> I wonder if it'd be wise to adjust the injection point stuff so that
>> it's active in only the specific database the injection point was
>> activated in.
> It can be made optional by extending
On Fri, Mar 15, 2024 at 07:53:57AM +0900, Michael Paquier wrote:
> It can be made optional by extending InjectionPointAttach() to
> specify a database OID or a database name. Note that
> 041_checkpoint_at_promote.pl wants an injection point to run in the
> checkpointer, where we don't have a
On Thu, Mar 14, 2024 at 09:32:55AM +0100, Daniel Gustafsson wrote:
> On 14 Mar 2024, at 07:02, Tatsuro Yamada wrote:
>> So, I created a patch to fix them.
>
> Thanks, applied.
Oops. Thanks.
--
Michael
signature.asc
Description: PGP signature
On Thu, Mar 14, 2024 at 04:27:43PM +0300, Teodor Sigaev wrote:
>> So I would like to suggest the attached patch for this first piece.
>> What do you think?
>
> I have not any objections
Okay, I've applied this piece for now. Not sure I'll have much room
to look at the rest.
--
Michael
On Thu, 14 Mar 2024 at 12:00, David Rowley wrote:
> I've attached a patch which fixes the problem for me.
I've pushed the patch to fix gather_grouping_paths(). The issue with
the RelOptInfo having the incorrect PathTarget->exprs after the
partial phase of partition-wise aggregate remains.
On Thu, Mar 14, 2024 at 06:19:38PM -0400, Tom Lane wrote:
> Do they? It'd be fairly easy to explain this if these things were
> being run in "installcheck" style. I'm not sure about CI, but from
> memory, the buildfarm does use installcheck for some things.
>
> I wonder if it'd be wise to
Thomas Munro writes:
> On Fri, Mar 15, 2024 at 11:19 AM Tom Lane wrote:
>> Do they? It'd be fairly easy to explain this if these things were
>> being run in "installcheck" style. I'm not sure about CI, but from
>> memory, the buildfarm does use installcheck for some things.
> Right, as
I wrote:
> Heikki Linnakangas writes:
>> Somehow the 'gin-leave-leaf-split-incomplete' injection point was active
>> in the 'intarray' test. That makes no sense. That injection point is
>> only used by the test in src/test/modules/gin/. Perhaps that ran at the
>> same time as the intarray
On Fri, Mar 15, 2024 at 11:19 AM Tom Lane wrote:
> Heikki Linnakangas writes:
> > Somehow the 'gin-leave-leaf-split-incomplete' injection point was active
> > in the 'intarray' test. That makes no sense. That injection point is
> > only used by the test in src/test/modules/gin/. Perhaps that ran
On Mon, 2024-03-11 at 10:01 +, Li, Yong wrote:
> - The clog LSN group has been brought back.
> Now the page LSN on each clog page is used for honoring the write-
> ahead rule
> and it is always the highest LSN of all the LSN groups on the page.
> The LSN groups are used by
Heikki Linnakangas writes:
> Somehow the 'gin-leave-leaf-split-incomplete' injection point was active
> in the 'intarray' test. That makes no sense. That injection point is
> only used by the test in src/test/modules/gin/. Perhaps that ran at the
> same time as the intarray test? But they run
On Thu, Mar 14, 2024 at 5:26 PM Tomas Vondra
wrote:
>
> On 3/14/24 19:16, Melanie Plageman wrote:
> > On Thu, Mar 14, 2024 at 03:32:04PM +0200, Heikki Linnakangas wrote:
> >> ...
> >>
> >> Ok, committed that for now. Thanks for looking!
> >
> > Attached v6 is rebased over your new commit. It also
On 3/14/24 19:16, Melanie Plageman wrote:
> On Thu, Mar 14, 2024 at 03:32:04PM +0200, Heikki Linnakangas wrote:
>> ...
>>
>> Ok, committed that for now. Thanks for looking!
>
> Attached v6 is rebased over your new commit. It also has the "fix" in
> 0010 which moves BitmapAdjustPrefetchIterator()
I got a weird test failure while testing my forking refactor patches on
Cirrus CI
(https://cirrus-ci.com/task/5880724448870400?logs=test_running#L121):
[16:52:39.753] Summary of Failures:
[16:52:39.753]
[16:52:39.753] 66/73 postgresql:intarray-running / intarray-running/regress
On Thu, Mar 14, 2024 at 1:38 PM Robert Haas wrote:
> On Thu, Mar 14, 2024 at 4:08 PM Tom Lane wrote:
> > The patch-of-record contains no such wording.
>
> I plan to fix that, if nobody else beats me to it.
>
> > And if this isn't a
> > security feature, then what is it? If you have to say to
On 3/14/24 20:14, Robert Haas wrote:
> On Tue, Feb 20, 2024 at 5:31 AM Tomas Vondra
> wrote:
>> I certainly agree that the current JIT costing is quite crude, and we've
>> all seen cases where the decision turns out to not be great. And I think
>> the plan to make the decisions at the node
On Wed, Jan 24, 2024 at 12:05:15PM -0600, Nathan Bossart wrote:
> There might be an overflow risk in the cutoff time calculation, but I doubt
> that's the root cause of these failures:
>
> /*
>* Files should only be removed if the last modification time precedes
> the
>*
On 14/03/2024 22:00, Melanie Plageman wrote:
On Thu, Mar 14, 2024 at 05:30:30PM +0200, Heikki Linnakangas wrote:
typedef struct SharedBitmapHeapInstrumentation
{
int num_workers;
BitmapHeapScanInstrumentation sinstrument[FLEXIBLE_ARRAY_MEMBER];
}
On Fri, Mar 15, 2024 at 3:18 AM Tomas Vondra
wrote:
> So, IIUC this means (1) the patched code is more aggressive wrt
> prefetching (because we prefetch more data overall, because master would
> prefetch N pages and patched prefetches N ranges, each of which may be
> multiple pages. And (2) it's
Thomas Munro writes:
> On Fri, Mar 15, 2024 at 7:00 AM Alexander Lakhin wrote:
>> Could it be that the timeout (360 sec?) is just not enough for the test
>> under the current (changed due to switch to meson) conditions?
> But you're right that under meson the test takes a lot longer, I guess
>
On Thu, 2024-03-14 at 15:38 +0100, Peter Eisentraut wrote:
> On 14.03.24 09:08, Jeff Davis wrote:
> > 0001 (the C.UTF-8 locale) is also close...
>
> If have tested this against the libc locale C.utf8 that was available
> on
> the OS, and the behavior is consistent.
That was the goal, in spirit.
On 3/14/24 20:00, Michael Paquier wrote:
On Thu, Mar 14, 2024 at 09:12:52AM +1300, David Steele wrote:
I think you are right that the start message is better since it can only
appear once when the backup_label is found. The completed message could in
theory appear after a restart, though the
On Thu, Mar 14, 2024 at 4:08 PM Tom Lane wrote:
> The patch-of-record contains no such wording.
I plan to fix that, if nobody else beats me to it.
> And if this isn't a
> security feature, then what is it? If you have to say to your
> (super) users "please don't mess with the system
On 13.03.2024 10:41, Anton A. Melnikov wrote:
Here is a version updated for the current master.
During patch updating i mistakenly added double counting of deallocatated
blocks.
That's why the tests in the patch tester failed.
Fixed it and squashed fix 0002 with 0001.
Here is fixed version.
On Thu, Mar 14, 2024 at 1:54 PM Jelte Fennema-Nio wrote:
> In my view there can be, **by definition,** only two general types of
> protocol changes:
> 1. A "simple protocol change": This is one that requires agreement by
> both the client and server, that they understand the new message types
>
On Fri, Mar 15, 2024 at 7:00 AM Alexander Lakhin wrote:
> Could it be that the timeout (360 sec?) is just not enough for the test
> under the current (changed due to switch to meson) conditions?
Hmm, well it looks like he switched over to meson around 42 days ago
2024-02-01, looking at
Robert Haas writes:
> On Thu, Mar 14, 2024 at 3:13 PM Tom Lane wrote:
>> With the possible exception of #1, every one of these is easily
>> defeatable by an uncooperative superuser. I'm not excited about
>> adding a "security" feature with such obvious holes in it.
> We're going to document
On Thu, Mar 14, 2024 at 05:30:30PM +0200, Heikki Linnakangas wrote:
> On 18/02/2024 00:31, Tomas Vondra wrote:
> > Do you plan to work continue working on this patch? I did take a look,
> > and on the whole it looks reasonable - it modifies the right places etc.
>
> +1
>
> > I think there are
Thanks for chipping in here.
On Fri, 15 Mar 2024 at 08:14, Robert Haas wrote:
> A slightly subtler way the patch could lose is if the new threshold is
> harder to adjust than the old one. For example, imagine that you have
> a query that does a Cartesian join. That makes the cost of the input
>
> -Original Message-
> From: Nathan Bossart
> Sent: Monday, March 11, 2024 6:35 PM
> To: Amonson, Paul D
> Thanks. There's no need to wait to post the AVX portion. I recommend using
> "git format-patch" to construct the patch set for the lists.
After exploring git format-patch
I've been poking at the partial token logic. The json_errdetail() bug
mentioned upthread (e.g. for an invalid input `[12zz]` and small chunk
size) seems to be due to the disconnection between the "main" lex
instance and the dummy_lex that's created from it. The dummy_lex
contains all the
On Thu, Mar 14, 2024 at 3:13 PM Tom Lane wrote:
> With the possible exception of #1, every one of these is easily
> defeatable by an uncooperative superuser. I'm not excited about
> adding a "security" feature with such obvious holes in it.
> We reverted MAINTAIN last year for much less obvious
Hi
čt 14. 3. 2024 v 19:20 odesílatel Robert Haas
napsal:
> On Wed, Mar 6, 2024 at 1:54 AM Pavel Stehule
> wrote:
> > after today update, the build with --with-llvm produces broken code, and
> make check fails with crash
> >
> > Upgradehwdata-0.380-1.fc40.noarch
> @updates-testing
> >
On Tue, Feb 20, 2024 at 5:31 AM Tomas Vondra
wrote:
> I certainly agree that the current JIT costing is quite crude, and we've
> all seen cases where the decision turns out to not be great. And I think
> the plan to make the decisions at the node level makes sense, so +1 to
> that in general.
Robert Haas writes:
> As far as I can see from reading the thread, most people agree that
> it's reasonable to have some way to disable ALTER SYSTEM, but there
> are at least six competing ideas about how to do that:
> 1. command-line option
> 2. GUC
> 3. event trigger
> 4. extension
> 5.
On Thu, 14 Mar 2024 at 17:37, Robert Haas wrote:
> or in the
> alternative (2) but with the GUC being PGC_SIGHUP and
> GUC_DISALLOW_IN_AUTO_FILE. I believe there would be adequate consensus
> to proceed with either of those approaches. Anybody feel like coding
> it up?
Here is a slightly
On Wed, Mar 6, 2024 at 1:54 AM Pavel Stehule wrote:
> after today update, the build with --with-llvm produces broken code, and make
> check fails with crash
>
> Upgradehwdata-0.380-1.fc40.noarch
> @updates-testing
> Upgraded hwdata-0.379-1.fc40.noarch
On Thu, 2024-02-29 at 17:02 -0800, Jeff Davis wrote:
> Attached is an implementation of a per-database option STRICT_UNICODE
> which enforces the use of assigned code points only.
The CF app doesn't seem to point at the latest patch:
> On 14 Mar 2024, at 20:10, Peter Eisentraut wrote:
>
> I think the behavior of uuid_extract_var(iant) is wrong. The code
> takes just two bits to return, but the draft document is quite clear
> that the variant is 4 bits (see Table 1).
Well, it was correct only for
On Sat, Feb 17, 2024 at 6:10 PM Tomas Vondra
wrote:
> I may be missing some important bit behind this idea, but this does not
> seem like a great idea to me. The comment added to FilePrefetch says this:
>
> /*
>* last time we visit this file (somewhere), nr_recently_evicted pages
>* of
Hello Thomas and Michael,
14.03.2024 06:16, Thomas Munro wrote:
Yeah, I was wondering if its checkpoint delaying logic might have
got the checkpointer jammed or something like that, but I don't
currently see how. Yeah, the replay of bulk newpages could be
relevant, but it's not exactly new
On Thu, 14 Mar 2024 at 16:45, Robert Haas wrote:
> I feel bad arguing about the patches that you think are a slam-dunk,
> but I find myself disagreeing with the design choices.
No worries, thanks a lot for responding. I'm happy to discuss this
design further. I didn't necessarily mean these
Hi Maiquel,
On Thu, Feb 29, 2024 at 10:02:21PM +, Maiquel Grassi wrote:
> Sorry for the delay. I will make the adjustments as requested soon.
We have only a few weeks left before feature-freeze for v17. Do you think
you will be able to send an updated patch soon?
--
Nathan Bossart
Amazon
On Thu, Mar 14, 2024 at 11:05 AM Amul Sul wrote:
> Thank you, Robert.
Thanks for the patch!
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Feb 13, 2024 at 2:05 AM Joel Jacobson wrote:
> > Wouldn't having system wide EVTs be a generic solution which could be the
> > infrastructure for this requested change as well as others in the same area?
>
> +1
>
> I like the wider vision of providing the necessary infrastructure to
Hi Robert,
On Thu, Mar 7, 2024 at 10:49 PM Robert Treat wrote:
> This patch adds a link to the "attach partition" command section
> (similar to the detach partition link above it) as well as a link to
> "create table like" as both commands contain additional information
> that users should
On Wed, Mar 13, 2024 at 01:09:18PM +0700, Yugo NAGATA wrote:
> On Tue, 12 Mar 2024 22:07:17 -0500
> Nathan Bossart wrote:
>> I did some light editing to prepare this for commit.
>
> Thank you. I confirmed the test you improved and I am fine with that.
Committed.
--
Nathan Bossart
Amazon Web
On 13.03.24 18:12, Bruce Momjian wrote:
On Wed, Mar 13, 2024 at 09:21:27AM -0700, Jeremy Schneider wrote:
It's not just roadmaps and release pages where we mix up these terms
either, it's even in user-facing SQL and libpq routines: both
PQserverVersion and current_setting('server_version_num')
On Fri, Mar 8, 2024 at 6:47 AM Jelte Fennema-Nio wrote:
> 1. 0001-0005 are needed for any protocol change, and hopefully
> shouldn't require much discussion
I feel bad arguing about the patches that you think are a slam-dunk,
but I find myself disagreeing with the design choices.
Regarding
On 18/02/2024 00:31, Tomas Vondra wrote:
Do you plan to work continue working on this patch? I did take a look,
and on the whole it looks reasonable - it modifies the right places etc.
+1
I think there are two things that may need an improvement:
1) Storing variable-length data in
On 14.03.24 12:25, Andrey M. Borodin wrote:
I think the behavior of uuid_extract_var(iant) is wrong. The code
takes just two bits to return, but the draft document is quite clear
that the variant is 4 bits (see Table 1).
Well, it was correct only for implemented variant. I've made version that
On Thu, Mar 14, 2024 at 12:48 AM Robert Haas wrote:
> On Fri, Mar 8, 2024 at 12:14 AM Amul Sul wrote:
> > Thank you for the improvement.
> >
> > The caller of verify_control_file() has the full path of the control
> file that
> > can pass it and avoid recomputing. With this change, it doesn't
On Sun, Mar 3, 2024 at 5:37 PM Erik Wienhold wrote:
> On 2024-03-03 03:00 +0100, Steve Chavez wrote:
> > psql has the :{?name} syntax for testing a psql variable existence.
> >
> > But currently doing \echo :{?VERB doesn't trigger tab completion.
> >
> > This patch fixes it. I've also included a
On Thu, 14 Mar 2024 at 15:49, Amit Kapila wrote:
>
> On Thu, Mar 14, 2024 at 1:45 PM Masahiko Sawada wrote:
> >
> > On Thu, Mar 14, 2024 at 2:27 PM Amit Kapila wrote:
> > >
> > > On Thu, Mar 14, 2024 at 5:57 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > This fact makes me think that the
On 3/14/24 11:13, Peter Eisentraut wrote:
> On 12.03.24 14:32, Tomas Vondra wrote:
>> On 3/12/24 13:47, Peter Eisentraut wrote:
>>> On 06.03.24 22:34, Tomas Vondra wrote:
0001
1) I think this bit in ALTER STATISTICS docs is wrong:
- >>>
On 14.03.24 09:08, Jeff Davis wrote:
0001 (the C.UTF-8 locale) is also close. Considering that most of the
infrastructure is already in place, that's not a large patch. You many
have some comments about the way I'm canonicalizing and validating in
initdb -- that could be cleaner, but it feels
On Mon, Mar 4, 2024 at 7:50 AM Peter Eisentraut wrote:
> Looking at this again, if we don't want the .xml files in the tree, then
> we don't really need this patch series.
Based on this, I've updated the status of this patch in the CommitFest
application to Withdrawn. If that's not correct,
On Wed, Feb 7, 2024 at 7:55 PM Noah Misch wrote:
> > So my suggestion is for people to respond with -1, -0.5, +-0, +0.5, or
> > +1 to indicate support against/for the change.
>
> I'm +1 for the change, for these reasons:
>
> - Fewer back-patch merge conflicts. The decls section of long functions
On 14.03.24 15:03, Alvaro Herrera wrote:
On 2024-Mar-14, Peter Eisentraut wrote:
Perhaps it would make sense if we change the ALTER TABLE command to be like
ALTER TABLE t1 ADD IF NOT EXISTS NOT NULL c1
Then the behavior is like one would expect.
For ALTER TABLE, we would reject this
On Thu, Mar 14, 2024 at 12:24 PM Amit Kapila wrote:
>
> On Wed, Mar 13, 2024 at 9:24 PM Bharath Rupireddy
> >
> > Yes, there will be some sort of duplicity if we emit conflict_reason
> > as a text field. However, I still think the better way is to turn
> > conflict_reason text to conflict boolean
On Wed, Oct 4, 2023 at 9:12 PM James Coleman wrote:
> All right, attached is a v3 which attempts to fix the wrong
> information with an economy of words. I may at some point submit a
> separate patch that adds a broader pruning section, but this at least
> brings the docs inline with reality
On 2024-Mar-14, Shlok Kyal wrote:
> Andrew Atkinson wrote:
>
> > Anyway, hopefully these examples show “node” and “database” are
> > mixed and perhaps others agree using one consistently might help the
> > goals of the docs.
>
> For me the existing content looks good, I felt let's keep it as it
On 3/13/24 23:38, Thomas Munro wrote:
> On Sun, Mar 3, 2024 at 11:41 AM Tomas Vondra
> wrote:
>> On 3/2/24 23:28, Melanie Plageman wrote:
>>> On Sat, Mar 2, 2024 at 10:05 AM Tomas Vondra
>>> wrote:
With the current "master" code, eic=1 means we'll issue a prefetch for B
and then
On Wed, Mar 13, 2024 at 3:05 PM Laurenz Albe wrote:
> I think we are pretty conservative with backpatching changes to the
> optimizer that could destabilize existing plans.
We have gotten better about that, which is good.
> I feel quite strongly that we should not use overly conservative
On 2024-Mar-13, Dean Rasheed wrote:
> On Wed, 13 Mar 2024 at 06:44, jian he wrote:
> >
> >
> > [ WITH with_query [, ...] ]
> > MERGE INTO [ ONLY ] >
> > here the "WITH" part should have "[ RECURSIVE ]"
>
> Actually, no. MERGE doesn't support WITH RECURSIVE.
>
> It's not entirely clear to me
On 2024-Mar-14, Peter Eisentraut wrote:
> Perhaps it would make sense if we change the ALTER TABLE command to be like
>
> ALTER TABLE t1 ADD IF NOT EXISTS NOT NULL c1
>
> Then the behavior is like one would expect.
>
> For ALTER TABLE, we would reject this command if IF NOT EXISTS is not
>
On Thursday, March 14, 2024, Étienne BERSAC
wrote:
>
> However, I'd prefer if Postgres fails properly. Because the GRANT is
> actually not revoked. This prevent ldap2pg to report an issue in
> handling privileges on such roles.
>
> What do you think of make this warning an error ?
>
>
The choice
On 14/03/2024 12:55, Dilip Kumar wrote:
On Thu, Mar 14, 2024 at 4:07 PM Heikki Linnakangas wrote:
_SPI_execute_plan() has code to deal with the possibility that the
active snapshot is not set. That seems fishy; do we really support SPI
without any snapshot? I'm inclined to turn that into an
One thing that first pops out to me is that we can do the refactor of
hash_initial_lookup() as an independent piece, without the extra paths
introduced. But rather than returning the bucket hash and have the
bucket number as an in/out argument of hash_initial_lookup(), there is
an argument for
On Thu, Mar 14, 2024 at 8:21 AM Daniel Gustafsson wrote:
>
> > On 14 Mar 2024, at 02:47, Robert Treat wrote:
>
> > I was taking a look at the login event triggers work (nice work btw)
>
> Thanks for reviewing committed code, that's something which doesn't happen
> often enough and is much
1 - 100 of 149 matches
Mail list logo
