Slony1 PostgreSQL Replication - Log shipping fails when the disk is full

Author

Log shipping fails when the disk is full

Jacek Konieczny

2005-08-01, 7:26 am

I have been experimenting with Slony-I (1.1.0) log shipping features.
That would work for me, but there is one, big problem: when my
filesystem is full slon daemon writes empty log files instead of
stopping until normal logging may continue. I thought it is not supposed
to work this way, so I looked into the sources and found out, that most
of log write errors are ignored, so one the logs are not reliable. Is is
really supposed to be that way?

Greets,
Jacek

cbbrowne-swQf4SbcV9C7WVzo/KQ3Mw@public.gmane.org

2005-08-01, 9:25 am

> I have been experimenting with Slony-I (1.1.0) log shipping features.
> That would work for me, but there is one, big problem: when my
> filesystem is full slon daemon writes empty log files instead of
> stopping until normal logging may continue. I thought it is not suppose=
d
> to work this way, so I looked into the sources and found out, that most
> of log write errors are ignored, so one the logs are not reliable. Is i=
s
> really supposed to be that way?

It is certainly supposed to fail when disk errors occur so that you don't
have empty logs.

If you can point out locations of insufficient error checking, that would
be helpful.

I have tried it out with a full disk and found it stopping; it sounds ver=
y
rather peculiar that that wouldn't happen for you.

In particular, every time a query is written out (e.g. -
INSERT/UPDATE/DELETE), the return codes are checked, and things roll back
if the writes do not succeed.

There is the possibility that maybe your platform is providing unexpected
return codes; can you detail operating system version, please?

Christopher Browne

2005-08-08, 11:25 am

cbbrowne-swQf4SbcV9C7WVzo/KQ3Mw@public.gmane.org wrote:

>
>It is certainly supposed to fail when disk errors occur so that you don't
>have empty logs.
>
>If you can point out locations of insufficient error checking, that would
>be helpful.
>
>I have tried it out with a full disk and found it stopping; it sounds very
>rather peculiar that that wouldn't happen for you.
>
>In particular, every time a query is written out (e.g. -
>INSERT/UPDATE/DELETE), the return codes are checked, and things roll back
>if the writes do not succeed.
>
>There is the possibility that maybe your platform is providing unexpected
>return codes; can you detail operating system version, please?
>
>
As followup to this, there were a number of places where return codes
were not being checked in detail.

I have modified function write_void_log() to incessantly check the
return codes that it receives, and to then pass them upstream if it runs
into problems.

Correspondingly, I have modified the places in the event loop where
write_void_log() is used to (again) incessantly check the return codes
passed back, and to slon_abort() if it discovers a problem.

This ought to be helpful...

I have only checked these changes into HEAD, not into 1.1_STABLE; it
might be a good idea to add this into 1.1_STABLE...

Sponsored Links