pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedautovacuum locking question
13+ messages / 6 participants
[nested] [flat]
* autovacuum locking question
@ 2019-12-05 17:46 Mike Schanne <mschanne@kns.com>
0 siblings, 3 replies; 13+ messages in thread
From: Mike Schanne @ 2019-12-05 17:46 UTC (permalink / raw)
To: pgsql-performance
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 UTC,"wb","postgres",6966,"127.0.0.1:53976",5ddbd990.1b36,17099,"INSERT waiting",2019-11-25 13:39:28 UTC,12/1884256,12615023,LOG,00000,"process 6966 still waiting for RowExclusiveLock on relation 32938 of database 32768 after 1000.085 ms","Process holding the lock: 6045. Wait queue: 6966.",,,,,"INSERT INTO myschema.mytable (...) VALUES (...) RETURNING process.mytable.mytable_id",13,,""
2019-12-01 13:05:39.458 UTC,,,6045,,5de3b800.179d,1,,2019-12-01 12:54:24 UTC,10/417900,0,ERROR,57014,"canceling autovacuum task",,,,,"automatic vacuum of table ""postgres.myschema.mytable""",,,,""
My understanding from reading the documentation was that a vacuum can run concurrently with table inserts/updates, but from reading the logs it appears they are conflicting over a row lock. This particular table gets very frequent inserts/updates (10-100 inserts / sec) so 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 are using postgres 9.6.10.
Thanks,
Mike
________________________________
This email is non-binding, is subject to contract, and neither Kulicke and Soffa Industries, Inc. nor its subsidiaries (each and collectively "K&S") shall have any obligation to you to consummate the transactions herein or to enter into any agreement, other than in accordance with the terms and conditions of a definitive agreement if and when negotiated, finalized and executed between the parties. This email and all its contents are protected by International and United States copyright laws. Any reproduction or use of all or any part of this email without the express written consent of K&S is prohibited.
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: autovacuum locking question
@ 2019-12-05 22:49 Michael Lewis <mlewis@entrata.com>
parent: Mike Schanne <mschanne@kns.com>
2 siblings, 1 reply; 13+ messages in thread
From: Michael Lewis @ 2019-12-05 22:49 UTC (permalink / raw)
To: Mike Schanne <mschanne@kns.com>; +Cc: pgsql-performance
On Thu, Dec 5, 2019 at 3:26 PM Mike Schanne <mschanne@kns.com> 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 are using postgres 9.6.10.
>
Have you checked when the table was last autovacuumed in
pg_stat_user_tables? If the autovacuum count is high and timestamp of last
run is relatively current, then no reason for concern as far as I can
figure.
Have you already configured (non-default values) for autovacuum options for
your system or this table?
^ permalink raw reply [nested|flat] 13+ messages in thread
* RE: autovacuum locking question
@ 2019-12-05 23:18 Mike Schanne <mschanne@kns.com>
parent: Michael Lewis <mlewis@entrata.com>
0 siblings, 0 replies; 13+ messages in thread
From: Mike Schanne @ 2019-12-05 23:18 UTC (permalink / raw)
To: Michael Lewis <mlewis@entrata.com>; +Cc: pgsql-performance
In this particular case autovacuum_count is 0. n_live_tup is 659,631 and n_dead_tup is 3,400,347.
We are using the default vacuum parameters.
From: Michael Lewis [mailto:mlewis@entrata.com]
Sent: Thursday, December 05, 2019 5:49 PM
To: Mike Schanne
Cc: pgsql-performance@postgresql.org
Subject: Re: autovacuum locking question
On Thu, Dec 5, 2019 at 3:26 PM Mike Schanne <mschanne@kns.com<mailto:mschanne@kns.com>> 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 are using postgres 9.6.10.
Have you checked when the table was last autovacuumed in pg_stat_user_tables? If the autovacuum count is high and timestamp of last run is relatively current, then no reason for concern as far as I can figure.
Have you already configured (non-default values) for autovacuum options for your system or this table?
________________________________
This email is non-binding, is subject to contract, and neither Kulicke and Soffa Industries, Inc. nor its subsidiaries (each and collectively “K&S”) shall have any obligation to you to consummate the transactions herein or to enter into any agreement, other than in accordance with the terms and conditions of a definitive agreement if and when negotiated, finalized and executed between the parties. This email and all its contents are protected by International and United States copyright laws. Any reproduction or use of all or any part of this email without the express written consent of K&S is prohibited.
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: autovacuum locking question
@ 2019-12-05 23:49 Tom Lane <tgl@sss.pgh.pa.us>
parent: Mike Schanne <mschanne@kns.com>
2 siblings, 2 replies; 13+ messages in thread
From: Tom Lane @ 2019-12-05 23:49 UTC (permalink / raw)
To: Mike Schanne <mschanne@kns.com>; +Cc: pgsql-performance
Mike Schanne <mschanne@kns.com> 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 13:39:28 UTC,12/1884256,12615023,LOG,00000,"process 6966 still waiting for RowExclusiveLock on relation 32938 of database 32768 after 1000.085 ms","Process holding the lock: 6045. Wait queue: 6966.",,,,,"INSERT INTO myschema.mytable (...) VALUES (...) RETURNING process.mytable.mytable_id",13,,""
> 2019-12-01 13:05:39.458 UTC,,,6045,,5de3b800.179d,1,,2019-12-01 12:54:24 UTC,10/417900,0,ERROR,57014,"canceling autovacuum task",,,,,"automatic vacuum of table ""postgres.myschema.mytable""",,,,""
> My understanding from reading the documentation was that a vacuum can run concurrently with table inserts/updates, but from reading the logs it appears they are conflicting over a row lock. This particular table gets very frequent inserts/updates (10-100 inserts / sec) so 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?
The main part of an autovacuum operation should go through OK. 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. Normally,
skipping that step isn't terribly problematic.
> We are using postgres 9.6.10.
IIRC, we've made improvements in this area since 9.6, to allow a
partial truncation to be done if someone wants the lock, rather
than just failing entirely.
regards, tom lane
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: autovacuum locking question
@ 2019-12-05 23:55 Jeff Janes <jeff.janes@gmail.com>
parent: Mike Schanne <mschanne@kns.com>
2 siblings, 1 reply; 13+ messages in thread
From: Jeff Janes @ 2019-12-05 23:55 UTC (permalink / raw)
To: Mike Schanne <mschanne@kns.com>; +Cc: pgsql-performance
On Thu, Dec 5, 2019 at 5:26 PM Mike Schanne <mschanne@kns.com> 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 UTC,"wb","postgres",6966,"127.0.0.1:53976",5ddbd990.1b36,17099,"INSERT
> waiting",2019-11-25 13:39:28 UTC,12/1884256,12615023,LOG,00000,"process
> 6966 still waiting for RowExclusiveLock on relation 32938 of database 32768
> after 1000.085 ms","Process holding the lock: 6045. Wait queue:
> 6966.",,,,,"INSERT INTO myschema.mytable (...) VALUES (...) RETURNING
> process.mytable.mytable_id",13,,""
>
> 2019-12-01 13:05:39.458 UTC,,,6045,,5de3b800.179d,1,,2019-12-01 12:54:24
> UTC,10/417900,0,ERROR,57014,"canceling autovacuum task",,,,,"automatic
> vacuum of table ""postgres.myschema.mytable""",,,,""
>
>
>
> My understanding from reading the documentation was that a vacuum can run
> concurrently with table inserts/updates, but from reading the logs it
> appears they are conflicting over a row lock. This particular table gets
> very frequent inserts/updates (10-100 inserts / sec) so 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 are using postgres 9.6.10.
>
If the vacuum finds a lot of empty pages at the end of the table, it will
try to truncate them and takes a strong lock to do so. It is supposed to
check every 20ms to see if anyone else is blocked on that lock, at which
point it stops doing the truncation and releases the lock. So it should
never get "caught" holding the lock in order to be cancelled. Is your
setting for deadlock_timeout much lower than usual? Also, if the
truncation is bogged down in very slow IO, perhaps it doesn't actually get
around to checking ever 20ms despite its intentionsl
How often have you seen it in the logs?
Cheers,
Jeff
>
^ permalink raw reply [nested|flat] 13+ messages in thread
* RE: autovacuum locking question
@ 2019-12-06 15:46 Mike Schanne <mschanne@kns.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 13+ messages in thread
From: Mike Schanne @ 2019-12-06 15:46 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-performance
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.
https://www.postgresql.org/docs/release/9.6.16/
Thanks,
Mike
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Thursday, December 05, 2019 6:49 PM
To: Mike Schanne
Cc: 'pgsql-performance@postgresql.org'
Subject: Re: autovacuum locking question
Mike Schanne <mschanne@kns.com> 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 13:39:28 UTC,12/1884256,12615023,LOG,00000,"process 6966 still waiting for RowExclusiveLock on relation 32938 of database 32768 after 1000.085 ms","Process holding the lock: 6045. Wait queue: 6966.",,,,,"INSERT INTO myschema.mytable (...) VALUES (...) RETURNING process.mytable.mytable_id",13,,""
> 2019-12-01 13:05:39.458 UTC,,,6045,,5de3b800.179d,1,,2019-12-01 12:54:24 UTC,10/417900,0,ERROR,57014,"canceling autovacuum task",,,,,"automatic vacuum of table ""postgres.myschema.mytable""",,,,""
> My understanding from reading the documentation was that a vacuum can run concurrently with table inserts/updates, but from reading the logs it appears they are conflicting over a row lock. This particular table gets very frequent inserts/updates (10-100 inserts / sec) so 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?
The main part of an autovacuum operation should go through OK. 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. Normally, skipping that step isn't terribly problematic.
> We are using postgres 9.6.10.
IIRC, we've made improvements in this area since 9.6, to allow a partial truncation to be done if someone wants the lock, rather than just failing entirely.
regards, tom lane
________________________________
This email is non-binding, is subject to contract, and neither Kulicke and Soffa Industries, Inc. nor its subsidiaries (each and collectively “K&S”) shall have any obligation to you to consummate the transactions herein or to enter into any agreement, other than in accordance with the terms and conditions of a definitive agreement if and when negotiated, finalized and executed between the parties. This email and all its contents are protected by International and United States copyright laws. Any reproduction or use of all or any part of this email without the express written consent of K&S is prohibited.
^ permalink raw reply [nested|flat] 13+ messages in thread
* RE: autovacuum locking question
@ 2019-12-06 15:55 Mike Schanne <mschanne@kns.com>
parent: Jeff Janes <jeff.janes@gmail.com>
0 siblings, 2 replies; 13+ messages in thread
From: Mike Schanne @ 2019-12-06 15:55 UTC (permalink / raw)
To: Jeff Janes <jeff.janes@gmail.com>; +Cc: pgsql-performance
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 symptom rather than the cause.
From: Jeff Janes [mailto:jeff.janes@gmail.com]
Sent: Thursday, December 05, 2019 6:55 PM
To: Mike Schanne
Cc: pgsql-performance@postgresql.org
Subject: Re: autovacuum locking question
On Thu, Dec 5, 2019 at 5:26 PM Mike Schanne <mschanne@kns.com<mailto:mschanne@kns.com>> 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 UTC,"wb","postgres",6966,"127.0.0.1:53976<http://127.0.0.1:53976>",5ddbd990.1b36,17099,"INSERT waiting",2019-11-25 13:39:28 UTC,12/1884256,12615023,LOG,00000,"process 6966 still waiting for RowExclusiveLock on relation 32938 of database 32768 after 1000.085 ms","Process holding the lock: 6045. Wait queue: 6966.",,,,,"INSERT INTO myschema.mytable (...) VALUES (...) RETURNING process.mytable.mytable_id",13,,""
2019-12-01 13:05:39.458 UTC,,,6045,,5de3b800.179d,1,,2019-12-01 12:54:24 UTC,10/417900,0,ERROR,57014,"canceling autovacuum task",,,,,"automatic vacuum of table ""postgres.myschema.mytable""",,,,""
My understanding from reading the documentation was that a vacuum can run concurrently with table inserts/updates, but from reading the logs it appears they are conflicting over a row lock. This particular table gets very frequent inserts/updates (10-100 inserts / sec) so 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 are using postgres 9.6.10.
If the vacuum finds a lot of empty pages at the end of the table, it will try to truncate them and takes a strong lock to do so. It is supposed to check every 20ms to see if anyone else is blocked on that lock, at which point it stops doing the truncation and releases the lock. So it should never get "caught" holding the lock in order to be cancelled. Is your setting for deadlock_timeout much lower than usual? Also, if the truncation is bogged down in very slow IO, perhaps it doesn't actually get around to checking ever 20ms despite its intentionsl
How often have you seen it in the logs?
Cheers,
Jeff
________________________________
This email is non-binding, is subject to contract, and neither Kulicke and Soffa Industries, Inc. nor its subsidiaries (each and collectively “K&S”) shall have any obligation to you to consummate the transactions herein or to enter into any agreement, other than in accordance with the terms and conditions of a definitive agreement if and when negotiated, finalized and executed between the parties. This email and all its contents are protected by International and United States copyright laws. Any reproduction or use of all or any part of this email without the express written consent of K&S is prohibited.
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: autovacuum locking question
@ 2019-12-06 17:12 Tom Lane <tgl@sss.pgh.pa.us>
parent: Mike Schanne <mschanne@kns.com>
0 siblings, 0 replies; 13+ messages in thread
From: Tom Lane @ 2019-12-06 17:12 UTC (permalink / raw)
To: Mike Schanne <mschanne@kns.com>; +Cc: pgsql-performance
Mike Schanne <mschanne@kns.com> 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.
> https://www.postgresql.org/docs/release/9.6.16/
Hmmm ... after digging through the commit log, it seems the improvements
I was thinking of were all pre-9.6. The only post-9.6 vacuum truncation
performance fix I can find is
https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=7e26e02ee
which came in in v10.
regards, tom lane
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: autovacuum locking question
@ 2019-12-06 17:19 Tom Lane <tgl@sss.pgh.pa.us>
parent: Mike Schanne <mschanne@kns.com>
1 sibling, 0 replies; 13+ messages in thread
From: Tom Lane @ 2019-12-06 17:19 UTC (permalink / raw)
To: Mike Schanne <mschanne@kns.com>; +Cc: 'Jeff Janes' <jeff.janes@gmail.com>; pgsql-performance
Mike Schanne <mschanne@kns.com> 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 symptom rather than the cause.
Well, it's also an inherently non-repeating problem: once some iteration
of autovacuum has managed to truncate away the large amount of trailing
dead space that the file presumably had, later runs won't need to do
that.
Of course, if you have a usage pattern that repeatedly bloats the table
with lots of stuff-to-be-vacuumed, the issue could recur that way.
regards, tom lane
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: autovacuum locking question
@ 2019-12-06 17:47 Jeff Janes <jeff.janes@gmail.com>
parent: Mike Schanne <mschanne@kns.com>
1 sibling, 1 reply; 13+ messages in thread
From: Jeff Janes @ 2019-12-06 17:47 UTC (permalink / raw)
To: Mike Schanne <mschanne@kns.com>; +Cc: pgsql-performance
On Fri, Dec 6, 2019 at 10:55 AM Mike Schanne <mschanne@kns.com> 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), so this error may be a symptom rather than the cause.
>
I think that at the point it is getting cancelled, it has done all the work
except the truncation of the empty pages, and reporting the results (for
example, updating n_live_tup and n_dead_tup). If this happens
every single time (neither last_autovacuum nor last_vacuum ever advances)
it will eventually cause problems. So this is mostly a symptom, but not
entirely. Simply running a manual vacuum should fix the reporting
problem. It is not subject to cancelling, so it will detect it is blocking
someone and gracefully bow. Meaning it will suspend the truncation, but
will still report its results as normal.
Reading the table backwards in order to truncate it might be contributing
to the IO problems as well as being a victim of those problems. Upgrading
to v10 might help with this, as it implemented a prefetch where it reads
the table forward in 128kB chunks, and then jumps backwards one chunk at a
time. Rather than just reading backwards 8kB at a time.
Cheers,
Jeff
>
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: autovacuum locking question
@ 2019-12-06 17:49 Justin Pryzby <pryzby@telsasoft.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 13+ messages in thread
From: Justin Pryzby @ 2019-12-06 17:49 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Jeff Janes <jeff.janes@gmail.com>; +Cc: Mike Schanne <mschanne@kns.com>; pgsql-performance
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 06:55:02PM -0500, Jeff Janes wrote:
> If the vacuum finds a lot of empty pages at the end of the table, it will
> try to truncate them and takes a strong lock to do so.
Should the exclusive lock bit be documented ?
https://www.postgresql.org/docs/12/explicit-locking.html
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: autovacuum locking question
@ 2019-12-06 17:50 MichaelDBA <MichaelDBA@sqlexec.com>
parent: Jeff Janes <jeff.janes@gmail.com>
0 siblings, 1 reply; 13+ messages in thread
From: MichaelDBA @ 2019-12-06 17:50 UTC (permalink / raw)
To: Jeff Janes <jeff.janes@gmail.com>; +Cc: Mike Schanne <mschanne@kns.com>; pgsql-performance
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 10:55 AM Mike Schanne <mschanne@kns.com
> <mailto:mschanne@kns.com>> 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), so this error
> may be a symptom rather than the cause.
>
>
> I think that at the point it is getting cancelled, it has done all the
> work except the truncation of the empty pages, and reporting the
> results (for example, updating n_live_tup and n_dead_tup). If this
> happens every single time (neither last_autovacuum nor last_vacuum
> ever advances) it will eventually cause problems. So this is mostly a
> symptom, but not entirely. Simply running a manual vacuum should fix
> the reporting problem. It is not subject to cancelling, so it will
> detect it is blocking someone and gracefully bow. Meaning it will
> suspend the truncation, but will still report its results as normal.
> Reading the table backwards in order to truncate it might be
> contributing to the IO problems as well as being a victim of those
> problems. Upgrading to v10 might help with this, as it implemented a
> prefetch where it reads the table forward in 128kB chunks, and then
> jumps backwards one chunk at a time. Rather than just reading
> backwards 8kB at a time.
>
> Cheers,
>
> Jeff
>
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: autovacuum locking question
@ 2019-12-07 00:59 Jeff Janes <jeff.janes@gmail.com>
parent: MichaelDBA <MichaelDBA@sqlexec.com>
0 siblings, 0 replies; 13+ messages in thread
From: Jeff Janes @ 2019-12-07 00:59 UTC (permalink / raw)
To: MichaelDBA <MichaelDBA@sqlexec.com>; +Cc: Mike Schanne <mschanne@kns.com>; pgsql-performance
On Fri, Dec 6, 2019 at 12:50 PM MichaelDBA <MichaelDBA@sqlexec.com> 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 situations and not in others. I don't know that
it is useful to categorize them into a monotonic priority scale.
Autovacs "to prevent wraparound" don't get cancelled the way ordinary
autovacs do, but they still use autovac IO throttling settings, not the
unthrottled (by default settings) manual vacuum settings, which can be a
major problem sometimes.
Note that no kind of vacuum should normally get cancelled using the
signalling mechanism during truncation phase, that seems to be due to some
rather extreme situation with IO congestion.
Cheers,
Jeff
^ permalink raw reply [nested|flat] 13+ messages in thread
end of thread, other threads:[~2019-12-07 00:59 UTC | newest]
Thread overview: 13+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2019-12-05 17:46 autovacuum locking question Mike Schanne <mschanne@kns.com>
2019-12-05 22:49 ` Michael Lewis <mlewis@entrata.com>
2019-12-05 23:18 ` Mike Schanne <mschanne@kns.com>
2019-12-05 23:49 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-12-06 15:46 ` Mike Schanne <mschanne@kns.com>
2019-12-06 17:12 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-12-06 17:49 ` Justin Pryzby <pryzby@telsasoft.com>
2019-12-05 23:55 ` Jeff Janes <jeff.janes@gmail.com>
2019-12-06 15:55 ` Mike Schanne <mschanne@kns.com>
2019-12-06 17:19 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-12-06 17:47 ` Jeff Janes <jeff.janes@gmail.com>
2019-12-06 17:50 ` MichaelDBA <MichaelDBA@sqlexec.com>
2019-12-07 00:59 ` Jeff Janes <jeff.janes@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox