On Sat, Apr 6, 2024 at 2:03 PM Amit Langote wrote:
>
> >
> > * problem with type "char". the view def output is not the same as
> > the select * from v1.
> >
> > create or replace view v1 as
> > SELECT col FROM s,
> > JSON_TABLE(jsonb '{"d": ["hello", "hello1"]}', '$' as c1
> > COLUMNS(col "char"
On Fri, Apr 5, 2024 at 10:31 AM shveta malik wrote:
>
> Please find v2. Changes are:
Thanks for the patch. Here are some comments.
1. Can we have a clear saying in the shmem variable who's syncing at
the moment? Is it a slot sync worker or a backend via SQL function?
Perhaps turn "bool syncing;"
On Sat, Apr 6, 2024 at 11:55 AM Bharath Rupireddy
wrote:
>
Why the handling w.r.t active_pid in InvalidatePossiblyInactiveSlot()
is not similar to InvalidatePossiblyObsoleteSlot(). Won't we need to
ensure that there is no other active slot user? Is it sufficient to
check inactive_since for the sa
On Sat, Apr 6, 2024 at 9:21 AM Thomas Munro wrote:
>
> On Sat, Apr 6, 2024 at 6:55 AM Alvaro Herrera wrote:
> > Pushed 0001.
>
> Could that be related to the 3 failures on parula that look like this?
>
> TRAP: failed Assert("node->next == 0 && node->prev == 0"), File:
> "../../../../src/include/s
On Fri, Apr 5, 2024 at 1:14 PM Bertrand Drouvot
wrote:
>
> > Please find the attached v36 patch.
>
> A few comments:
>
> 1 ===
>
> +
> +The timeout is measured from the time since the slot has become
> +inactive (known from its
> +inactive_since value) until it gets
On Fri, Apr 5, 2024 at 10:31 AM shveta malik wrote:
>
> Please find v2. Changes are:
> 1) Rebased the patch as there was conflict due to recent commit 6f132ed.
> 2) Added an Assert in update_synced_slots_inactive_since() to ensure
> that the slot does not have active_pid.
> 3) Improved commit msg
On Sat, Apr 6, 2024 at 12:31 PM jian he wrote:
> On Fri, Apr 5, 2024 at 8:35 PM Amit Langote wrote:
> > Here's one. Main changes:
> >
> > * Fixed a bug in get_table_json_columns() which caused nested columns
> > to be deparsed incorrectly, something Jian reported upthread.
> > * Simplified the a
On 05.04.24 23:48, Daniel Gustafsson wrote:
The reason to expand the check is to ensure that we have the version we want
for both OpenSSL and LibreSSL, and deprecating OpenSSL versions isn't all that
commonly done so having to change the version in the check didn't seem that
invasive to me.
Why
> On 5 Apr 2024, at 07:19, Michael Paquier wrote:
>
> It's been a couple of weeks since this has been sent, and this did not
> get any reviews. I'd still be happy with the simplicity of a single
> injection_points_local() that can be used to link all the injection
> points created in a single
On Sat, Apr 6, 2024 at 10:13 AM Amit Kapila wrote:
>
There are still a few pending issues to be fixed in this feature but
otherwise, we have committed all the main patches, so I marked the CF
entry corresponding to this work as committed.
--
With Regards,
Amit Kapila.
Hi Michael,
On Fri, Apr 5, 2024 at 3:07 PM Michael Paquier wrote:
> On Fri, Apr 05, 2024 at 09:00:00AM +0300, Alexander Lakhin wrote:
> > Please look at an assertion failure:
> > TRAP: failed Assert("count <= tupdesc->natts"), File: "parse_relation.c",
> > Line: 3048, PID: 1325146
> >
> > trigge
On Fri, Apr 5, 2024 at 8:05 PM Bertrand Drouvot
wrote:
>
> On Fri, Apr 05, 2024 at 06:23:10PM +0530, Amit Kapila wrote:
> > On Fri, Apr 5, 2024 at 5:17 PM Amit Kapila wrote:
> > Thinking more on this, it doesn't seem related to
> > c9920a9068eac2e6c8fb34988d18c0b42b9bf811 as that commit doesn't c
Jeff Davis writes:
> Thank you, this has improved a lot and the fundamentals are very close.
> I think it could benefit from a bit more time to settle on a few
> issues:
Yeah ... it feels like we aren't quite going to manage to get this
over the line for v17. We could commit with the hope that t
On Sat, Apr 6, 2024 at 6:55 AM Alvaro Herrera wrote:
> Pushed 0001.
Could that be related to the 3 failures on parula that look like this?
TRAP: failed Assert("node->next == 0 && node->prev == 0"), File:
"../../../../src/include/storage/proclist.h", Line: 63, PID: 29119
2024-04-05 16:16:26.812 U
On Thu, 2024-04-04 at 00:30 -0400, Corey Huinker wrote:
>
> v17
>
> 0001
> - array_in now repackages cast errors as warnings and skips the stat,
> test added
> - version parameter added, though it's mostly for future
> compatibility, tests modified
> - both functions delay object/attribute lockin
On Fri, Apr 5, 2024 at 8:35 PM Amit Langote wrote:
> Here's one. Main changes:
>
> * Fixed a bug in get_table_json_columns() which caused nested columns
> to be deparsed incorrectly, something Jian reported upthread.
> * Simplified the algorithm in JsonTablePlanNextRow()
>
> I'll post another rev
On Sat, 6 Apr 2024 at 03:24, Tom Lane wrote:
> OK. I did not read the patch very closely, but at least in principle
> I have no further objections. David, are you planning to take point
> on getting this in?
Yes. I'll be looking soon.
David
Noah Misch writes:
> On Fri, Apr 05, 2024 at 07:10:59PM -0400, Tom Lane wrote:
>> The fact that the DROP ROLE added by 936e3fa37 succeeded indicates
>> that these role references weren't captured in pg_shdepend.
>> I imagine that we also lack code that would allow DROP OWNED BY to
>> follow up on
On Fri, Apr 5, 2024 at 7:28 PM Thomas Munro wrote:
>
> On Sat, Apr 6, 2024 at 6:55 AM Melanie Plageman
> wrote:
> > I haven't looked into or reviewed the memory prefetching part.
> >
> > While reviewing 0002, I realized that I don't quite see how
> > read_stream_get_block() will be used in the fa
On Sat, 6 Apr 2024 at 14:17, Nathan Bossart wrote:
>
> On Sat, Apr 06, 2024 at 12:08:14PM +1300, David Rowley wrote:
> > Won't Valgrind complain about this?
> >
> > +pg_popcount_avx512(const char *buf, int bytes)
> >
> > + buf = (const char *) TYPEALIGN_DOWN(sizeof(__m512i), buf);
> >
> > + val =
On Fri, Apr 05, 2024 at 07:10:59PM -0400, Tom Lane wrote:
> I wondered why buildfarm member copperhead has started to fail
> xversion-upgrade-HEAD-HEAD tests. I soon reproduced the problem here:
>
> pg_restore: creating ACL "regress_pg_dump_schema.TYPE "test_type""
> pg_restore: while PROCESSING
On Fri, 5 Apr 2024 at 03:28, Melih Mutlu wrote:
>
> 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 in
On Sat, Apr 06, 2024 at 12:08:14PM +1300, David Rowley wrote:
> Won't Valgrind complain about this?
>
> +pg_popcount_avx512(const char *buf, int bytes)
>
> + buf = (const char *) TYPEALIGN_DOWN(sizeof(__m512i), buf);
>
> + val = _mm512_maskz_loadu_epi8(mask, (const __m512i *) buf);
I haven't be
On Sat, Apr 6, 2024 at 3:47 AM Jeff Davis wrote:
> In hashfn_unstable.h, fasthash32() is declared as:
>
> /* like fasthash64, but returns a 32-bit hashcode */
> static inline uint64
> fasthash32(const char *k, size_t len, uint64 seed)
>
> Is the return type of uint64 a typo?
Yes it is, will
On Sat, Apr 06, 2024 at 08:56:04AM +0900, Michael Paquier wrote:
> There is pg_read_all_stats as well, so I don't see a big issue in
> requiring to be a member of this role as well for the sake of what's
> proposing here.
Well, that tells you quite a bit more than just which PIDs correspond to
aut
On 4/6/24 01:53, Melanie Plageman wrote:
> On Fri, Apr 05, 2024 at 04:06:34AM -0400, Melanie Plageman wrote:
>> On Thu, Apr 04, 2024 at 04:35:45PM +0200, Tomas Vondra wrote:
>>>
>>>
>>> On 4/4/24 00:57, Melanie Plageman wrote:
On Sun, Mar 31, 2024 at 11:45:51AM -0400, Melanie Plageman wrote:
On Mon, Apr 1, 2024 at 8:06 AM James Coleman wrote:
>
> 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_predte
On Fri, Apr 05, 2024 at 05:18:51PM -0400, Tom Lane wrote:
> What I suggest Michael do with tanager is install the
> OS-version-appropriate version of GNU readline, so that the animal
> will test what ilmari describes as the actually common use-case.
Thanks for the investigations! It's clear that
On Fri, Apr 5, 2024 at 3:32 PM Daniel Gustafsson wrote:
> > An autoreconf run on my machine pulls in more changes (getting rid of
> > the symbols we no longer check for).
>
> Ah yes, missed updating before formatting the patch. Done in the attached.
The commit subject may still need to be reverte
On Fri, Apr 05, 2024 at 11:40:46AM -0700, Jacob Champion wrote:
> On Fri, Apr 5, 2024 at 6:24 AM Robert Haas wrote:
>> I'm also sort of afraid that we're getting sucked into thinking real
>> hard about this SSL certificate issue rather than trying to brainstorm
>> all the other places that might b
On Fri, Apr 05, 2024 at 07:56:56AM -0500, Nathan Bossart wrote:
> On Fri, Apr 05, 2024 at 02:39:05PM +0900, Michael Paquier wrote:
>> One thing that we should definitely not do is letting any user calling
>> pg_signal_backend() know that a given PID maps to an autovacuum
>> worker. This informatio
On Fri, Apr 05, 2024 at 01:26:29PM +0900, 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-sa
On Sat, Apr 6, 2024 at 6:55 AM Melanie Plageman
wrote:
> On Fri, Apr 5, 2024 at 12:15 AM Thomas Munro wrote:
> > The interesting column is hot. The 200ms->211ms regression is due to
> > the extra bookkeeping in the slow path. The rejiggered fastpath code
> > fixes it for me, or maybe sometimes
I wondered why buildfarm member copperhead has started to fail
xversion-upgrade-HEAD-HEAD tests. I soon reproduced the problem here:
pg_restore: creating ACL "regress_pg_dump_schema.TYPE "test_type""
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 4355; 0 0 ACL TYPE "test_type" build
On Sat, 6 Apr 2024 at 04:38, Nathan Bossart wrote:
> This seems to provide a small performance boost, so I've incorporated it
> into v27.
Won't Valgrind complain about this?
+pg_popcount_avx512(const char *buf, int bytes)
+ buf = (const char *) TYPEALIGN_DOWN(sizeof(__m512i), buf);
+ val = _mm
> > I think it ends up doing a copy thus the copy error in my log failures
> > which don't exist anywhere in the Makefil
> >
> > cp -pR ../../backend/storage/lmgr/lwlocknames.h
> >
> > Sorry for not checking on a linux system. I was thinking I should have done
> that first.
>
> Ah yeah, that's pe
> On 5 Apr 2024, at 22:55, Jacob Champion
> wrote:
>
> On Fri, Apr 5, 2024 at 9:59 AM Daniel Gustafsson wrote:
>> Attached is a WIP patch to get more eyes on it, the Meson test for 1.1.1
>> fails
>> on Windows in CI which I will investigate next.
The attached version fixes the Windows 1.1.1 c
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Hello
I think it is convenient to know the last commit LSN of a data
On Fri, Apr 5, 2024 at 2:48 PM Daniel Gustafsson wrote:
> But does that actually work? If I change the API_COMPAT to the 1.1.1 version
> number and run configure against 1.0.2 it passes just fine. Am I missing some
> clever trick here?
Similarly, I changed my API_COMPAT to a nonsense 0x9010
> On 5 Apr 2024, at 23:26, Peter Eisentraut wrote:
>
> On 05.04.24 18:59, Daniel Gustafsson wrote:
>> Attached is a WIP patch to get more eyes on it, the Meson test for 1.1.1
>> fails
>> on Windows in CI which I will investigate next.
>
> I'm not a fan of the new PGAC_CHECK_OPENSSL. It creates
On 05.04.24 18:59, Daniel Gustafsson wrote:
Attached is a WIP patch to get more eyes on it, the Meson test for 1.1.1 fails
on Windows in CI which I will investigate next.
I'm not a fan of the new PGAC_CHECK_OPENSSL. It creates a second place
where the OpenSSL version number has to be updated.
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Tom Lane writes:
>> So it seems like the bug does not exist in any currently-supported
>> NetBSD release. Debian has been known to ship obsolete libedit
>> versions, though.
> Both the current (bokworm/12) and previous (bullseye/11) versions o
On Fri, Apr 5, 2024 at 9:59 AM Daniel Gustafsson wrote:
> Attached is a WIP patch to get more eyes on it, the Meson test for 1.1.1 fails
> on Windows in CI which I will investigate next.
The changes for SSL_OP_NO_CLIENT_RENEGOTIATION and
SSL_R_VERSION_TOO_LOW look good to me.
> -Remove s
In hashfn_unstable.h, fasthash32() is declared as:
/* like fasthash64, but returns a 32-bit hashcode */
static inline uint64
fasthash32(const char *k, size_t len, uint64 seed)
Is the return type of uint64 a typo?
Regards,
Jeff Davis
On Fri, 2024-04-05 at 16:58 +0900, Masahiko Sawada wrote:
> IIUC for example in ReorderBuffer, the heap key is transaction size
> and the hash key is xid.
Yes.
>
> I see your point. It assumes that the bh_node_type is a pointer or at
> least unique. So it cannot work with Datum being a value.
R
After some more poking at this topic, I realize that there is already
very strange and undocumented behavior for backslash-dot even in
non-CSV mode. Create a file like this:
$ cat eofdata
foobar
foobaz\.
more
\.
yet more
and try importing it with COPY:
regression=# create table eofdata(f1 text)
On 2024-04-05 Fr 10:12, Andrew Dunstan wrote:
On 2024-04-05 Fr 08:25, Andrew Dunstan wrote:
Here is an attempt to fix all that. It's ugly, but I think it's more
principled.
First, instead of getting the ldopts and then trying to filter out
the ldflags and ccdlflags, it tells perl not to
On 2024-04-05 Fr 11:43, Nathan Bossart wrote:
On Fri, Apr 05, 2024 at 10:15:45AM -0400, Andrew Dunstan wrote:
On 2024-04-04 Th 15:54, Nathan Bossart wrote:
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 warning
CopyReadLineText quoth:
* The objective of this loop is to transfer the entire next input line
* into line_buf. Hence, we only care for detecting newlines (\r and/or
* \n) and the end-of-copy marker (\.).
*
* In CSV mode, \r and \n inside a quoted field are just part of t
"Daniel Verite" writes:
> Tom Lane wrote:
>> Not sure what to do here. One idea is to install just the psql-side
>> fix, which should break nothing now that version-2 protocol is dead,
>> and then wait a few years before introducing the server-side change.
>> That seems kind of sad though.
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
All three patches applied nivcely.
Code fits standart, commen
On Fri, Apr 5, 2024 at 6:24 AM Robert Haas wrote:
> I wonder how hard it would be to just code up our own binary to do
> this. If it'd be a pain to do that, or to maintain it across SSL
> versions, then it's a bad plan and we shouldn't do it. But if it's not
> that much code, maybe it'd be worth c
On Fri, 2024-04-05 at 13:54 +0200, Alvaro Herrera wrote:
> Couldn't push: I tested with --disable-atomics --disable-spinlocks
> and
> the tests fail because the semaphore for the atomic variables is not
> always initialized. This is weird -- it's like a client process is
> running at a time when S
Hello,
BTW I noticed that
https://coverage.postgresql.org/src/backend/commands/waitlsn.c.gcov.html
says that lsn_cmp is not covered by the tests. This probably indicates
that the tests are a little too light, but I'm not sure how much extra
effort we want to spend.
I'm still concerned that Wait
On 2024-Apr-05, Regina Obe wrote:
> I think it ends up doing a copy thus the copy error in my log failures which
> don't exist anywhere in the Makefil
>
> cp -pR ../../backend/storage/lmgr/lwlocknames.h
>
> Sorry for not checking on a linux system. I was thinking I should have done
> that fir
>
>
> Plus, you've got all of the consequences for non-core drivers, which
> have to both add support for the new wire protocol - if they don't
> want to seem outdated and eventually obsolete - and also test that
> they're still compatible with all supported server versions.
> Connection poolers ha
> > I think I got something not too far off from what's there now that works
> under my msys2 setup again. This is partly using your idea of using
> $(top_builddir) to qualify the path but in the LN_S section that is causing me
> grief.
> > This seems to work okay building in tree and out of tree.
On Fri, Apr 5, 2024 at 12:15 AM Thomas Munro wrote:
>
> 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 prefet
Pushed 0001. Here's the patch that adds the Copy position one more
time, with the monotonic_advance function returning the value.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
>From 3f5c860576245b92701e7bfc517947c418c68510 Mon Sep 17 00:00:00 2001
From: Alvaro
On Fri, Apr 5, 2024 at 2:59 AM Jakub Wartak
wrote:
> And of course i'm attaching reproducer with some braindump notes in
> case in future one hits similiar issue and wonders where to even start
> looking (it's very primitive though but might help).
Thanks. I've committed the patch now.
--
Rober
On 2024-Apr-04, Regina Obe wrote:
> I think I got something not too far off from what's there now that works
> under my msys2 setup again. This is partly using your idea of using
> $(top_builddir) to qualify the path but in the LN_S section that is causing
> me grief.
> This seems to work okay
On Fri, Apr 05, 2024 at 04:12:06PM +, Sriram RK wrote:
>
> > What you do need to do to reproduce the described problems is
> > check out the Postgres git tree and rewind to just before
> > commit 0b16bb877, where we deleted AIX support. Any attempt
> > to restore AIX support would have to sta
> On 5 Apr 2024, at 18:41, Jacob Champion
> wrote:
> On Thu, Apr 4, 2024 at 6:37 PM Michael Paquier wrote:
>> I would be OK to draw a line to what we test in the buildfarm if it
>> comes to that, down to OpenBSD 6.9.
>
> That would correspond to LibreSSL 3.3 if I'm not mistaken. Any
> particul
> On 5 Apr 2024, at 03:37, Michael Paquier wrote:
> 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
On Fri, 5 Apr 2024 at 18:43, Tom Lane wrote:
> I don't buy that argument, actually. libpq, and pretty much every
> other client AFAIK, has provisions to let higher code levels insert
> random options into the startup packet. So to make this work libpq
> would have to filter or at least inspect s
Tom Lane wrote:
> Not sure what to do here. One idea is to install just the psql-side
> fix, which should break nothing now that version-2 protocol is dead,
> and then wait a few years before introducing the server-side change.
> That seems kind of sad though.
Wouldn't backpatching solve
On Fri, 5 Apr 2024 at 18:30, Dave Cramer wrote:
>> > I really intended the _pq_ prefix as a way of taking something out of
>> > the GUC namespace, not as a part of the GUC namespace that users would
>> > see. And I'm reluctant to go back on that. If we want to make
>> > pg_protocol.${NAME} mean a
On Fri, Apr 5, 2024 at 12:09 PM Jelte Fennema-Nio wrote:
> But I do think that we shouldn't be at all averse to the act of
> bumping the protocol version itself. If we have a single small
> protocol change in one release, then imho it's no problem to bump the
> protocol version. Bumping the versio
Dave Cramer writes:
> On Fri, 5 Apr 2024 at 12:09, Jelte Fennema-Nio wrote:
>> Setting PGC_PROTOCOL gucs would be allowed in the startup packet,
>> which is fine afaict because that's also something that's part of the
>> protocol level and is thus fully controlled by client libraries and
>> poole
On Thu, Apr 4, 2024 at 6:37 PM Michael Paquier wrote:
> From where did you pull the LibreSSL sources? Directly from the
> OpenBSD tree?
I've been building LibreSSL Portable: https://github.com/libressl/portable
> Ah, right. OpenSSL_add_all_algorithms() is documented as having no
> effect in 1.
On Fri, 5 Apr 2024 at 12:09, Jelte Fennema-Nio wrote:
> On Fri, 5 Apr 2024 at 16:02, Robert Haas wrote:
> > Often?
> >
> > I kind of hope that the protocol starts to evolve a bit more than it
> > has, but I don't want a continuous stream of changes. That will be
> > very hard to test and verify
I wrote:
> So this means that the patch introduces a rather serious cross-version
> compatibility problem. I doubt we can consider inlined CSV data to be
> a niche case that few people use; but it will fail every time if your
> psql is older than your server.
On third thought, that may not be as
On Fri, Apr 5, 2024 at 9:18 AM Robert Haas wrote:
> On Fri, Apr 5, 2024 at 12:15 PM David G. Johnston
> wrote:
> > Here is a link to my attempt at this a couple of years ago. It
> basically "abuses" refentry.
> >
> >
> https://www.postgresql.org/message-id/CAKFQuwaVm%3D6d_sw9Wrp4cdSm5_k%3D8ZVx0
On Fri, 5 Apr 2024 at 17:24, Andres Freund wrote:
> I recommend opening a bug report for clang, best with an already preprocessed
> input file.
> We're going to need to do something about this from our side as well, I
> suspect. The times aren't great with gcc either, even if not as bad as with
>
On Fri, Apr 5, 2024 at 12:15 PM David G. Johnston
wrote:
> Here is a link to my attempt at this a couple of years ago. It basically
> "abuses" refentry.
>
> https://www.postgresql.org/message-id/CAKFQuwaVm%3D6d_sw9Wrp4cdSm5_k%3D8ZVx0--v2v4BH4KnJtqXqg%40mail.gmail.com
>
> I never did dive into th
On Fri, Apr 5, 2024 at 9:01 AM Robert Haas wrote:
>
> > The rendering can be adjusted to some degree, but then we also need to
> > make sure any new chunking makes sense in other chapters. (And it might
> > also change a bunch of externally known HTML links.)
>
> I looked into this and I'm uncle
> What you do need to do to reproduce the described problems is
> check out the Postgres git tree and rewind to just before
> commit 0b16bb877, where we deleted AIX support. Any attempt
> to restore AIX support would have to start with reverting that
> commit (and perhaps the followup f0827b443).
On Fri, 5 Apr 2024 at 16:02, Robert Haas wrote:
> Often?
>
> I kind of hope that the protocol starts to evolve a bit more than it
> has, but I don't want a continuous stream of changes. That will be
> very hard to test and verify correctness, and a hassle for drivers to
> keep up with, and a mess
> The original \conninfo was designed to report values from the libpq API
> about what libpq connected to. And the convention in psql is that "+"
> provide more or less the same information but a bit more. So I think it
> is wrong to make "\conninfo+" something fundamentally different than
> "\conn
"Daniel Verite" writes:
> Tom Lane wrote:
>> I've looked over this patch and I generally agree that this is a
>> reasonable solution.
> Thanks for reviewing this!
While testing this, I tried running the tests with an updated server
and non-updated psql, and not only did the new test case f
> On Fri, Apr 05, 2024 at 03:50:50PM +0200, Dmitry Dolgov wrote:
> > On Fri, Apr 05, 2024 at 03:21:06PM +0200, Dmitry Dolgov wrote:
> > > On Sat, Apr 06, 2024 at 02:00:38AM +1300, Thomas Munro wrote:
> > > On Sun, Mar 31, 2024 at 12:49 PM Thomas Munro
> > > wrote:
> > > > https://github.com/llvm/
On Mon, Mar 25, 2024 at 11:40 AM Peter Eisentraut wrote:
> I think a possible problem we need to consider with these proposals to
> combine chapters is that they could make the chapters themselves too
> deep and harder to navigate.
I looked into various options for further combining chapters and/
Hi, hackers!
On Tue, 2 Apr 2024 at 19:17, Jeff Davis wrote:
> On Tue, 2024-04-02 at 11:49 +0300, Alexander Korotkov wrote:
> > I don't like the idea that every custom table AM reltoptions should
> > begin with StdRdOptions. I would rather introduce the new data
> > structure with table options,
On Fri, Apr 05, 2024 at 10:15:45AM -0400, Andrew Dunstan wrote:
> On 2024-04-04 Th 15:54, Nathan Bossart wrote:
>> 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
On Fri, Apr 05, 2024 at 07:58:44AM -0500, Nathan Bossart wrote:
> On Fri, Apr 05, 2024 at 10:33:27AM +0300, Ants Aasma wrote:
>> The main issue I saw was that clang was able to peel off the first
>> iteration of the loop and then eliminate the mask assignment and
>> replace masked load with a memor
On Thu, Apr 4, 2024 at 12:39 PM Andres Freund wrote:
>
> 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,
On Fri, 5 Apr 2024 at 16:04, Robert Haas wrote:
>
> On Thu, Apr 4, 2024 at 1:10 PM Jelte Fennema-Nio wrote:
> > Attached is a rebased patchset
>
> We should keep talking about this, but I think we're far too close to
> the wire at this point to think about committing anything for v17 at
> this po
Hi,
On 2024-04-05 15:36:34 +0200, Jelte Fennema-Nio wrote:
> On Fri, 5 Apr 2024 at 00:45, Jelte Fennema-Nio wrote:
> > It improved clean build times on my machine (10 cores/20 threads) from ~40
> > seconds to ~30 seconds.
>
> After discussing this off-list with Bilal, I realized that this gain
>
Hi,
On Fri, Apr 05, 2024 at 02:35:42PM +, Bertrand Drouvot wrote:
> I think that maybe as a first step we should move the "elog(DEBUG2," message
> as
> proposed above to help debugging (that could help to confirm the above
> theory).
If you agree and think that makes sense, pleae find attac
On Fri, Mar 29, 2024 at 9:40 AM Robert Haas wrote:
> 2. Demote "Monitoring Disk Usage" from a chapter on its own to a
> section of the "Monitoring Database Activity" chapter. I haven't seen
> any objections to this, and I'd like to move ahead with it.
>
> 3. Merge the separate chapters on various
On 04.04.24 18:15, Maiquel Grassi wrote:
Well, I can revert \conninfo to its original state and keep \conninfo+
as it is, perhaps removing the application name, as I believe everything
else is important for a DBA/SysAdmin. Do you think we can proceed
with the patch this way? I am open to ideas th
Hi,
On Fri, Apr 05, 2024 at 06:23:10PM +0530, Amit Kapila wrote:
> On Fri, Apr 5, 2024 at 5:17 PM Amit Kapila wrote:
> Thinking more on this, it doesn't seem related to
> c9920a9068eac2e6c8fb34988d18c0b42b9bf811 as that commit doesn't change
> any locking or something like that which impacts writ
Matthias van de Meent writes:
> On Thu, 4 Apr 2024 at 22:43, Tom Lane wrote:
>> The only objection I can think of is that perhaps this would slow
>> things down a tad by requiring more complicated shifting/masking.
>> I wonder if we could redo the performance checks that were done
>> on the way t
On 2024-04-04 Th 15:54, Nathan Bossart wrote:
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.
On 2024-04-04 Th 17:24, Tom Lane wrote:
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
On 2024-04-05 Fr 08:25, Andrew Dunstan wrote:
Here is an attempt to fix all that. It's ugly, but I think it's more
principled.
First, instead of getting the ldopts and then trying to filter out the
ldflags and ccdlflags, it tells perl not to include those in the first
place, by overridi
On Thu, Apr 4, 2024 at 1:10 PM Jelte Fennema-Nio wrote:
> Attached is a rebased patchset
We should keep talking about this, but I think we're far too close to
the wire at this point to think about committing anything for v17 at
this point. These are big changes, they haven't been thoroughly
revie
On Thu, Apr 4, 2024 at 12:45 PM Jelte Fennema-Nio wrote:
> Yeah, we definitely think differently here then. To me bumping the
> minor protocol version shouldn't be a thing that we would need to
> carefully consider. It should be easy to do, and probably done often.
Often?
I kind of hope that the
> On Fri, Apr 05, 2024 at 03:21:06PM +0200, Dmitry Dolgov wrote:
> > On Sat, Apr 06, 2024 at 02:00:38AM +1300, Thomas Munro wrote:
> > On Sun, Mar 31, 2024 at 12:49 PM Thomas Munro
> > wrote:
> > > https://github.com/llvm/llvm-project/pull/87093
> >
> > Oh, with those clues, I think I might see..
On Fri, 5 Apr 2024 at 00:45, Jelte Fennema-Nio wrote:
> It improved clean build times on my machine (10 cores/20 threads) from ~40
> seconds to ~30 seconds.
After discussing this off-list with Bilal, I realized that this gain
is only happening for clang builds on my system. Because those take a
l
1 - 100 of 131 matches
Mail list logo
