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

Re: [WIP] The relminxid addition, try 3

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [WIP] The relminxid addition, try 3
Date: 2006-05-26 03:34:29
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Well, if a transaction modifies a table in some way, even without
> > changing the data, should generate an unfreeze event, because it will
> > need to lock the table; for example AlterTable locks the affected
> > relation with AccessExclusiveLock.  It's important for the
> > non-transactional change to the pg_class tuple be the very first in the
> > transaction, because otherwise the change could be lost; but other than
> > this, I don't think there's any problem.
> You can't guarantee that.  Consider for instance manual updates to
> pg_class:
> 	UPDATE pg_class SET reltriggers = 0 WHERE relname = ...
> 	... alter table contents ...
> I believe there are actually patterns like this in some pg_dump output.
> Will you hack every UPDATE operation to test whether it's changing
> pg_class and if so force an "unfreeze" operation before changing any
> row?  No thanks :-(

Oh, true, I hadn't thought of direct updates to pg_class.

> >> I'm wondering if we need a second pg_class-derived catalog that carries
> >> just the nontransactional columns.
> > I hope we don't need to do this because ISTM it will be a very big change.
> (Yawn...)  We've made far bigger changes than that.  The important
> thing is to get it right.

Yeah, I know -- I've been involved in some of them.  I hereby volunteer
to do it for 8.2 because I'd really like to see this patch in.

Alvaro Herrera                      
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

pgsql-patches by date

Next:From: Gurjeet SinghDate: 2006-05-26 15:38:47
Subject: Re: [HACKERS] BEGIN inside transaction should be an error
Previous:From: Tom LaneDate: 2006-05-26 03:09:51
Subject: Re: [WIP] The relminxid addition, try 3

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