Re: problem with large maintenance_work_mem settings and

Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> 
>>LOG:  begin index sort: unique = f, workMem = 8024000, randomAccess = f
>>LOG:  switching to external sort with 28658 tapes: CPU 4.18s/13.96u sec 
>>elapsed 32.43 sec
>>LOG:  finished writing run 1 to tape 0: CPU 173.56s/3425.85u sec elapsed 
>>3814.82 sec
>>LOG:  performsort starting: CPU 344.17s/7013.20u sec elapsed 7715.45 sec
>>LOG:  finished writing final run 2 to tape 1: CPU 347.19s/7121.78u sec 
>>elapsed 7827.25 sec
>>LOG:  performsort done (except 2-way final merge): CPU 348.25s/7132.99u 
>>sec elapsed 7846.47 sec
> 
> 
>>after that the postmaster is now consuming 99% CPU for about 22 hours(!) 
> 
> 
> I'll look into it, but I was already wondering if we shouldn't bound the
> number of tapes somehow.  It's a bit hard to believe that 28000 tapes is
> a sane setting.


heh - don't think it is a sane setting either (and it doesn't look like
that pg is using more than 2GB anyway).

If this testing helps with defining appropriate upper bounds to prevent
bad behaviour like this (not responding to signals any more and eating
CPU like mad) I'm more than happy.
And the ltsReleaseBlock-fix already reduced dump&restore times for one
of our production databases by at about 15% which is already quite an
impressive improvment on its own ;-)


Stefan