From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: checkpointer continuous flushing |
Date: | 2015-11-16 09:08:39 |
Message-ID: | alpine.DEB.2.10.1511161001010.7981@angers |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Marti Raudsepp | 2015-11-16 09:27:52 | Re: [PATCH] Skip ALTER x SET SCHEMA if the schema didn't change |
Previous Message | Kyotaro HORIGUCHI | 2015-11-16 09:05:37 | Conversion error of floating point numbers in pl/pgsql |