Re: Prevent an error on attaching/creating a DSM/DSA from an interrupt handler.

From: Rahila Syed <rahilasyed90(at)gmail(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>
Subject: Re: Prevent an error on attaching/creating a DSM/DSA from an interrupt handler.
Date: 2025-04-11 19:08:03
Message-ID: CAH2L28u24A8mgZC=wvhai4fCfYgmsqoyYWm0vT9cQB3mipg4wQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Daniel,

Thank you for your review and code improvements.

Please find below some observations.

1. dsm_unpin_mapping(dsm_segment *seg)
+ if (CurrentResourceOwner &&
IsResourceOwnerReleasing(CurrentResourceOwner))
+ return;

Given that the function can return without setting resowner to a
CurrentResourceOwner which is not NULL, shall we change the function
signature to return true when "unpin" is successful and false when not?
This behavior existed earlier too, but adding the check has made it
explicit.
Although this function is not currently in use, it would be beneficial to
make
the API more verbose.

2. If value of IsResourceOwnerReleasing changes between
dsm_create_descriptor
and attach_internal, the dsm segment and dsa area will end up with
different resource owners.
Earlier the chances of CurrentResourceOwner changing between the two
functions were zero.
May be something can be done to keep resowner assignments under both these
functions
in sync.

Thank you,
Rahila Syed

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2025-04-11 19:33:35 Re: n_ins_since_vacuum stats for aborted transactions
Previous Message Nikita Malakhov 2025-04-11 18:57:05 Re: SQL/JSON json_table plan clause