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 jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461