On 31/3/2024 00:33, Alexander Korotkov wrote:
I think the way forward might be to introduce the new API, which would
isolate executor details from table AM. We may introduce a new data
structure InsertWithArbiterContext which would contain EState and a
set of callbacks which would avoid table AM
Hi,
On Mon, Apr 01, 2024 at 08:47:59AM +0530, Bharath Rupireddy wrote:
> On Fri, Mar 29, 2024 at 9:39 AM Amit Kapila wrote:
> >
> > Commit message states: "why we can't just update inactive_since for
> > synced slots on the standby with the value received from remote slot
> > on the primary. This
Hi,
When attempting to implement a new table access method, I discovered that
relation_copy_for_cluster() has the following declaration:
void(*relation_copy_for_cluster) (Relation NewTable,
Relation OldTable,
On Mon, Apr 1, 2024 at 8:00 AM jian he wrote:
>
> +-- Should fail (JSON arguments are not passed to column paths)
> +SELECT *
> +FROM JSON_TABLE(
> + jsonb '[1,2,3]',
> + '$[*] ? (@ < $x)'
> + PASSING 10 AS x
> + COLUMNS (y text FORMAT JSON PATH '$ ? (@ < $x)')
> + ) jt;
> +ERROR: could not find
On 01/04/2024 09:05, Andrey M. Borodin wrote:
I think it makes sense to close this commitfest only after Feature Freeze on
April 8, 2024 at 0:00 AoE.
What do you think?
+1. IIRC that's how it's been done in last commitfest in previous years too.
--
Heikki Linnakangas
Neon (https://neon.tech)
Hi,
On Mon, Apr 01, 2024 at 06:05:34AM +, Zhijie Hou (Fujitsu) wrote:
> On Monday, April 1, 2024 8:56 AM Zhijie Hou (Fujitsu)
> wrote:
> Attach the V4 patch which includes the optimization to skip the decoding if
> the snapshot at the syncing restart_lsn is already serialized. It can avoid
Hi,
On Sun, Mar 31, 2024 at 10:25:46AM +0530, Bharath Rupireddy wrote:
> On Thu, Mar 28, 2024 at 3:13 PM Bertrand Drouvot
> wrote:
> > I think in this case it should always reflect the value from the primary (so
> > that one can understand why it is invalidated).
>
> I'll come back to this as so
On Mon, Apr 1, 2024 at 5:25 AM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Mon, Apr 1, 2024 at 5:54 AM Alexander Korotkov
> wrote:
> >
> > > 9. To me the following query blocks even though I didn't mention
> timeout.
> > > CALL pg_wal_replay_wait('0/fff');
> >
> >
Did performance test on optimization patch
(v2-0001-optimize-the-slot-advancement.patch). Please find the
results:
Setup:
- One primary node with 100 failover-enabled logical slots
- 20 DBs, each having 5 failover-enabled logical replication slots
- One physical standby node with 'sync_replica
I looked through the repositories of 19 linux distros [1] to see what
kind of patches are applied often. Many of them share the same package
managers / repositories and thus the same patches. I made sure to look
at some smaller, "other" distros as well, to see what kind of problems
appear outsi
Hi,
>From your prior reply:
On Thu, 21 Mar 2024 at 23:44, Wolfgang Walther wrote:
>
> Nazir Bilal Yavuz:
> > 0001 & 0002: Adding code comments to explain why they have fallback
> > could be nice.
> > 0003: Looks good to me.
>
> Added some comments in the attached.
Comments look good, thanks.
O
Hi, Japin!
On Mon, 1 Apr 2024 at 12:15, Japin Li wrote:
>
> Hi,
>
> When attempting to implement a new table access method, I discovered that
> relation_copy_for_cluster() has the following declaration:
>
>
> void(*relation_copy_for_cluster) (Relation NewTable,
>
Hi Corey,
On Mon, Mar 25, 2024 at 3:38 PM Ashutosh Bapat
wrote:
> Hi Corey,
>
>
> On Sat, Mar 23, 2024 at 7:21 AM Corey Huinker
> wrote:
>
>> v12 attached.
>>
>> 0001 -
>>
>>
> Some random comments
>
> +SELECT
> +format('SELECT pg_catalog.pg_set_attribute_stats( '
> +|| 'relati
On Mon, Apr 1, 2024 at 6:26 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Friday, March 29, 2024 2:50 PM Amit Kapila wrote:
> >
>
> >
> >
> > 2.
> > +extern XLogRecPtr pg_logical_replication_slot_advance(XLogRecPtr moveto,
> > + bool *found_consistent_point);
> > +
> >
> > This API looks a bit awkward
Hi Corey,
Some more comments on v15.
+/*
+ * A more encapsulated version of can_modify_relation for when the the
+ * HeapTuple and Form_pg_class are not needed later.
+ */
+static void
+check_relation_permissions(Relation rel)
This function is used exactly at one place, so usually won't make muc
On Mon, Apr 1, 2024 at 2:51 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Mon, Apr 01, 2024 at 06:05:34AM +, Zhijie Hou (Fujitsu) wrote:
> > On Monday, April 1, 2024 8:56 AM Zhijie Hou (Fujitsu)
> > wrote:
> > Attach the V4 patch which includes the optimization to skip the decoding if
> > the sn
On Sat, Mar 9, 2024 at 9:13 AM jian he wrote:
>
> On Sat, Mar 9, 2024 at 2:03 AM Joe Conway wrote:
> >
> > On 3/8/24 12:28, Andrey M. Borodin wrote:
> > > Hello everyone!
> > >
> > > Thanks for working on this, really nice feature!
> > >
> > >> On 9 Jan 2024, at 01:40, Joe Conway wrote:
> > >>
>
On Mon, Mar 25, 2024 at 11:45 PM Tom Lane wrote:
>
> I wrote:
> > I went ahead and committed 0001 after one more round of review
> >
> > statements; my bad). I also added the changes in test_predtest.c from
> > 0002. I attach a rebased version of 0002, as well as 0003 which isn't
> > changed, ma
On Mon, Mar 25, 2024 at 5:53 PM Tom Lane wrote:
>
> James Coleman writes:
> > [ v6 patchset ]
>
> I went ahead and committed 0001 after one more round of review
>
> statements; my bad). I also added the changes in test_predtest.c from
> 0002. I attach a rebased version of 0002, as well as 0003
correction: so now code is not broken
>
On Mon, Apr 1, 2024 at 10:40 AM Amit Kapila wrote:
>
> After this step and before the next, did you ensure that the slot sync
> has synced the latest confirmed_flush/restart LSNs? You can query:
> "select slot_name,restart_lsn, confirmed_flush_lsn from
> pg_replication_slots;" to ensure the same o
Hi,
On Mon, Apr 01, 2024 at 05:04:53PM +0530, Amit Kapila wrote:
> On Mon, Apr 1, 2024 at 2:51 PM Bertrand Drouvot
> wrote:
> > Then there is no need to call WaitForStandbyConfirmation() as it could go
> > until
> > the RecoveryInProgress() in StandbySlotsHaveCaughtup() for nothing (as we
> > a
On Thu, 28 Mar 2024 at 13:05, Masahiko Sawada wrote:
>
> Hi,
>
> Thank you for the patch!
>
> On Mon, Jul 3, 2023 at 12:12 AM vignesh C wrote:
> >
> > Hi,
> >
> > Improved tab completion for "ALTER DEFAULT PRIVILEGE" and "ALTER TABLE":
> > 1) GRANT, REVOKE and FOR USER keyword was not displayed i
Hi hackers,
I'm playing a toy static analysis checker with PostgreSQL and found a
variable is missing volatile qualifier.
Best Regards,
Xing
From 7084055da64d0433b09e50faff630e551c363f27 Mon Sep 17 00:00:00 2001
From: Xing Guo
Date: Mon, 1 Apr 2024 21:39:04 +0800
Subject: [PATCH v1] Add missing
On 2024-Mar-31, Maiquel Grassi wrote:
> Yes Álvaro, I have already appointed you as the patch reviewer.
> It's true, even before publishing it on Commifest, you have
> already provided good ideas and guidance.
Thanks.
> I adjusted the translation syntax for the SSL and GSSAPI columns.
> After yo
On 2024-Mar-31, Nathan Bossart wrote:
> +uint64
> +pg_popcount_avx512(const char *buf, int bytes)
> +{
> + uint64 popcnt;
> + __m512i accum = _mm512_setzero_si512();
> +
> + for (; bytes >= sizeof(__m512i); bytes -= sizeof(__m512i))
> + {
> + const
On Apr 1, 2024, at 06:55, walt...@technowledgy.de wrote:
> Also a configurable directoy to look up extensions, possibly even to be
> changed at run-time like [2]. The patch says this:
>
>> This directory is prepended to paths when loading extensions (control and
>> SQL files), and to the '$libd
I took the liberty of continuing to work on this after chatting with Nathan.
I've attached the updated patch with some improvements.
Thanks.
--
Anthony Leung
Amazon Web Services: https://aws.amazon.com
v1-0001-Introduce-pg_signal_autovacuum-role-to-allow-non-sup.patch
Description: v1-0001
Hi!
(v24)
> I meant those columns to be just examples, but this should be applied to
> all the other columns in the output as well.
Applied the translation to all columns.
Regards,
Maiquel Grassi.
v24-0001-psql-meta-command-conninfo-plus.patch
Description: v24-0001-psql-meta-command-conninfo-
Corey Huinker writes:
>> IIRC, "variadic any" requires having at least one variadic parameter.
>> But that seems fine --- what would be the point, or even the
>> semantics, of calling pg_set_attribute_stats with no data fields?
> If my pg_dump run emitted a bunch of stats that could never be impo
On Mon, Apr 01, 2024 at 01:06:12PM +0200, Alvaro Herrera wrote:
> On 2024-Mar-31, Nathan Bossart wrote:
>> +popcnt = _mm512_reduce_add_epi64(accum);
>> +return popcnt + pg_popcount_fast(buf, bytes);
>
> Hmm, doesn't this arrangement cause an extra function call to
> pg_popcount_fast to be
Xing Guo writes:
> I'm playing a toy static analysis checker with PostgreSQL and found a
> variable is missing volatile qualifier.
Good catch! It looks like the consequences of a failure would be
pretty minimal --- AFAICS, no worse than a possible failure to remove
a refcount on Py_None --- but
On Mon Mar 25, 2024 at 1:44 PM CDT, Robert Haas wrote:
On Fri, Mar 22, 2024 at 4:58 PM Tristan Partin wrote:
> I had a question about parameter naming. Right now I have a mix of
> camel-case and snake-case in the function signature since that is what
> I inherited. Should I change that to be con
On Mon, Apr 01, 2024 at 05:17:51PM +0300, Heikki Linnakangas wrote:
> On 30/03/2024 07:57, Melanie Plageman wrote:
> > On Fri, Mar 29, 2024 at 12:32:21PM -0400, Melanie Plageman wrote:
> > > On Fri, Mar 29, 2024 at 12:00 PM Heikki Linnakangas
> > > wrote:
> > > > Here's another idea: In the first
Laurenz Albe wrote:
> I had a look at patch 0001 (0002 will follow).
Thanks for reviewing this!
I've implemented the suggested doc changes. A patch update
will follow with the next part of the review.
> > --- a/src/interfaces/libpq/fe-exec.c
> > +++ b/src/interfaces/libpq/fe-exec.c
> >
Hello
Yeah, that's what I meant about the translations, thanks.
Two more comments,
- You don't need a two-level conditional here
if (pset.sversion >= 90500)
{
if (pset.sversion < 14)
appendPQExpBuffer(&buf,
Coverity complained about what you did in RelationParseRelOptions
in c95c25f9a:
*** CID 1595992: Null pointer dereferences (FORWARD_NULL)
/srv/coverity/git/pgsql-git/postgresql/src/backend/utils/cache/relcache.c: 499
in RelationParseRelOptions()
493
494 /*
495 * Fe
On Mon, Apr 1, 2024 at 7:36 PM Tom Lane wrote:
>
> Coverity complained about what you did in RelationParseRelOptions
> in c95c25f9a:
>
> *** CID 1595992: Null pointer dereferences (FORWARD_NULL)
> /srv/coverity/git/pgsql-git/postgresql/src/backend/utils/cache/relcache.c:
> 499 in RelationParseR
On Sat, 2024-03-30 at 20:08 -0400, Tom Lane wrote:
> I haven't looked at the details, but I'm really a bit surprised
> by Jeff's assertion that CREATE INDEX destroys statistics on the
> base table. That seems wrong from here, and maybe something we
> could have it not do. (I do realize that it re
Reality check --- are we still targeting this feature for PG 17?
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
Jeff Davis writes:
> On Sat, 2024-03-30 at 20:08 -0400, Tom Lane wrote:
>> I haven't looked at the details, but I'm really a bit surprised
>> by Jeff's assertion that CREATE INDEX destroys statistics on the
>> base table. That seems wrong from here, and maybe something we
>> could have it not do.
On Mon, Apr 01, 2024 at 05:17:51PM +0300, Heikki Linnakangas wrote:
> On 30/03/2024 07:57, Melanie Plageman wrote:
>
> > The final state of the code could definitely use more cleanup. I've been
> > staring at it for awhile, so I could use some thoughts/ideas about what
> > part to focus on improvi
On Sun, Mar 31, 2024 at 02:12:57PM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-03-31 12:18:29 +0200, Michael Banck wrote:
> > If you ask where they are maintained, the answer is here:
> >
> > https://salsa.debian.org/postgresql/postgresql/-/tree/17/debian/patches?ref_type=heads
> >
> > the other
Bruce Momjian writes:
> Reality check --- are we still targeting this feature for PG 17?
I'm not sure. I think if we put our heads down we could finish
the changes I'm suggesting and resolve the other issues this week.
However, it is starting to feel like the sort of large, barely-ready
patch th
On Mon, 2024-04-01 at 13:11 -0400, Bruce Momjian wrote:
> Reality check --- are we still targeting this feature for PG 17?
I see a few useful pieces here:
1. Support import of statistics (i.e.
pg_set_{relation|attribute}_stats()).
2. Support pg_dump of stats
3. Support pg_upgrade with stats
It
On Sun, Mar 31, 2024 at 07:04:47PM -0400, Tom Lane wrote:
> Corey Huinker writes:
> >> I can't quibble with that view of what has priority. I'm just
> >> suggesting that redesigning what pg_upgrade does in this area
> >> should come later than doing something about extended stats.
>
> > I mostly
On 01/04/2024 19:08, Melanie Plageman wrote:
On Mon, Apr 01, 2024 at 05:17:51PM +0300, Heikki Linnakangas wrote:
diff --git a/src/backend/access/heap/pruneheap.c
b/src/backend/access/heap/pruneheap.c
@@ -256,15 +270,16 @@ heap_page_prune(Relation relation, Buffer buffer,
tup.t_tableOid
On Sun, 2024-03-31 at 14:48 -0400, Tom Lane wrote:
> What happens when
> somebody adds a new stakind (and hence new pg_stats column)?
> You could try to add an overloaded pg_set_attribute_stats
> version with more parameters, but I'm pretty sure that would
> lead to "ambiguous function call" failur
> That minor point aside, I disagree with Sami about repeating the docs
> for system_user() here. I would just say "The authentication data
> provided for this connection; see the function system_user() for more
> details."
+1. FWIW; Up the thread [1], I did mention we should link to the function
"Euler Taveira" writes:
> On Wed, Mar 27, 2024, at 8:50 PM, Ranier Vilela wrote:
>> Coverity has some reports in the new code
>> pg_createsubscriber.c
>> I think that Coverity is right.
> It depends on your "right" definition. If your program execution is ephemeral
> and the leak is just before e
Laurenz Albe wrote:
> Here is the code review for patch number 2:
> +static void
> +CloseGOutput(FILE *gfile_fout, bool is_pipe)
>
> It makes sense to factor out this code.
> But shouldn't these functions have a prototype at the beginning of the file?
Looking at the other static functio
Jeff Davis writes:
> On Mon, 2024-04-01 at 13:11 -0400, Bruce Momjian wrote:
>> Reality check --- are we still targeting this feature for PG 17?
> I see a few useful pieces here:
> 1. Support import of statistics (i.e.
> pg_set_{relation|attribute}_stats()).
> 2. Support pg_dump of stats
> 3.
Em seg., 1 de abr. de 2024 às 14:52, Tom Lane escreveu:
> "Euler Taveira" writes:
> > On Wed, Mar 27, 2024, at 8:50 PM, Ranier Vilela wrote:
> >> Coverity has some reports in the new code
> >> pg_createsubscriber.c
> >> I think that Coverity is right.
>
> > It depends on your "right" definition.
Jeff Davis writes:
> On Sun, 2024-03-31 at 14:48 -0400, Tom Lane wrote:
>> What happens when
>> somebody adds a new stakind (and hence new pg_stats column)?
> Why would you need to overload in this case? Wouldn't we just define a
> new function with more optional named parameters?
Ah, yeah, you
On Mon, Apr 01, 2024 at 11:57:07AM -0400, Tom Lane wrote:
> Xing Guo writes:
>> I'm playing a toy static analysis checker with PostgreSQL and found a
>> variable is missing volatile qualifier.
>
> Good catch! It looks like the consequences of a failure would be
> pretty minimal --- AFAICS, no wo
Nathan Bossart writes:
> On Mon, Apr 01, 2024 at 11:57:07AM -0400, Tom Lane wrote:
>> Good catch! It looks like the consequences of a failure would be
>> pretty minimal --- AFAICS, no worse than a possible failure to remove
>> a refcount on Py_None --- but that's still a bug.
> Huh. I seem to h
>
> That's not what I suggested at all. The function parameters would
> be declared anyarray, but the values passed to them would be coerced
> to the correct concrete array types. So as far as the coercion rules
> are concerned this'd be equivalent to the variadic-any approach.
>
+1
>
> > Tha
On Mon, Apr 1, 2024 at 1:37 PM Heikki Linnakangas wrote:
>
> Committed the first of the remaining patches with those changes. And
> also this, which is worth calling out:
>
> > if (prstate.htsv[offnum] == HEAPTUPLE_DEAD)
> > {
> > ItemId i
>
> I think pg_upgrade could check for the existence of extended statistics
> in any database and adjust the analyze recommdnation wording
> accordingly.
>
+1
>
> Ah, yeah, you could change the function to have more parameters,
> given the assumption that all calls will be named-parameter style.
> I still suggest that my proposal is more robust for the case where
> the dump lists parameters that the receiving system doesn't have.
>
So what's the behavio
Bruce Momjian writes:
> I was more asking if users have access to patches so they could recreate
> the build by using the Postgres git tree and supplied OS-specific
> patches.
AFAIK, every open-source distro makes all the pieces needed to
rebuild their packages available to users. It wouldn't be
On Wed, Mar 27, 2024 at 10:08:26AM -0500, Nathan Bossart wrote:
> On Wed, Mar 27, 2024 at 10:54:05AM -0400, Tom Lane wrote:
>> Michael Banck writes:
>>> What is the status of this? In the commitfest, this patch is marked as
>>> "Needs Review" with Nathan as reviewer - Nathan, were you going to tak
Database:
The database name of the connection.
Authenticated User:
The authenticated database user of the connection.
Socket Directory:
The Unix socket directory of the connection. NULL if host or hostaddr are
specified.
Host:
The host name or address of the connection. NULL if a Unix
Corey Huinker writes:
> So what's the behavior when the user fails to supply a parameter that is
> currently NOT NULL checked (example: avg_witdth)? Is that a WARN-and-exit?
I still think that we could just declare the function strict, if we
use the variadic-any approach. Passing a null in any p
Nathan Bossart writes:
> Sorry for taking so long to get back to this one. Overall, I think the
> code is in decent shape.
Thanks for looking at it!
> The one design point that worries me a little is the non-configurability of
> --transaction-size in pg_upgrade. I think it's fine to default it
On Mon, Apr 01, 2024 at 03:28:26PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> The one design point that worries me a little is the non-configurability of
>> --transaction-size in pg_upgrade. I think it's fine to default it to 1,000
>> or something, but given how often I've had to fiddle w
On 2024-03-20 We 12:44, Tom Lane wrote:
David Wheeler complained over in [1] that genbki.pl fails to produce a
useful error message if there's anything wrong in a catalog data file.
He's right about that, but the band-aid patch he proposed doesn't
improve the situation much. The actual problem
Amigos, boa tarde!
(v25)
>if (pset.version >= 14)
> one thing;
>else if (pset.version > 90500)
> second thing;
> else
> third thing;
>
>This also appears where you add the GSSAPI columns; and it's also in the
>final part where you append the FROM clause, thoug
>
>
> I still think that we could just declare the function strict, if we
> use the variadic-any approach. Passing a null in any position is
> indisputable caller error. However, if you're allergic to silently
> doing nothing in such a case, we could have pg_set_attribute_stats
> check each argum
On Wed, Mar 27, 2024 at 08:47:03PM -0400, Melanie Plageman wrote:
> On Fri, Mar 8, 2024 at 4:56 PM Melanie Plageman
> wrote:
> >
> > On Sat, Mar 02, 2024 at 06:07:48PM -0500, Melanie Plageman wrote:
> > > On Wed, Feb 28, 2024 at 12:30 PM Melanie Plageman
> > > wrote:
> > > >
> > > > On Mon, Feb 2
On Mon, Apr 01, 2024 at 02:29:29PM +, Leung, Anthony wrote:
> I've attached the updated patch with some improvements.
Thanks!
+
+ pg_signal_autovacuum
+ Allow terminating backend running autovacuum
+
I think we should be more precise here by calling out the exact type
On Tue, Mar 12, 2024 at 1:32 PM Tom Lane wrote:
> > 1. You stated that it changes lots of plans in the regression tests,
> > but you haven't provided any sort of analysis of why those plans
> > changed. I'm kind of surprised that there would be "tons" of plan
> > changes. You (or someone) should l
On Fri, Mar 29, 2024 at 06:37:24PM -0400, Bruce Momjian wrote:
> You might have seen reports today about a very complex exploit added to
> recent versions of liblzma. Fortunately, it was only enabled two months
> ago and has not been pushed to most stable operating systems like Debian
> and Ubuntu
On Mon, Apr 1, 2024 at 03:17:55PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I was more asking if users have access to patches so they could recreate
> > the build by using the Postgres git tree and supplied OS-specific
> > patches.
>
> AFAIK, every open-source distro makes all the piece
Robert Haas writes:
> One of the things I realized relatively early is that the patch does
> nothing to propagate disable_cost upward through the plan tree.
> ...
> After straining my brain over various plan changes for a long time,
> and hacking on the code somewhat, I realized that just propagat
Bruce Momjian writes:
> On Mon, Apr 1, 2024 at 03:17:55PM -0400, Tom Lane wrote:
>> AFAIK, every open-source distro makes all the pieces needed to
>> rebuild their packages available to users. It wouldn't be much
>> of an open-source situation otherwise. You do have to learn
>> their package bu
Corey Huinker writes:
> Any thoughts about going back to having a return value, a caller could then
> see that the function returned NULL rather than whatever the expected value
> was (example: TRUE)?
If we are envisioning that the function might emit multiple warnings
per call, a useful definiti
On Mon, 1 Apr 2024 at 18:53, Nathan Bossart wrote:
>
> On Mon, Apr 01, 2024 at 01:06:12PM +0200, Alvaro Herrera wrote:
> > On 2024-Mar-31, Nathan Bossart wrote:
> >> +popcnt = _mm512_reduce_add_epi64(accum);
> >> +return popcnt + pg_popcount_fast(buf, bytes);
> >
> > Hmm, doesn't this arra
>
> If we are envisioning that the function might emit multiple warnings
> per call, a useful definition could be to return the number of
> warnings (so zero is good, not-zero is bad). But I'm not sure that's
> really better than a boolean result. pg_dump/pg_restore won't notice
> anyway, but per
> Here I considered your suggestion (Sami and Álvaro's). However, I haven't yet
> added the links for the functions system_user(), current_user(), and
> session_user().
> 'm not sure how to do it. Any suggestion on how to create/add the link?
Here is an example [1] where the session information f
On Tue, Apr 02, 2024 at 12:11:59AM +0300, Ants Aasma wrote:
> What about using the masking capabilities of AVX-512 to handle the
> tail in the same code path? Masked out portions of a load instruction
> will not generate an exception. To allow byte level granularity
> masking, -mavx512bw is needed.
On Tue, Apr 2, 2024 at 8:43 AM Tomas Vondra
wrote:
> And I think he's right, and my tests confirm this. I did a trivial patch
> to align the blocks to 8K boundary, by forcing the header to be a
> multiple of 8K (I think 4K alignment would be enough). See the 0001
> patch that does this.
>
> And if
Corey Huinker writes:
> A boolean is what we had before, I'm quite comfortable with that, and it
> addresses my silent-failure concerns.
WFM.
regards, tom lane
On 01/04/2024 20:22, Melanie Plageman wrote:
From 17e183835a968e81daf7b74a4164b243e2de35aa Mon Sep 17 00:00:00 2001
From: Melanie Plageman
Date: Fri, 29 Mar 2024 19:43:09 -0400
Subject: [PATCH v11 3/7] Introduce PRUNE_DO_* actions
We will eventually take additional actions in heap_page_prune()
On 2024-03-31 Su 17:12, Andres Freund wrote:
Hi,
On 2024-03-31 12:18:29 +0200, Michael Banck wrote:
If you ask where they are maintained, the answer is here:
https://salsa.debian.org/postgresql/postgresql/-/tree/17/debian/patches?ref_type=heads
the other major versions have their own branch
On Thu, Mar 28, 2024 at 3:34 PM Daniel Gustafsson wrote:
> In jsonapi.c, makeJsonLexContextCstringLen initialize a JsonLexContext with
> palloc0 which would need to be ported over to use ALLOC for frontend code.
Seems reasonable (but see below, too).
> On
> that note, the errorhandling in parse_
On Tue, 2 Apr 2024 at 00:31, Nathan Bossart wrote:
>
> On Tue, Apr 02, 2024 at 12:11:59AM +0300, Ants Aasma wrote:
> > What about using the masking capabilities of AVX-512 to handle the
> > tail in the same code path? Masked out portions of a load instruction
> > will not generate an exception. To
Here is a v19 of the patch set. I moved out the refactoring of the
function pointer selection code to 0001. I think this is a good change
independent of $SUBJECT, and I plan to commit this soon. In 0002, I
changed the syslogger.c usage of pg_popcount() to use pg_number_of_ones
instead. This is
On Tue, Apr 02, 2024 at 01:09:57AM +0300, Ants Aasma wrote:
> On Tue, 2 Apr 2024 at 00:31, Nathan Bossart wrote:
>> On Tue, Apr 02, 2024 at 12:11:59AM +0300, Ants Aasma wrote:
>> > What about using the masking capabilities of AVX-512 to handle the
>> > tail in the same code path? Masked out portio
On Wed, Mar 13, 2024 at 02:04:16PM -0400, Robert Treat wrote:
> I tend to agree with Bruce, and major/minor seems to be the more
> common usage within the industry; iirc, debian, ubuntu, gnome, suse,
> and mariadb all use that nomenclature; and ISTR some distro's who
> release packaged versions of
On Fri, 29 Mar 2024 at 08:53, Tom Lane wrote:
> On third thought, I'm not at all convinced that we even want to
> invent this struct as compared to just adding another parameter
> to subquery_planner. The problem with a struct is what happens
> the next time we need to add a parameter? If we add
On Thu, 28 Mar 2024 at 04:34, Regina Obe wrote:
> CREATE TABLE edge_data AS
> SELECT i AS edge_id, i + 1 AS start_node, i + 2 As end_node
> FROM generate_series(1,10) AS i;
>
> WITH edge AS (
> SELECT start_node, end_node
> FROM edge_data
> WHERE edge_id = 1
> )
> SELECT start_no
On Sat, 30 Mar 2024 at 09:17, Tom Lane wrote:
>
> I wrote:
> > I'd not looked closely enough at the previous failure, because
> > now that I have, this is well out in WTFF territory: how can
> > reltuples be greater than zero when relpages is zero? This can't
> > be a state that autovacuum would
A warning was recently[0] introduced into the Meson build:
WARNING: Project targets '>=0.54' but uses feature introduced in '0.55.0':
Passing executable/found program object to script parameter of add_dist_script
There are 3 way to solve the issue that I have laid out in 3 separate
patches tha
On Mon, Apr 1, 2024 at 5:00 PM Tom Lane wrote:
> Very interesting, thanks for the summary. So the fact that
> disable_cost is additive across plan nodes is actually a pretty
> important property of the current setup. I think this is closely
> related to one argument you made against my upthread
On Mon, Apr 1, 2024 at 7:36 PM Tom Lane wrote:
> Coverity complained about what you did in RelationParseRelOptions
> in c95c25f9a:
>
> *** CID 1595992: Null pointer dereferences (FORWARD_NULL)
> /srv/coverity/git/pgsql-git/postgresql/src/backend/utils/cache/relcache.c:
> 499 in RelationParseRel
I noticed that buildfarm member batfish has been complaining like
this for awhile:
hmac_openssl.c:90:1: warning: unused function 'ResourceOwnerRememberHMAC'
[-Wunused-function]
hmac_openssl.c:95:1: warning: unused function 'ResourceOwnerForgetHMAC'
[-Wunused-function]
Looking at the code, this
David Rowley writes:
> On Sat, 30 Mar 2024 at 09:17, Tom Lane wrote:
>> ... in connection with which, I can't help noticing that parula
>> is using a very old compiler:
>> configure: using compiler=gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-17)
>> I wonder why parula is using that when its underlyin
On Monday, April 1, 2024 7:30 PM Amit Kapila wrote:
>
> On Mon, Apr 1, 2024 at 6:26 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Friday, March 29, 2024 2:50 PM Amit Kapila
> wrote:
> > >
> >
> > >
> > >
> > > 2.
> > > +extern XLogRecPtr pg_logical_replication_slot_advance(XLogRecPtr
> moveto,
>
On Mon, Apr 1, 2024 at 11:36 AM Zhijie Hou (Fujitsu)
wrote:
>
> Attach the V4 patch which includes the optimization to skip the decoding if
> the snapshot at the syncing restart_lsn is already serialized. It can avoid
> most
> of the duplicate decoding in my test, and I am doing some more tests l
1 - 100 of 117 matches
Mail list logo
