On Tue, Apr 25, 2006 at 12:48:04PM -0400, Alvaro Herrera wrote: > I'm late to this thread, but maybe we can make the process of storing > the new data in pg_class take a lock using LockObject() or something > like that to serialize the access to the pg_class row. The idea would > be that this lock doesn't conflict with a LockRelation(), but it would > of course conflict with itself so no two CREATE INDEXES can enter that > code section concurrently.
Is there anything in comments/docs/list archives about why catalog access uses a bunch of 'magic' instead of treating catalog tables the same as every other table? I realize that ultimately you have to bootstrap somehow (kinda hard to read from pg_class if the info needed to do so is in pg_class), but perhaps switching over to the regular access methods after the system is up would be worth-while. Advantages: Allows for concurrent access (using MVCC) Potentially reduces locking requirements (if snapshots aren't required anymore, each backend should theoretically be able to rely on MVCC to get the right catalog info, though of course this depends on the actual operation) Should allow for much-sought-after triggers on the system catalogs But I'm sure this has come up in the past, I just can't find any info about why not to do this... -- 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 4: Have you searched our list archives? http://archives.postgresql.org
