On Fri, Jun 23, 2017 at 3:01 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Thu, Jun 22, 2017 at 4:29 AM, Kuntal Ghosh > <kuntalghosh.2...@gmail.com> wrote: >> On Wed, Jun 21, 2017 at 7:52 PM, Dilip Kumar <dilipbal...@gmail.com> wrote: >>> On Wed, Jun 21, 2017 at 7:47 PM, Kuntal Ghosh >>> <kuntalghosh.2...@gmail.com> wrote: >>>>> IMHO, It's not a good idea to use DSM call to verify the DSA handle. >>>>> >>>> Okay. Is there any particular scenario you've in mind where this may fail? >>> >>> It's not about failure, but about the abstraction. When we are using >>> the DSA we should not directly access the DSM which is under DSA. >>> >> Okay. I thought that I've found at least one usage of >> dsm_find_mapping() in the code. :-) >> >> But, I've some more doubts. >> 1. When should we use dsm_find_mapping()? (The first few lines of >> dsm_attach is same as dsm_find_mapping().) >> 2. As a user of dsa, how should we check whether my dsa handle is >> already attached? I guess this is required because, if a user tries to >> re-attach a dsa handle, it's punishing the user by throwing an error >> and the user wants to avoid such errors. > > I thought about this when designing the DSA API. I couldn't think of > any good reason to provide an 'am-I-already-attached?' function > equivalent to dsm_find_mapping. It seemed to me that the client code > shouldn't ever be in any doubt about whether it's attached, and that > wilfully or absent-mindedly throwing away dsa_area pointers and having > to ask for them again doesn't seem like a very good design. I suspect > the same applies to dsm_find_mapping, and I don't see any callers in > the source tree or indeed anywhere on the internet (based on a quick > Google search). But I could be missing something. > Thanks a lot for the clarification.
-- Thanks & Regards, Kuntal Ghosh EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
