On Wed, Feb 23, 2011 at 12:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> ...but that begs the question of why DROP INDEX needs an
>> AccessExclusiveLock. It probably needs such a lock *on the index* but
>> I don't see why we'd need it on the table.
>
> Some other session might be in process of
Robert Haas writes:
> ...but that begs the question of why DROP INDEX needs an
> AccessExclusiveLock. It probably needs such a lock *on the index* but
> I don't see why we'd need it on the table.
Some other session might be in process of planning a query on the table.
It would be sad if the inde
On Tue, Feb 22, 2011 at 11:21 PM, Noah Misch wrote:
> On Tue, Feb 22, 2011 at 10:18:36PM -0500, Robert Haas wrote:
>> On Wed, Feb 2, 2011 at 12:20 AM, Noah Misch wrote:
>> >> CREATE TABLE account (account_id SERIAL PRIMARY KEY, name CHARACTER
>> >> VARYING
>> >> NOT NULL);
>> >> CREATE TABLE foo
On Tue, Feb 22, 2011 at 10:18:36PM -0500, Robert Haas wrote:
> On Wed, Feb 2, 2011 at 12:20 AM, Noah Misch wrote:
> >> CREATE TABLE account (account_id SERIAL PRIMARY KEY, name CHARACTER VARYING
> >> NOT NULL);
> >> CREATE TABLE foo (account_id INTEGER NOT NULL REFERENCES account
> >> (account_id)
Robert Haas writes:
> The problem is that constraints can affect the query plan. If a
> transaction sees the constraint in the system catalogs (under
> SnapshotNow) but the table data doesn't conform (under some earlier
> snapshot) and if the chosen plan depends on the validity of the
> constrain
On Wed, Feb 2, 2011 at 12:20 AM, Noah Misch wrote:
>> CREATE TABLE account (account_id SERIAL PRIMARY KEY, name CHARACTER VARYING
>> NOT NULL);
>> CREATE TABLE foo (account_id INTEGER NOT NULL REFERENCES account
>> (account_id), stuff CHARACTER VARYING);
>
>> DROP TABLE foo;
>
>> That query shows
On Tue, Feb 01, 2011 at 02:18:37PM -0500, Nikolas Everett wrote:
> Is there an exhaustive list of what takes what locks and how long they last?
This documents which commands take each lock type, but it is not exhaustive:
http://www.postgresql.org/docs/current/interactive/explicit-locking.html
All
On Tue, Feb 1, 2011 at 2:18 PM, Nikolas Everett wrote:
> This isn't exactly how our workload actually works. Ours is more deadlock
> prone. We have many connections all querying account and we do the
> migration in a transaction. It looks as though the AccessExclusiveLock is
> held until the tr
On Wed, Feb 2, 2011 at 3:29 PM, Nikolas Everett wrote:
>
>
> On Wed, Feb 2, 2011 at 2:53 PM, Nikolas Everett wrote:
>
>> Given that the a list would be difficult to maintain, is there some way I
>> can make Postgres spit out the list of what locks are taken?
>>
>> --Nik
>>
>
> I just answered my
On Wed, Feb 2, 2011 at 2:53 PM, Nikolas Everett wrote:
> Given that the a list would be difficult to maintain, is there some way I
> can make Postgres spit out the list of what locks are taken?
>
> --Nik
>
I just answered my own question -
compile with -DLOCK_DEBUG in your src/Makefile.custom an
Given that the a list would be difficult to maintain, is there some way I
can make Postgres spit out the list of what locks are taken?
--Nik
On Wed, Feb 2, 2011 at 1:58 PM, Greg Smith wrote:
> Nikolas Everett wrote:
>
>> Is there an exhaustive list of what takes what locks and how long they
>>
Nikolas Everett wrote:
Is there an exhaustive list of what takes what locks and how long they
last? I'm asking because we just had some trouble doing a hot db
change to an 8.3.6 system. I know it is an old version but it is what
I have to work with.
There haven't been any major changes in t
12 matches
Mail list logo
