Amit Kapila <amit.kapil...@gmail.com> writes:
> Hmm. Consider that the first time relcahe invalidation occurs while
> computing id_attrs, so now the retry logic will compute the correct
> set of attrs (considering two indexes, if we take the example given by
> Alvaro above.). However, the attrs computed for hot_* and key_* will
> be using only one index, so this will lead to a situation where two of
> the attrs (hot_attrs and key_attrs) are computed with one index and
> id_attrs is computed with two indexes. I think this can lead to
> Assertion in HeapSatisfiesHOTandKeyUpdate().
That seems like something we'd be best off to fix by changing the
assertion. I doubt it's really going to be practical to guarantee that
those bitmapsets are always 100% consistent throughout a transaction.
> Okay, please find attached patch which is an extension of Tom's and
> Andres's patch and I think it fixes the above problem noted by me.
I don't like this patch at all. It only fixes the above issue if the
relcache inval arrives while RelationGetIndexAttrBitmap is executing.
If the inval arrives between two such calls, you still have the problem
of the second one delivering a bitmapset that might be inconsistent
with the first one.
To go in this direction, I think we would have to hot-wire
RelationGetIndexAttrBitmap so that once any bitmapset has been requested
in a transaction, we intentionally ignore all index set updates for the
remainder of the transaction. And that would very likely create more
problems than it solves (consider locally initiated DDL within the
transaction, for example).
Better to fix the callers so that they don't have the assumption you
refer to. Or maybe we could adjust the API of RelationGetIndexAttrBitmap
so that it returns all the sets needed by a given calling module at
once, which would allow us to guarantee they're consistent.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
