Original-Nachricht
> Datum: Sun, 03 Apr 2011 16:25:35 +0200
> Von: Thomas Kellerer
> An: pgsql-general@postgresql.org
> Betreff: Re: [GENERAL] Table lock while adding a column and clients are
> logged in
> Sven Haag wrote on 03.04.2011 16:13:
> &g
Sven Haag wrote on 03.04.2011 16:13:
Original-Nachricht
Datum: Sun, 03 Apr 2011 15:37:17 +0200
Von: Thomas Kellerer
An: pgsql-general@postgresql.org
Betreff: Re: [GENERAL] Table lock while adding a column and clients are logged
in
Alban Hertroys wrote on 03.04.2011 11:17
Original-Nachricht
> Datum: Sun, 03 Apr 2011 15:37:17 +0200
> Von: Thomas Kellerer
> An: pgsql-general@postgresql.org
> Betreff: Re: [GENERAL] Table lock while adding a column and clients are
> logged in
> Alban Hertroys wrote on 03.04.2011 11:17:
> >
Alban Hertroys wrote on 03.04.2011 11:17:
On 2 Apr 2011, at 12:44, Thomas Kellerer wrote:
Even after a plain SELECT you should issue a COMMIT (or ROLLBACK)
to end the transaction that was implicitely started with the
SELECT.
Sorry, but you're wrong about that. A statement that implicitly
star
Alban Hertroys wrote on 03.04.2011 11:31:
On 3 Apr 2011, at 11:22, Alban Hertroys wrote:
Oracle and SQL server don't "suffer" from this because they do not
handle DDL statements transactionally (I could be mistaken about
SQL server, I don't know it all that well).
I forgot to mention, if you
On 3 Apr 2011, at 11:22, Alban Hertroys wrote:
> Oracle and SQL server don't "suffer" from this because they do not handle DDL
> statements transactionally (I could be mistaken about SQL server, I don't
> know it all that well).
I forgot to mention, if you perform DDL in Oracle all your curren
On 2 Apr 2011, at 11:09, Sven Haag wrote:
> hello pg fans,
>
> we have an application that communicates via ODBC directly to the postgres
> database.
>
> if i'm trying to add an additional column to a table in pgadmin while clients
> are logged in, pgadmin hangs. only if all cients are logged
On 2 Apr 2011, at 12:44, Thomas Kellerer wrote:
> Even after a plain SELECT you should issue a COMMIT (or ROLLBACK) to end the
> transaction that was implicitely started with the SELECT.
Sorry, but you're wrong about that. A statement that implicitly starts a
transaction also implicitly COMMIT
Jerry Sievers writes:
> "Sven Haag" writes:
>
>> hello pg fans,
>>
>> we have an application that communicates via ODBC directly to the
>> postgres database.
>>
>> if i'm trying to add an additional column to a table in pgadmin while
>> clients are logged in, pgadmin hangs. only if all cients ar
"Sven Haag" writes:
> hello pg fans,
>
> we have an application that communicates via ODBC directly to the
> postgres database.
>
> if i'm trying to add an additional column to a table in pgadmin while
> clients are logged in, pgadmin hangs. only if all cients are logged
> out it returns to the n
Sven Haag wrote on 02.04.2011 12:13:
if i'm trying to add an additional column to a table in pgadmin
while
clients are logged in, pgadmin hangs. only if all cients are logged
out it returns to the normal state. according to our consultant of
the application this behavior doesn't appear in oracle
: Guillaume Lelarge
> An: Sven Haag
> CC: pgsql-general@postgresql.org
> Betreff: Re: [GENERAL] Table lock while adding a column and clients are
> logged in
> Le 02/04/2011 11:09, Sven Haag a écrit :
> > hello pg fans,
> >
> > we have an application that comm
Le 02/04/2011 11:09, Sven Haag a écrit :
> hello pg fans,
>
> we have an application that communicates via ODBC directly to the postgres
> database.
>
> if i'm trying to add an additional column to a table in pgadmin while clients
> are logged in, pgadmin hangs. only if all cients are logged ou
14 matches
Mail list logo
