Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 03.06.2011 23:44, Kevin Grittner wrote:
>> Hmm. As mentioned earlier in the thread, cleaning these up
>> doesn't actually have any benefit beyond freeing space in the
>> predicate locking collections. I'm not sure that benefit is
>> enough to justify this much new mechanism. Maybe I should just
>> leave them alone and let them get cleaned up in due course with
>> the rest of the locks. Any opinions on that?
>
> Is there a chance of false positives if oid wraparound happens and
> a new table gets the same oid as the old one? It's also possible
> for a heap to get the OID of an old index or vice versa, will that
> confuse things?
Tuple locks should be safe from that because we use the tuple xmin
as part of the target key, but page and heap locks could result in
false positive serialization failures on OID wraparound unless we do
the cleanup. I guess that tips the scales in favor of it being
worth the extra code. I think it's still in that gray area where
it's a judgment call because it would be very infrequent and it
would be recoverable; but the fewer mysterious rollbacks, the fewer
posts about it we'll get. So any costs in maintaining the extra
code will probably be saved in reduced support, even if the
performance benefit is negligible.
-Kevin