On Sat, 2024-03-30 at 23:33 +0200, Alexander Korotkov wrote:
> I've pushed 0001, 0002 and 0006.
Sorry to jump in to this discussion so late. I had worked on something
like the custom reloptions (0002) in the past, and there were some
complications that don't seem to be addressed in commit
Justin Pryzby writes:
> On Sun, Mar 31, 2024 at 12:00:00PM +0300, Alexander Lakhin wrote:
>> I've stumbled upon a test failure caused by the test query added in that
>> commit:
>> +ERROR: deadlock detected
>> +DETAIL: Process 3076180 waits for AccessShareLock on relation 1259 of
>> database
Hi,
On Tue, Apr 02, 2024 at 04:24:49AM +, Zhijie Hou (Fujitsu) wrote:
> On Monday, April 1, 2024 9:28 PM Bertrand Drouvot
> wrote:
> >
> > On Mon, Apr 01, 2024 at 05:04:53PM +0530, Amit Kapila wrote:
> > > On Mon, Apr 1, 2024 at 2:51 PM Bertrand Drouvot
> >
> > >
> > > > 2 ===
> > > >
> >
"Tharakan, Robins" writes:
>> I've now switched to GCC v13.2 and triggered a run. Let's see if the tests
>> stabilize now.
> So although HEAD ran fine, but I saw multiple failures (v12, v13, v16) all of
> which passed on subsequent-tries,
> of which some were even"signal 6: Aborted".
Ugh...
> I've now switched to GCC v13.2 and triggered a run. Let's see if the tests
> stabilize now.
So although HEAD ran fine, but I saw multiple failures (v12, v13, v16) all of
which passed on subsequent-tries,
of which some were even"signal 6: Aborted".
FWIW, I compiled gcc v13.2 (default options)
On Mon, Apr 1, 2024 at 5:05 PM Amit Kapila wrote:
>
> > 2 ===
> >
> > + {
> > + if (SnapBuildSnapshotExists(remote_slot->restart_lsn))
> > + {
> >
> > That could call SnapBuildSnapshotExists() multiple times for the same
> > "restart_lsn" (for example in case of
On Tuesday, April 2, 2024 8:43 AM Bharath Rupireddy
wrote:
>
> 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
On Mon, Apr 1, 2024 at 6:58 PM Bertrand Drouvot
wrote:
>
> 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
Alexander Korotkov writes:
Hello,
>
> Did you forget to attach the new patch?
>
> Yes, here it is.
>
> --
> Regards,
> Alexander Korotkov
>
> [4. text/x-diff;
> v17-0001-Implement-pg_wal_replay_wait-stored-procedure.patch]...
+
+pg_wal_replay_wait (
+
On Tue, Mar 5, 2024 at 5:30 PM John Naylor wrote:
>
> On Tue, Jan 30, 2024 at 5:04 PM John Naylor wrote:
> >
> > On Tue, Jan 30, 2024 at 4:13 AM Ants Aasma wrote:
> > > But given that we know the data length and we have it in a register
> > > already, it's easy enough to just mask out data past
On Mon, Apr 1, 2024 at 12:18 PM 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 is
On 15/10/2023 13:25, Alexander Korotkov wrote:
Great! I'm looking forward to the revised patch.
Revising the code and opinions before restarting this work, I found two
different possible strategies mentioned in the thread:
1. 'Common Resources' shares the materialised result of the inner table
> ... 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)
>
> From some quick checking around, that would have to be near the beginning of
> aarch64
> support in RHEL (Fedora hadn't
On Tue, 02 Apr 2024 at 07:59, Alexander Korotkov wrote:
> 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)
>>
On Mon, Apr 1, 2024 at 10:03 AM Masahiko Sawada wrote:
>
> On Sat, Mar 30, 2024 at 11:05 PM Bharath Rupireddy
> wrote:
> >
> > On Thu, Mar 28, 2024 at 6:31 PM Masahiko Sawada
> > wrote:
> > >
> > > That is,
> > > since the LOG_VERBOSITY option is an enum parameter, it might make
> > > more
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
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,
>
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
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
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
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
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
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
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
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
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 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
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, 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.
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
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
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
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 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
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
> 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
>
> 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
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
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
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
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
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
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
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
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
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
>
>
> 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
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,
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
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
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
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
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
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
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
>
> 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
>
> I think pg_upgrade could check for the existence of extended statistics
> in any database and adjust the analyze recommdnation wording
> accordingly.
>
+1
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
>
> 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
>
> >
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
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
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
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"
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.
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
"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
> 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
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"
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, 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
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
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
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
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
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
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.
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
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
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 *
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(,
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
> >
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
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
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, 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
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
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:
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:
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
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 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
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 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
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
> >
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
correction: so now code is not broken
>
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
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,
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, 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
1 - 100 of 122 matches
Mail list logo
