On Sun, Jun 30, 2019 at 9:07 AM Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Jun 24, 2019 at 1:43 PM Alvaro Herrera <alvhe...@2ndquadrant.com> > wrote: > > I think enlarging multixacts to 64 bits is a terrible idea. I would > > rather get rid of multixacts completely; zheap is proposing not to use > > multixacts at all, for example. > > But zedstore, at least as of the Saturday after PGCon, is proposing to > keep using them, after first widening them to 64 bits: > > https://www.postgresql.org/message-id/CA+TgmoYeTeQSmALox0PmSm5Gh03oe=unjhml+k+btofy_u2...@mail.gmail.com > > I think we all have a visceral reaction against MultiXacts at this > point; they've just caused us too much pain, and the SLRU > infrastructure is a bunch of crap.[1] However, the case where N > sessions all do "SELECT * FROM sometab FOR SHARE" is pretty wretched > without multixacts. You'll just have to keep reducing the tuple > density per page to fit all the locks, whereas the current heap is > totally fine and neither the heap nor the multixact space bloats all > that terribly much. > > I currently think it's likely that zheap will use something > multixact-like rather than actually using multixacts per se. I am > having trouble seeing how we can have some sort of fixed-bit-width ID > number that represents as set of XIDs for purposes of lock-tracking > without creating some nasty degenerate cases that don't exist > today.[2]
The new thing described over here is intended to support something a bit like multixacts: https://www.postgresql.org/message-id/CA%2BhUKGKni7EEU4FT71vZCCwPeaGb2PQOeKOFjQJavKnD577UMQ%40mail.gmail.com For example, here is some throw-away demo code that puts arbitrary data into an undo log, in this case a list of xids given with SELECT test_multixact(ARRAY[1234, 2345, 3456]), and provides a callback to say when the data can be discarded, in this case when all of those xids are no longer running. You can see the record with SELECT * FROM undoinspect('shared'), until it gets eaten by a background worker. The reason it has to be an in-core demo is just because we don't have a way to do extensions that have an RMGR ID and callback functions yet. Although this demo throws the return value away, the function PrepareUndoInsert() returns a 64 bit UndoRecPtr which could be stored in any page and can be used to retrieve the records (via the buffer pool) including the binary payload which can be whatever struct you like (though there is a size limit so you might need more than one record for a huge list of multi-lockers). When you try to load the record, you might be told that it's gone, which means that the lockers are gone, whcih means that your callback must have said that was OK. This probably makes most sense for a system that is already planning to use UndoRecPtr for other things, like MVCC, since it probably already has per page or per tuple space to store UndoRecPtr, and updates and explicit locks are so closely related. https://github.com/EnterpriseDB/zheap/commit/c92fdfd1f1178cbb44557a7c630b366d1539c332 -- Thomas Munro https://enterprisedb.com
