On Fri, Dec 7, 2012 at 03:32:51PM +0100, Andres Freund wrote: > > Well, it is a CONCURRENT index creation, so locking would be minimal. > > I wouldn't call a ShareUpdateExclusiveLock minimal... > > > Do we want pg_upgrade to be groveling over the lock view to look for > > locks? I don't think so. > > ISTM that anybody who does DDL during or after pg_upgrade --check > deserves any pain. > > So throwing an error in both seems perfectly fine for me.
Well, most of the current checks relate to checks for created objects. To fail for in-process concurrent index creation is to fail for an intermediate state --- index creation in process, but might complete before we do the actual upgrade. Or it might not be an intermediate state. I am just saying that this makes the --check report more likely to false failures than currently configured. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
