On Wed, 10 Jan 2024 at 15:55, Anthonin Bonnefoy
wrote:
> PREPARE test_prepared (text, integer) AS /*$1*/ SELECT $2;
> EXECUTE
> test_prepared('dddbs=''postgres.db'',traceparent=''00-0009-0009-01''',
> 1);
Wow, I had no idea that parameters could be expande
v6 attached with the following changes:
1. Fixed rebase conflicts with master
2. removed PGC_S_PROTOCOL (but kept PGC_PROTOCOL and PGC_SU_PROTOCOL).
This extra source level was not needed. And after some more testing I
realized this extra source level even caused problems, since protocol
messages
On Wed, 10 Jan 2024 at 22:12, Robert Haas wrote:
> Could you explain why you think that the protocol version bump is necessary?
Patch 0006 adds a new protocol message to the protocol. Somehow the
client needs to be told that the server understands that message.
Using the protocol version seems li
On Tue, 12 Sept 2023 at 09:46, Peter Eisentraut wrote:
> ISTM that for a purpose like pgbouncer, it would be simpler to add a new
> GUC "report these variables" and send that in the startup message? That
> might not help with the psql use case, but it would be much simpler.
FYI I implemented it
On Wed, 10 Jan 2024 at 23:53, Jelte Fennema-Nio wrote:
> Honestly, I care more about patch 0010 than patch 0008. Patch 0008
> simply seemed like the easiest way to demonstrate the ParameterSet
> message.
So to be clear, if you consider 0008 the most controversial/risky part
of this
On Fri, 12 Jan 2024 at 15:53, Michael Banck wrote:
> I propose to add a new predefined role to Postgres,
> pg_manage_extensions. The idea is that it allows Superusers to delegate
> the rights to create, update or delete extensions to other roles, even
> if those extensions are not trusted or those
On Thu, 2 Nov 2023 at 10:52, Anthonin Bonnefoy
wrote:
> The main goal is to provide more ways to test extended protocol in
> regression tests
> similarly to what \bind is doing.
I think this is a great addition. One thing that I think should be
added for completeness though is the ability to deal
On Mon, 15 Jan 2024 at 08:50, Michael Paquier wrote:
> Yeah, I'll go with that after a second look. Attached is what I am
> finishing with, and I have reproduced some numbers with the pgbench
> metacommand mentioned upthread, which is reeeaaally nice.
Code looks good to me. But one small notes o
On Thu, 28 Sept 2023 at 03:08, Michael Paquier wrote:
> dummy_index_am has included from the start additional coverage for the
> various internal add_*_reloption routines, that were never covered in
> the core tree. Except if I am missing something, I am not seeing some
> of the extra usefulness
On Mon, 15 Jan 2024 at 14:26, Aleksander Alekseev
wrote:
> To be fair, Postgres uses TAM internally, so there is at least one
> complete and up-to-date real-life example.
Sure, but that one is quite hard to follow if you don't already know
lots of details of the heap storage. At least for me, hav
Looks really good now. One thing I noticed is that \bindx doesn't call
ignore_slash_options if it's not in an active branch. Afaict it
should. I do realize the same is true for plain \bind, but it seems
like a bug there too.
One more usability thing. I think \parse and \close should not require
a \g to send the message. You can do that by returning PSQL_CMD_SEND
instead of PSQL_CMD_SKIP_LIN.
I feel like the main point of requiring \g for \bind and \bindx is so
you can also use \gset or \gexec. But since \parse and \clo
On Tue, 16 Jan 2024 at 10:37, Jelte Fennema-Nio wrote:
>
> Looks really good now. One thing I noticed is that \bindx doesn't call
> ignore_slash_options if it's not in an active branch. Afaict it
> should. I do realize the same is true for plain \bind, but it seems
> l
On Tue, 16 Jan 2024 at 15:44, Andrey M. Borodin wrote:
> > On 16 Jan 2024, at 18:00, Aleksander Alekseev
> > wrote:
> > Not 100% sure what this is for. Any chance this could be part of another
> > patch?
> Nope, it’s necessary there. Without these changes catalog functions cannot
> have defaul
On Tue, 16 Jan 2024 at 19:17, Andrey M. Borodin wrote:
> Jelte, what is your opinion on naming the function which extracts timestamp
> from UUID v7?
I looked at a few more datatypes: json, jsonb & hstore. The get_
prefix is not used there at all, so I'm still opposed to that. But
they seem to us
On Tue, 16 Jan 2024 at 22:02, Przemysław Sztoch wrote:
> But replace uuidv7_extract_time(uuid) with uuid_extract_time(uuid) - function
> should be able extract timestamp from v1/v6/v7
I'm fine with this.
> I would highly recommend to add:
> uuidv5(namespace uuid, name text) -> uuid
> using uuid
On Tue, 16 Jan 2024 at 21:36, Robert Haas wrote:
> Sorry for not getting back to this right away; there are quite a few
> threads competing for my attention.
No worries, I know it's a busy time.
> But I think we would want to have those changes in all supported
> branches before we could think o
On Wed, 17 Jan 2024 at 14:39, Robert Haas wrote:
> I think it's hard to say for sure what API is going to work well here,
> because we just don't have much experience with this.
Agreed, but I strongly believe PQunsupportedProtocolExtensions() is
useful regardless of the API choice.
> I also thin
I ran into an SSL issue when using the MSYS2/MINGW build of Postgres
for the PgBouncer test suite. Postgres crashed whenever you tried to
open an ssl connection to it.
https://github.com/msys2/MINGW-packages/issues/19851
I'm wondering if the issue described in this thread could be related
to the i
On Wed, 24 Jan 2024 at 21:47, Marcos Pegoraro wrote:
>
> I understand your point, but
> '2000-01-01' :: timestamp and '1900-01-01' :: timestamp are both valid
> timestamps.
>
> So looks strange if user can do
> select uuidv7(TIMESTAMP '2000-01-01')
> but cannot do
> select uuidv7(TIMESTAMP '1900-
On Thu, 25 Jan 2024 at 21:43, Pavel Stehule wrote:
> 2. using GUC for all reported GUC looks not too readable. Maybe it should be
> used just for customized reporting, not for default
I thought about this too, because indeed the default list is quite
long. But I decided against it because it see
On Fri, 26 Jan 2024 at 02:59, vignesh C wrote:
> Please post an updated version for the same.
Done.
From 5a94d610a4fe138365e2e88c5cec72eba53ed036 Mon Sep 17 00:00:00 2001
From: Jelte Fennema-Nio
Date: Thu, 14 Dec 2023 13:39:04 +0100
Subject: [PATCH v25 2/3] Add non-blocking version of PQcan
On Fri, 26 Jan 2024 at 13:11, Alvaro Herrera wrote:
> I wonder, would it make sense to put all these new functions in a
> separate file fe-cancel.c?
Okay I tried doing that. I think the end result is indeed quite nice,
having all the cancellation related functions together in a file. But
it did
On Fri, 26 Jan 2024 at 21:35, Pavel Stehule wrote:
> I see a possibility of disabling reporting as possibly dangerous. Without
> reporting encoding you can break psql. So it should be limited just to few
> values where is known behave.
I agree that client_encoding is a GUC that likely all clie
On Fri, 26 Jan 2024 at 18:19, Alvaro Herrera wrote:
> Yeah, I see that point of view as well. I like the end result; the
> additional protos in libpq-int.h don't bother me. Does anybody else
> wants to share their opinion on it? If none, then I'd consider going
> ahead with this version.
To be
On Sat, 27 Jan 2024 at 08:35, Pavel Stehule wrote:
> Until now, it is not possible to disable reporting. So clients can expect so
> reporting is workable.
Sure, so if we leave the default as is that's fine. It's not as if
this GUC would be changed without the client knowing, the client would
be
On Sat, 27 Jan 2024 at 20:44, Pavel Stehule wrote:
> client_encoding, standard_conforming_strings, server_version,
> default_transaction_read_only, in_hot_standby and scram_iterations
> are used by libpq directly, so it can be wrong to introduce the possibility
> to break it.
libpq could add th
On Sun, 28 Jan 2024 at 04:15, vignesh C wrote:
> CFBot shows that the patch has few compilation errors as in [1]:
> [17:07:07.621] /usr/bin/ld:
> ../../../src/fe_utils/libpgfeutils.a(cancel.o): in function
> `handle_sigint':
> [17:07:07.621] cancel.c:(.text+0x50): undefined reference to `PQcancel'
On Sun, 28 Jan 2024 at 10:51, Jelte Fennema-Nio wrote:
> Both of those are fixed now.
Okay, there turned out to also be an issue on Windows with
setKeepalivesWin32 not being available in fe-cancel.c. That's fixed
now too (as well as some minor formatting issue
On Sun, 28 Jan 2024 at 20:01, Pavel Stehule wrote:
> There is another reason - compatibility with other drivers. We maintain just
> libpq, but there are JDBC, Npgsql, and some native Python drivers. I didn't
> checked, but maybe they expect GUC with GUC_REPORT flag.
This doesn't matter, becaus
tl;dr I believe we should remove the uuidv7(timestamp) function from
this patchset.
On Thu, 25 Jan 2024 at 18:04, Sergey Prokhorenko
wrote:
> In this case the documentation must state that the functions
> uuid_extract_time() and uuidv7(T) are against the RFC requirements, and that
> developers
On Thu, 25 Jan 2024 at 13:31, Aleksander Alekseev
wrote:
> PFA v14.
+uuidv4 () uuid
+
+ Both functions return a version 4 (random) UUID. This is the most commonly
+ used type of UUID and is appropriate when random distribution of keys does
+ not affect performance of an application.
+
+uuid
On Mon, 29 Jan 2024 at 12:44, Alvaro Herrera wrote:
> Thanks! I committed 0001 now. I also renamed the new
> pq_parse_int_param to pqParseIntParam, for consistency with other
> routines there. Please rebase the other patches.
Awesome! Rebased, and renamed pq_release_conn_hosts to
pqReleaseConn
7;ll start: +1
Attached is a patch that removes -Wdeclaration-after-statement in the
codebase. This is mainly to be able to add it to the commitfest, to
hopefully get a decent amount of responses.
From 105a4aaff2d142b40d8b093f67597d6340f66b68 Mon Sep 17 00:00:00 2001
From: Jelte Fennema-Nio
Date: M
On Mon, 29 Jan 2024 at 19:32, Andrey M. Borodin wrote:
> Even if the developer pass constant time to uuidv7(T) they will get what they
> asked for - unique identifier. Moreover - it still will be keeping locality.
> There will be no negative consequences at all.
It will be significantly "less u
On Mon, 29 Jan 2024 at 19:37, Tristan Partin wrote:
>
> On Mon Jan 29, 2024 at 11:37 AM CST, Alvaro Herrera wrote:
> > I just realized while looking at Jelte's patch for the new nonblocking
> > query cancel stuff that the Meson build doesn't run the libpq_pipeline
> > tests :-(
> >
> > Is there an
On Tue, 30 Jan 2024 at 13:37, Alvaro Herrera wrote:
>
> I noticed while answering a question that commit b577743000cd added the
> GUC scram_iterations and marked it GUC_REPORT, but failed to add it to
> the PQparameterStatus documentation.
+1 the improvements your suggesting (although 3 I don't k
On Tue, 30 Jan 2024 at 23:20, Tristan Partin wrote:
> Not next week, but here is a respin. I've exposed pqSocketPoll as
> PQsocketPoll and am just using that. You can see the diff is so much
> smaller, which is great!
The exports.txt change should be made part of patch 0001, also docs
are missing
On Tue, 30 Jan 2024 at 19:48, Robert Haas wrote:
>
> On Tue, Jan 30, 2024 at 12:58 PM Melih Mutlu wrote:
> > Sounds like it's difficult to come up with a heuristic that would work well
> > enough for most cases.
> > One thing with sending data instead of copying it if the buffer is empty is
> >
On Wed, 31 Jan 2024 at 18:23, Robert Haas wrote:
> That's kind of an odd artifact, but maybe it's fine in
> practice.
I agree it's an odd artifact, but it's not a regression over the
status quo. Achieving that was the intent of my suggestion: A change
that improves some cases, but regresses nowhe
On Wed, 31 Jan 2024 at 19:07, Tristan Partin wrote:
> I was looking for documentation of PQsocket(), but didn't find any
> standalone (unless I completely missed it). So I just copied how
> PQsocket() is documented in PQconnectPoll(). I am happy to document it
> separately if you think it would be
On Thu, 1 Feb 2024 at 21:00, Tom Lane wrote:
>Note that the request is not itself flushed to the server
> automatically;
>use PQflush if necessary.
>
> Doesn't that require some rewording?
I agree that the current wording is slightly incorrect, but I think I
prefer we keep it thi
ot;been")
in a comment that I noticed while reading your fixes.
From 7736e940567878c32355c2143cddba3b13bfa71e Mon Sep 17 00:00:00 2001
From: Jelte Fennema-Nio
Date: Fri, 26 Jan 2024 16:47:51 +0100
Subject: [PATCH v30 3/5] libpq: Change some static functions to extern
This is in preparation of
On Fri, 2 Feb 2024 at 16:06, Alvaro Herrera wrote:
> Now, looking at this list, I think it's surprising that the nonblocking
> request for a cancellation is called PQcancelPoll. PQcancelSend() is at
> odds with the asynchronous query API, which uses the verb "send" for the
> asynchronous variants
On Tue, 30 Jan 2024 at 18:49, Robert Haas wrote:
> I also think that using the GUC system to manage itself is a little
> bit suspect. I wonder if it would be better to do this some other way,
> e.g. a sentinel file in the data directory. For example, suppose we
> refuse ALTER SYSTEM if $PGDATA/dis
On Wed, 7 Feb 2024 at 11:16, Peter Eisentraut wrote:
> On 06.02.24 16:22, Jelte Fennema-Nio wrote:
> > On Tue, 30 Jan 2024 at 18:49, Robert Haas wrote:
> >> I also think that using the GUC system to manage itself is a little
> >> bit suspect. I wonder if it would be b
On Wed, 7 Feb 2024 at 11:35, Gabriele Bartolini
wrote:
> This is mostly the approach I have taken in the patch, except allowing to
> change the value in the configuration file.
(I had missed the patch in the long thread). I think it would be nice
to have this be PGC_SIGHUP, and set GUC_DISALLOW_
On Wed, 13 Mar 2024 at 20:08, Jacob Champion
wrote:
> I hit this on my machine. With the attached diff I can reproduce
> constantly (including with the most recent test patch); I think the
> cancel must be arriving between the bind/execute steps?
Nice find! Your explanation makes total sense. Att
On Thu, 14 Mar 2024 at 11:33, Alvaro Herrera wrote:
> Hmm, isn't this basically saying that we're giving up on reliably
> canceling queries altogether? I mean, maybe we'd like to instead fix
> the bug about canceling queries in extended query protocol ...
> Isn't that something you're worried abo
On Thu, 14 Mar 2024 at 12:22, Melih Mutlu wrote:
> I did some experiments with this patch, after previous discussions
One thing I noticed is that the buffer sizes don't seem to matter much
in your experiments, even though Andres his expectation was that 1400
would be better. I think I know the re
On Thu, 14 Mar 2024 at 13:12, Robert Haas wrote:
>
> On Thu, Mar 14, 2024 at 7:22 AM Melih Mutlu wrote:
> > 1- Even though I expect both the patch and HEAD behave similarly in case of
> > small data (case 1: 100 bytes), the patch runs slightly slower than HEAD.
>
> I wonder why this happens. It
On Thu, 14 Mar 2024 at 16:45, Robert Haas wrote:
> I feel bad arguing about the patches that you think are a slam-dunk,
> but I find myself disagreeing with the design choices.
No worries, thanks a lot for responding. I'm happy to discuss this
design further. I didn't necessarily mean these patch
On Thu, 14 Mar 2024 at 17:37, Robert Haas wrote:
> or in the
> alternative (2) but with the GUC being PGC_SIGHUP and
> GUC_DISALLOW_IN_AUTO_FILE. I believe there would be adequate consensus
> to proceed with either of those approaches. Anybody feel like coding
> it up?
Here is a slightly modified
On Thu, 14 Mar 2024 at 22:15, Maciek Sakrejda wrote:
> In this case, the end user with access to Postgres superuser
> privileges presumably also has access to the outside configuration
> mechanism. The goal is not to prevent them from changing settings, but
> to offer guard rails that prevent them
On Fri, 15 Mar 2024 at 11:08, Daniel Gustafsson wrote:
> Another quirk for the documentation of this: if I disable ALTER SYSTEM I would
> assume that postgresql.auto.conf is no longer consumed, but it still is (and
> still need to be), so maybe "enable/disable" is the wrong choice of words?
Updat
On Mon, 18 Mar 2024 at 13:57, Robert Haas wrote:
> I would have been somewhat inclined to find an existing section
> of postgresql.auto.conf for this parameter, perhaps "platform and
> version compatibility".
I tried to find an existing section, but I couldn't find any that this
new GUC would fit
On Mon, 18 Mar 2024 at 18:27, Robert Haas wrote:
> I think for now we
> should just file this under "Other platforms and clients," which only
> has one existing setting. If the number of settings of this type
> grows, we can split it out.
Done. I also included a patch to rename COMPAT_OPTIONS_CLI
On Tue, 19 Mar 2024 at 15:52, Tom Lane wrote:
> I like this idea. The "bonus" is not optional though, because
> setting the files' ownership/permissions is the only way to be
> sure that the prohibition is even a little bit bulletproof.
I don't agree with this. The only "normal" way of modifying
On Tue, 19 Mar 2024 at 17:05, Tom Lane wrote:
> I've said this repeatedly: it's not enough. The only reason we need
> any feature whatsoever is that somebody doesn't trust their database
> superusers to not try to modify the configuration.
And as everyone else on this thread has said: It is enou
On Wed, 20 Mar 2024 at 14:04, Greg Sabino Mullane wrote:
>>
>> As a bonus, if that GUC is set, we could even check at server startup that
>> all the configuration files are not writable by the postgres user,
>> and print a warning or refuse to start up if they are.
>
>
> Ugh, please let's not do
On Wed, 20 Mar 2024 at 07:35, Peter Eisentraut wrote:
> If we want to be robust without any guarantees from gettimeofday(), then
> arguably gettimeofday() is not the right underlying function to use for
> UUIDv7.
There's also clock_gettime which exposes its resolution using clock_getres
On Thu, 21 Mar 2024 at 01:45, David Rowley wrote:
> As I understand the code, there's no problem calling
> internal_flush_buffer() when the buffer is empty and I suspect that if
> we're sending a few buffers with "len > PqSendBufferSize" that it's
> just so unlikely that the buffer is empty that w
On Thu, 21 Mar 2024 at 01:24, Melih Mutlu wrote:
> What if I do a simple comparison like PqSendStart == PqSendPointer instead of
> calling pq_is_send_pending()
Yeah, that sounds worth trying out. So the new suggestions to fix the
perf issues on small message sizes would be:
1. add "inline" to i
On Wed, 20 Mar 2024 at 08:16, Heikki Linnakangas wrote:
> Yeah, it's not a very valuable assertion. Removed, thanks!
How about we add it as a static assert instead of removing it, like we
have for many other similar arrays.
v1-0001-Add-child_process_kinds-static-assert.patch
Description: Binary
On Wed, 13 Mar 2024 at 16:32, Jelte Fennema-Nio wrote:
> How
> about the following aproach. It still uses 3 GUCs, but they now all
> work together. There's one entry point and two additional filters
> (level and function name)
>
> # Says what log entries to log backtra
On Wed, 20 Mar 2024 at 19:08, Andrey M. Borodin wrote:
> Timer-based bits contribute to global sortability. But the real timers we
> have are not even millisecond adjusted. We can hope for ~few ms variation in
> one datacenter or in presence of atomic clocks.
I think the main benefit of using m
On Thu, 21 Mar 2024 at 03:54, Noah Misch wrote:
>
> On Mon, Mar 18, 2024 at 07:40:10PM +0100, Alvaro Herrera wrote:
> > I enabled the test again and also pushed the changes to dblink,
> > isolationtester and fe_utils (which AFAICS is used by pg_dump,
>
> I recommend adding a libpqsrv_cancel() func
On Thu, 21 Mar 2024 at 15:41, Jelte Fennema-Nio wrote:
> Attached is a patch that implements this. Since the more I think about
> it, the more I like this approach.
I now added a 3rd patch to this patchset which changes the
log_backtrace default to "internal", because it seems qu
On Fri, 22 Mar 2024 at 11:14, Bharath Rupireddy
wrote:
> A few comments:
>
> 1.
> @@ -832,6 +849,9 @@ matches_backtrace_functions(const char *funcname)
> {
> const char *p;
>
> +if (!backtrace_functions || backtrace_functions[0] == '\0')
> +return true;
> +
>
> Shouldn't this be
On Sat, 23 Mar 2024 at 00:34, Tom Lane wrote:
> Prompt space is
> expensive and precious, at least for people who aren't in the
> habit of working in very wide windows.
That problem seems easy to address by adding a newline into the
default prompt. Something like this:
\set PROMPT1 '%n@%~%R%\n#
On Mon, 25 Mar 2024 at 09:30, Jelte Fennema-Nio wrote:
> \set PROMPT1 '%n@%~%R%\n# '
Obviously I meant to put the \n before the %:
\set PROMPT1 '%n@%~%R\n%# '
On Mon, 25 Mar 2024 at 11:40, jian he wrote:
> transaction related information lost.
Ah yeah, it seems I somehow lost the %x
How about:
\set PROMPT1 '%n@%~\n%R%x%# '
Or maybe even this more verbose one, which closely matches the
postgresql:// connection string format:
\set PROMPT1 '%n@%M:%>/%/\
On Mon, 25 Mar 2024 at 14:06, Robert Haas wrote:
> On Mon, Mar 25, 2024 at 4:30 AM Jelte Fennema-Nio wrote:
> > That problem seems easy to address by adding a newline into the
> > default prompt.
>
> Ugh. Please, no!
I guess it's partially a matter of taste, but perso
On Mon, 25 Mar 2024 at 20:16, Bruce Momjian wrote:
> I am wondering if the fact that you would be able to do:
>
> ALTER SYSTEM SET externally_managed_configuration = false
>
> and then be unable to use ALTER SYSTEM to revert the change is
> significant.
This is not possible, due to the ex
On Wed, 27 Mar 2024 at 02:24, Andrew Dunstan wrote:
> Agree. I don’t think “_command” adds much clarity.
Alright, changed the GUC name to "allow_alter_system" since that seems
to have the most "votes". One other option would be to call it simply
"alter_system", just like "jit" is not called "allo
On Wed, 27 Mar 2024 at 16:10, Robert Haas wrote:
>
> On Wed, Mar 27, 2024 at 11:01 AM Bruce Momjian wrote:
> > Uh, the above is clearly wrong. I think you mean "off" on the second line.
>
> Woops. When the name changed from externally_managed_configuration to
> allow_alter_system, the sense of i
On Wed, 27 Mar 2024 at 23:23, Bruce Momjian wrote:
>
> On Wed, Mar 27, 2024 at 11:10:31AM -0400, Robert Haas wrote:
> > > Is this really a patch we think we can push into PG 17. I am having my
> > > doubts.
> >
> > If the worst thing that happens in PG 17 is that we push a patch that
> > needs a f
On Wed, 27 Mar 2024 at 20:10, Maciek Sakrejda wrote:
>
> On Wed, Mar 27, 2024, 11:46 Robert Haas wrote:
>>
>> On Wed, Mar 27, 2024 at 1:12 PM Isaac Morland
>> wrote:
>> > On Wed, 27 Mar 2024 at 13:05, Greg Sabino Mullane
>> > wrote:
>> >>> The purpose of the setting is to prevent accidental
On Wed, 27 Mar 2024 at 23:06, Bruce Momjian wrote:
> > > > > +some outside mechanism. In such environments, using
> > > > > ALTER
> > > > > +SYSTEM to make configuration changes might appear
> > > > > to work,
> > > > > +but then may be discarded at some point in the futu
On Thu, 28 Mar 2024 at 01:43, David G. Johnston
wrote:
>
> On Wed, Mar 27, 2024 at 5:17 PM Bruce Momjian wrote:
>>
>>
I addressed them all I think. Mostly the small changes that were
suggested, but I rewrote the sentence with "might be discarded". And I
added references to the new GUC in both p
On Wed, 27 Mar 2024 at 19:46, Alvaro Herrera wrote:
>
> On 2024-Mar-27, Alvaro Herrera wrote:
>
> > I changed it so that the error messages are returned as translated
> > phrases, and was bothered by the fact that if errors happen repeatedly,
> > the memory for them might be leaked. Maybe this is
On Wed, 27 Mar 2024 at 19:27, Alvaro Herrera wrote:
> I ended up reducing the two PG_TRY blocks to a single one. I see no
> reason to split them up, and this way it looks more legible.
I definitely agree this looks better. Not sure why I hadn't done that,
maybe it wasn't possible in one of the e
On Thu, 28 Mar 2024 at 10:24, Jelte Fennema-Nio wrote:
> I addressed them all I think. Mostly the small changes that were
> suggested, but I rewrote the sentence with "might be discarded". And I
> added references to the new GUC in both places suggested by David.
Changed th
On Thu, 28 Mar 2024 at 12:57, Robert Haas wrote:
> I disagree with a lot of these changes. I think the old version was
> mostly better. But I can live with a lot of it if it makes other
> people happy.
I'd have been fine with many of the previous versions of the docs too.
(I'm not a native englis
On Thu, 28 Mar 2024 at 17:34, Alvaro Herrera wrote:
>
> Eh, kestrel has also failed[1], apparently every query after the large
> JOIN that this commit added as test fails with a statement timeout error.
>
> [1]
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=kestrel&dt=2024-03-28%2016%3
On Thu, 28 Mar 2024 at 17:43, Alvaro Herrera wrote:
> Hah, you're right, I can reproduce with a smaller timeout, and using SET
> LOCAL works as a fix. If we're doing that, why not reduce the timeout
> to 1ms? We don't need to wait extra 9ms ...
I think we don't really want to make the timeout t
On Thu, 28 Mar 2024 at 19:03, Tom Lane wrote:
>
> Alvaro Herrera writes:
> > It doesn't fail when it's too fast -- it's just that it doesn't cover
> > the case we want to cover.
>
> That's hardly better, because then you think you have test
> coverage but maybe you don't.
Honestly, that seems qu
On Sun, 7 Jan 2024 at 07:55, vignesh C wrote:
> One of the test has aborted in CFBot at [1] with:
Rebased the patchset and removed patch 0003 since it was causing the
CI issue reported by vignesh and it seems much less useful and more
controversial to me anyway (due to the extra required roundtri
00:00:00 2001
From: Jelte Fennema-Nio
Date: Wed, 3 Apr 2024 15:21:52 +0200
Subject: [PATCH v11 2/2] Remove PGRES_POLLING_ACTIVE
This enum variant has been unused for at least 21 years
44aba280207740d0956160c0288e61f28f024a71. It was left for backwards
compatibility for "awhile". I think
iant. But remove it from
the recently added switch/case. And also updated the comment to remove
the "for awhile".
From 29100578b5f0b4cec68ee1b8c572c4f280335da3 Mon Sep 17 00:00:00 2001
From: Jelte Fennema-Nio
Date: Wed, 3 Apr 2024 15:19:04 +0200
Subject: [PATCH v12 1/2] Fix actually reachable
17: warning: enumeration value
> > ‘PGRES_POLLING_ACTIVE’ not handled in switch [-Wswitch]
> > 3803 | switch (PQconnectPoll(conn))
> > | ^~
Ofcourse... fixed now
From 29100578b5f0b4cec68ee1b8c572c4f280335da3 Mon Sep 17 00:00:00 2001
From
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
ccfb6fca3e4ae9e1e62ac3b6a4c5f428b56e04 Mon Sep 17 00:00:00 2001
From: Jelte Fennema-Nio
Date: Wed, 3 Apr 2024 15:19:04 +0200
Subject: [PATCH v14 1/2] Fix actually reachable pg_unreachable call
In cafe1056558fe07cdc52b95205588fcd80870362 a call to pg_unreachable was
introduced that was actua
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 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
tion. I definitely think it
would be good if there was an official cli tool like that for
editorconfig, but the Javascript one was the closest I could find. The
Go one I haven't tried.
On Thu, 4 Apr 2024 at 17:23, Peter Eisentraut wrote:
>
> On 04.04.24 16:58, Jelte Fennema-Nio wrote:
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.
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, 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` ri
1 - 100 of 595 matches
Mail list logo
