On 14.03.24 02:33, Andreas Karlsson wrote:
On 3/13/24 12:41 PM, Andreas Karlsson wrote:
On 2/8/24 8:58 AM, Peter Eisentraut wrote:
I think keeping the two build systems aligned this way will be useful
for longer-term maintenance.
Agreed, so started reviewing the patch. Attached is a rebased
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 backup_label must have been found
> at
On Wed, Mar 13, 2024 at 04:40:38PM +0300, Teodor Sigaev wrote:
> Done, all patches should be applied consequentially.
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
On Wed, Mar 13, 2024 at 11:20:16AM -0700, Jacob Champion wrote:
> Sounds good, split into v2-0002. (That gives me room to switch other
> call sites to the new API, too.) Thanks both!
That looks OK to me. I can see 7~8 remaining sites where StringInfo
data is freed, like in the syslogger, but we
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 slotsync worker might be able to
> > accept the primary_conninfo value even if there is no dbname in the
> > value. That is, if there is no
> On 14 Mar 2024, at 07:02, Tatsuro Yamada wrote:
> So, I created a patch to fix them.
Thanks, applied.
--
Daniel Gustafsson
On Wed, 13 Mar 2024 at 20:08, Jacob Champion
wrote:
> I hit this on my machine. With the attached diff I can reproduce
> constantly (including with the most recent test patch); I think the
> cancel must be arriving between the bind/execute steps?
Nice find! Your explanation makes total sense.
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 slotsync worker might be able to
> > > accept the primary_conninfo
On Thu, Mar 14, 2024 at 4:07 PM Heikki Linnakangas wrote:
>
> > Yeah, that's a very valid point. So I think now Heikki/Melanie might
> > have got an answer to their question, about the thought process behind
> > serializing the snapshot for each scan node. And the same thing is
> > followed for
one more question...
SELECT JSON_value(NULL::int, '$' returning int);
ERROR: cannot use non-string types with implicit FORMAT JSON clause
LINE 1: SELECT JSON_value(NULL::int, '$' returning int);
^
SELECT JSON_query(NULL::int, '$' returning int);
ERROR: cannot use
On 14/03/2024 07:05, Evgeny Smirnov wrote:
The question (a short version): is it possible for a client to send two
selects in the same transaction using the extended query protocol
(without declaring cursors) and pull rows simultaneously by means of
interleaving portal names and restricting
On Wed, Mar 13, 2024 at 10:16 PM Bharath Rupireddy
wrote:
>
> On Wed, Mar 13, 2024 at 11:13 AM shveta malik wrote:
> >
> > > Thanks. v8-0001 is how it looks. Please see the v8 patch set with this
> > > change.
> >
> > JFYI, the patch does not apply to the head. There is a conflict in
> >
On Thu, Mar 14, 2024 at 10:57 AM Amit Kapila wrote:
>
> On Thu, Mar 14, 2024 at 5:57 AM Masahiko Sawada wrote:
> >
> > This fact makes me think that the slotsync worker might be able to
> > accept the primary_conninfo value even if there is no dbname in the
> > value. That is, if there is no
On Wed, Mar 13, 2024 at 02:33:52PM +0100, Peter Eisentraut wrote:
> The 0002 patch looks sensible. It would be good to fix that, otherwise it
> could have some confusing outcomes in the future.
You mean if we begin to use %m in future callers of
emit_tap_output_v(), hypothetically? That's a
> On 11 Mar 2024, at 09:23, Anthonin Bonnefoy
> wrote:
> pg_regress accepts the expecteddir argument. However, it is never used
> and outputdir is used instead to get the expected files paths.
Nice catch, c855872074b5bf44ecea033674d22fac831cfc31 added --expecteddir
support to pg_regress but
On Wed, Mar 13, 2024 at 9:24 PM Bharath Rupireddy
wrote:
>
> On Wed, Mar 13, 2024 at 9:21 AM Amit Kapila wrote:
> >
> > > So, how about we turn conflict_reason to only report the reasons that
> > > actually cause conflict with recovery for logical slots, something
> > > like below, and then have
On 14.03.2024 03:19, Alexander Korotkov wrote:
Pushed.
Thanks!
--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Mon, Mar 4, 2024 at 9:15 PM Bharath Rupireddy
wrote:
>
> > 0003:
> >
> > * We need to maintain the invariant that Copy >= Write >= Flush. I
> > believe that's always satisfied, because the
> > XLogWaitInsertionsToFinish() is always called before XLogWrite(). But
> > we should add an assert or
On Wed, Mar 13, 2024 at 2:16 PM Andrei Lepikhov
wrote:
> On 13/3/2024 18:05, Alexander Korotkov wrote:
> > On Wed, Mar 13, 2024 at 7:52 AM Andrei Lepikhov
> > Given all of the above, I think moving transformation to the
> > canonicalize_qual() would be the right way to go.
> Ok, I will try to
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 test_lookup_tids() to be more
> > general and put the validation down into C as well. First we save the
> > blocks from do_set_block_offsets()
On 14/3/2024 16:31, Alexander Korotkov wrote:
On Wed, Mar 13, 2024 at 2:16 PM Andrei Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
> On 13/3/2024 18:05, Alexander Korotkov wrote:
> > On Wed, Mar 13, 2024 at 7:52 AM Andrei Lepikhov
> > Given all of the above, I think moving
> On 14 Mar 2024, at 09:06, Michael Paquier wrote:
> I think that it is cleaner to create the new API first, and then
> rely on it, reversing the order of both patches
I agree with this ordering.
> (perhaps the extra destroyStringInfo in freeJsonLexContext() should
> have been moved in 0001).
On Thu, 14 Mar 2024 at 18:23, Ashutosh Bapat
wrote:
> I don't understand why root->query_pathkeys has both a and b. "a" is there
> because of GROUP BY and ORDER BY clause. But why "b"?
So that the ORDER BY aggregate function can be evaluated without
nodeAgg.c having to perform the sort. See
On 2024-Mar-14, Jelte Fennema-Nio wrote:
> On Wed, 13 Mar 2024 at 20:08, Jacob Champion
> wrote:
> > I hit this on my machine. With the attached diff I can reproduce
> > constantly (including with the most recent test patch); I think the
> > cancel must be arriving between the bind/execute
On Thu, Mar 14, 2024 at 12:11 PM Andrei Lepikhov
wrote:
>
> On 14/3/2024 16:31, Alexander Korotkov wrote:
> > On Wed, Mar 13, 2024 at 2:16 PM Andrei Lepikhov
> > mailto:a.lepik...@postgrespro.ru>> wrote:
> > > On 13/3/2024 18:05, Alexander Korotkov wrote:
> > > > On Wed, Mar 13, 2024 at 7:52 AM
Hi,
The synopsis of pg_md5_hash() seems wrong such as:
- s/int/bool/
- "errstr" is missing
So, I created a patch to fix them.
src/common/md5_common.c
==
* SYNOPSIS #include "md5.h"
*int pg_md5_hash(const void *buff,
On 14.03.24 09:08, Jeff Davis wrote:
On Wed, 2024-03-13 at 00:44 -0700, Jeff Davis wrote:
New series attached. I plan to commit 0001 very soon.
Committed the basic builtin provider, supporting only the "C" locale.
As you were committing this, I had another review of
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:
- new_target
+ SET STATISTICS { integer | DEFAULT }
because it means we now have list entries
On 14/03/2024 06:54, Dilip Kumar wrote:
On Wed, Mar 13, 2024 at 9:25 PM Robert Haas wrote:
On Wed, Mar 13, 2024 at 11:39 AM Dilip Kumar wrote:
Andres already commented on the snapshot stuff on an earlier patch
version, and that's much nicer with this version. However, I don't
understand why
Hi Andrew,
> If there's a movement towards "node" to refer to the database which has the
> Subscription object, then perhaps the documentation for
>
> 31.2. Subscription, Chapter 31. Logical Replication should be updated as
> well, since it uses both the "database" and "node" terms on the same
Michael Paquier writes:
> On Wed, Mar 13, 2024 at 02:33:52PM +0100, Peter Eisentraut wrote:
>> The 0002 patch looks sensible. It would be good to fix that, otherwise it
>> could have some confusing outcomes in the future.
>
> You mean if we begin to use %m in future callers of
>
Hi,
Since ldap2pg 6, I'm working on running by default as non-super role
with CREATEDB. Robert Haas made this a viable solution as of Postgres
16.
I got a case where ldap2pg tries to remove a role from a group. But
ldap2pg user is not the grantor of this membership. This triggers a
warning:
$
On 12.02.24 11:24, Alvaro Herrera wrote:
On 2024-Feb-11, Peter Eisentraut wrote:
But I see that table constraints do not work that way. A command like ALTER
TABLE t1 ADD NOT NULL c1 does nothing if the column already has a NOT NULL
constraint. I'm not sure this is correct. At least it's not
On Tue, Mar 12, 2024 at 9:33 AM Robert Haas wrote:
> On Mon, Mar 11, 2024 at 11:11 PM Jingxian Li wrote:
> > Your version changes less code than mine by pushing the nowait flag down
> > into ProcSleep(). This looks fine in general, except for a little advice,
> > which I don't think there is
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 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-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 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 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 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 Thu, 14 Mar 2024 at 11:33, Alvaro Herrera wrote:
> Hmm, isn't this basically saying that we're giving up on reliably
> canceling queries altogether? I mean, maybe we'd like to instead fix
> the bug about canceling queries in extended query protocol ...
> Isn't that something you're worried
On Thu, Mar 14, 2024 at 6:37 AM Heikki Linnakangas wrote:
> If es_snapshot was different from the active snapshot, things would get
> weird, even without parallel query. The scans would use es_snapshot for
> the visibility checks, but any functions you execute in quals would use
> the active
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, 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 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 10.03.24 13:59, Andrey M. Borodin wrote:
The functions uuid_extract_ver and uuid_extract_var could be named
uuid_extract_version and uuid_extract_variant. Otherwise, it's hard
to tell them apart, with only one letter different.
Renamed.
Another related comment: Throughout your patch,
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 test_lookup_tids() to be more
> > > general and put the validation down into C
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 Thu, Mar 14, 2024 at 7:22 AM Melih Mutlu wrote:
> 1- Even though I expect both the patch and HEAD behave similarly in case of
> small data (case 1: 100 bytes), the patch runs slightly slower than HEAD.
I wonder why this happens. It seems like maybe something that could be fixed.
--
Robert
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
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 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 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 appreciated.
> and saw a couple of minor items that I thought would be
On Thu, 14 Mar 2024 at 12:22, Melih Mutlu wrote:
> I did some experiments with this patch, after previous discussions
One thing I noticed is that the buffer sizes don't seem to matter much
in your experiments, even though Andres his expectation was that 1400
would be better. I think I know the
> On 14 Mar 2024, at 05:20, Kyotaro Horiguchi wrote:
> I'd be happy if the two messages kept consistency. I suggest aligning
> types instead of making the messages different, as attached.
I've only skimmed this so far but +1 on keeping the messages the same where
possible to reduce translation
On 14/03/2024 13:22, Melih Mutlu wrote:
@@ -1282,14 +1283,32 @@ internal_putbytes(const char *s, size_t len)
if (internal_flush())
return EOF;
}
- amount = PqSendBufferSize - PqSendPointer;
- if
On 14/03/2024 14:34, Robert Haas wrote:
On Thu, Mar 14, 2024 at 6:37 AM Heikki Linnakangas wrote:
If es_snapshot was different from the active snapshot, things would get
weird, even without parallel query. The scans would use es_snapshot for
the visibility checks, but any functions you execute
On 14.03.24 05:20, Kyotaro Horiguchi wrote:
A recent commit 6612185883 introduced two error messages that are
identical in text but differ in their placeholders.
- pg_fatal("could not read file \"%s\": read only %d of %d
bytes",
-
On Thu, 14 Mar 2024 at 13:12, Robert Haas wrote:
>
> On Thu, Mar 14, 2024 at 7:22 AM Melih Mutlu wrote:
> > 1- Even though I expect both the patch and HEAD behave similarly in case of
> > small data (case 1: 100 bytes), the patch runs slightly slower than HEAD.
>
> I wonder why this happens. It
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
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 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 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
Hi hackers,
I did some experiments with this patch, after previous discussions. This
probably does not answer all questions, but would be happy to do more if
needed.
First, I updated the patch according to what suggested here [1]. PSA v2.
I tweaked the master branch a bit to not allow any
> On 14 Mar 2024, at 16:07, Peter Eisentraut wrote:
>
> On 10.03.24 13:59, Andrey M. Borodin wrote:
>>> The functions uuid_extract_ver and uuid_extract_var could be named
>>> uuid_extract_version and uuid_extract_variant. Otherwise, it's hard
>>> to tell them apart, with only one letter
On Thu, Mar 14, 2024 at 9:00 AM Heikki Linnakangas wrote:
> The portal code is pretty explicit about it, the ExecutorRun() call in
> PortalRunSelect() looks like this:
>
> PushActiveSnapshot(queryDesc->snapshot);
> ExecutorRun(queryDesc, direction, (uint64) count,
>
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 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
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
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 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 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 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 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 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 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 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
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 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
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
>
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
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 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 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, 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 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 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
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
> >
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, 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
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 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 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
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
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 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.
> -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
1 - 100 of 149 matches
Mail list logo
