Re: [PATCHES] Non-transactional pg_class, try 2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] Non-transactional pg_class, try 2
Date: 2006-06-27 13:58:02
Message-ID: 12797.1151416682@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

"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
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-06-27 14:08:52 Re: refcount leak warnings
Previous Message Thomas Hallgren 2006-06-27 13:55:06 refcount leak warnings

Browse pgsql-patches by date

  From Date Subject
Next Message Yoshiyuki Asaba 2006-06-27 15:23:13 SO_SNDBUF size is small on win32?
Previous Message Zeugswetter Andreas DCP SD 2006-06-27 08:57:15 Re: [PATCHES] Non-transactional pg_class, try 2