From: | Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | Timothy Garnett <tgarnett(at)panjiva(dot)com> |
Subject: | Re: Documentation of what schema modifications cause what level of table locking |
Date: | 2011-09-24 18:23:57 |
Message-ID: | 201109241123.57741.adrian.klaver@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Friday, September 23, 2011 3:52:54 pm Timothy Garnett wrote:
> Hi all,
>
> I was wondering if there was some good documentation on what kinds of
> schema modifications block reads vs. which ones don't. For ex. we
> recently had an issue where someone ran as part of a migration
>
> ALTER TABLE tname ALTER COLUMN cname SET NOT NULL;
>
> on a large table that is not inserted to or updated. While we'd expect
> such an operation to block inserts/updates (writes) to the table, we were
> surprised to observe that it also blocked selects (reads) from the table
> as well, which we would not have naively expected (and caused a great deal
> of headache). On the other hand creating an index on a table blocks
> writes, but still allows reads (even a unique index), as documented in the
> create index docs. Is there a list somewhere of what operations block
> selects (reads) to a table that we should watch out for?
http://www.postgresql.org/docs/9.1/interactive/explicit-locking.html
>
> We are currently using PostgreSQL 9.0.3.
>
> Thanks!
> Tim
--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2011-09-24 18:31:28 | Re: Mac OS X shared_buffers not same as postgresql.conf file |
Previous Message | Marti Raudsepp | 2011-09-24 15:30:11 | Re: get number and names of processes connected to postgresql |