On Sat, Jul 22, 2023 at 07:47:50PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> I first tried modifying
>> binaryheap to use "int" or "void *" instead, but that ended up requiring
>> some rather invasive changes in backend code, not to mention any extensions
>> that happen to be using it.
I
> https://momjian.us/pgsql_docs/release-16.html
>
> I will adjust it to the feedback I receive; that URL will quickly show
> all updates.
> Create a predefined role and grantable privilege with permission to perform
> maintenance operations (Nathan Bossart)
> The predefined role is is c
Nathan Bossart writes:
> On Thu, Jul 20, 2023 at 12:06:44PM -0700, Nathan Bossart wrote:
>> One item that requires more thought is binaryheap's use of Datum. AFAICT
>> the Datum definitions live in postgres.h and aren't available to frontend
>> code. I think we'll either need to move the Datum d
On Sat, Jul 22, 2023 at 04:19:41PM -0700, Nathan Bossart wrote:
> In v3, I moved the Datum definitions to c.h. I first tried modifying
> binaryheap to use "int" or "void *" instead, but that ended up requiring
> some rather invasive changes in backend code, not to mention any extensions
> that hap
On Thu, Jul 20, 2023 at 12:06:44PM -0700, Nathan Bossart wrote:
> Here is a work-in-progress patch set for converting ready_list to a
> priority queue. On my machine, Tom's 100k-table example [0] takes 11.5
> minutes without these patches and 1.5 minutes with them.
>
> One item that requires more
On Sat, 2023-07-22 at 07:04 -0700, Noah Misch wrote:
> Commit a117ceb added that, and it added some test cases that behaved
> differently without that.
Thank you. The reasoning there seems to apply to search_path
restriction as well, so I will leave it as-is.
I'll wait a few more days for comment
On Fri, Jul 21, 2023 at 03:32:43PM -0700, Jeff Davis wrote:
> Why do we switch to the table owner and use
> SECURITY_RESTRICTED_OPERATION in DefineIndex(), when we will switch in
> index_build (etc.) anyway?
Commit a117ceb added that, and it added some test cases that behaved
differently without t
On Fri, Jul 21, 2023 at 6:55 AM Masahiko Sawada wrote:
>
> I've attached the updated patch. I'll push it early next week, barring
> any objections.
>
You have moved most of the comments related to the restriction of
which index can be picked atop IsIndexUsableForReplicaIdentityFull().
Now, the co
On Fri, Jul 21, 2023 at 11:29 AM Michael Paquier wrote:
>
> + /* Reading atomically avoids getting a torn value */
> + value = pg_atomic_read_u64(valptr);
>
> Should this specify that this is specifically important for platforms
> where reading a uint64 could lead to a torn value read,
