On 11/10/11 12:48, John R Pierce wrote:
> On 10/10/11 7:44 PM, Craig Ringer wrote:
>> If blocking writes causes a server failure that persists once writes
>> have been unblocked, that's a bug IMO. You might have a bit of a backlog
>> of writes to clear, but after that all should be well, and if it isn't
>> then something needs fixing.
>
> the process is blocked waiting for this disk write to complete,
> meanwhile, the packets are queuing up and waiting for service.
>
> best of luck with all that....
xfs_freeze for long enough to take a snapshot doesn't take long, or it
shouldn't, anyway. Even if it did, that shouldn't cause a server failure
that persists past when disk I/O is resumed, though it might cause
individual connections to drop.
I can `kill -STOP' Pg, or unplug my network cable for several seconds
and expect everything to resume just fine when I `kill -CONT' or plug
back in. Packets will be buffered by the OS if Pg is busy or by the
closest router if the network is unplugged, and will be delivered when
it becomes responsive again. If that takes too long or if too many
packets arrive, packets will be dropped, in which case TCP/IP will
re-send them. If the outage is protracted enough the client might
eventually decide the peer has gone away and drop the connection, but
even then new connections should be established to the server just fine
once it resumes responding.
It is totally unreasonable for Pg to *stay* nonfunctional once disk I/O
resumes. Existing connections should receive responses they're waiting
on or die, depending on how long it's been, and new connections should
be accepted fine.
--
Craig Ringer
