Re: Inefficiency in parallel pg_restore with many tables

2023-07-22 Thread Nathan Bossart
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.

Re: PG 16 draft release notes ready

2023-07-22 Thread jian he
> 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

Re: Inefficiency in parallel pg_restore with many tables

2023-07-22 Thread Tom Lane
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

Re: Inefficiency in parallel pg_restore with many tables

2023-07-22 Thread Nathan Bossart
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

Re: Inefficiency in parallel pg_restore with many tables

2023-07-22 Thread Nathan Bossart
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

Re: Fix search_path for all maintenance commands

2023-07-22 Thread Jeff Davis
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

Re: Fix search_path for all maintenance commands

2023-07-22 Thread Noah Misch
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

Re: doc: improve the restriction description of using indexes on REPLICA IDENTITY FULL table.

2023-07-22 Thread Amit Kapila
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

Re: WAL Insertion Lock Improvements

2023-07-22 Thread Bharath Rupireddy
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

Re: Row pattern recognition

2023-07-22 Thread Tatsuo Ishii
> On 7/22/23 03:11, Tatsuo Ishii wrote: > Maybe > that can help clarify the design? It feels like it'll need to > eventually > be a "real" function that operates on the window state, even if it > doesn't support all of the possible complexities in v1. Unfortunately an