Re: autovacuum locking question

2019-12-06 Thread Jeff Janes
On Fri, Dec 6, 2019 at 12:50 PM MichaelDBA wrote: > And Just to reiterate my own understanding of this... > > autovacuum priority is less than a user-initiated request, so issuing a > manual vacuum (user-initiated request) will not result in being cancelled. > Somethings happen in some

Re: autovacuum locking question

2019-12-06 Thread MichaelDBA
And Just to reiterate my own understanding of this... autovacuum priority is less than a user-initiated request, so issuing a manual vacuum (user-initiated request) will not result in being cancelled. Regards, Michael Vitale Jeff Janes wrote on 12/6/2019 12:47 PM: On Fri, Dec 6, 2019 at

Re: autovacuum locking question

2019-12-06 Thread Justin Pryzby
On Thu, Dec 05, 2019 at 06:49:06PM -0500, Tom Lane wrote: > The only part that would get canceled in response to somebody taking a > non-exclusive lock is the last step, which is truncation of unused blocks at > the end of the table; that requires an exclusive lock. On Thu, Dec 05, 2019 at

Re: autovacuum locking question

2019-12-06 Thread Jeff Janes
On Fri, Dec 6, 2019 at 10:55 AM Mike Schanne wrote: > The error is not actually showing up very often (I have 8 occurrences from > 11/29 and none since then). So maybe I should not be concerned about it. > I suspect we have an I/O bottleneck from other logs (i.e. long checkpoint > sync times),

Re: autovacuum locking question

2019-12-06 Thread Tom Lane
Mike Schanne writes: > The error is not actually showing up very often (I have 8 occurrences from > 11/29 and none since then). So maybe I should not be concerned about it. I > suspect we have an I/O bottleneck from other logs (i.e. long checkpoint sync > times), so this error may be a

Re: autovacuum locking question

2019-12-06 Thread Tom Lane
Mike Schanne writes: > Is this what you are referring to? > - Prevent VACUUM from trying to freeze an old multixact ID involving a > still-running transaction (Nathan Bossart, Jeremy Schneider) > This case would lead to VACUUM failing until the old transaction terminates. >

RE: autovacuum locking question

2019-12-06 Thread Mike Schanne
. From: Jeff Janes [mailto:jeff.ja...@gmail.com] Sent: Thursday, December 05, 2019 6:55 PM To: Mike Schanne Cc: pgsql-performa...@postgresql.org Subject: Re: autovacuum locking question On Thu, Dec 5, 2019 at 5:26 PM Mike Schanne mailto:mscha...@kns.com>> wrote: Hi, I am investigating a perfo

RE: autovacuum locking question

2019-12-06 Thread Mike Schanne
/ Thanks, Mike -Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Thursday, December 05, 2019 6:49 PM To: Mike Schanne Cc: 'pgsql-performa...@postgresql.org' Subject: Re: autovacuum locking question Mike Schanne writes: > I am investigating a performance problem in

Re: autovacuum locking question

2019-12-05 Thread Jeff Janes
On Thu, Dec 5, 2019 at 5:26 PM Mike Schanne wrote: > Hi, > > I am investigating a performance problem in our application and am seeing > something unexpected in the postgres logs regarding the autovacuum. > > > > 2019-12-01 13:05:39.029 >

Re: autovacuum locking question

2019-12-05 Thread Tom Lane
Mike Schanne writes: > I am investigating a performance problem in our application and am seeing > something unexpected in the postgres logs regarding the autovacuum. > 2019-12-01 13:05:39.029 > UTC,"wb","postgres",6966,"127.0.0.1:53976",5ddbd990.1b36,17099,"INSERT > waiting",2019-11-25

Re: autovacuum locking question

2019-12-05 Thread Michael Lewis
On Thu, Dec 5, 2019 at 3:26 PM Mike Schanne wrote: > I am concerned that if the autovacuum is constantly canceled, then the > table never gets cleaned and its performance will continue to degrade over > time. Is it expected for the vacuum to be canceled by an insert in this > way? > > > > We