Re: checkpointer continuous flushing - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: checkpointer continuous flushing
Date
Msg-id alpine.DEB.2.10.1511161001010.7981@angers
Whole thread Raw
In response to Re: checkpointer continuous flushing  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: checkpointer continuous flushing  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
> Hmmm...
>
> Maybe I'm a little bit too optimistic here, because it seems that I'm 
> suggesting to create a dead lock if the checkpointer has both buffers to 
> flush in waiting and wishes to close the very same file that holds them.
>
> So on wanting to close the file the checkpointer should rather flushes the 
> outstanding flushes in wait and then close the fd, which suggest some global 
> variable to hold flush context so that this can be done.
>
> Hmmm.

On third (fourth, fifth:-) thoughts:

The vfd (virtual file descriptor?) structure in the checkpointer could 
keep a pointer to the current flush if it concerns this fd, so that if it 
decides to close if while there is a write in progress (I'm still baffled 
at why and when the checkpointer process would take such a decision, maybe 
while responding to some signals, because it seems that there is no such 
event in the checkpointer loop itself...) then on close the process could 
flush before close, or just close which probably would induce flushing, 
but at least cleanup the structure so that the the closed fd would not be 
flushed after being closed and result in an error.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Conversion error of floating point numbers in pl/pgsql
Next
From: Marti Raudsepp
Date:
Subject: Re: [PATCH] Skip ALTER x SET SCHEMA if the schema didn't change