On Sun, Aug 14, 2016 at 9:33 PM, zh1029 <zh1029@xxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
