> On 6 Apr 2024, at 08:02, Peter Eisentraut wrote:
>
> 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 ch
> On 6 Apr 2024, at 01:10, Tom Lane wrote:
> (So now I'm wondering why *only* copperhead has shown this so far.
> Are our other cross-version-upgrade testing animals AWOL?)
Clicking around searching for Xversion animals I didn't spot any, but without
access to the database it's nontrivial to kno
On Sat, 6 Apr 2024 at 03:34, David Rowley wrote:
> Does anyone else want to try the attached script on the v5 patch to
> see if their numbers are better?
On my machine (i9-10900X, in Ubuntu 22.04 on WSL on Windows) v5
consistently beats master by ~0.25 seconds:
master:
Run 100 100 500: 1.948
> On 29 Feb 2024, at 06:59, Kyotaro Horiguchi wrote:
>
> At Sat, 3 Feb 2024 22:32:45 +0500, "Andrey M. Borodin"
> wrote in
>> Here's the test draft. This test reliably reproduces sleep on CV when
>> waiting next multixact to be filled into "members" SLRU.
>
> By the way, I raised a questi
On Sat, Apr 6, 2024 at 12:18 PM Amit Kapila 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 s
On Sat, 6 Apr 2024 at 23:17, Jelte Fennema-Nio wrote:
> Weird that on your machines you don't see a difference. Are you sure
> you didn't make a silly mistake, like not restarting postgres or
> something?
I'm sure. I spent quite a long time between the AMD and an Apple m2 trying.
I did see the s
On Sat, Apr 06, 2024 at 02:51:45AM +0200, Tomas Vondra wrote:
>
>
> 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:
> >>
Daniel Gustafsson writes:
>> On 6 Apr 2024, at 08:02, Peter Eisentraut wrote:
>> Why do we need to check for the versions at all? We should just check for
>> the functions we need. At least that's always been the normal approach in
>> configure.
> We could, but finding a stable set of functi
On Fri, Apr 5, 2024 at 8:35 PM Amit Langote wrote:
>
> On Thu, Apr 4, 2024 at 9:02 PM Amit Langote wrote:
> > I'll post the rebased 0002 tomorrow after addressing your comments.
>
> Here's one. Main changes:
>
> * Fixed a bug in get_table_json_columns() which caused nested columns
> to be depars
On 4/6/24 02:51, Tomas Vondra wrote:
>
> * The one question I'm somewhat unsure about is why Tom chose to use the
> "wrong" recheck flag in the 2017 commit, when the correct recheck flag
> is readily available. Surely that had a reason, right? But I can't think
> of one ...
>
I've been wondering
On 4/6/24 15:40, Melanie Plageman wrote:
> On Sat, Apr 06, 2024 at 02:51:45AM +0200, Tomas Vondra wrote:
>>
>>
>> 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:
> O
Melanie Plageman writes:
> On Sat, Apr 06, 2024 at 02:51:45AM +0200, Tomas Vondra wrote:
>> * The one question I'm somewhat unsure about is why Tom chose to use the
>> "wrong" recheck flag in the 2017 commit, when the correct recheck flag
>> is readily available. Surely that had a reason, right? B
Hi,
On Sat, Apr 6, 2024 at 3:55 PM jian he wrote:
> 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_TABL
On Sat, Apr 06, 2024 at 04:57:51PM +0200, Tomas Vondra wrote:
> On 4/6/24 15:40, Melanie Plageman wrote:
> > On Sat, Apr 06, 2024 at 02:51:45AM +0200, Tomas Vondra wrote:
> >>
> >>
> >> On 4/6/24 01:53, Melanie Plageman wrote:
> >>> On Fri, Apr 05, 2024 at 04:06:34AM -0400, Melanie Plageman wrote:
On 2024-Apr-05, Jeff Davis wrote:
> Minor comments:
> * Also, I assume that the Max() call in
> pg_atomic_monotonic_advance_u64() is just for clarity? Surely the
> currval cannot be less than _target when it returns. I'd probably just
> do Assert(currval >= _target) and then return currval.
Uhh
Hi,
On Sat, Apr 06, 2024 at 10:13:00AM +0530, Amit Kapila wrote:
> On Fri, Apr 5, 2024 at 8:05 PM Bertrand Drouvot
> wrote:
>
> I think the new LSN can be visible only when the corresponding WAL is
> written by XLogWrite(). I don't know what in XLogSetAsyncXactLSN() can
> make it visible. In you
I wrote:
> So the current behavior is that \. that is on the end of a line,
> but is not the whole line, is silently discarded and we keep going.
> All versions throw "end-of-copy marker corrupt" if there is
> something after \. on the same line.
> This is sufficiently weird that I'm starting to
On Sat, 6 Apr 2024, 14:36 David Rowley, wrote:
> On Sat, 6 Apr 2024 at 02:30, Matthias van de Meent
> wrote:
> >
> > On Thu, 4 Apr 2024 at 22:43, Tom Lane wrote:
> > >
> > > Matthias van de Meent writes:
> > > > It extends memory context IDs to 5 bits (32 values), of which
> > > > - 8 have gli
On Sat, 2024-04-06 at 18:13 +0200, Alvaro Herrera wrote:
> my understanding of pg_atomic_compare_exchange_u64 is that
> *expected is set to the value that's stored in *ptr prior to the
> exchange.
Sorry, my mistake. Your version looks good.
Regards,
Jeff Davis
> On 6 Apr 2024, at 16:04, Tom Lane wrote:
> Daniel Gustafsson writes:
>>> On 6 Apr 2024, at 08:02, Peter Eisentraut wrote:
>>> Why do we need to check for the versions at all? We should just check for
>>> the functions we need. At least that's always been the normal approach in
>>> configu
Hello all
The issue described bellow exists in postgresql ver 16.2 (found in some
previous major versions)
The documentation defines a comment as:
> A comment is a sequence of characters beginning with double dashes and
> extending to the end of the line
When using such a comment within CASE c
On Sat, Apr 06, 2024 at 02:51:39PM +1300, David Rowley wrote:
> 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 = (
Hi,
On 2024-04-06 14:34:17 +1300, David Rowley wrote:
> I don't see any issues with v5, so based on the performance numbers
> shown on this thread for the latest patch, it would make sense to push
> it. The problem is, I just can't recreate the performance numbers.
>
> I've tried both on my AMD 3
On 2024-04-06 20:14 +0200, Michal Bartak wrote:
> The issue described bellow exists in postgresql ver 16.2 (found in some
> previous major versions)
Can confirm also on master.
> The documentation defines a comment as:
>
> > A comment is a sequence of characters beginning with double dashes and
>
>
>
> I think it'll be a serious, serious error for this not to be
> SECTION_DATA. Maybe POST_DATA is OK, but even that seems like
> an implementation compromise not "the way it ought to be".
>
We'd have to split them on account of when the underlying object is
created. Index statistics would b
Hi,
On Fri, 5 Apr 2024 at 03:28, Melih Mutlu
wrote:
>Right. It was a mistake, forgot to remove that. Fixed it in v5.
If you don't mind, I have some suggestions for patch v5.
1. Shouldn't PqSendBufferSize be of type size_t?
There are several comparisons with other size_t variables.
static size_
Hi,
On 2024-04-06 10:58:32 +0530, Amit Kapila wrote:
> 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 com
Hi,
I recently started to be bothered by regress_* logs after some kinds of test
failures containing the whole log of a test failure. E.g. in
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus&dt=2024-04-06%2016%3A28%3A38
...
### Restarting node "standby"
# Running: pg_ctl -w -D
/ho
Hi, Alvaro!
Thank you for your care on this matter.
On Fri, Apr 5, 2024 at 9:15 PM Alvaro Herrera wrote:
> 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
For every complex problem there is an answer that is clear, simple, and wrong.
Since the RFC allows microsecond timestamp granularity, the first thing that
comes to everyone's mind is to insert microsecond granularity into UUIDv7. And
if the RFC allowed nanosecond timestamp granularity, then the
Tom Lane wrote:
> This is sufficiently weird that I'm starting to come around to
> Daniel's original proposal that we just drop the server's recognition
> of \. altogether (which would allow removal of some dozens of lines of
> complicated and now known-buggy code)
FWIW my plan was to not
On Fri, 5 Apr 2024 at 18:48, Robert Haas wrote:
> Maybe we'd be better off adding a libpq connection
> option that forces the use of a specific minor protocol version, but
> then we'll need backward-compatibility code in libpq basically
> forever. But maybe we need that anyway to avoid older and n
> On 6 Apr 2024, at 23:44, Andres Freund wrote:
> It might be useful to print a few lines, but the whole log files can be
> several megabytes worth of output.
The non-context aware fix would be to just print the last 1024 (or something)
bytes from the logfile:
diff --git a/src/test/perl/Postgre
Hi, Dmitry!
On Fri, Apr 5, 2024 at 4:00 PM Dmitry Koval wrote:
> > I've revised the patchset.
>
> Thanks for the corrections (especially ddl.sgml).
> Could you also look at a small optimization for the MERGE PARTITIONS
> command (in a separate file
> v31-0003-Additional-patch-for-ALTER-TABLE-.-ME
Hi, Alexander!
I didn't push 0003 for the following reasons.
Thanks for clarifying. You are right, these are serious reasons.
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
On Sat, 6 Apr 2024 at 22:21, Andres Freund wrote:
> The small regression for small results is still kinda visible, I haven't yet
> tested the patch downthread.
Thanks a lot for the faster test script, I'm also impatient. I still
saw the small regression with David his patch. Here's a v6 where I
t
On second thoughts, I think the original "invalidate" terminology was
fine, no need to invent a new term.
I thought of a better name for the bufmgr.c function though:
InvalidateUnpinnedBuffer(). That name seemed better to me after I
festooned it with warnings about why exactly it's inherently rac
On Sun, 7 Apr 2024 at 05:45, Matthias van de Meent
wrote:
> Malloc's docs specify the minimum chunk size at 4*sizeof(void*) and itself
> uses , so using powers of 2 for chunks would indeed fail to detect 1s in the
> 4th bit. I suspect you'll get different results when you check the allocation
>
On 4/6/24 23:34, Melanie Plageman wrote:
> ...
>>
>> I realized it makes more sense to add a FIXME (I used XXX. I'm not when
>> to use what) with a link to the message where Andres describes why he
>> thinks it is a bug. If we plan on fixing it, it is good to have a record
>> of that. And it makes
On Sun, 7 Apr 2024, 01:59 David Rowley, wrote:
> On Sun, 7 Apr 2024 at 05:45, Matthias van de Meent
> wrote:
> > Malloc's docs specify the minimum chunk size at 4*sizeof(void*) and
> itself uses , so using powers of 2 for chunks would indeed fail to detect
> 1s in the 4th bit. I suspect you'll g
Hi,
On 2024-04-07 00:19:35 +0200, Daniel Gustafsson wrote:
> > On 6 Apr 2024, at 23:44, Andres Freund wrote:
>
> > It might be useful to print a few lines, but the whole log files can be
> > several megabytes worth of output.
>
> The non-context aware fix would be to just print the last 1024 (o
So what was really bothering me about this patchset was that I
didn't think marginal performance gains were a sufficient reason
to put a whole different operating mode into libpq. However,
I've reconsidered after realizing that implementing FETCH_COUNT
atop traditional single-row mode would requir
I found a bug in read_stream.c that could be hit with Melanie's
streaming seq scan patch with parallelism enabled and certain buffer
pool conditions. Short version: there is an edge case where an "if"
needed to be a "while", or we could lose a few blocks. Here's the fix
for that, longer explanati
On Sat, Apr 6, 2024 at 9:25 PM Thomas Munro wrote:
>
> I found a bug in read_stream.c that could be hit with Melanie's
> streaming seq scan patch with parallelism enabled and certain buffer
> pool conditions. Short version: there is an edge case where an "if"
> needed to be a "while", or we could
Hi,
On 2024-04-07 00:45:31 +0200, Jelte Fennema-Nio wrote:
> On Sat, 6 Apr 2024 at 22:21, Andres Freund wrote:
> > The small regression for small results is still kinda visible, I haven't yet
> > tested the patch downthread.
>
> Thanks a lot for the faster test script, I'm also impatient. I stil
On Tue, Jan 30, 2024 at 4:13 AM Ants Aasma wrote:
>
> But given that we know the data length and we have it in a register
> already, it's easy enough to just mask out data past the end with a
> shift. See patch 1. Performance benefit is about 1.5x Measured on a
> small test harness that just hashe
On Mon, Apr 1, 2024 at 9:54 AM Masahiko Sawada wrote:
>
> Thank you! I've attached the patch that I'm going to push tomorrow.
Excellent!
I've attached a mostly-polished update on runtime embeddable values,
storing up to 3 offsets in the child pointer (1 on 32-bit platforms).
As discussed, this i
On Sun, Apr 7, 2024 at 12:00:25AM +0200, Daniel Verite wrote:
> Tom Lane wrote:
>
> > This is sufficiently weird that I'm starting to come around to
> > Daniel's original proposal that we just drop the server's recognition
> > of \. altogether (which would allow removal of some dozens of li
Hi, Pavel!
On Fri, Apr 5, 2024 at 6:58 PM Pavel Borisov wrote:
> 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 rathe
On Sat, Apr 06, 2024 at 02:41:01PM -0500, Nathan Bossart wrote:
> Here is what I have staged for commit, which I intend to do shortly.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Bruce Momjian writes:
> On Sun, Apr 7, 2024 at 12:00:25AM +0200, Daniel Verite wrote:
>> Agreed we don't want to document that, but also why doesn't \. in the
>> contents represent just a dot (as opposed to being an error),
>> just like \a is a?
> I looked into this and started to realize that
On Sun, Apr 07, 2024 at 02:27:43AM +0200, Tomas Vondra wrote:
> On 4/6/24 23:34, Melanie Plageman wrote:
> > ...
> >>
> >> I realized it makes more sense to add a FIXME (I used XXX. I'm not when
> >> to use what) with a link to the message where Andres describes why he
> >> thinks it is a bug. If w
hi.
about v50.
+/*
+ * JsonTableSiblingJoin -
+ * Plan to union-join rows of nested paths of the same level
+ */
+typedef struct JsonTableSiblingJoin
+{
+ JsonTablePlan plan;
+
+ JsonTablePlan *lplan;
+ JsonTablePlan *rplan;
+} JsonTableSiblingJoin;
"Plan to union-join rows of nested paths of the
Erik Wienhold writes:
> On 2024-04-06 20:14 +0200, Michal Bartak wrote:
>> The issue described bellow exists in postgresql ver 16.2 (found in some
>> previous major versions)
> Can confirm also on master.
I'm sure it's been there a while :-(
> I'm surprised that the comment is not skipped by th
Hi,
On 2024-01-22 13:01:31 +0700, John Naylor wrote:
> On Mon, Jul 17, 2023 at 9:58 PM Andres Freund wrote:
> > And 397->320ms
> > for something as core as this, is imo worth considering on its own.
>
> Hi Andres, this interesting work seems to have fallen off the radar --
> are you still planni
On Sun, Apr 7, 2024 at 11:49 AM Andres Freund wrote:
>
> Hi,
>
> On 2024-01-22 13:01:31 +0700, John Naylor wrote:
> > On Mon, Jul 17, 2023 at 9:58 PM Andres Freund wrote:
> > > And 397->320ms
> > > for something as core as this, is imo worth considering on its own.
> >
> > Hi Andres, this interes
> On 15 Mar 2024, at 17:12, Nazir Bilal Yavuz wrote:
>
> I did not have the time to check other things you mentioned but I
> tested the read performance. The table size is 5.5GB, I did 20 runs in
> total.
Hi Nazir!
Do you plan to review anything else? Or do you think it worth to look at by
> On 3 Jan 2024, at 15:15, Pavel Borisov wrote:
>
> Hi and Happy New Year!
>
> I've looked through the patches and the change seems quite small and
> justified. But at the second round, some doubt arises on whether this long
> patchset indeed introduces enough performance gain? I may be wro
58 matches
Mail list logo
