Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2006-06-27 14:08:52
Subject: Re: refcount leak warnings
Previous:From: Thomas HallgrenDate: 2006-06-27 13:55:06
Subject: refcount leak warnings

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group