"Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at> writes:
>> That was with a mind to performance. Checking every INSERT,
>> UPDATE and DELETE statement to see if they are being done
>> against a frozen table seems like a waste.
> I'd think we would have relminxid in the relcache, so I don't buy the
> performance argument :-)
Me either. Further, auto-revoking permissions loses information.
I think that idea is an ugly kluge.
Anyway, the bottom line here seems to be that we should forget about
pg_class_nt and just keep the info in pg_class; there's not sufficient
justification to build the infrastructure needed for a nontransactional
auxiliary catalog. This implies the following conclusions:
* template0 has to be vacuumed against wraparound, same as any other
* To support frozen tables, "VACUUM FREEZE" and "ALTER TABLE UNFREEZE"
would need to be explicit commands taking ExclusiveLock, and can't be
nested inside transaction blocks either. Automatic unfreeze upon an
updating command isn't possible.
Neither of these are bad enough to justify pg_class_nt --- in fact,
I'd argue that explicit unfreeze is better than automatic anyway.
So it was a cute idea, but its time hasn't come.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Martijn van Oosterhout||Date: 2006-06-27 14:08:52|
|Subject: Re: refcount leak warnings|
|Previous:||From: Thomas Hallgren||Date: 2006-06-27 13:55:06|
|Subject: refcount leak warnings|
pgsql-patches by date
|Next:||From: Yoshiyuki Asaba||Date: 2006-06-27 15:23:13|
|Subject: SO_SNDBUF size is small on win32?|
|Previous:||From: Zeugswetter Andreas DCP SD||Date: 2006-06-27 08:57:15|
|Subject: Re: [PATCHES] Non-transactional pg_class, try 2|