| From: | Marcin Stępnicki <mstepnicki(at)gmail(dot)com> |
|---|---|
| To: | Janet Jacobsen <jsjacobsen(at)lbl(dot)gov> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: slow DELETE on 12 M row table |
| Date: | 2009-06-26 10:40:40 |
| Message-ID: | 179149fe0906260340o77e0bfd3n8913341e115ce995@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Fri, Jun 26, 2009 at 9:34 AM, Janet Jacobsen<jsjacobsen(at)lbl(dot)gov> wrote:
> I assume that killing the user's process released the lock on the
> table. This user has only SELECT privileges. Under what
> conditions would a SELECT lock a table. The user connects
> to the database via a (Python?) script that runs on another
> machine. Would this way of connecting to the database result
> in a lock?
Was this process 'idle in transaction' perhaps? Does this Python
script use any ORM, like SQLAlchemy? If not, which library does it use
to connect? If it's psycopg2, which isolation level (autocommit, read
committed, serializable) is set?
Regards,
Marcin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2009-06-26 14:33:24 | Re: GiST index performance |
| Previous Message | Janet Jacobsen | 2009-06-26 07:34:07 | Re: slow DELETE on 12 M row table |