On Mon, Mar 5, 2012 at 4:32 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Sun, Mar 4, 2012 at 11:39 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >> Marti, please review this latest version which has new isolation tests added. >> >> This does both TRUNCATE and CREATE TABLE. > > I don't see any need for a GUC to control this behavior. The current > behavior is wrong, so if we're going to choose this path to fix it, > then we should just fix it, period. The narrow set of circumstances > in which it might be beneficial to disable this behavior doesn't seem > to me to be sufficient to justify a behavior-changing GUC.
I agree behaviour is wrong, the only question is whether our users rely in some way on that behaviour. Given the long discussion on that point earlier I thought it best to add a GUC. Easy to remove, now or later. > It does not seem right that the logic for detecting the serialization > error is in heap_beginscan_internal(). Surely this is just as much of > a problem for an index-scan or index-only-scan. err, very good point. Doh. > We don't want to > patch all those places individually, either: I think the check should > happen right around the time we initially lock the relation and build > its relcache entry. OK, that makes sense and works if we need to rebuild relcache. > The actual text of the error message could use some work. Maybe > something like "could not serialize access due to concurrent DDL", > although I think we try to avoid using acronyms like DDL in > translatable strings. Yeh that was designed-to-be-replaced text. We do use DDL already elsewhere without really explaining it; its also one of those acronyms that doesn't actually explain what it really means very well. So I like the phrase you suggest. -- 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
