Martijn van Oosterhout writes:
> I think what you're missing here is that RowExclusiveLocks are taken by
> marking the row itself.
More specifically: row-level locks are not reflected in pg_locks at all.
A RowExclusiveLock entry in pg_locks reflects a *table* level lock,
which is taken by any INS
On Apr 25, 2012, at 1:31 PM, Tom Lane wrote:
> I don't have all the details in my head, but if you deliberately provoke
> a deadlock by making two transactions update the same two rows in
> opposite orders, you'll soon find out what it looks like in the log.
Heh, duh. Looks like your first guess
On Wed, Apr 25, 2012 at 01:12:37PM -0600, Ben Chobot wrote:
> So, if I understand what you're saying, if I have two connections
> each transactionally updating many rows, then each transaction will
> need to acquire a RowExclusiveLock for each row (as documented), and
> also (as not documented?) ea
Ben Chobot writes:
> So, if I understand what you're saying, if I have two connections each
> transactionally updating many rows, then each transaction will need to
> acquire a RowExclusiveLock for each row (as documented), and also (as not
> documented?) each acquisition will temporarily acqui
On Apr 25, 2012, at 12:35 PM, Tom Lane wrote:
> Ben Chobot writes:
>> We have a few daemon process that constantly pull batches of logs from a
>> work queue and then insert into or update a single table in a single
>> transaction, ~1k rows at a time. I've been told the transaction does nothing
Ben Chobot writes:
> We have a few daemon process that constantly pull batches of logs from a work
> queue and then insert into or update a single table in a single transaction,
> ~1k rows at a time. I've been told the transaction does nothing other than
> insert and update on that table, and I
We have a few daemon process that constantly pull batches of logs from a work
queue and then insert into or update a single table in a single transaction,
~1k rows at a time. I've been told the transaction does nothing other than
insert and update on that table, and I can verify the table in que
