On Fri, Nov 26, 2010 at 7:27 PM, Tom Lane <tgl@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