From: | Thomas Hallgren <thhal(at)mailblocks(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #1502: hash_seq_search might return removed entry |
Date: | 2005-02-23 16:28:08 |
Message-ID: | thhal-0mkf4AhPcxicK12cCHrA/1L1cbyRqUM@mailblocks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tom Lane wrote:
>"Thomas" <thhal(at)mailblocks(dot)com> writes:
>
>
>>The hash_seq_search keeps track of what element that it should return next
>>in a HASH_SEQ_STATUS struct when it peruses a bucket. Removing that element
>>from the table won't change anything since the struct remains unaffected. It
>>still holds onto that element and hence, will return it on next iteration.
>>
>>
>
>This isn't a bug; it's the designed way for it to work. It's up to
>callers to avoid causing a problem.
>
>
This report origins from the hackers thread "SPI_finish and
RegisterExprContextCallback" where you indicated that my report did not
properly describe a problem. Since my report was correct and since you
stated that "hash_seq_search() shouldn't return any already-dropped
entries." I was led me to believe that it was *not* designed to do that.
Anyway, the AtCommit_Portals doesn't avoid this problem and the end
result for me is the same regardless of where the error is. I can't drop
portals using a ExprContextCallback and I'd like to know the best way to
fix it. I can contribute a patch but I want you to decide what needs to
be fixed.
Regards,
Thomas Hallgren
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2005-02-23 16:32:21 | Re: BUG #1500: child dead |
Previous Message | Tom Lane | 2005-02-23 16:13:04 | Re: BUG #1502: hash_seq_search might return removed entry |