On Mon, Jul 29, 2019 at 2:24 PM Peter Geoghegan <p...@bowt.ie> wrote: > Yes. It doesn't really make any difference with B-Trees, because the > locks there are very similar to row locks (you still need forwarding > UNDO metadata in index pages, probably for checking the visibility of > index tuples that have their ghost bit set). But when you need to undo > changes to an indexes with coarse grained index tuples (e.g. in a GIN > index), the transaction needs to roll back the index tuple as a whole, > necessitating that locks be held. Heap TIDs need to be completely > stable to avoid a VACUUM-like mechanism -- you cannot just create a > new HOT chain. You even have to be willing to store a single heap row > across two heap pages in extreme cases where an UPDATE makes it > impossible to fit a new row on the same heap page as the original -- > this is called row forwarding.
I find this hard to believe, because an UPDATE can always be broken up into a DELETE and an INSERT. If that were to be done, you would not have a stable heap TID and you would have a "new HOT chain," or your AM's equivalent of that concept. So if we can't handle an UPDATE that changes the TID, then we also can't handle a DELETE + INSERT. But surely handling that case is a hard requirement for any AM. Sorry if I'm being dense here, but I feel like you're making some assumptions that I'm not quite following. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
