Re: Commitfest 2023-09 starts soon - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: Commitfest 2023-09 starts soon
Date
Msg-id CAJ7c6TONwKRH4z9y-bH7FSEoum2mZ2Hj2==EkWs3w=EC8O2Crg@mail.gmail.com
Whole thread Raw
In response to Re: Commitfest 2023-09 starts soon  (Aleksander Alekseev <aleksander@timescale.com>)
Responses Re: Commitfest 2023-09 starts soon
List pgsql-hackers
Hi,

> > There are a number of patches carried over from the PG16 development
> > cycle that have been in "Waiting on author" for several months.  I will
> > aggressively prune those after the start of this commitfest if there
> > hasn't been any author activity by then.
>
> The "64-bit TOAST value ID" [1] is one of such "Waiting on author"
> patches I've been reviewing. See the last 2-3 messages in the thread.
> I believe it's safe to mark it as RwF for now.
>
> [1]: https://commitfest.postgresql.org/44/4296/

This was the one that I could name off the top of my head.

1. Flush SLRU counters in checkpointer process
https://commitfest.postgresql.org/44/4120/

Similarly, I suggest marking it as RwF

2. Allow logical replication via inheritance root table
https://commitfest.postgresql.org/44/4225/

This one seems to be in active development. Changing status to "Needs
review" since it definitely could use more code review.

3. ResourceOwner refactoring
https://commitfest.postgresql.org/44/3982/

The patch is in good shape but requires actions from Heikki. I suggest
keeping it as is for now.

4. Move SLRU data into the regular buffer pool
https://commitfest.postgresql.org/44/3514/

Rotted one and for a long time. Suggestion: RwF

5. A minor adjustment to get_cheapest_path_for_pathkeys
https://commitfest.postgresql.org/44/4286/

Doesn't seem to be valuable. Suggestion: Rejected.

I will apply corresponding status changes if there will be no objections.

-- 
Best regards,
Aleksander Alekseev



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: generate syscache info automatically
Next
From: Junwang Zhao
Date:
Subject: Re: Should we use MemSet or {0} for struct initialization?