Re: SPI_finish and RegisterExprContextCallback

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Hallgren <thhal(at)mailblocks(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SPI_finish and RegisterExprContextCallback
Date: 2005-02-19 03:47:21
Message-ID: 6456.1108784841@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Hallgren <thhal(at)mailblocks(dot)com> writes:
> AtCommitPortals (portalmem.c) iterates over the entries in the
> PortalHashTable. This causes a chain of calls that sometimes reach an
> ExprContextCallback. If that callback issues a succesfull
> SPI_cursor_close some problems might lay ahead. As the AcCommitPortals
> iteration continues, it sometimes encounter a deleted portal and elogs
> with an error stating "trying to delete portal name that does not exist".

The comment for AtCommit_Portals points out that there are risks of this
sort, but I don't think you've described it properly. The
SPI_cursor_close operation is probably failing not succeeding, because
AtCommit_Portals will never find an already-deleted portal ---
hash_seq_search() shouldn't return any already-dropped entries.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-02-19 03:58:34 Re: UTF8 or Unicode
Previous Message Tom Lane 2005-02-19 03:35:31 Re: Data loss, vacuum, transaction wrap-around