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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
