On Fri, Nov 26, 2010 at 7:27 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> In fact, now that I think about it, what I'm proposing would actually >> substantially REDUCE the risk of deadlock on the standby, because the >> master would only ever need to lock a backing file long enough to drop >> or truncate it, whereas under the present system the startup process >> might need to hold many locks at once. > > Now you're the one spouting nonsense. Consider a master transaction > that does > > begin; > lock table foo; > alter table foo --- some rewriting table operation; > alter table foo --- some rewriting table operation; > alter table foo --- some rewriting table operation; > alter table foo --- some rewriting table operation; > alter table foo --- some rewriting table operation; > alter table foo --- some rewriting table operation; > alter table foo --- some rewriting table operation; > commit; > > On the master, no other transaction can see the intermediate states. > We don't want that property to disappear on the slave.
And why would it? Which states are visible is something that gets controlled by MVCC, not by the order in which we remove backing files. It's possible that to make what I'm describing work correctly, you need to acquire the locks and then drop all the backing files, rather than interleaving those operations. I'm not sure about that. But acquiring them at the same point in WAL that master did seems quite pointless - AFAICS, you lose nothing by postponing until commit time. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
