On Sun, Jul 30, 2006 at 11:44:44AM -0400, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Stefan Kaltenbrunner wrote: > >> FYI: lionfish just managed to hit that problem again: > >> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lionfish&dt=2006-07-29%2023:30:06 > > > The test alter_table, which is on the same parallel group as limit (the > > failing test), contains these lines: > > ALTER INDEX onek_unique1 RENAME TO tmp_onek_unique1; > > ALTER INDEX tmp_onek_unique1 RENAME TO onek_unique1; > > I bet Alvaro's spotted the problem. ALTER INDEX RENAME doesn't seem to > take any lock on the index's parent table, only on the index itself. > That means that a query on "onek" could be trying to read the pg_class > entries for onek's indexes concurrently with someone trying to commit > a pg_class update to rename an index. If the query manages to visit > the new and old versions of the row in that order, and the commit > happens between, *neither* of the versions would look valid. MVCC > doesn't save us because this is all SnapshotNow. > > Not sure what to do about this. Trying to lock the parent table could > easily be a cure-worse-than-the-disease, because it would create > deadlock risks (we've already locked the index before we could look up > and lock the parent). Thoughts? > > The path of least resistance might just be to not run these tests in > parallel. The chance of this issue causing problems in the real world > seems small.
It doesn't seem that unusual to want to rename an index on a running system, and it certainly doesn't seem like the kind of operation that should pose a problem. So at the very least, we'd need a big fat warning in the docs about how renaming an index could cause other queries in the system to fail, and the error message needs to be improved. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
