Re: [PATCHES] Non-transactional pg_class, try 2 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] Non-transactional pg_class, try 2
Date
Msg-id 12797.1151416682@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] Non-transactional pg_class, try 2  ("Zeugswetter Andreas DCP SD" <ZeugswetterA@spardat.at>)
List pgsql-hackers
"Zeugswetter Andreas DCP SD" <ZeugswetterA@spardat.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
database.

* 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


pgsql-hackers by date:

Previous
From: Thomas Hallgren
Date:
Subject: refcount leak warnings
Next
From: Martijn van Oosterhout
Date:
Subject: Re: refcount leak warnings