Michael Paquier <michael.paqu...@gmail.com> writes:
> On Fri, Sep 4, 2015 at 6:51 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Ideas?
> Yes. This diff on top of your patch:
> @@ -922,8 +922,7 @@ AtSubAbort_Portals(SubTransactionId mySubid,
> * must be forced into FAILED state, for
> the same reasons
> * discussed below.
> */
> - if (portal->status == PORTAL_READY ||
> - portal->status == PORTAL_ACTIVE)
> + if (portal->status == PORTAL_ACTIVE)
> MarkPortalFailed(portal);
> This way only the active portals are marked as failed.
Hmm. I am not feeling especially comfortable about this: it's not clear
that there's anything preventing a suspended portal from containing a
dangerous reference. However, a quick trial did not show that it was
possible to break it --- in the cases I tried, we detected that a cached
plan was no longer valid, tried to rebuild it, and noticed the missing
object at that point. So maybe it's OK.
On reflection I think that the tracking of activeSubid in my patch is
probably overkill if we're attacking it this way. We can just have
AtSubAbort_Portals fail any ACTIVE portal regardless of subxact level,
which is pretty analogous to what AtAbort_Portals has done for a long
time.
Let me work on this and see if I can get to a simpler patch.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
