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 th
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:
https://cirrus-ci.com/t
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
https://api.cirrus-ci.com/v1/artifact/task/6151847080624128/testrun/build/testru
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 fe2926ccd49a460cbaa39a8916a
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
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 f355228462b4942bec2a7e0a663331a7ab62
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 wh
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 filterin
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 wr
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
https://cirrus-ci.com/github/
> 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 | tuple_len
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]
> https://api.cirrus-ci.com/v1/artifact/task/5709014662119424/testrun/build/testrun/pg_up
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 hun
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 qu
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
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,
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,
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'
[12:25
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 w
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’:
[11:03
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:
h
"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
>> migh
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:
https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/39/
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.,
https://cirrus-ci.com/task/5816109
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 f
> 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 decreasin
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 asser
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] meson
"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.
> I’m
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 s
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 su
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 ENOE
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 threa
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 functi
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
> immedia
> 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 compatibili
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 BY
> 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 locall
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 invocati
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.
>
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 be
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. Wasti
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 fie
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 ~
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 tes
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 pa
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 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 fa
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 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 allow
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 u
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 recommend
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 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 a
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:
> https://cirrus-ci.com/task/6247907681632256?logs=gcc_warning#L446
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 i
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 (sleep+ret
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
-fno
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:
> Correct
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 wr
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
> -Wmissing-
On Mon, Oct 03, 2022 at 04:03:12PM +1300, Thomas Munro wrote:
> So I think that setting is_lnk = false is good enough here. Do
> you see a hole in it?
I cannot think on one, on top of my head. Thanks for the
explanation.
--
Michael
signature.asc
Description: PGP signature
62 matches
Mail list logo
