| From: | Jan Wieck <jan(at)wi3ck(dot)info> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Aleksander Alekseev <aleksander(at)timescale(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, tomas(at)vondra(dot)me |
| Subject: | Re: Commit Timestamp and LSN Inversion issue |
| Date: | 2024-11-06 19:22:10 |
| Message-ID: | 4410956c-dcb9-4bbc-a47b-8abb2fddd6d8@wi3ck.info |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 11/6/24 06:23, Amit Kapila wrote:
> I think we avoid calling hook/callback functions after holding a lock
> (spinlock or LWLock) as the user may do an expensive operation or
> acquire some other locks in those functions which could lead to
> deadlocks or impact the concurrency. So, it would be better to
> directly call an inline function to perform the required operation.
This is a valid concern. The reason why I kept it as a hook is because
ReserveXLogInsertLocation() has no knowledge that this is allocating WAL
space for a commit record. Only the caller does. We certainly need to be
extremely careful what any such hook function is doing. Acquiring
additional locks is definitely not acceptable. But I am not sure we
should burden this function with specialized knowledge about what it is
reserving WAL space for.
Regards, Jan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Maiquel Grassi | 2024-11-06 19:28:33 | RE: Rename Function: pg_postmaster_start_time |
| Previous Message | David Rowley | 2024-11-06 19:10:17 | Re: define pg_structiszero(addr, s, r) |