Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, simon(at)2ndquadrant(dot)com, kleptog(at)svana(dot)org, gsstark(at)mit(dot)edu, pg(at)rbt(dot)ca, zhouqq(at)cs(dot)toronto(dot)edu, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and
Date: 2006-01-03 16:43:25
Message-ID: 20060103164325.GJ82560@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 03, 2006 at 11:26:51AM -0500, Tom Lane wrote:
> "Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> > Dumb question: if the ALTER is done inside a transaction, and then
> > reverted at the end of the transaction, does that mean that no other
> > transactions would have those permissions? I think the general use-case
> > is that you only one the session doing the ALTER to be able to use these
> > special modes, not anyone else who happens to be hitting the table at
> > that time...
>
> Such an ALTER would certainly require exclusive lock on the table,
> so I'm not sure that I see much use-case for doing it like that.
> You'd want to do the ALTER and commit so as not to lock other people
> out of the table entirely while doing the bulk data-pushing.

Maybe this just isn't clear, but would EXCLUSIVE block writes from all
other sessions then? The post I replied to mentioned that the ALTER
would affect all backends is why I'm wondering...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-01-03 16:48:01 Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and
Previous Message Bruce Momjian 2006-01-03 16:43:23 Re: Stats collector performance improvement