From: | Thomas Hallgren <thhal(at)mailblocks(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SPI_finish and RegisterExprContextCallback |
Date: | 2005-02-19 10:07:51 |
Message-ID: | thhal-0eqjyAqWsxicN+zUpc/NneTcsA1CNrd@mailblocks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>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.
>
>
The hash_seq_search keeps track of what element that it should return
next when it peruses a bucket. Removing that element from the table
won't change anything since the HASH_SEQ_STATUS remains unaffected. It
still holds onto that element and hence, will return it on next iteration.
This should be considered a bug I think.
Regards,
Thomas Hallgren
From | Date | Subject | |
---|---|---|---|
Next Message | pgsql | 2005-02-19 14:15:14 | Re: Data loss, vacuum, transaction wrap-around |
Previous Message | Manuel Sugawara | 2005-02-19 06:21:35 | problems with locale settings |