On Mon, Oct 3, 2022 at 4:56 PM Po-Chuan Hsieh wrote:
> While building PostgreSQL 15 RC 1 with LLVM 15, I got a build failure as
> follows:
>
> cc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
> -Werror=vla -Werror=unguarded-availability-new -Wendif-labels
>
Hi,
On Mon, Oct 03, 2022 at 06:00:12AM +0200, Pavel Stehule wrote:
> ne 2. 10. 2022 v 22:52 odesílatel Daniel Gustafsson
> napsal:
>
> > > On 2 Oct 2022, at 18:04, Andres Freund wrote:
> > > On 2022-10-02 00:19:59 -0700, Andres Freund wrote:
> > >> On 2022-10-01 23:56:59 -0700, Andres Freund
ne 2. 10. 2022 v 22:52 odesílatel Daniel Gustafsson
napsal:
> > On 2 Oct 2022, at 18:04, Andres Freund wrote:
> > On 2022-10-02 00:19:59 -0700, Andres Freund wrote:
> >> On 2022-10-01 23:56:59 -0700, Andres Freund wrote:
> >>> On 2022-09-12 09:58:37 +0200, Daniel Gustafsson wrote:
>
Hello,
While building PostgreSQL 15 RC 1 with LLVM 15, I got a build failure as
follows:
cc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Werror=vla -Werror=unguarded-availability-new -Wendif-labels
-Wmissing-format-attribute -Wcast-function-type -Wformat-security
On Mon, Oct 3, 2022 at 1:40 PM Michael Paquier wrote:
> On Mon, Oct 03, 2022 at 12:10:06PM +1300, Thomas Munro wrote:
> > I think something like the attached should do the right thing for
> > STATUS_DELETE_PENDING (sort of "ENOENT-in-progress"). unlink() goes
> > back to being blocking
On Sat, Oct 1, 2022 at 7:53 PM Peter Eisentraut
wrote:
>
> On 29.09.22 06:52, Masahiko Sawada wrote:
> > While this seems a future-proof idea, I wonder if it might be overkill
> > since we don't need to worry about accumulation of leaked memory in
> > this case. Given that only check_cluter_name
On Mon, Oct 3, 2022 at 2:04 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-09-16 15:00:31 +0900, Masahiko Sawada wrote:
> > I've updated the radix tree patch. It's now separated into two patches.
>
> cfbot notices a compiler warning:
>
On Sun, Oct 02, 2022 at 10:02:37AM -0700, Andres Freund wrote:
> This fails tests widely, and has so for a while:
> https://cirrus-ci.com/build/4862820121575424
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/39/3649
>
> Note that it causes timeouts, which end up chewing up
On Sun, Oct 02, 2022 at 02:54:21PM -0700, Andres Freund wrote:
> the clang-only memory sanitizer there (if it works on freebsd)...
Have you looked at this much ? I think it'll require a bunch of
exclusions, right ?
--
Justin
On Sun, Oct 02, 2022 at 02:11:12PM -0400, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> OK. For v15 I am heavily in favor for the least risky approach given the
>> point we are at in the release cycle. The RMT hasn’t met yet to discuss,
>> but from re-reading this thread again, I would
On Mon, Oct 03, 2022 at 12:10:06PM +1300, Thomas Munro wrote:
> I think something like the attached should do the right thing for
> STATUS_DELETE_PENDING (sort of "ENOENT-in-progress"). unlink() goes
> back to being blocking (sleep+retry until eventually we reach ENOENT
> or we time out and give
On Sun, Oct 02, 2022 at 01:38:37PM -0500, Justin Pryzby wrote:
> On Sun, Oct 02, 2022 at 11:05:30AM -0700, Andres Freund wrote:
> > > Also, you wrote "rm -fr build" between building for gcc and clang, but
> > > since they run in an "always" block, it'd be better to use separate
> > > dirs, to
On Thu, 29 Sept 2022 at 18:30, David Rowley wrote:
> Does anyone have any opinions on this?
I by no means think I've nailed the fix in
other_ideas_to_fix_MemoryContextContains.patch, so it would be good to
see if anyone else has any new ideas on how to solve this issue.
Andres did mention to me
On Mon, Oct 3, 2022 at 9:07 AM Thomas Munro wrote:
> On Tue, Sep 20, 2022 at 1:31 PM Justin Pryzby wrote:
> > I suspect that rmtree() was looping in pgunlink(), and got ENOENT, so
> > didn't warn about the file itself, but then failed one moment later in
> > rmdir.
>
> Yeah, I think this is my
David Rowley writes:
> * I can't quite figure out why you're doing "DROP TABLE a CASCADE;" in
> inherits.sql. You've not changed anything else in that file. Did you
> mean to do this in join.sql?
Doing that would be a bad idea no matter where it's done. IIRC,
those tables are intentionally set
On Sun, 2 Oct 2022 at 05:34, Arne Roland wrote:
>
> On Tue, Sep 20, 2022 at 4:53 PM David Rowley wrote:
> > Arne sent me an off-list
> > message to say he's planning on working on the patch that uses the
> > existing field instead of the new one he originally added. Let's hold
> > off for that
Hi,
On 2022-10-02 16:35:06 -0500, Justin Pryzby wrote:
> On Sun, Oct 02, 2022 at 01:52:01PM -0700, Andres Freund wrote:
> > On 2022-10-01 18:36:41 -0700, Andres Freund wrote:
> > > I am wondering if we should instead introduce a new "quickcheck" task that
> > > just compiles and runs maybe one
Hi,
On 2022-10-02 16:35:06 -0500, Justin Pryzby wrote:
> Maybe - that would avoid waiting 4 minutes for a windows instance to
> start in the (hopefully atypical) case of a patch that fails in 1-2
> minutes under linux/freebsd.
>
> If the patch were completely broken, the windows task would take
David Rowley writes:
> As for the slight misuse of group_pathkeys, I guess since there are no
> users that require just the plain pathkeys belonging to the GROUP BY,
> then likely the best thing would be just to rename that field to
> something like groupagg_pathkeys. Maintaining two separate
On Sun, Oct 02, 2022 at 01:52:01PM -0700, Andres Freund wrote:
> Hi,
>
> On 2022-10-01 18:36:41 -0700, Andres Freund wrote:
> > I am wondering if we should instead introduce a new "quickcheck" task that
> > just compiles and runs maybe one test and have *all* other tests depend on
> > that.
On Mon, 3 Oct 2022 at 09:59, Tom Lane wrote:
>
> David Rowley writes:
> > For the master version, I think it's safe just to get rid of
> > PlannerInfo.num_groupby_pathkeys now. I only added that so I could
> > strip off the ORDER BY / DISTINCT aggregate PathKeys from the group by
> > pathkeys
On 2022-10-02 22:52:33 +0200, Daniel Gustafsson wrote:
> The parser in the original submission was -1'd by me, and the current version
> proposed as an alternative. This was subsequently -1'd as well but no updated
> patch with a rewritten parser has been posted. So this is now stalled again.
>
Daniel Gustafsson writes:
> On 2 Oct 2022, at 18:04, Andres Freund wrote:
>> c.h (and postgres.h, postgres_fe.h) shouldn't be included in headers.
>> This is a common enough mistake that I'm wondering if we could automate
>> warning about it somehow.
> Maybe we can add a simple git grep
> On 2 Oct 2022, at 03:49, Andres Freund wrote:
> On 2022-09-30 11:35:36 +0200, Daniel Gustafsson wrote:
>> Installing the stylesheets locally as we document solves the issue of course,
>> but maybe it's time to move to using --nonet as we discussed in [0] and
>> require
>> the stylesheets
David Rowley writes:
> For the master version, I think it's safe just to get rid of
> PlannerInfo.num_groupby_pathkeys now. I only added that so I could
> strip off the ORDER BY / DISTINCT aggregate PathKeys from the group by
> pathkeys before passing to the functions that rearranged the GROUP
> On 2 Oct 2022, at 18:04, Andres Freund wrote:
> On 2022-10-02 00:19:59 -0700, Andres Freund wrote:
>> On 2022-10-01 23:56:59 -0700, Andres Freund wrote:
>>> On 2022-09-12 09:58:37 +0200, Daniel Gustafsson wrote:
Correct, fixed in the attached.
>>>
>>> Updated patch adding meson
Hi,
On 2022-10-01 18:36:41 -0700, Andres Freund wrote:
> I am wondering if we should instead introduce a new "quickcheck" task that
> just compiles and runs maybe one test and have *all* other tests depend on
> that. Wasting a precious available windows instance to just fail to build or
>
On Mon, 3 Oct 2022 at 08:10, Tom Lane wrote:
> As attached.
For the master version, I think it's safe just to get rid of
PlannerInfo.num_groupby_pathkeys now. I only added that so I could
strip off the ORDER BY / DISTINCT aggregate PathKeys from the group by
pathkeys before passing to the
On Fri, Sep 30, 2022 at 3:19 PM Benjamin Coutu wrote:
> > For all I know you might be onto something. But it really seems
> > independent to me.
>
> Yeah, I‘m sorry if I highjacked this thread for something related but
> technically different.
I certainly wouldn't say that you hijacked the
On Tue, Sep 20, 2022 at 1:31 PM Justin Pryzby wrote:
> I suspect that rmtree() was looping in pgunlink(), and got ENOENT, so
> didn't warn about the file itself, but then failed one moment later in
> rmdir.
Yeah, I think this is my fault. In commit f357233c the new lstat()
call might return
On Sun, Oct 2, 2022 at 3:43 AM Robert Haas wrote:
> On Fri, Sep 30, 2022 at 2:24 PM Peter Geoghegan wrote:
> > It's not just that the risks are ludicrously high, of course. The
> > potential benefits must *also* be very low. It's both factors,
> > together.
>
> Hmm, maybe. But it also wouldn't
On Sun, Oct 02, 2022 at 11:05:30AM -0700, Andres Freund wrote:
> > Also, you wrote "rm -fr build" between building for gcc and clang, but
> > since they run in an "always" block, it'd be better to use separate
> > dirs, to allow seeing logs for the the all (failed) tasks, in case the
> > last one
"Jonathan S. Katz" writes:
> OK. For v15 I am heavily in favor for the least risky approach given the
> point we are at in the release cycle. The RMT hasn’t met yet to discuss,
> but from re-reading this thread again, I would recommend to revert
> (i.e. the “straight up revert”).
OK by me.
>
Hi,
On 2022-10-02 12:25:20 -0500, Justin Pryzby wrote:
> On Mon, Sep 26, 2022 at 06:19:51PM -0700, Andres Freund wrote:
> > From 680ff3f7b4da1dbf21d0c7cd87af9bb5ee8b230c Mon Sep 17 00:00:00 2001
> > From: Andres Freund
> > Date: Wed, 21 Sep 2022 20:36:36 -0700
> > Subject: [PATCH v17 01/23]
Hi,
On 2022-09-13 20:50:20 +0300, Alexander Korotkov wrote:
> On Fri, Jul 29, 2022 at 1:05 PM Justin Kwan wrote:
> > Not sure if this email went through previously but thank you for your
> > feedback, I've incorporated your suggestions by scanning the logs produced
> > from pg_rewind when
> On Oct 2, 2022, at 1:12 PM, Tom Lane wrote:
>
> "Jonathan S. Katz" writes:
>>> On 10/1/22 6:57 PM, Tom Lane wrote:
>>> I plan to have a look tomorrow at the idea of reverting only the cost_sort
>>> changes, and rewriting get_cheapest_group_keys_order() to just sort the
>>> keys by
On Mon, Sep 26, 2022 at 06:19:51PM -0700, Andres Freund wrote:
> From 680ff3f7b4da1dbf21d0c7cd87af9bb5ee8b230c Mon Sep 17 00:00:00 2001
> From: Andres Freund
> Date: Wed, 21 Sep 2022 20:36:36 -0700
> Subject: [PATCH v17 01/23] meson: ci: wip: move compilerwarnings task to meson
This patch isn't
Hi,
On 2022-09-27 14:20:44 -0400, Melanie Plageman wrote:
> v30 attached
> rebased and pgstat_io_ops.c builds with meson now
> also, I tested with pgstat_report_stat() only flushing when forced and
> tests still pass
Unfortunately tests fail in CI / cfbot. E.g.,
Hi,
On 2022-09-26 12:12:15 -0300, Israel Barth Rubio wrote:
> Thanks for your review! I have applied the suggested changes, and I'm
> submitting the new patch version.
cfbot shows that tests started failing with this version:
"Jonathan S. Katz" writes:
> On 10/1/22 6:57 PM, Tom Lane wrote:
>> I plan to have a look tomorrow at the idea of reverting only the cost_sort
>> changes, and rewriting get_cheapest_group_keys_order() to just sort the
>> keys by decreasing numgroups estimates as I suggested upthread. That
>>
Hi,
On 2022-09-07 18:23:06 +0900, Amit Langote wrote:
> Attached updated patches.
Thanks to Justin's recent patch (89d16b63527) to add
-DRELCACHE_FORCE_RELEASE -DCOPY_PARSE_PLAN_TREES -DWRITE_READ_PARSE_PLAN_TREES
-DRAW_EXPRESSION_COVERAGE_TEST
to the FreeBSD ci task we now see the following:
Hi,
On 2022-09-16 15:00:31 +0900, Masahiko Sawada wrote:
> I've updated the radix tree patch. It's now separated into two patches.
cfbot notices a compiler warning:
https://cirrus-ci.com/task/6247907681632256?logs=gcc_warning#L446
[11:03:05.343] radixtree.c: In function ‘rt_iterate_next’:
Hi,
On 2022-07-29 16:15:26 -0500, Justin Pryzby wrote:
> This was using the old psql rather than the new one.
> Before v10, psql didn't have \if.
>
> I think Cluster.pm should be updated to support the upgrades that upgrade.sh
> supported. I guess it ought to be fixed in v15.
This fails tests
Hi,
On 2022-07-31 16:05:20 -0400, Tom Lane wrote:
> Thoughts?
As the patch got some feedback ~2 months ago, I'm updating the status to
waiting-for-author.
Minor note: cfbot complains about a cpluspluscheck violation:
[12:24:50.124] time make -s cpluspluscheck EXTRAFLAGS='-fmax-errors=10'
Hi,
The patch for this CF entry doesn't apply currently, and it looks like that's
been the case for quite a while...
Greetings,
Andres Freund
Hi,
The CF entry for this patch doesn't currently apply and there has been a bunch
of feedback on the approach. Mats, are you actually waiting for further
feedback right now?
Greetings,
Andres Freund
Hi,
See e.g. https://cirrus-ci.com/task/4682373060100096
2022-10-01 15:15:21.849 UTC [41962][postmaster] LOG: could not bind IPv4
address "127.0.0.1": Address already in use
2022-10-01 15:15:21.849 UTC [41962][postmaster] HINT: Is another postmaster
already running on port 57003? If not, wait
On 10/1/22 6:57 PM, Tom Lane wrote:
"Jonathan S. Katz" writes:
On 10/1/22 3:13 PM, Tom Lane wrote:
I'm still of the opinion that we need to revert this code for now.
[RMT hat, but speaking just for me] reading through Tom's analysis, this
seems to be the safest path forward. I have a few
Hi,
On 2022-10-02 00:19:59 -0700, Andres Freund wrote:
> On 2022-10-01 23:56:59 -0700, Andres Freund wrote:
> > On 2022-09-12 09:58:37 +0200, Daniel Gustafsson wrote:
> > > Correct, fixed in the attached.
> >
> > Updated patch adding meson compatibility attached.
>
> Err, forgot to amend one
Hi,
On 2022-09-27 11:47:37 +0530, Bharath Rupireddy wrote:
> Just for the records - the same issue was also seen here [1], [2].
>
> [1] https://cirrus-ci.com/task/5709014662119424?logs=check_world#L82
> [2]
>
> Which indeed is the case, e.g. on 32bit systems it fails:
>
> https://cirrus-ci.com/task/4619535222308864?logs=test_world_32#L253
>
> https://api.cirrus-ci.com/v1/artifact/task/4619535222308864/testrun/build-32/testrun/pgstattuple/regress/regression.diffs
>
> table_len | tuple_count |
Hi,
On 2022-09-21 11:56:56 +, kuroda.hay...@fujitsu.com wrote:
> PSA rebased patches. I reviewed my myself and they contain changes.
> E.g., move GUC-related code to option.c.
This seems to reliably fail on windows. See
https://cirrus-ci.com/task/6454408568373248
On Sun, Oct 2, 2022 at 6:40 AM Zhihong Yu wrote:
>
>
> On Sat, Oct 1, 2022 at 12:45 AM Zhihong Yu wrote:
>
>>
>>
>> On Fri, Sep 30, 2022 at 9:20 PM Zhihong Yu wrote:
>>
>>>
>>>
>>> On Fri, Sep 30, 2022 at 8:40 PM Zhihong Yu wrote:
>>>
On Fri, Sep 30, 2022 at 3:44 PM Zheng Li
On Sat, Oct 1, 2022 at 12:45 AM Zhihong Yu wrote:
>
>
> On Fri, Sep 30, 2022 at 9:20 PM Zhihong Yu wrote:
>
>>
>>
>> On Fri, Sep 30, 2022 at 8:40 PM Zhihong Yu wrote:
>>
>>>
>>>
>>> On Fri, Sep 30, 2022 at 3:44 PM Zheng Li wrote:
>>>
Hello,
A bloom filter provides early
On Fri, Sep 30, 2022 at 2:24 PM Peter Geoghegan wrote:
> It's not just that the risks are ludicrously high, of course. The
> potential benefits must *also* be very low. It's both factors,
> together.
Hmm, maybe. But it also wouldn't surprise me very much if someone can
come up with a test case
On 2022-10-02 00:23:32 -0700, Andres Freund wrote:
> Updated the patch to add the minimal change for meson compat.
Now I made the same mistake of not adding the change... Clearly I need to stop
for tonight. Either way, here's the hopefully correct change.
>From
Hi,
On 2022-08-31 21:15:40 +0200, Christoph Heiss wrote:
> Notable changes from v1:
> - gbt_enum_sortsupport() now passes on fcinfo->flinfo
> enum_cmp_internal() needs a place to cache the typcache entry.
> - inet sortsupport now uses network_cmp() directly
Updated the patch to add the minimal
Hi,
On 2022-10-01 23:56:59 -0700, Andres Freund wrote:
> On 2022-09-12 09:58:37 +0200, Daniel Gustafsson wrote:
> > Correct, fixed in the attached.
>
> Updated patch adding meson compatibility attached.
Err, forgot to amend one hunk :(
Greetings,
Andres Freund
>From
Hi,
On 2022-09-27 15:51:25 +0200, Peter Eisentraut wrote:
> Updated version with meson build system support added (for added files and
> new tests).
This fails on windows: https://cirrus-ci.com/task/6151847080624128
Hi,
On 2022-08-03 11:19:59 +0900, Dong Wook Lee wrote:
> Is there no problem with selecting all the columns during SELECT statements?
> I thought there might be a problem where the test results could change easily.
Which indeed is the case, e.g. on 32bit systems it fails:
Hi,
On 2022-09-22 08:19:09 -0700, Andres Freund wrote:
> Hi,
>
> On 2022-08-17 17:28:02 +0500, Andrey Borodin wrote:
> > Here's v13. Changes:
> > 1. Fixed passing through downlink in GIN index
> > 2. Fixed GIN tests (one test case was not working)
> >
> > Thanks to Vitaliy Kukharik for trying
Hi,
On 2022-09-12 09:58:37 +0200, Daniel Gustafsson wrote:
> Correct, fixed in the attached.
Updated patch adding meson compatibility attached.
Greetings,
Andres Freund
>From 5d3ba4d2d6567626ccc0019208ea4c0ea91ac866 Mon Sep 17 00:00:00 2001
From: Daniel Gustafsson
Date: Wed, 7 Sep 2022
62 matches
Mail list logo
