Hi everyone...
I have a python-based application which provides a user interface
to a Postgresql database. The latest version of the application suddenly
lost the inability to insert new data in some of the tables. The SQL
statement(s) used still work if manually typed in psql, but it a
On 8/4/05, Frank Miles <[EMAIL PROTECTED]> wrote:
> Hi everyone...
>
>I have a python-based application which provides a user interface
> to a Postgresql database. The latest version of the application suddenly
> lost the inability to insert new data in some of the tables. The SQL
> stat
On Thu, Aug 04, 2005 at 03:03:47PM -0700, Frank Miles wrote:
> I have a python-based application which provides a user interface
> to a Postgresql database. The latest version of the application suddenly
> lost the inability to insert new data in some of the tables. The SQL
> statement(s) u
On Thu, 4 Aug 2005, Michael Fuhr wrote:
On Thu, Aug 04, 2005 at 03:03:47PM -0700, Frank Miles wrote:
I have a python-based application which provides a user interface
to a Postgresql database. The latest version of the application suddenly
lost the inability to insert new data in some
Frank Miles <[EMAIL PROTECTED]> writes:
> ... By the way, in this forced condition, the rows that show granted='f'
> have blank relname, relation, and database fields :(
Those would be locks on transaction IDs, which is what you see in
pg_locks when someone is blocked on a row-level lock. (For re
Following up on my question regarding locking...
Well... I'm less and less inclined to think that the update/insert failure
is due to a lock problem. Weird! Perhaps the python/psycopg interface?
I've never had a case where the python/psycopg invocation worked differently
than with the psql int
