"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
> I've brought this up to an extent in the past, but is there an easy
> way to extend section 12.3.1 (or create some form of appendix) such
> that it reveals all possible locking paths for SQL commands in
> postgres?
It's very simple: any for
On Apr 4, 2006, at 4:53 PM, Tom Lane wrote:
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
As for how this plays out in the real world, a pg_dumpall will start
and run for a few hours. Sometime during that, this function might
get called. When it does, an ACCESS EXCLUSIVE lock is held again
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
> As for how this plays out in the real world, a pg_dumpall will start
> and run for a few hours. Sometime during that, this function might
> get called. When it does, an ACCESS EXCLUSIVE lock is held against
> the table identified as t13, her
On Apr 4, 2006, at 12:53 AM, Tom Lane wrote:
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
I'm dealing with an application that can potentially do ad hoc DDL.
It uses a PG/pgSQL function, and the only DDL statements in the
function are CREATE TABLE and CREATE INDEX statements. But I'm
noti
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
> I'm dealing with an application that can potentially do ad hoc DDL.
> It uses a PG/pgSQL function, and the only DDL statements in the
> function are CREATE TABLE and CREATE INDEX statements. But I'm
> noticing that during the backup process
I'm guessing that CREATE TABLE in itself doesn't take an ACCESS
EXCLUSIVE lock because there's nothing yet to lock. But can CREATE
TABLE ... INHERITS ... take an ACCESS EXCLUSIVE lock? Is it
functioning as an ALTER TABLE?
I'm dealing with an application that can potentially do ad hoc DDL.
