Re: BUG #1502: hash_seq_search might return removed entry
От | Thomas Hallgren |
---|---|
Тема | Re: BUG #1502: hash_seq_search might return removed entry |
Дата | |
Msg-id | thhal-0mkf4AhPcxicK12cCHrA/1L1cbyRqUM@mailblocks.com обсуждение исходный текст |
Ответ на | Re: BUG #1502: hash_seq_search might return removed entry (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #1502: hash_seq_search might return removed entry
|
Список | pgsql-bugs |
Tom Lane wrote: >"Thomas" <thhal@mailblocks.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
В списке pgsql-bugs по дате отправления: