Re: Change BgWriterCommLock to spinlock - Mailing list pgsql-patches

From Qingqing Zhou
Subject Re: Change BgWriterCommLock to spinlock
Date
Msg-id Pine.LNX.4.58.0601081945110.4796@eon.cs
Whole thread Raw
In response to Re: Change BgWriterCommLock to spinlock  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Change BgWriterCommLock to spinlock
List pgsql-patches

On Sun, 8 Jan 2006, Tom Lane wrote:
>
> If you want the bgwriter to keep working in the face of an out-of-memory
> condition in the hashtable, I think you'd have to change the coding so
> that it takes requests one at a time from the queue.
>
Patched version will issue ERROR instead of PANIC at this condition, so
the bgwriter can still keep running. I don't quite understand what do you
mean by "want the bgwriter keep working" -- do you mean by not issuing an
ERROR but do retry? An ERROR is not avoidable unless we change the
out-of-memory handling logic inside hashtable.

>
> Another issue to keep in mind is that correct operation requires that
> the bgwriter not declare a checkpoint complete until it's completed
> every fsync request that was queued before the checkpoint started.
> So if the bgwriter is to try to keep going after failing to absorb
> all the pending requests, there would have to be some logic addition
> to keep track of whether it's OK to complete a checkpoint or not.
>
As above, if bgwriter fails to absorb, it will quite the job (and
checkpoint will not be finished).

Do you suggest it makes sense that we continue to work on the patch or let
it be?

Regards,
Qingqing

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Change BgWriterCommLock to spinlock
Next
From: Tom Lane
Date:
Subject: Re: Change BgWriterCommLock to spinlock