On Mon, Aug 01, 2005 at 10:55:50AM -0400, cbbrowne at ca.afilias.info wrote:
> It is certainly supposed to fail when disk errors occur so that you don't
> have empty logs.

I am sorry for the confusion. The failure I was talking about is
creation of empty logs. That is why I wrote the log shipping is not
reliable. Instead of stopping replication it writes empty log files
until no more inodes are available on the filesystem.
 
> If you can point out locations of insufficient error checking, that would
> be helpful.

> 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.

It seems I looked at wrong part of the code, like this (this is part of
MERGE_SET handling):

	if (archive_dir) {
	    rc = open_log_archive(rtcfg_nodeid, seqbuf);
	    rc = generate_archive_header(rtcfg_nodeid, seqbuf);
	    slon_mkquery(&query1,
			 "delete from %s.sl_setsync_offline "
			 "  where ssy_setid= %d;",
			 rtcfg_namespace, set_id);
	    rc = submit_query_to_archive(&query1);
	    rc = close_log_archive();
	}

As you see "rc" is overwritten here, which lights a big red alert light for me.
But now I see, that SYNC events are processed elsewhere and the most important
result codes are checked properly.

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

PLD Linux, kernel 2.6.11.10, glibc 2.3.4, XFS filesystem.

It seems like fprintf() used to write logs must have returned value >= 0 in my
case. Strange. I will try to investigate that further.

The log entries causing problems where empty SYNC events (only the tracking
information), maybe that matters.

Greets,
	Jacek