From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: isTempNamespaceInUse() is incorrect with its handling of MyBackendId |
Date: | 2020-01-13 13:56:13 |
Message-ID: | 20200113135613.GA53910@nol |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 13, 2020 at 10:14:52PM +0900, Michael Paquier wrote:
> On Mon, Jan 13, 2020 at 01:09:01PM +0100, Julien Rouhaud wrote:
> > But that means an extraneous call to BackendIdGetProc() in that
> > case, it seems better to avoid it if we already have the information.
>
> Note that you cannot make a direct comparison of the result from
> GetTempNamespaceBackendId() with MyBackendId, because it is critical
> to be able to handle the case of a session which has not created yet
> an object on its own temp namespace (this way any temp objects from
> previous connections which used the same backend slot can be marked as
> orphaned and discarded by autovacuum, the whole point of 246a6c8).
Oh right.
> So in order to get a fast-exit path we could do the following:
> - Add a routine GetTempNamespace which returns myTempNamespace (the
> result can be InvalidOid).
> - Add an assertion at the beginning of isTempNamespaceInUse() to make
> sure that it never gets called with InvalidOid as input argument.
> - Return true as a first step of GetTempNamespaceBackendId() if
> namespaceId matches GetTempNamespace().
>
> What do you think?
Well, since isTempNamespaceInUse is for now only called by autovacuum, and
shouldn't change soon, this really feels premature optimzation, so your
original approach looks better.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-01-13 14:19:47 | Re: [PATCH] distinct aggregates within a window function WIP |
Previous Message | Michael Paquier | 2020-01-13 13:46:00 | Re: Add pg_file_sync() to adminpack |