On Wed, Apr 3, 2024 at 9:57 PM Bertrand Drouvot
wrote:
>
> > > shouldn't the slot be dropped/recreated instead of updating
> > > inactive_since?
> >
> > The sync slots that are invalidated on the primary aren't dropped and
> > recreated on the standby.
>
> Yeah, right (I was confused with synced
On Fri, Apr 5, 2024 at 9:56 AM Michael Paquier wrote:
>
> On Wed, Feb 07, 2024 at 06:42:21PM +0900, Michael Paquier wrote:
> > On Wed, Feb 07, 2024 at 02:08:42PM +0530, Amit Kapila wrote:
> > > Thanks for the report and looking into it. Pushed!
> >
> > Thanks Amit for the commit and Kuroda-san
On Fri, Apr 05, 2024 at 12:03:05AM +, Leung, Anthony wrote:
> Adding tap test for pg_signal_autovacuum using injection points as a
> separate patch. I also made a minor change on the original patch.
+ ret = pgstat_get_beentry_by_proc_number(procNumber);
+
+ if (!ret)
+
> On 5 Apr 2024, at 05:03, Leung, Anthony wrote:
>
> Adding tap test for pg_signal_autovacuum using injection points as a separate
> patch. I also made a minor change on the original patch.
The test looks good, but:
1. remove references to passcheck :)
2. detach injection point when it's
On Thu, Apr 4, 2024 at 5:17 PM Amit Kapila wrote:
>
> On Thu, Apr 4, 2024 at 5:05 PM shveta malik wrote:
> >
> > Hello hackers,
> >
> > Currently, promotion related handling is missing in the slot sync SQL
> > function pg_sync_replication_slots(). Here is the background on how
> > it is done
Hi,
On Fri, Apr 05, 2024 at 09:43:35AM +0530, shveta malik wrote:
> On Fri, Apr 5, 2024 at 9:22 AM Bertrand Drouvot
> wrote:
> >
> > Hi,
> >
> > On Thu, Apr 04, 2024 at 05:31:45PM +0530, shveta malik wrote:
> > > On Thu, Apr 4, 2024 at 2:59 PM shveta malik
> > > wrote:
> > 2 ===
> >
> > +
Ashutosh Bapat writes:
> I read that discussion, and it may be ok for pg_upgrade/pg_dump usecase and
> maybe also for IMPORT foreign schema where the SQL is generated by
> PostgreSQL itself. But not for simulating statistics. In that case, if the
> function happily installs statistics cooked by
On Fri, Apr 5, 2024 at 4:21 AM Jeff Davis wrote:
>
> > 4. If we're not modifying any callers of WALReadFromBuffers(), then
> > AFAICS the added check that the request is not past the Copy pointer
> > is
> > useless. In a quick look at that code, I think we only try to read
> > data
> > that's
On Wed, Feb 07, 2024 at 06:42:21PM +0900, Michael Paquier wrote:
> On Wed, Feb 07, 2024 at 02:08:42PM +0530, Amit Kapila wrote:
> > Thanks for the report and looking into it. Pushed!
>
> Thanks Amit for the commit and Kuroda-san for the patch!
I have been pinged about this thread and I should
On Fri, Apr 5, 2024 at 7:00 AM Corey Huinker
wrote:
> For a partitioned table this value has to be true. For a normal table when
>> setting this value to true, it should at least make sure that the table has
>> at least one child. Otherwise it should throw an error. Blindly accepting
>> the
Here is an updated patch set. IMHO this is in decent shape and is
approaching committable.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From df59d3e78604e4530f5096bafc08ac94e13d82d2 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 27 Mar 2024 16:39:24 -0500
Subject:
Erik Wienhold writes:
> Libedit 20191025-3.1 is the first version where ":{?VERB" works as
> expected. The previous release 20190324-3.1 still produces the escaped
> output that Michael found. That narrows down the changes to everything
> between [1] (changed on 2019-03-24 but not included in
Yeah, I plead benchmarking myopia, sorry. The fastpath as committed
is only reached when distance goes 2->1, as pg_prewarm does. Oops.
With the attached minor rearrangement, it works fine. I also poked
some more at that memory prefetcher. Here are the numbers I got on a
desktop system (Intel
On Fri, Apr 5, 2024 at 9:22 AM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Thu, Apr 04, 2024 at 05:31:45PM +0530, shveta malik wrote:
> > On Thu, Apr 4, 2024 at 2:59 PM shveta malik wrote:
> > >
> > >
> > > Prior to commit 2ec005b, this check was okay, as we did not expect
> > > restart_lsn of the
On 2024-04-05 05:37 +0200, Tom Lane wrote:
> Erik Wienhold writes:
> > I'm trying to build Postgres with that older libedit version but can't
> > figure out what options to pass to ./configure so that it picks
> > /usr/local/lib/libedit.so instead of /usr/lib/libedit.so. This didn't
> > work:
>
Hi,
On Thu, Apr 04, 2024 at 05:31:45PM +0530, shveta malik wrote:
> On Thu, Apr 4, 2024 at 2:59 PM shveta malik wrote:
> >
> >
> > Prior to commit 2ec005b, this check was okay, as we did not expect
> > restart_lsn of the synced slot to be ahead of remote since we were
> > directly copying the
Erik Wienhold writes:
> I'm trying to build Postgres with that older libedit version but can't
> figure out what options to pass to ./configure so that it picks
> /usr/local/lib/libedit.so instead of /usr/lib/libedit.so. This didn't
> work:
You probably want configure
On 2024-04-05 05:10 +0200, Tom Lane wrote:
> Erik Wienhold writes:
> > It works with the latest libedit 20230828-3.1. Have to check the NetBSD
> > source to find out what changed since 20181209-3.1.
>
> Yeah, the test is passing on mamba which is running the (just
> officially released) NetBSD
Erik Wienhold writes:
> It works with the latest libedit 20230828-3.1. Have to check the NetBSD
> source to find out what changed since 20181209-3.1.
Yeah, the test is passing on mamba which is running the (just
officially released) NetBSD 10.0. I'm not sure whether 10.0
has the "latest"
On Thu, Apr 4, 2024 at 5:53 PM Bharath Rupireddy
wrote:
>
> On Thu, Apr 4, 2024 at 4:35 PM Amit Kapila wrote:
> >
> > > Thanks for the changes. v34-0001 LGTM.
> >
> > I was doing a final review before pushing 0001 and found that
> > 'inactive_since' could be set twice during startup after
On 2024-04-05 04:37 +0200, Michael Paquier wrote:
> On Thu, Apr 04, 2024 at 10:31:24PM -0400, Tom Lane wrote:
> > Michael Paquier writes:
> >> This stuff is actually kind of funny on this host, "\echo :{?VERB\t"
> >> completes to something incorrect, as of:
> >> postgres=# \echo :\{\?VERBOSITY\}
On Thu, Apr 04, 2024 at 10:31:24PM -0400, Tom Lane wrote:
> Michael Paquier writes:
>> This stuff is actually kind of funny on this host, "\echo :{?VERB\t"
>> completes to something incorrect, as of:
>> postgres=# \echo :\{\?VERBOSITY\}
>
> Just to be clear: you see the extra backslashes if you
> > Hi Regina,
> >
> > On 2024-Mar-27, Regina Obe wrote:
> >
> > > The error is
> > >
> > > rm -f '../../src/include/storage/lwlocknames.h'
> > > cp -pR ../../backend/storage/lmgr/lwlocknames.h
> > > '../../src/include/storage/lwlocknames.h'
> > > cp: cannot stat
Michael Paquier writes:
> On Thu, Apr 04, 2024 at 07:09:53PM -0400, Tom Lane wrote:
>> If you have time, that'd be great. What I suspect is that that
>> machine's readline isn't regurgitating the string verbatim but is
>> doing something fancy with backspaces or other control characters.
> I
On Mon, Mar 18, 2024 at 10:04:45AM +0900, Michael Paquier wrote:
> Please find a patch to do exactly that, without touching the backend
> APIs. 0001 adds a new function call injection_points_local() that can
> be added on top of a SQL test to make it concurrent-safe. 0002 is the
> fix for the
On Thu, Apr 04, 2024 at 07:09:53PM -0400, Tom Lane wrote:
> If you have time, that'd be great. What I suspect is that that
> machine's readline isn't regurgitating the string verbatim but is
> doing something fancy with backspaces or other control characters.
> But we need to see what it's
(Adding Mikael Kjellstrom in CC as OpenBSD owner)
On Thu, Apr 04, 2024 at 11:03:35AM -0700, Jacob Champion wrote:
> v3 does that by putting back checks for symbols that aren't part of
> LibreSSL (tested back to 2.7, which is where the 1.1.x APIs started to
> arrive).
From where did you pull the
>
> For a partitioned table this value has to be true. For a normal table when
> setting this value to true, it should at least make sure that the table has
> at least one child. Otherwise it should throw an error. Blindly accepting
> the given value may render the statistics unusable. Prologue of
Looking for an index to support top-n searches, were n has a fixed maximum
Recently, I've been looking at strategies to handle top-n queries in
Postgres. In my current cases, we've got definition tables, and very large
related tables. Here's a stripped-down example, the real tables are much
On Thu, Apr 04, 2024 at 11:56:36AM +, Bertrand Drouvot wrote:
> On Thu, Apr 04, 2024 at 07:14:47PM +0900, Michael Paquier wrote:
>> I'd add a "as -this section- has its own C code", for clarity. This
>> just looked a bit strange here.
>
> Sounds good, done that way in v5 attached.
If
Adding tap test for pg_signal_autovacuum using injection points as a separate
patch. I also made a minor change on the original patch.
Thanks.
--
Anthony
Amazon Web Services: https://aws.amazon.com
v3-0001-Introduce-pg_signal_autovacuum-role-to-signal-autovacuum-worker.patch
Description:
On Fri, 2024-04-05 at 11:22 +1300, Thomas Munro wrote:
> Hi,
>
> +command_ok(
> + [
> + 'initdb', '--no-sync',
> + '--locale-provider=builtin', '-E UTF-8',
> + '--builtin-locale=C.UTF-8', "$tempdir/data8"
> + ],
> + 'locale provider
Michael Paquier writes:
> On Thu, Apr 04, 2024 at 05:24:05PM -0400, Tom Lane wrote:
>> The particular thing that started me down this road was wondering
>> why we are getting no useful failure details from buildfarm member
>> tanager's struggles with the tab-completion test case added by commit
On Thu, Apr 04, 2024 at 05:24:05PM -0400, Tom Lane wrote:
> The particular thing that started me down this road was wondering
> why we are getting no useful failure details from buildfarm member
> tanager's struggles with the tab-completion test case added by commit
> 927332b95 [1].
Also please
On Thu, 2024-04-04 at 19:45 +0200, Alvaro Herrera wrote:
> 1. Using pg_atomic_write_membarrier_u64 is useless and it imposes
> mora
> barriers than we actually need. So I switched back to
> pg_atomic_write_u64 and add one barrier between the two writes. Same
> for reads.
+1.
This looks correct
> Hi Regina,
>
> On 2024-Mar-27, Regina Obe wrote:
>
> > The error is
> >
> > rm -f '../../src/include/storage/lwlocknames.h'
> > cp -pR ../../backend/storage/lmgr/lwlocknames.h
> > '../../src/include/storage/lwlocknames.h'
> > cp: cannot stat '../../backend/storage/lmgr/lwlocknames.h': No such
Building the generated ecpg preproc file can take a long time. You can
check how long using:
ninja -C build src/interfaces/ecpg/preproc/ecpg.p/meson-generated_.._preproc.c.o
This moves that file much closer to the top of our build order, so
building it can be pipelined much better with other
Jelte Fennema-Nio writes:
> Okay turns out even generating them in parallel isn't any faster than
> running that sequentially. I guess it's because of the strong random
> generation being the slow part. Command I used was the following and
> took ~5 seconds on my machine:
> make -C src/test/ssl
Hi,
+command_ok(
+ [
+ 'initdb', '--no-sync',
+ '--locale-provider=builtin', '-E UTF-8',
+ '--builtin-locale=C.UTF-8', "$tempdir/data8"
+ ],
+ 'locale provider builtin with -E UTF-8 --builtin-locale=C.UTF-8');
This Sun animal recently
On Thu, 4 Apr 2024 at 23:52, Jelte Fennema-Nio wrote:
> Fair enough, I guess I'll change my invocation to include the ninja
> "test" target too:
> ninja -C build test install-quiet && meson test -C build
Actually that doesn't do what I want either because that actually runs
the tests too... And
On Thu, 4 Apr 2024 at 23:34, Jacob Champion
wrote:
>
> On Thu, Apr 4, 2024 at 1:42 PM Jelte Fennema-Nio wrote:
> > Maybe that's something worth addressing too. I expected that
> > install/install-quiet was a strict superset of a plain ninja
> > invocation.
>
> Maybe that's the intent, but I hope
> On 4 Apr 2024, at 23:24, Tom Lane wrote:
> A minimum fix that seems to make this work better is as attached,
> but I feel like somebody ought to examine all the IPC::Run::timer
> and IPC::Run::timeout calls and see which ones are mistaken.
> It's a little scary to convert a timeout to a timer
On Thu, 4 Apr 2024 at 23:06, Daniel Gustafsson wrote:
>
> > On 4 Apr 2024, at 23:02, Jelte Fennema-Nio wrote:
>
> > How about we make it meson/make targets, so they are simply cached
> > just like any of our other build artefacts are cached. Then only clean
> > builds are impacted, not every
On Thu, Apr 4, 2024 at 1:42 PM Jelte Fennema-Nio wrote:
> Maybe that's something worth addressing too. I expected that
> install/install-quiet was a strict superset of a plain ninja
> invocation.
Maybe that's the intent, but I hope not, because I don't see any
reason for `ninja install` to worry
Jelte Fennema-Nio writes:
> How about we make it meson/make targets, so they are simply cached
> just like any of our other build artefacts are cached. Then only clean
> builds are impacted, not every test run.
Every buildfarm and CI run is "clean" in those terms.
TIL that IPC::Run::timer is not the same as IPC::Run::timeout.
With a timer object you have to check $timer->is_expired to see
if the timeout has elapsed, but with a timeout object you don't
because it will throw a Perl exception upon timing out, probably
killing your test program.
It appears
Hi,
On Thu, 4 Apr 2024 at 22:21, Heikki Linnakangas wrote:
> You cannot run queries on a Hot Standby server until the standby has
> seen a running-xacts record. Furthermore if the subxids cache had
> overflowed, you also need to wait for those transactions to finish. That
> is usually not a
> On 4 Apr 2024, at 23:02, Jelte Fennema-Nio wrote:
> How about we make it meson/make targets, so they are simply cached
> just like any of our other build artefacts are cached. Then only clean
> builds are impacted, not every test run.
They already are (well, make not meson yet), they're just
On Thu, 4 Apr 2024 at 22:56, Daniel Gustafsson wrote:
>
> > On 4 Apr 2024, at 22:47, Tom Lane wrote:
> >
> > Robert Haas writes:
> >> On Thu, Apr 4, 2024 at 4:25 PM Daniel Gustafsson wrote:
> >>> I don't disagree, like I said that very email: it's non-trivial and I
> >>> wish we
> >>> could
>
> It would be better if we created the required test files as part of the
> test run. (Why not? Too slow?) Alternatively, I have been thinking
> that maybe we could make the output more reproducible by messing with
> whatever random seed OpenSSL uses. Or maybe use a Python library to
>
On Thu, Apr 4, 2024 at 10:56:01PM +0200, Daniel Gustafsson wrote:
> > On 4 Apr 2024, at 22:47, Tom Lane wrote:
> >
> > Robert Haas writes:
> >> On Thu, Apr 4, 2024 at 4:25 PM Daniel Gustafsson wrote:
> >>> I don't disagree, like I said that very email: it's non-trivial and I
> >>> wish we
>
On Fri, Apr 5, 2024 at 4:20 AM Melanie Plageman
wrote:
> So, sequential scan does not have per-buffer data. I did some logging
> and the reason most fully-in-SB sequential scans don't use the fast
> path is because read_stream->pending_read_nblocks is always 0.
Hnghghghgh... right, sorry I
> On 4 Apr 2024, at 22:47, Tom Lane wrote:
>
> Robert Haas writes:
>> On Thu, Apr 4, 2024 at 4:25 PM Daniel Gustafsson wrote:
>>> I don't disagree, like I said that very email: it's non-trivial and I wish
>>> we
>>> could make it better somehow, but I don't hav an abundance of good ideas.
>
On Thu, Apr 4, 2024 at 04:38:10PM -0400, Greg Sabino Mullane wrote:
> On Thu, Apr 4, 2024 at 2:23 PM Bruce Momjian wrote:
> +Such upgrades might require manual changes to complete so always read
> +the release notes first.
>
> Proposal:
> "Such upgrades might require additional steps,
> On 4 Apr 2024, at 22:40, Robert Haas wrote:
>
> On Thu, Apr 4, 2024 at 4:25 PM Daniel Gustafsson wrote:
>> I don't disagree, like I said that very email: it's non-trivial and I wish we
>> could make it better somehow, but I don't hav an abundance of good ideas.
>
> Is the basic issue that we
Robert Haas writes:
> On Thu, Apr 4, 2024 at 4:25 PM Daniel Gustafsson wrote:
>> I don't disagree, like I said that very email: it's non-trivial and I wish we
>> could make it better somehow, but I don't hav an abundance of good ideas.
> Is the basic issue that we can't rely on the necessary
Matthias van de Meent writes:
> On Mon, 25 Mar 2024 at 22:44, Tom Lane wrote:
>> Basically, I'm not happy with consuming the last reasonably-available
>> pattern for a memory context type that has little claim to being the
>> Last Context Type We Will Ever Want. Rather than making a further
>>
On Thu, 4 Apr 2024 at 20:48, Jacob Champion
wrote:
>
> On Thu, Apr 4, 2024 at 11:12 AM Jacob Champion
> wrote:
> > What's in the `...`? I wouldn't expect to find the test binary in your
> > tmp_install.
>
> Oh, I wonder if this is just a build dependency thing? I typically run
> a bare `ninja`
On Thu, Apr 4, 2024 at 4:25 PM Daniel Gustafsson wrote:
> I don't disagree, like I said that very email: it's non-trivial and I wish we
> could make it better somehow, but I don't hav an abundance of good ideas.
Is the basic issue that we can't rely on the necessary toolchain to be
present on
Thanks Jelte and Robert for the extra effort to correct my mistake.
I apologize. Bad copy-paste from a previous revision of the patch at
some point.
--
Tristan Partin
Neon (https://neon.tech)
On Thu, Apr 4, 2024 at 2:23 PM Bruce Momjian wrote:
> -end-of-life (EOL) and no longer supported.
> +after its initial release. After this, a final minor version will be
> released
> +and the software will then be unsupported (end-of-life).
Would be a shame to lose the EOL acronym.
+Such
On Thu, Apr 4, 2024 at 12:27:32PM -0700, David G. Johnston wrote:
> How about this:
> """
> Major versions make complex changes, so the contents of the data directory
> cannot be maintained in a backward compatible way. A dump and restore of the
> databases is required, either done manually or
I made some updates based on the feedbacks in v2. This patch only contains the
code change for allowing the signaling to av worker with pg_signal_autovacuum.
I will send a separate patch for the tap test shortly.
Thanks
--
Anthony Leung
Amazon Web Services: https://aws.amazon.com
On Thu, Apr 4, 2024 at 6:43 AM Jelte Fennema-Nio wrote:
> But I don't agree with this. Having pg_unreachable in places where it
> brings no perf benefit has two main downsides:
>
> 1. It's extra lines of code
> 2. If a programmer/reviewer is not careful about maintaining this
> unreachable
> On 4 Apr 2024, at 21:38, Robert Haas wrote:
> Essentially, your argument is the same as his, namely: hey, don't
> worry, you could totally verify these test files if you wanted to! But
> of course, nobody did, because it was hard, and everybody had better
> things to do with their time. And I
On Thu, Apr 04, 2024 at 03:31:12PM -0400, Andrew Dunstan wrote:
> Does the attached patch fix it for you?
It clears up 2 of the 3 warnings for me:
../postgresql/src/common/jsonapi.c: In function ‘IsValidJsonNumber’:
../postgresql/src/common/jsonapi.c:2018:30: error: ‘dummy_lex.inc_state’ may be
On Mon, 25 Mar 2024 at 22:44, Tom Lane wrote:
>
> David Rowley writes:
> > On Tue, 26 Mar 2024 at 03:53, Tom Lane wrote:
> >> Could we move the knowledge of exactly which context type it is out
> >> of the per-chunk header and keep it in the block header?
>
> > I wasn't 100% clear on your
On Wed, Apr 3, 2024 at 3:42 PM Daniel Gustafsson wrote:
> > So you just have to "trust" that what's there now makes sense.
>
> Not entirely, you can review the input files which are used to generate the
> test data and verify that those make sense..
Yeah, I mean, in theory I suppose that's true,
On 2024-04-04 Th 14:06, Nathan Bossart wrote:
Apologies for piling on, but my compiler (gcc 9.4.0) is unhappy:
../postgresql/src/common/jsonapi.c: In function ‘IsValidJsonNumber’:
../postgresql/src/common/jsonapi.c:2016:30: error: ‘dummy_lex.inc_state’ may be
used uninitialized in this
On Thu, Apr 4, 2024 at 11:06 AM Nathan Bossart wrote:
> ../postgresql/src/common/jsonapi.c: In function ‘IsValidJsonNumber’:
> ../postgresql/src/common/jsonapi.c:2016:30: error: ‘dummy_lex.inc_state’ may
> be used uninitialized in this function [-Werror=maybe-uninitialized]
> 2016 | if
On Thu, Apr 4, 2024 at 11:23 AM Bruce Momjian wrote:
> On Wed, Apr 3, 2024 at 06:01:41PM -0700, David G. Johnston wrote:
> >
> > The PostgreSQL Global Development Group supports a major version for 5
> years
> > -after its initial release. After its five year anniversary, a major
> version
>
Tom Lane:
You'd have to commit a failing patch first to break CI for all other
developers.
No, what I'm more worried about is some change in the environment
causing the build to start failing. When that happens, it'd better
be an environment that many of us are familiar with and can test/fix.
> The point about application_name is a valid one. I guess it's there
> because it's commonly given from the client side rather than being set
>server-side, even though it's still a GUC. Arguably we could remove it
> from \conninfo+, and claim that nothing that shows up in \dconfig should
> also
On 4/4/24 19:38, Robert Haas wrote:
> Hi,
>
> Yesterday, Tomas Vondra reported to me off-list that he was seeing
> what appeared to be data corruption after taking and restoring an
> incremental backup. Overnight, Jakub Wartak further experimented with
> Tomas's test case, did some initial
On Thu, 2024-04-04 at 10:55 -0700, Jeff Davis wrote:
> * Make a proper indexed binary heap API that accepts a hash
> function
> and provides both heap methods and HT methods that operate based on
> values (transaction size and transaction ID, respectively).
> * Get rid of ReorderBuffer->by_txn
On Thu, Apr 4, 2024 at 11:12 AM Jacob Champion
wrote:
> What's in the `...`? I wouldn't expect to find the test binary in your
> tmp_install.
Oh, I wonder if this is just a build dependency thing? I typically run
a bare `ninja` right before testing, because I think most of those
dependencies are
On Wed, Apr 3, 2024 at 06:01:41PM -0700, David G. Johnston wrote:
>
> The PostgreSQL Global Development Group supports a major version for 5 years
> -after its initial release. After its five year anniversary, a major version
> will
> -have one last minor release containing any fixes and will
On Thu, Apr 04, 2024 at 12:30:51AM +, Leung, Anthony wrote:
>> if (pg_stat_is_backend_autovac_worker(proc->backendId) &&
>> !has_privs_of_role(GetUserId(), ROLE_PG_SIGNAL_AUTOVACUUM))
>> return SIGNAL_BACKEND_NOAUTOVACUUM;
>
> I tried to add them above the existing
On Thu, Apr 4, 2024 at 10:17 AM Jelte Fennema-Nio wrote:
> Command 'test_json_parser_incremental' not found in
> /home/jelte/opensource/postgres/build/tmp_install//home/jelte/.pgenv/pgsql-17beta9/bin,
> ...
I can't reproduce this locally...
What's in the `...`? I wouldn't expect to find the
> On 4 Apr 2024, at 18:45, Peter Eisentraut wrote:
>
> On 26.03.24 18:26, Andrey M. Borodin wrote:
>>> Also, you are initializing 4 bits (I think?) to zero to guard against
>>> counter rollovers (so it's really just an 8 bit counter?). But nothing
>>> checks against such rollovers, so I
[ from a week ago ]
Alvaro Herrera writes:
> Hm, indri failed:
> ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Werror=vla -Werror=unguarded-availability-new
> -Wendif-labels -Wmissing-format-attribute -Wcast-function-type
> -Wformat-security
Apologies for piling on, but my compiler (gcc 9.4.0) is unhappy:
../postgresql/src/common/jsonapi.c: In function ‘IsValidJsonNumber’:
../postgresql/src/common/jsonapi.c:2016:30: error: ‘dummy_lex.inc_state’ may be
used uninitialized in this function [-Werror=maybe-uninitialized]
2016 | if
On Wed, Apr 3, 2024 at 3:27 PM Daniel Gustafsson wrote:
> The patch will also need to be adjusted to work with LibreSSL, but I know
> Jacob
> was looking into that so ideally we should have something to review before
> the weekend.
v3 does that by putting back checks for symbols that aren't
On Wed, Apr 3, 2024 at 11:09 PM David Rowley wrote:
> On Thu, 4 Apr 2024 at 10:15, David Rowley wrote:
> > In short, I don't find it strange that disabling one node type results
> > in considering another type that we'd otherwise not consider in cases
> > where we assume that the disabled node
On Thu, 2024-04-04 at 17:28 +0900, Masahiko Sawada wrote:
> > Perhaps it's not worth the effort though, if performance is already
> > good enough?
>
> Yeah, it would be better to measure the overhead first. I'll do that.
I have some further comments and I believe changes are required for
v17.
I've noticed a few things here, v16 attached with some rather largish
changes.
1. Using pg_atomic_write_membarrier_u64 is useless and it imposes mora
barriers than we actually need. So I switched back to
pg_atomic_write_u64 and add one barrier between the two writes. Same
for reads.
2. Using
Hi,
Yesterday, Tomas Vondra reported to me off-list that he was seeing
what appeared to be data corruption after taking and restoring an
incremental backup. Overnight, Jakub Wartak further experimented with
Tomas's test case, did some initial analysis, and made it very easy to
reproduce. I spent
Em qua., 3 de abr. de 2024 às 08:36, Ranier Vilela
escreveu:
>
> Em ter., 2 de abr. de 2024 às 18:13, Tom Lane
> escreveu:
>
>> Ranier Vilela writes:
>> > While I working in [1], Coverity reported some errors:
>> > src/bin/pg_basebackup/pg_createsubscriber.c
>> > CID 1542690: (#1 of 2):
On Thu, Apr 04, 2024 at 04:02:53PM +0300, Ants Aasma wrote:
> Speaking of which, what does bumping up the inlined version threshold
> to 16 do with and without AVX-512 available? Linearly extrapolating
> the 2 and 4 byte numbers it might just come ahead in both cases,
> making the choice easy.
Hi,
Is there any way to add check constraints to a materialized view, or plans
to add this feature in the future?
Attempting to use "ALTER TABLE tablename ADD CHECK(...)" or "ALTER
MATERIALIZED VIEW" result in error:
ERROR: "tablename" is not a table or foreign table
Check constraints are
On Apr 3, 2024, at 12:46 PM, Christoph Berg wrote:
> Thanks for bringing this up, I should have submitted this years ago.
> (The patch is originally from September 2020.)
That’s okay, it’s still 2020 in some ways.
> I designed the patch to require a superuser to set it, so it doesn't
>
On Thu, Apr 04, 2024 at 04:28:58PM +1300, David Rowley wrote:
> On Thu, 4 Apr 2024 at 11:50, Nathan Bossart wrote:
>> If we can verify this approach won't cause segfaults and can stomach the
>> regression between 8 and 16 bytes, I'd happily pivot to this approach so
>> that we can avoid the
On Thu, 4 Apr 2024 at 18:13, Andrew Dunstan wrote:
> Argh. You get out of the habit when you're running with meson :-(
I'm having some issues with meson too actually. "meson test -C build"
is now failing with this for me:
Command 'test_json_parser_incremental' not found in
On 2024-Apr-04, Peter Eisentraut wrote:
> But I don't really see the point of this. The information you are querying
> is already available in various system views. This proposal is just a
> shorthand for a collection of various random things some people like to see.
> Like, by what reason is
Hi,
On 2024-04-04 19:00:00 +0300, Alexander Lakhin wrote:
> 26.03.2024 10:59, Andres Freund wrote:
> > Late, will try to look more in the next few days.
> >
>
> AFAICS, last 027_streaming_regress.pl failures on calliphoridae,
> culicidae, tamandua occurred before 2024-03-27:
>
Hi!
(v29)
I left the command \conninfo in its original form.
I removed the 'Application Name' column from the \conninfo+ command.
Thanks,
Maiquel Grassi.
v29-0001-psql-meta-command-conninfo-plus.patch
Description: v29-0001-psql-meta-command-conninfo-plus.patch
On Thu, 4 Apr 2024 at 14:50, Peter Eisentraut wrote:
> It appears there are several different perspectives about this. My
> intuition was that a protocol version change indicates something that we
> eventually want all client libraries to support. Whereas protocol
> extensions are truly opt-in.
Ugh, I seem to have somehow missed this response completely.
On Thu, 14 Mar 2024 at 21:33, Robert Haas wrote:
> While I think that will be a common
> pattern, I do not think it will be a universal one. I do agree,
> however, that every possible variation of the protocol is either
>
Hi,
On 2024-04-04 22:37:39 +1300, Thomas Munro wrote:
> On Thu, Apr 4, 2024 at 10:31 PM Thomas Munro wrote:
> > Alright what about this?
I think it's probably worth adding a bit more of the commit message to the
function comment. Yes, there's a bit in one of the return branches, but that's
not
On Tue, 2 Apr 2024 at 13:08, Masahiko Sawada wrote:
>
> On Mon, Apr 1, 2024 at 10:41 PM vignesh C wrote:
> >
> > 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:
> > > >
> > >
1 - 100 of 183 matches
Mail list logo
