On Thu, 4 Apr 2024 at 16:45, David Rowley wrote:
> I've pushed the v9-0001 with that rename done.
I've now just pushed the 0002 patch with some revisions:
1. The function declarations you added for heapgettup_advance_block()
and heapgettup_initial_block() didn't match the properties of their
def
Hi,
I encounter a new behaviour in Postgres 16: DROP OWNED BY drops
memberships when dropping grantor of memberhsip. A call on REASSIGN
OWNED BY does not reassign membership from grantor to target owner.
Attached is a script my-reassign.sql which reproduce the behaviour.
Just run it with psql -f
On Thu, 4 Apr 2024, at 03:35, Michael Paquier wrote:
> On Fri, Mar 22, 2024 at 01:58:24PM +, Dagfinn Ilmari Mannsåker wrote:
>> Here's an updated patch that adds such a comment. I'll add it to the
>> commitfest later today unless someone commits it before then.
>
> I see no problem to do that
On Thu, Apr 4, 2024 at 2:41 PM jian he wrote:
>
> On Wed, Apr 3, 2024 at 8:39 PM Amit Langote wrote:
> >
> > Attached updated patches. I have addressed your doc comments on 0001,
> > but not 0002 yet.
> >
>
about v49, 0002.
--tests setup.
drop table if exists s cascade;
create table s(js jsonb)
On Wed, 3 Apr 2024 at 23:50, Tom Lane wrote:
>
> Matthias van de Meent writes:
>> On Tue, 2 Apr 2024 at 17:47, Tom Lane wrote:
>>> IIUC, it's not possible to use the SERIALIZE option when explaining
>>> CREATE TABLE AS, because you can't install the instrumentation tuple
>>> receiver when the In
> On 4 Apr 2024, at 01:24, Michael Paquier wrote:
>
> On Wed, Apr 03, 2024 at 01:38:50PM -0400, Tom Lane wrote:
>> The discussion we had last year concluded that we were OK with
>> dropping 1.0.1 support when RHEL6 goes out of extended support
>> (June 2024 per this thread, I didn't check it). S
> On 4 Apr 2024, at 01:50, Thomas Munro wrote:
> That's a shame. But it sounds like the developer burden isn't so
> different from 1.1.1 to 3.x, so maybe it's not such a big deal from
> our point of view.
It isn't as of now since OpenSSL still supply the deprecated API's we use, but
there is no
On Thu, Apr 4, 2024 at 1:34 PM Bharath Rupireddy
wrote:
>
> On Thu, Apr 4, 2024 at 9:42 AM Masahiko Sawada wrote:
> >
> > @@ -1368,6 +1416,7 @@ ShutDownSlotSync(void)
> > if (SlotSyncCtx->pid == InvalidPid)
> > {
> > SpinLockRelease(&SlotSyncCtx->mutex);
> > + update_synced_
On Thu, Apr 4, 2024 at 3:50 PM jian he wrote:
>
> On Thu, Apr 4, 2024 at 2:41 PM jian he wrote:
> >
> > On Wed, Apr 3, 2024 at 8:39 PM Amit Langote wrote:
> > >
> > > Attached updated patches. I have addressed your doc comments on 0001,
> > > but not 0002 yet.
hi
some doc issue about v49, 0002
On Wed, Apr 3, 2024 at 7:06 PM Amit Kapila wrote:
>
> On Wed, Apr 3, 2024 at 11:13 AM Amit Kapila wrote:
> >
> > On Wed, Apr 3, 2024 at 9:36 AM Bharath Rupireddy
> > wrote:
> >
> > > I quickly looked at v8, and have a nit, rest all looks good.
> > >
> > > +if (DecodingContextReady(ctx) &
On Thu, Apr 4, 2024 at 1:54 PM Jeff Davis wrote:
>
> On Thu, 2024-04-04 at 09:31 +0900, Masahiko Sawada wrote:
> > IIUC, with your suggestion, sift_{up|down} needs to update the
> > heap_index field as well. Does it mean that the caller needs to pass
> > the address of heap_index down to sift_{up|
On Thu, Apr 4, 2024 at 1:32 PM Masahiko Sawada wrote:
>
> On Thu, Apr 4, 2024 at 1:34 PM Bharath Rupireddy
> wrote:
> >
> > On Thu, Apr 4, 2024 at 9:42 AM Masahiko Sawada
> > wrote:
> > >
> > > @@ -1368,6 +1416,7 @@ ShutDownSlotSync(void)
> > > if (SlotSyncCtx->pid == InvalidPid)
> > >
On 2024-Apr-03, Tom Lane wrote:
> On my machine, headerscheck does not like this:
>
> $ src/tools/pginclude/headerscheck --cplusplus
> In file included from /tmp/headerscheck.4gTaW5/test.cpp:3:
> ./src/include/libpq/libpq-be-fe-helpers.h: In function 'char*
> libpqsrv_cancel(PGconn*, TimestampTz
On Thu, 4 Apr 2024 at 10:45, Alvaro Herrera wrote:
> Yeah, this seems to work and I no longer get that complaint from
> headerscheck.
patch LGTM
On Thu, Apr 4, 2024 at 5:36 PM Amit Kapila wrote:
>
> On Thu, Apr 4, 2024 at 1:32 PM Masahiko Sawada wrote:
> >
> > On Thu, Apr 4, 2024 at 1:34 PM Bharath Rupireddy
> > wrote:
> > >
> > > On Thu, Apr 4, 2024 at 9:42 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > @@ -1368,6 +1416,7 @@ ShutDown
> On 4 Apr 2024, at 08:19, Tom Lane wrote:
>
> Over at [1] we have a complaint of postgres_fdw failing with
> a remote-server error
>
>> ERROR: invalid value for parameter "TimeZone": "UTC"
>
> I am not quite clear on how broken an installation needs to be to
> reject "UTC" as a time zone sett
On Fri, Mar 22, 2024 at 9:09 PM Etsuro Fujita wrote:
> On Fri, Mar 22, 2024 at 7:23 PM Alexander Pyhalov
> wrote:
> > The updated patch still looks good to me.
>
> I am planning to apply the patch to the back branches next week.
Pushed. Sorry for the delay.
Best regards,
Etsuro Fujita
On 26.03.24 12:53, Svetlana Derevyanko wrote:
Peter Eisentraut писал(а) 2024-03-25 17:10:
But MXOFF_SIZE doesn't exist anywhere else. The actual formula uses
sizeof(MultiXactOffset), which isn't obvious from your patch. So this
just moves the magic constants around by one level.
I think if
On Fri, Mar 22, 2024 at 9:30 PM Etsuro Fujita wrote:
> If there are no objections, I will apply the patch to HEAD only.
Done.
Best regards,
Etsuro Fujita
Hi,
On Thu, Apr 04, 2024 at 03:50:21PM +0900, Michael Paquier wrote:
> On Tue, Mar 19, 2024 at 07:34:09AM +, Bertrand Drouvot wrote:
> > I'm not sure as v2 used the "version >= 17" wording which I think would not
> > need
> > manual refresh each time a new stable branch is forked.
> >
> > Bu
On Wed, Apr 3, 2024 at 3:36 PM Amit Kapila wrote:
>
> On Wed, Apr 3, 2024 at 11:13 AM Amit Kapila wrote:
> >
> > On Wed, Apr 3, 2024 at 9:36 AM Bharath Rupireddy
> > wrote:
> >
> > > I quickly looked at v8, and have a nit, rest all looks good.
> > >
> > > +if (DecodingContextReady(ctx) &
On Thu, Apr 4, 2024 at 11:13 AM Andres Freund wrote:
> The / 2 is to avoid causing unnecessarily frequent WAL flushes, right? If so,
> should we apply that only if the ring the strategy doesn't use the
> StrategyRejectBuffer() logic?
Hmm, I don't really know, but that sounds plausible. What do y
On 02.04.24 01:46, Tristan Partin wrote:
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 tha
On Thu, Apr 4, 2024 at 1:55 PM Masahiko Sawada wrote:
>
> While testing this change, I realized that it could happen that the
> server logs are flooded with the following logical decoding logs that
> are written every 200 ms:
>
> 2024-04-04 16:15:19.270 JST [3838739] LOG: starting logical decodin
On Thu, Apr 4, 2024 at 10:31 PM Thomas Munro wrote:
> Alright what about this?
Forgot to git add a change, new version.
From 6dea2983abf8d608c34e02351d70694de99f25f2 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Thu, 4 Apr 2024 20:31:26 +1300
Subject: [PATCH v2 1/2] Allow BufferAccessStrateg
Hi apologies for the late reply.
> Maybe you forgot to recompile/reinstall after updating past that commit?
I did recompile it earlier but just to be sure I followed the steps again
and now its working!
Regards,
Akshat Jaimini
On Wed, Apr 3, 2024 at 12:34 AM Tom Lane wrote:
> Akshat Jaimini wr
On Thu, Apr 04, 2024 at 09:28:36AM +, Bertrand Drouvot wrote:
> On Thu, Apr 04, 2024 at 03:50:21PM +0900, Michael Paquier wrote:
>> Is "Backpatch" the best choice we have, though? It speaks by itself
>> but I was thinking about something different, like "Stable". Other
>> ideas or objections
On Thu, Apr 4, 2024 at 12:56 AM Tomas Vondra
wrote:
>
> Hi,
>
> Here's a much more polished and cleaned up version of the patches,
> fixing all the issues I've been aware of, and with various parts merged
> into much more cohesive parts (instead of keeping them separate to make
> the changes/evolu
On Wed, 3 Apr 2024 at 21:49, Robert Haas wrote:
> It seems to me that 0001 should either remove the pg_unreachable()
> call or change the break to a return, but not both.
Updated the patch to only remove the pg_unreachable call (and keep the breaks).
> but there's not much value in omitting
> pg
On 4/4/24 12:25, Jakub Wartak wrote:
> On Thu, Apr 4, 2024 at 12:56 AM Tomas Vondra
> wrote:
>>
>> Hi,
>>
>> Here's a much more polished and cleaned up version of the patches,
>> fixing all the issues I've been aware of, and with various parts merged
>> into much more cohesive parts (instead of ke
On 2024-04-02 Tu 17:12, Andrew Dunstan wrote:
On 2024-04-02 Tu 15:38, Jacob Champion wrote:
On Mon, Apr 1, 2024 at 4:53 PM Andrew Dunstan
wrote:
Anyway, here are new patches. I've rolled the new semantic test into
the
first patch.
Looks good! I've marked RfC.
Thanks! I appreciate all t
Hi,
On Wed, 3 Apr 2024 at 23:44, Melanie Plageman wrote:
>
>
> I've reviewed the patches inline below and attached a patch that has
> some of my ideas on top of your patch.
Thank you!
>
> > From 8d396a42186325f920d5a05e7092d8e1b66f3cdf Mon Sep 17 00:00:00 2001
> > From: Nazir Bilal Yavuz
> > D
On Thu, Apr 4, 2024 at 11:12 AM Bharath Rupireddy
wrote:
>
> On Thu, Apr 4, 2024 at 10:48 AM Amit Kapila wrote:
> >
> > The v33-0001 looks good to me. I have made minor changes in the
> > comments/commit message and removed one part of the test which was a
> > bit confusing and didn't seem to add
On Thu, 28 Mar 2024, 13:37 Heikki Linnakangas, wrote:
>
> On 28/03/2024 13:15, Matthias van de Meent wrote:
> > On Tue, 5 Mar 2024 at 15:08, Heikki Linnakangas wrote:
> >>
> >> I hope I didn't joggle your elbow reviewing this, Jacob, but I spent
> >> some time rebase and fix various little things
Hi,
Melih Mutlu , 28 Mar 2024 Per, 22:44 tarihinde şunu
yazdı:
>
> On Wed, Mar 27, 2024 at 14:39 David Rowley wrote:
>>
>> On Fri, 22 Mar 2024 at 12:46, Melih Mutlu wrote:
>> can you confirm if the test was done in debug with casserts on? If
>> so, it would be much better to have asserts off a
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 in slot sync worker:
During promotion, the startup process in order to shut down the
slot-sync worker, sets the 'stopSignaled' flag,
On Thu, Apr 4, 2024 at 8:02 PM David Rowley wrote:
> 3a4a3537a
> latency average = 34.497 ms
> latency average = 34.538 ms
>
> 3a4a3537a + read_stream_for_seqscans.patch
> latency average = 40.923 ms
> latency average = 41.415 ms
>
> i.e. no meaningful change from the refactor, but a regression fr
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 in slot sync worker:
> During promotion, the startup process in order
Hi,
On Thu, Apr 04, 2024 at 07:14:47PM +0900, Michael Paquier wrote:
> On Thu, Apr 04, 2024 at 09:28:36AM +, Bertrand Drouvot wrote:
> > +# No "Backpatch" region here as code is generated automatically.
> >
> > What about "region here as has its own C code" (that would be more
> > consis
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 lsns. But now when we use 'advance' to do logical
> decoding on standby, there is
On Wed, Apr 3, 2024 at 11:48 PM jian he wrote:
> hi.
> +
> + json_table is an SQL/JSON function which
> + queries JSON data
> + and presents the results as a relational view, which can be accessed as a
> + regular SQL table. You can only use
> json_table inside the
> + FROM clause of a
On 01.04.24 21:52, Jeff Davis wrote:
On Tue, 2024-03-26 at 08:04 +0100, Peter Eisentraut wrote:
The patch set v27 is ok with me, modulo (a) discussion about initcap
semantics, and (b) what collation to assign to ucs_basic, which can
be
revisited later.
Attached v28.
The remaining patches are
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 promotion,
> once while restoring slots and then via ShutDownSlotSync(). The r
On 14.03.24 21:33, Robert Haas wrote:
You seem to be supposing here that all protocol changes will consist
of adding new message types. While I think that will be a common
pattern, I do not think it will be a universal one.
As an additional data point, the column encryption patch that is
curre
On Thu, 4 Apr 2024 at 01: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 function call dance that I have in v25.
The approach I posted does not r
On 19.02.24 16:21, Jelte Fennema-Nio wrote:
v3-0003-Bring-editorconfig-in-line-with-gitattributes.patch
I question whether we need to add rules to .editorconfig about files
that are generated or imported from elsewhere, since those are not meant
to be edited.
I agree that it's not strictly nece
On Thu, 4 Apr 2024 at 13:08, Melih Mutlu wrote:
> I changed internal_flush() to an inline function, results look better this
> way.
It seems you also change internal_flush_buffer to be inline (but only
in the actual function definition, not declaration at the top). I
don't think inlining interna
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 don't understand the use of that.
No, there's only one guard rollover bi
On Thu, Apr 4, 2024 at 3:02 AM David Rowley wrote:
>
> On Thu, 4 Apr 2024 at 16:45, David Rowley wrote:
> > I've pushed the v9-0001 with that rename done.
>
> I've now just pushed the 0002 patch with some revisions:
Thanks!
> 1. The function declarations you added for heapgettup_advance_block()
On Wed, Apr 3, 2024 at 4:45 AM Tom Lane wrote:
>
> jian he writes:
> > On Thu, Jan 18, 2024 at 4:17 PM Peter Eisentraut
> > wrote:
> >> Reading back through the discussion, I wasn't quite able to interpret
> >> the resolution regarding Oracle compatibility. From the patch, it looks
> >> like y
On 31.03.24 15:34, walt...@technowledgy.de wrote:
I'd rather adapt one of the existing tasks, to avoid increasing CI
costs unduly.
I looked into this and I think the only task that could be changed is
the SanityCheck.
I think SanityCheck should run a simple, "average" environment, like the
Peter Eisentraut:
On 31.03.24 15:34, walt...@technowledgy.de wrote:
I'd rather adapt one of the existing tasks, to avoid increasing CI
costs unduly.
I looked into this and I think the only task that could be changed is
the SanityCheck.
I think SanityCheck should run a simple, "average" envi
Andrew Dunstan writes:
> pushed.
My animals don't like this [1][2]:
parse_manifest.c:99:3: error: redefinition of typedef
'JsonManifestParseIncrementalState' is a C11 feature
[-Werror,-Wtypedef-redefinition]
} JsonManifestParseIncrementalState;
^
../../src/include/common/parse_manifest.h:23:
Jelte Fennema-Nio , 4 Nis 2024 Per, 16:34 tarihinde
şunu yazdı:
> On Thu, 4 Apr 2024 at 13:08, Melih Mutlu wrote:
> > I changed internal_flush() to an inline function, results look better
> this way.
>
> It seems you also change internal_flush_buffer to be inline (but only
> in the actual functio
On 03.04.24 19:16, David Christensen wrote:
I removed _() in the output of the query/stars since there'd be no
sensible existing translations for the constructed string, which
included the query string itself. If we need it for the "QUERY"
string, this could be added fairly easily, but the exist
Building the docs fail for v26. The error is:
ref/psql-ref.sgml:1042: element member: validity error : Element term is not
declared in member list of possible children
^
I am able to build up to v24 before the was replaced with
I tested building with a mod
> On Wed, Mar 27, 2024 at 08:56:12AM +0900, Yasuo Honda wrote:
> Thanks for the useful info.
>
> Ruby on Rails uses bigint as a default data type for the primary key
> and prepared statements have been enabled by default for PostgreSQL.
> I'm looking forward to these current patches being merged as
Wolfgang Walther writes:
> Peter Eisentraut:
>> I think SanityCheck should run a simple, "average" environment, like the
>> current Debian one. Otherwise, niche problems with musl or multi-arch
>> or whatever will throw off the entire build pipeline.
> I do agree: SanityCheck doesn't feel like
On 2024-04-04 Th 10:26, Tom Lane wrote:
Andrew Dunstan writes:
pushed.
My animals don't like this [1][2]:
parse_manifest.c:99:3: error: redefinition of typedef
'JsonManifestParseIncrementalState' is a C11 feature
[-Werror,-Wtypedef-redefinition]
} JsonManifestParseIncrementalState;
^
.
Hi folks,
(v28)
I made a modification to a variable in the 'host' column in the archive
'describe.c'.
Test:
[postgres@localhost ~]$ /home/pgsql-17devel/bin/psql -x -p 5432
psql (17devel, server 15.6)
Type "help" for help.
postgres=# \conninfo
You are connected to database "postgres" as user "
On Thu, 4 Apr 2024 at 15:25, Peter Eisentraut wrote:
> Everybody has git. Everybody who edits .gitattributes can use git to
> check what they did.
What CLI command do you use to fix/ gitattributes on all existing
files? Afaict there's no command to actually remove the trailing
whitespace that gi
Andrew Dunstan writes:
> On 2024-04-04 Th 10:26, Tom Lane wrote:
>> My animals don't like this [1][2]:
> Darn it. Ok, will try to fix.
I think you just need to follow the standard pattern:
typedef struct foo foo;
... foo* is ok to use here ...
struct foo {
... fields
};
Tom Lane:
That is not the concern here. What I think Peter is worried about,
and certainly what I'm worried about, is that a breakage in
SanityCheck comprehensively breaks all CI testing for all Postgres
developers.
You'd have to commit a failing patch first to break CI for all other
develope
I wrote:
> I think you just need to follow the standard pattern:
Yeah, the attached is enough to silence it for me.
(But personally I'd add comments saying that the typedef
appears in thus-and-such header file; see examples in
our tree.)
regards, tom lane
diff --git a/src
Wolfgang Walther writes:
>> That is not the concern here. What I think Peter is worried about,
>> and certainly what I'm worried about, is that a breakage in
>> SanityCheck comprehensively breaks all CI testing for all Postgres
>> developers.
> You'd have to commit a failing patch first to break
The existing \conninfo command gets its values from libpq APIs. You are
changing all of this to make a server query, which is a totally
different thing. If we wanted to take a change like this, I don't think
it should be reusing the \conninfo command.
But I don't really see the point of this
On Thu, Apr 4, 2024 at 7:45 AM Thomas Munro wrote:
>
> On Thu, Apr 4, 2024 at 8:02 PM David Rowley wrote:
> > 3a4a3537a
> > latency average = 34.497 ms
> > latency average = 34.538 ms
> >
> > 3a4a3537a + read_stream_for_seqscans.patch
> > latency average = 40.923 ms
> > latency average = 41.415 m
On 04.04.24 16:58, Jelte Fennema-Nio wrote:
On Thu, 4 Apr 2024 at 15:25, Peter Eisentraut wrote:
Everybody has git. Everybody who edits .gitattributes can use git to
check what they did.
What CLI command do you use to fix/ gitattributes on all existing
files? Afaict there's no command to actu
On Thu, 4 Apr 2024 at 17:23, Peter Eisentraut wrote:
> git diff-tree --check $(git hash-object -t tree /dev/null) HEAD
>
> That's what I was hoping for for editorconfig-check, but as I said, the
> experience wasn't good.
Ah, I wasn't able to find that git incantation. I definitely think it
w
On 2024-04-04 Th 11:16, Tom Lane wrote:
I wrote:
I think you just need to follow the standard pattern:
Yeah, the attached is enough to silence it for me.
Thanks, that's what I came up with too (after converting my setup to use
clang)
(But personally I'd add comments saying that the ty
The existing \conninfo command gets its values from libpq APIs. You are
changing all of this to make a server query, which is a totally
different thing. If we wanted to take a change like this, I don't think
it should be reusing the \conninfo command.
But I don't really see the point of this. T
Maiquel Grassi writes:
>> The existing \conninfo command gets its values from libpq APIs. You are
>> changing all of this to make a server query, which is a totally
>> different thing. If we wanted to take a change like this, I don't think
>> it should be reusing the \conninfo command.
FWIW, I
Hello Andres,
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:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=calliphoridae&dt=2024
Oh, more problems: after running check-world in a non-VPATH build,
there are droppings all over my tree:
$ git status
On branch master
Your branch is up to date with 'origin/master'.
Untracked files:
(use "git add ..." to include in what will be committed)
src/interfaces/ecpg/test/sql/s
On Thu, Apr 4, 2024 at 9:32 AM Peter Eisentraut wrote:
>
> On 03.04.24 19:16, David Christensen wrote:
> > I removed _() in the output of the query/stars since there'd be no
> > sensible existing translations for the constructed string, which
> > included the query string itself. If we need it fo
On 2024-04-04 Th 12:04, Tom Lane wrote:
Oh, more problems: after running check-world in a non-VPATH build,
there are droppings all over my tree:
$ git status
On branch master
Your branch is up to date with 'origin/master'.
Untracked files:
(use "git add ..." to include in what will be comm
>> The existing \conninfo command gets its values from libpq APIs. You are
>> changing all of this to make a server query, which is a totally
>> different thing. If we wanted to take a change like this, I don't think
>> it should be reusing the \conninfo command.
FWIW, I agree with Peter's conce
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:
> > > >
> > > >
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 w
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
> Boolean-valued
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.
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
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:
> https://buildfarm.
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 ap
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
/home/jelte/opensource
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 functi
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
> matter
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 used
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.
IIR
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): Out-of-
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 t
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 mo
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.
An
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 ty
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 part
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 (lex-
[ 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 -fno-strict
> 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 don
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 test
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 code.
1 - 100 of 184 matches
Mail list logo