> On 20 Mar 2017, at 15:17, Craig Ringer <cr...@2ndquadrant.com> wrote: > >> I thought about having special field (or reusing one of the existing fields) >> in snapshot struct to force filtering xmax > snap->xmax or xmin = snap->xmin >> as Petr suggested. Then this logic can reside in ReorderBufferCommit(). >> However this is not solving problem with catcache, so I'm looking into it >> right now. > > OK, so this is only an issue if we have xacts that change the schema > of tables and also insert/update/delete to their heaps. Right? > > So, given that this is CF3 for Pg10, should we take a step back and > impose the limitation that we can decode 2PC with schema changes or > data row changes, but not both?
Yep, time is tight. I’ll try today/tomorrow to proceed with this two scan approach. If I’ll fail to do that during this time then I’ll just update this patch to decode only non-ddl 2pc transactions as you suggested. >> Just as before I marking this transaction committed in snapbuilder, but after >> decoding I delete this transaction from xip (which holds committed >> transactions >> in case of historic snapshot). > > That seems kind of hacky TBH. I didn't much like marking it as > committed then un-committing it. > > I think it's mostly an interface issue though. I'd rather say > SnapBuildPushPrepareTransaction and SnapBuildPopPreparedTransaction or > something, to make it clear what we're doing. Yes, that will be less confusing. However there is no any kind of queue, so SnapBuildStartPrepare / SnapBuildFinishPrepare should work too. > -- > Craig Ringer http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers