On 2023-04-15 05:22, Tom Lane wrote:
Thomas Munro writes:
On Sat, Apr 15, 2023 at 7:50 AM Mikael Kjellström
wrote:
want me to switch to clang instead?
I vote +1, that's the system compiler in modern OpenBSD.
Ditto, we need coverage of that.
OK. I switched to clang on morepork now.
David Rowley writes:
> I don't think that's really going to help. The crash already tells us
> there's a problem down the line, but if the commit you mention is to
> blame for this, then the problem is elsewhere, either in our
> assumption that we can get away without the datumCopy() or in the
>
Thomas Munro writes:
> On Sat, Apr 15, 2023 at 7:50 AM Mikael Kjellström
> wrote:
>> want me to switch to clang instead?
> I vote +1, that's the system compiler in modern OpenBSD.
Ditto, we need coverage of that.
> As for curculio, I don't understand the motivation for maintaining
> that
On Fri, Apr 14, 2023 at 05:04:35PM +0100, Dagfinn Ilmari Mannsåker wrote:
> Looks like I completely dropped the ball on this one, sorry.
So did I ;)
> Here's a
> rebased patch which uses the new COMPLETE_WITH_QUERY_PLUS functionality
> added in commit 02b8048ba5dc36238f3e7c3c58c5946220298d71.
On Sat, 15 Apr 2023 at 13:03, Justin Pryzby wrote:
> Maybe you'll find valgrind errors to be helpful.
I don't think that's really going to help. The crash already tells us
there's a problem down the line, but if the commit you mention is to
blame for this, then the problem is elsewhere, either
On Fri, 14 Apr 2023 at 13:06, vignesh C wrote:
>
> Few comments:
Some more comments on 0001 patch:
Few comments:
1) We could add a space after the 2nd parameter
+ * Note we don't have the luxury of sprintf-like compiler warnings for
+ * malformed argument lists.
+ */
+static ObjTree *
Maybe you'll find valgrind errors to be helpful.
==17971== Source and destination overlap in memcpy(0x1eb8c078, 0x1d88cb20,
123876054)
==17971==at 0x4C2E81D: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1035)
==17971==by 0x9C705A: memcpy (string3.h:51)
==17971==by 0x9C705A:
David Rowley writes:
> Any chance you could try and come up with a minimal reproducer?
Yeah --- there's an awful lot of moving parts there, and a stack
trace is not much to go on.
regards, tom lane
On Fri, 14 Apr 2023 at 19:20, Peter Eisentraut
wrote:
>
> I came across these new options and had a little bit of trouble figuring
> them out from the documentation. Maybe this could be polished a bit.
>
> vacuumdb --help says
>
> --buffer-usage-limit=BUFSIZE
>
> I can guess what a "SIZE"
On Sat, Apr 15, 2023 at 7:50 AM Mikael Kjellström
wrote:
> want me to switch to clang instead?
I vote +1, that's the system compiler in modern OpenBSD.
https://www.cambus.net/the-state-of-toolchains-in-openbsd/
As for curculio, I don't understand the motivation for maintaining
that machine.
On Sat, 15 Apr 2023 at 10:48, Justin Pryzby wrote:
>
> On Sat, Apr 15, 2023 at 10:04:52AM +1200, David Rowley wrote:
> > Which aggregate function is being called here? Is it a custom
> > aggregate written in C, by any chance?
>
> That function is not an aggregate:
There's an aggregate somewhere
Hi there,
In my implementation of CustomScan, when I have a query that scans multiple
tables (select c from t1,t2,t3), the planner always picks one table to be
scanned by CustomScan and offloads the rest to SeqScan. I tried assigning a
cost of 0 to the CustomScan path, but still not working.
On Sat, Apr 15, 2023 at 7:38 AM Tom Lane wrote:
> Andres Freund writes:
> > On 2023-04-14 15:21:18 -0400, Tom Lane wrote:
> >> +1 for that, though. (Also, the fact that these animals aren't
> >> actually failing suggests that 004_io_direct.pl needs expansion.)
>
> > It's skipped, due to lack of
On Sat, Apr 15, 2023 at 10:04:52AM +1200, David Rowley wrote:
> On Sat, 15 Apr 2023 at 08:36, Justin Pryzby wrote:
> >
> > I hit this elog() while testing reports under v16 and changed to PANIC
> > to help diagnose.
> >
> > DETAILS: PANIC: invalid memory alloc request size 18446744072967930808
>
> On 14 Apr 2023, at 19:34, Jacob Champion wrote:
>
> On Fri, Apr 14, 2023 at 7:20 AM Daniel Gustafsson wrote:
>> And again with the attachment.
>
> After some sleep... From inspection I think the final EOF branch could
> be masked by the new branch, if verification has failed but was already
On Sat, 15 Apr 2023 at 08:36, Justin Pryzby wrote:
>
> I hit this elog() while testing reports under v16 and changed to PANIC
> to help diagnose.
>
> DETAILS: PANIC: invalid memory alloc request size 18446744072967930808
> CONTEXT: PL/pgSQL function array_weight(real[],real[]) while storing
I hit this elog() while testing reports under v16 and changed to PANIC
to help diagnose.
DETAILS: PANIC: invalid memory alloc request size 18446744072967930808
CONTEXT: PL/pgSQL function array_weight(real[],real[]) while storing call
arguments into local variables
I can't share the query,
On Tue, Mar 28, 2023 at 9:40 PM Michael Paquier wrote:
> Looking at the patch, nothing really stands out..
It doesn't seem like anyone's unhappy about this patch. I don't think
it's necessary to back-patch it, given that in-place tablespaces are
intended for developer use, not real-world use,
Andres Freund writes:
> On 2023-04-14 15:21:18 -0400, Tom Lane wrote:
>> +1 for that, though. (Also, the fact that these animals aren't
>> actually failing suggests that 004_io_direct.pl needs expansion.)
> It's skipped, due to lack of O_DIRECT:
> [20:50:22] t/004_io_direct.pl ..
On Fri, Apr 14, 2023 at 10:47 AM Andres Freund wrote:
> I don't think it's outright wrong, but it is very confusing what it relates
> to. For some reason I tried to "attach" the parenthetical to the "otherwise",
> which doesn't make a whole lot of sense. How about:
I suppose that it doesn't
Hi,
On 2023-04-14 15:21:18 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-04-14 13:21:33 -0400, Tom Lane wrote:
> >> ... I'm not sure why only those two animals
> >> are unhappy, but I think they have a point: typical ABIs don't
> >> guarantee alignment of function stack frames to
Andres Freund writes:
> On 2023-04-14 13:21:33 -0400, Tom Lane wrote:
>> ... I'm not sure why only those two animals
>> are unhappy, but I think they have a point: typical ABIs don't
>> guarantee alignment of function stack frames to better than
>> 16 bytes or so. In principle the compiler
On 4/14/23 1:15 PM, Laurenz Albe wrote:
Let's remove vacuum_defer_cleanup_age, and put a note in the release notes
that recommends using statement_timeout and hot_standby_feedback = on
on the standby instead.
That should have pretty much the same effect, and it is measured in
time and not in
Hi,
On 2023-04-14 13:21:33 -0400, Tom Lane wrote:
> Since the direct I/O commit went in, buildfarm animals
> curculio and morepork have been issuing warnings like
>
> hashpage.c: In function '_hash_expandtable':
> hashpage.c:995: warning: ignoring alignment for stack allocated 'zerobuf'
>
> in
Andres Freund writes:
> I pushed the fix + test now.
Cool, thanks.
regards, tom lane
Hi,
On 2023-04-11 15:03:02 -0700, Andres Freund wrote:
> On 2023-04-11 16:54:53 -0400, Tom Lane wrote:
> > Here's something related to what I hit that time:
> >
> > diff --git a/src/backend/optimizer/plan/subselect.c
> > b/src/backend/optimizer/plan/subselect.c
> > index 052263aea6..d43a7c7bcb
Hi,
On 2023-04-12 08:00:00 +0300, Alexander Lakhin wrote:
> 12.04.2023 02:21, Andres Freund wrote:
> > Hi,
> >
> > On 2023-04-11 22:00:00 +0300, Alexander Lakhin wrote:
> > > A few days later I've found a new defect introduced with 31966b151.
> > That's the same issue that Tom also just
On Fri, 14 Apr 2023 at 13:15, Laurenz Albe wrote:
>
> On Fri, 2023-04-14 at 18:43 +0200, Alvaro Herrera wrote:
> > On 2023-Apr-14, Greg Stark wrote:
> > > I assume people would use hot_standby_feedback if they have streaming
> > > replication.
> >
> > Yes, either that or a replication slot.
>
> A
Buildfarm member hamerkop has a niggle about this patch:
c:\\build-farm-local\\buildroot\\head\\pgsql.build\\contrib\\fuzzystrmatch\\daitch_mokotoff.c
: warning C4819: The file contains a character that cannot be represented in
the current code page (932). Save the file in Unicode format to
Hi,
On 2023-04-14 10:05:08 -0400, Greg Stark wrote:
> On Thu, 13 Apr 2023 at 13:01, Peter Geoghegan wrote:
> >
> > On Thu, Apr 13, 2023 at 9:45 AM Robert Haas wrote:
> > >
> > > On Wed, Apr 12, 2023 at 4:23 PM Greg Stark wrote:
> > > > Am I crazy or is the parenthetical comment there exactly
On Thu, 13 Apr 2023 10:53:31 -0500
"Karl O. Pinc" wrote:
> On Thu, 13 Apr 2023 16:01:35 +0200
> Brar Piening wrote:
>
> > On 13.04.2023 at 10:31, Peter Eisentraut wrote:
> > > Side project: I noticed that these new hover links don't appear in
> > > the single-page HTML output (make
On Fri, Apr 14, 2023 at 7:20 AM Daniel Gustafsson wrote:
> And again with the attachment.
After some sleep... From inspection I think the final EOF branch could
be masked by the new branch, if verification has failed but was already
ignored.
To test that, I tried hanging up on the client
Since the direct I/O commit went in, buildfarm animals
curculio and morepork have been issuing warnings like
hashpage.c: In function '_hash_expandtable':
hashpage.c:995: warning: ignoring alignment for stack allocated 'zerobuf'
in places where there's a local variable of type PGIOAlignedBlock
or
On Fri, 2023-04-14 at 18:43 +0200, Alvaro Herrera wrote:
> On 2023-Apr-14, Greg Stark wrote:
> > I assume people would use hot_standby_feedback if they have streaming
> > replication.
>
> Yes, either that or a replication slot.
A replication slot doesn't do anything against snapshot conflicts,
On 2023-Apr-14, Greg Stark wrote:
> On Fri, 14 Apr 2023 at 09:47, Jonathan S. Katz wrote:
> >
> > Let me restate [1] in a different way.
> >
> > Using a large enough dataset, I did qualitatively look at overall usage
> > of both "vacuum_defer_cleanup_age" and compared to
> >
Hi,
On 2023-04-14 11:58:42 -0400, Greg Stark wrote:
> On Wed, 11 May 2022 at 06:19, Peter Eisentraut
> wrote:
> >
> > After that, these configure options don't have an equivalent yet:
> >
> > --enable-profiling
>
> Afaics this still doesn't exist? Is there a common idiom to enable
> this? Like,
Michael Paquier writes:
> On Wed, Aug 11, 2021 at 10:16:15AM +0900, Michael Paquier wrote:
>> + else if (Matches("CREATE", "SCHEMA", "AUTHORIZATION"))
>> + COMPLETE_WITH_QUERY(Query_for_list_of_owner_roles);
>> + else if (Matches("CREATE", "SCHEMA", MatchAny,
On Wed, 11 May 2022 at 06:19, Peter Eisentraut
wrote:
>
> After that, these configure options don't have an equivalent yet:
>
> --enable-profiling
Afaics this still doesn't exist? Is there a common idiom to enable
this? Like, if I add in something to cflags is that enough? I seem to
recall we
On Fri, 14 Apr 2023 at 09:47, Jonathan S. Katz wrote:
>
> Let me restate [1] in a different way.
>
> Using a large enough dataset, I did qualitatively look at overall usage
> of both "vacuum_defer_cleanup_age" and compared to
> "hot_standby_feedback", given you can use both to accomplish similar
On Fri, Apr 14, 2023 at 7:05 AM Greg Stark wrote:
> But I'm saying the parenthetical part is not just confusing, it's
> outright wrong. I guess that just means the first half was so
> confusing it confused not only the reader but the author too.
I knew that that was what you meant. I agree that
LLVM 16 is apparently released, because Fedora has started using
it in their rawhide (development) branch, which means Postgres
is failing to build there [1][2]:
../../../../src/include/jit/llvmjit_emit.h: In function 'l_load_gep1':
../../../../src/include/jit/llvmjit_emit.h:123:30: warning:
On 2023/04/14 18:59, Etsuro Fujita wrote:
The primary message basically should avoid reference to implementation details
such as specific structure names like PGcancel, shouldn't it, as per the error
message style guide?
I do not think that PGcancel is that specific, as it is described in
> On 14 Apr 2023, at 16:20, Daniel Gustafsson wrote:
>
>> On 14 Apr 2023, at 15:51, Tom Lane wrote:
>>
>> Daniel Gustafsson writes:
>>> I mainly put save_errno back into SOCK_ERRNO for greppability, I don't have
>>> any
>>> strong opinions either way so I went with the latter suggestion.
> On 14 Apr 2023, at 15:51, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> I mainly put save_errno back into SOCK_ERRNO for greppability, I don't have
>> any
>> strong opinions either way so I went with the latter suggestion. Attached v3
>> does the above change and passes the tests both
On Thu, 13 Apr 2023 at 13:01, Peter Geoghegan wrote:
>
> On Thu, Apr 13, 2023 at 9:45 AM Robert Haas wrote:
> >
> > On Wed, Apr 12, 2023 at 4:23 PM Greg Stark wrote:
> > > Am I crazy or is the parenthetical comment there exactly backwards? If
> > > the horizon is *more recent* then fewer tuples
Daniel Gustafsson writes:
> I mainly put save_errno back into SOCK_ERRNO for greppability, I don't have
> any
> strong opinions either way so I went with the latter suggestion. Attached v3
> does the above change and passes the tests both with a broken and working
> system CA pool. Unless
On 4/14/23 8:30 AM, Robert Haas wrote:
On Thu, Apr 13, 2023 at 11:06 PM Laurenz Albe wrote:
I am not against this in principle, but I know that there are people using
this parameter; see the discussion linked in
https://postgr.es/m/e1jkzxe-0006dw...@gemulon.postgresql.org
I can't say if they
Hi,
On 11/15/22 10:02 AM, Drouvot, Bertrand wrote:
Hi,
On 2/11/22 3:26 PM, Peter Eisentraut wrote:
On 10.02.22 22:47, Bruce Momjian wrote:
On Tue, Feb 8, 2022 at 08:27:32PM +0530, Ashutosh Sharma wrote:
Which means that if e.g. the standby_slot_names GUC differs from
synchronize_slot_names
Hi Nishant,
On Fri, Apr 14, 2023 at 8:39 PM Nishant Sharma
wrote:
> I debugged this issue and was able to find a fix for the same. Kindly please
> refer to the attached fix. With the fix I am able to resolve the issue.
Thanks for the report and patch!
> What is the technical issue?
> The
On Fri, Apr 14, 2023 at 11:43 PM Jehan-Guillaume de Rorthais
wrote:
> Would you be able to test the latest patchset posted [1] ? This does not fix
> the work_mem overflow, but it helps to keep the number of batches
> balanced and acceptable. Any feedback, comment or review would be useful.
>
>
On Mon, Apr 3, 2023 at 11:29 AM Dave Cramer wrote:
> > participating clients to receive GUC configured format. I do not
>
>> > think that libpq's result format being able to be overridden by GUC
>>> > is a good idea at all, the library has to to participate, and I
>>> > think can be made to so
On Thu, Apr 13, 2023 at 7:06 PM Thomas Munro wrote:
> For some reason I thought we weren't supposed to use the flat thing,
> but it looks like I'm just wrong and people do that all the time so I
> take that back.
>
> Pushed. Thanks Richard and Melanie.
I tend to use http://postgr.es/m/ or
> On 14 Apr 2023, at 14:30, Robert Haas wrote:
> ..as Peter rightly says, XID age is likely a poor proxy for
> whatever people really care about, so I don't think continuing to have
> a setting that works like that is a good plan.
Agreed, and removing it is likely to be a good vehicle for
On Thu, Apr 13, 2023 at 11:06 PM Laurenz Albe wrote:
> I am not against this in principle, but I know that there are people using
> this parameter; see the discussion linked in
>
> https://postgr.es/m/e1jkzxe-0006dw...@gemulon.postgresql.org
>
> I can't say if they have a good use case for that
On Fri, 14 Apr 2023 13:21:05 +0200
Matthias van de Meent wrote:
> On Fri, 14 Apr 2023 at 12:59, Konstantin Knizhnik wrote:
> >
> > Hi hackers,
> >
> > Too small value of work_mem cause memory overflow in parallel hash join
> > because of too much number batches.
> > There is the plan:
>
>
Hi,
We have observed that running the same self JOIN query on postgres FDW
setup is returning different results with set enable_nestloop off & on. I
am at today's latest commit:- 928e05ddfd4031c67e101c5e74dbb5c8ec4f9e23
I created a local FDW setup. And ran this experiment on the same. Kindly
On Fri, Apr 14, 2023 at 10:59 PM Konstantin Knizhnik wrote:
> Too small value of work_mem cause memory overflow in parallel hash join
> because of too much number batches.
Yeah. Not only in parallel hash join, but in any hash join
(admittedly parallel hash join has higher per-batch overheads;
On Fri, 14 Apr 2023 at 12:59, Konstantin Knizhnik wrote:
>
> Hi hackers,
>
> Too small value of work_mem cause memory overflow in parallel hash join
> because of too much number batches.
> There is the plan:
[...]
> There is still some gap between size reported by memory context sump and
>
Hi hackers,
Too small value of work_mem cause memory overflow in parallel hash join
because of too much number batches.
There is the plan:
explain SELECT * FROM solixschema.MIG_50GB_APR04_G1_H a join
solixschema.MIG_50GB_APR04_G2_H b on a.seq_pk = b.seq_pk join
Dear Julien,
> Sorry for the delay, I didn't had time to come back to it until this
> afternoon.
No issues, everyone is busy:-).
> I don't think that your analysis is correct. Slots are guaranteed to be
> stopped after all the normal backends have been stopped, exactly to avoid such
>
On 14.04.23 11:29, Dagfinn Ilmari Mannsåker wrote:
It doesn't tab complete the AT TIME ZONE operator itself, just the
timezone name after it, so this sholud work:
# SELECT now() AT TIME ZONE
or
# SELECT now() AT TIME ZONE am
However, looking more closely at the grammar, the word
Jim Jones writes:
> On 12.04.23 19:53, Dagfinn Ilmari Mannsåker wrote:
>> Dagfinn Ilmari Mannsåker writes:
>>
>>> Hi hackers,
>>>
>>> I'm sure I'm not the only one who can never remember which way around
>>> the value and delimiter arguments go for string_agg() and has to look it
>>> up in the
On Fri, Apr 14, 2023 at 3:19 AM Fujii Masao wrote:
> On 2023/04/13 15:13, Etsuro Fujita wrote:
> > I am not 100% sure that it is a good idea to use the same error
> > message "could not send cancel request" for the PQgetCancel() and
> > PQcancel() cases, because they are different functions. How
Hi Jim,
Thanks for having a look at my patch, but please don't top post on
PostgreSQL lists.
Jim Jones writes:
> Hi,
>
> On 12.04.23 19:53, Dagfinn Ilmari Mannsåker wrote:
>> Dagfinn Ilmari Mannsåker writes:
>>
>>> Hi hackers,
>>>
>>> A while back we added support for completing time zone
On 12.04.23 19:53, Dagfinn Ilmari Mannsåker wrote:
Dagfinn Ilmari Mannsåker writes:
Hi hackers,
I'm sure I'm not the only one who can never remember which way around
the value and delimiter arguments go for string_agg() and has to look it
up in the manual every time. To make it more
On 27.01.23 15:48, Peter Eisentraut wrote:
Btw., something that I have had in my notes for a while, but with this
it would now be officially exposed: Not all options can be safely set
during bootstrap. For example,
initdb -D data -c track_commit_timestamp=on
will fail an assertion.
> On 14 Apr 2023, at 05:50, Michael Paquier wrote:
>
> On Fri, Apr 14, 2023 at 01:27:46AM +0200, Daniel Gustafsson wrote:
>> What would be the intended usecase? I don’t have the RFC handy, does
>> it say anything about salt length?
>
> Hmm. I thought it did, but RFC 5802 has only these two
> On 14 Apr 2023, at 01:27, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> Good points, it should of course be SOCK_ERRNO. The attached saves off errno
>> and reinstates it to avoid clobbering. Will test it on Windows in the
>> morning
>> as well.
>
> I think instead of this:
>
> +
At Thu, 13 Apr 2023 12:01:04 -0700, sirisha chamarthi
wrote in
> The documentation [1] says max_wal_size and min_wal_size defaults are 1GB
> and 80 MB respectively. However, these are configured based on the
> wal_segment_size and documentation is not clear about it. Attached a patch
> to fix
Hi,
Is this supposed to provide tab completion for the AT TIME ZONE operator
like in this query?
SELECT '2023-04-14 08:00:00' AT TIME ZONE 'Europe/Lisbon';
The patch applied cleanly but I'm afraid I cannot reproduce the intended
behaviour:
postgres=# SELECT '2023-04-14 08:00:00' AT
On Fri, 7 Apr 2023 at 08:52, houzj.f...@fujitsu.com
wrote:
>
> On Friday, April 7, 2023 11:13 AM houzj.f...@fujitsu.com
>
> >
> > On Tuesday, April 4, 2023 7:35 PM shveta malik
> > wrote:
> > >
> > > On Tue, Apr 4, 2023 at 8:43 AM houzj.f...@fujitsu.com
> > > wrote:
> > >
> > > > Attach the
Sorry for joining in late..
At Thu, 13 Apr 2023 15:44:20 +0300, Pavel Luzanov
wrote in
> After playing with the \du command, I found that we can't avoid
> translation.
> All attributes are translatable. Also, two of nine attributes shows in
> new line separated format (connection limit and
On 07.04.23 02:52, David Rowley wrote:
On Fri, 7 Apr 2023 at 09:44, Melanie Plageman wrote:
Otherwise, LGTM.
Thanks for looking. I've also taken Justin's comments about the
README into account and fixed that part.
I've pushed the patch after a little more adjusting. I added some
text to
On Thu, Apr 13, 2023 at 10:56:26AM +,
fujii.y...@df.mitsubishielectric.co.jp wrote:
> > Yes, good. Did we never push down aggregates before? I thought we
> > pushed down partitionwise aggregates already, and such a check should
> > already be done. If the check isn't there, it should be.
>
Hi,
Sorry for the delay, I didn't had time to come back to it until this afternoon.
On Mon, Apr 10, 2023 at 09:18:46AM +, Hayato Kuroda (Fujitsu) wrote:
>
> I have analyzed about the point but it seemed to be difficult. This is because
> some additional records like followings may be
75 matches
Mail list logo
