Re: Commitfest 2023-03 starting tomorrow! - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: Commitfest 2023-03 starting tomorrow!
Date
Msg-id ZBzQVWPxIAK3seOc@telsasoft.com
Whole thread Raw
In response to Re: Commitfest 2023-03 starting tomorrow!  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On Thu, Mar 23, 2023 at 04:41:39PM -0400, Greg Stark wrote:
> * Avoid hiding shared filesets in pg_ls_tmpdir (pg_ls_* functions for
> showing metadata ...)
>   - According to the internet "As part of their 39 month old
> development and milestones, your patch should be able to see like an
> adult (20/20 vision), be able to run, walk, hop and balance himself
> while standing with one foot quite confidently." Can it do all those
> things yet?

It's not a large patch, and if you read the summaries that I've written,
you'll see that I've presented it as several patches specifically to
allow the essential, early patches to progress; the later patches are
optional - I stopped sending them since people were evidently distracted
by the optional patches at the exclusion of the essential patches.

>   - Should this be broken up into smaller CF entries so at least some
> of them can be Ready for Committer and closed?

Opening and closing CF entries sounds like something which would
maximize the administrative overhead of the process rather than
progressing the patch.

> > * CREATE INDEX CONCURRENTLY on partitioned table
>   - I'm guessing this patch is too big and too late to go in this CF.
> And it sounds like there's still work to be done? Should this be
> marked RwF?

If you look, you'll see that's it's straightforward and *also* small.
As I wrote last week, it's very viable for v16.

On Fri, Mar 17, 2023 at 09:56:10AM -0500, Justin Pryzby wrote:
> >  * CREATE INDEX CONCURRENTLY on partitioned table
> 
> My patch.  I think there's agreement that this patch is ready, except
> that it's waiting on the bugfix for the progress reporting patch.  IDK
> if there's interest in this, but it'd be a good candidate for v16.

-- 
Justin



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Data is copied twice when specifying both child and parent table in publication
Next
From: Tom Lane
Date:
Subject: Re: Can we avoid chdir'ing in resolve_symlinks() ?