| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Report distinct wait events when waiting for WAL "operation" |
| Date: | 2023-07-20 05:18:05 |
| Message-ID: | ZLjDjZU176W7Ezje@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jul 19, 2023 at 06:49:57PM +0530, Amit Kapila wrote:
> On Mon, Jul 17, 2023 at 10:26 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>> FWIW, the former is bottlenecked by the number of WAL insertion locks, the
>> second is bottlenecked by copying WAL into buffers due to needing to flush
>> them.
>
> This gives a better idea of what's going on. +1 for separating these waits.
+ * As this is not used to wait for lwlocks themselves, the caller has to
+ * provide a wait event to be reported.
*/
bool
-LWLockWaitForVar(LWLock *lock, uint64 *valptr, uint64 oldval, uint64 *newval)
+LWLockWaitForVar(LWLock *lock, uint64 *valptr, uint64 oldval, uint64 *newval,
+ uint32 wait_event_info)
Makes sense to me to do this split, nice! And this gives more
flexibility for out-of-core callers, while on it.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2023-07-20 05:29:46 | Re: Report distinct wait events when waiting for WAL "operation" |
| Previous Message | Amit Kapila | 2023-07-20 05:17:12 | Re: Do we want to enable foreign key constraints on subscriber? |