On 3/5/21 6:57 PM, Tom Lane wrote:
Not sure how fast that is either. If you need to do it again, you could
try manually rm'ing everything under the pgsql_tmp directory before
letting the postmaster start.
That is actually a strategy that works rather well. mv(1) the tmp
directory to something
Jerry Sievers writes:
> Tom Lane writes:
>> The "unkillable" aspect is odd, but I wonder if that's just a red
>> herring. A query that's generated lots of temp files will try to
>> clean them up at termination, so maybe the backend is just sitting
>> there removing temp files before it'll give c
Hi Tom, thx for the quick response and a few remarks below...
I work at the same site that Jeremy does and we're both looking at this
today.
Tom Lane writes:
> Jeremy Finzel writes:
>
>> We are running postgres 11.9 (were running 11.7 prior to recent restart) on
>> a large db (10s of TB) with
Jeremy Finzel writes:
> We are running postgres 11.9 (were running 11.7 prior to recent restart) on
> a large db (10s of TB) with 5 or 6 tablespaces and 1000s of tables/indexes.
> Within the past few days we have started to see a few queries running for
> over 8 hours which we then attempt to ter
Greetings!
We are running postgres 11.9 (were running 11.7 prior to recent restart) on
a large db (10s of TB) with 5 or 6 tablespaces and 1000s of tables/indexes.
Within the past few days we have started to see a few queries running for
over 8 hours which we then attempt to terminate, but will no