Re: log chunking broken with large queries under load - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: log chunking broken with large queries under load
Date
Msg-id 4F7C7BC8.8010601@dunslane.net
Whole thread Raw
In response to Re: log chunking broken with large queries under load  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: log chunking broken with large queries under load  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 04/04/2012 12:13 PM, Tom Lane wrote:
> Andrew Dunstan<andrew@dunslane.net>  writes:
>> On 04/02/2012 01:03 PM, Tom Lane wrote:
>>> When I said "list", I meant a "List *".  No fixed size.
>> Ok, like this?
> I think this could use a bit of editorialization (I don't think the
> "stripe" terminology is still applicable, in particular), but the
> general idea seems OK.
>
> Does anyone feel that it's a bad idea that list entries are never
> reclaimed?  In the worst case a transient load peak could result in
> a long list that permanently adds search overhead.  Not sure if it's
> worth the extra complexity to delete a list cell that's no longer
> needed, rather than leaving it present and empty.

Me either. The logic could possibly be something simple when we free a 
node like "while the list tail is an available node prune the tail". But 
as you say, it might not be worth it.

>
>> Do we consider this a bug fix, to be backpatched?
> Yes, definitely.
>
> I think I'd like to have a go at coding it the other way (with
> release of list entries), just to see if that comes out cleaner
> or uglier than this way.  If you don't mind I'll pick this up
> and commit whichever way turns out better.
>
>             


Go for it.

cheers

andrew



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: invalid search_path complaints
Next
From: Greg Stark
Date:
Subject: Re: patch: improve SLRU replacement algorithm