Thomas Hallgren wrote: > Tom Lane wrote: > > >"Thomas" <[EMAIL PROTECTED]> 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.
Does this need a C comment addition? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
