On Fri, Jun 24, 2011 at 9:00 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Jun 24, 2011 at 3:46 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >> Test case please. I don't understand the problem you're describing. > > S1: select * from foo; > S2: begin; > S2: alter table foo alter column a set storage plain; > S1: select * from foo; > <blocks>
Er,,.yes, that what locks do. Where is the bug? We have these choices of behaviour 1. It doesn't error and doesn't block - not possible for 9.1, probably not for 9.2 either 2. It doesn't block, but may throw an error sometimes - the reported bug 3. It blocks in some cases for short periods where people do repeated DDL, but never throws errors - this patch 4. Full scale locking - human sacrifice, cats and dogs, living together, mass hysteria If you want to avoid the blocking, then don't hold open the transaction. Do this S1: select * from foo S2: alter table.... run in its own transaction S1: select * from foo Doesn't block, no errors. Which is exactly what most people do on their production servers. The ALTER TABLE statements we're talking about are not schema changes. They don't need to be coordinated with other DDL. This patch has locking, but its the most reduced form of locking that is available for a non invasive patch for 9.1 -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
