Re: AccessShareLock question - Mailing list pgsql-general

From Clayton Graf
Subject Re: AccessShareLock question
Date
Msg-id 7b2fe65d0912191245j7dc363ex7ac9a0ce131c4fff@mail.gmail.com
Whole thread Raw
In response to Re: AccessShareLock question  (Jaime Casanova <jcasanov@systemguards.com.ec>)
Responses Re: AccessShareLock question  (Adrian Klaver <aklaver@comcast.net>)
List pgsql-general
I think I got it...

I was just using 

select * from table1;
select * from table2;
select * from tablen;

instead of

begin;
select * from table1;
select * from table2;
select * from tablen;
commit;

Using MS-SQLSERVER the begin trans is "implicit" at first update or delete command. It is not necessary to "worry" about selects before the first update or delete command. I got confused but I understand now. I guess :-)

Thank you,

Clayton


2009/12/19 Jaime Casanova <jcasanov@systemguards.com.ec>
On Sat, Dec 19, 2009 at 10:58 AM, Clayton Graf <clayton.graf@gmail.com> wrote:
> Ok, but this is really my problem: I cannot perform an ALTER TABLE with the
> system in production mode, because the ALTER TABLE hangs due an
> AccessShareLock.

until the lock is released, are your selects all that long?
besides, why are you ALTERing the table in production... i guess
clients will suffer if the expect less or more columns than the ones
they receive from the ALTERed table

> We use two-tier mode,

don't understand this

> so is it necessary to shutdown all users before
> perform an ALTER TABLE?

no

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157



--
Clayton Graf

pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Triggers made with plpythonu performance issue
Next
From: Adrian Klaver
Date:
Subject: Re: Charset Win1250 on Windows and Ubuntu