On Wed, Oct 25, 2017 at 1:59 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> Another thing to consider is that, if we could replace satisfiesfunc, >> it would probably break some existing code. There are multiple places >> in the code that compare snapshot->satisfies to >> HeapTupleSatisfiesHistoricMVCC and HeapTupleSatisfiesMVCC. >> >> I think the storage API should just leave snapshots alone. If a >> storage engine wants to call HeapTupleSatisfiesVisibility() with that >> snapshot, it can do so. Otherwise it can switch on >> snapshot->satisfies and handle each case however it likes. >> > > How will it switch satisfies at runtime? There are places where we > might know which visibility function (*MVCC , *Dirty, etc) needs to be > called, but I think there are other places (like heap_fetch) where it > is not clear and we decide based on what is stored in > snapshot->satisfies.
An alternative storage engine needs to provide its own implementation of heap_fetch, and that replacement implementation can implement MVCC and other snapshot behavior in any way it likes. My point here is that I think it's better if the table access method stuff doesn't end up modifying snapshots. I think it's fine for a table access method to get passed a standard snapshot. Some code may be needed to cater to the access method's specific needs, but that code can live inside the table access method, without contaminating the snapshot stuff. We have to try to draw some boundary around table access methods -- we don't want to end up teaching everything in the system about them. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers