On Sun, Aug 14, 2016 at 9:33 PM, zh1029 <zh1029@sina.com> wrote:
> Hi,
> We are using PostgreSQL 9.3.11. We are observing DB update failed due to
> lock timeout. failure because waiting for RowExclusiveLock. Autovacuum uses
> plain vacuum which uses ShareUpdateExclusiveLock. right?
> But from Postgres Manual chapter 13.3. Explicit Locking. both Locks has no
> conflict. So in which situation conflict lock happened. Does autovacuum use
> other lock than ShareUpdateExclusiveLock in certain situation?
>
> Aug 10 15:03:16 DB-1 postgres[3314]: [5-1] DEBUG: sending cancel to
> blocking autovacuum PID 25047
What is your log_line_prefix? I am not familiar with the '[5-1]'
thing. I assume %l is the final part, but what is the first first
part? Also, including the milliseconds in the timestamps can help a
lot (%m rather than %t), because a 200ms gap between log messages can
lead to much different interpretation than a 2ms gap. And is 3314 the
port you are running on, or is it the pid of the process? Is DEBUG
set globally or locally?
Why don't we ever see 25047 responding to the cancellation?
Anyway, ShareUpdateExclusiveLock and RowExclusiveLock do not directly
interfere with each other. If you have a chain of processes blocking
each other, it is possible that one blocks the other indirectly. Your
log file seems incomplete, so it is hard to say what is going on.
Does your app use any explicit table locks?
Cheers,
Jeff
