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-12 19:25:34 |
Message-ID: | alpine.DEB.2.10.1511122018350.20444@sto |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>> Basically yes, I'm suggesting a mutex in the vdf struct.
>>
>> I can't see that being ok. I mean what would that thing even do? VFD
>> isn't shared between processes, and if we get a smgr flush we have to
>> apply it, or risk breaking other things.
>
> Probably something is eluding my comprehension:-)
>
> My basic assumption is that the fopen & fd is per process, so we just have to
> deal with the one in the checkpointer process, so it is enough that the
> checkpointer does not close the file while it is flushing things to it?
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.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Verite | 2015-11-12 19:38:49 | Re: psql: add \pset true/false |
Previous Message | Thomas Munro | 2015-11-12 19:11:08 | Re: Proposal: "Causal reads" mode for load balancing reads without stale data |