Here's only a part of the reply I should do, but as to I/O error
checking ...

Here's a list of system calls and other external function/library calls
used in pg_lesslog patch series, together with how current patch checks
each errors and how current postgresql source handles the similar calls:

1. No error check is done
1-1. fileno()
     fileno() is called against stdin and stdout from pg_compresslog.c
and pg_decompresslog.c.  They are intended to be invoked from a shell
and so stdin and stdout are both available.  fileno() error occurs only
if invoker of pg_compresslog or pg_decompresslog closes stdin and/or
stdout before the invoker executes them.   I found similar fileno()
usage in pg_dump/pg_backup_archive.c and postmaster/syslogger.c.   I
don't think this is an issue.

1-2. fflush()
        fflush() is called against stdout within a debug routine, debug.c.
Such usage can also be found in bin/initdb.c, bin/scripts/createdb.c,
bin/psql/common.c and more.   I don't think this is an issue either.

1-3. printf() and fprintf()
     It is common practice not to check the error.   We can find such
calls in many of existing source codes.

1-4. strerror()
     It is checked that system call returns error before calling
strerror.   Similar code can be found in other PostgreSQL source too.

2. Error check is done
All the following function calls are associated with return value check.
open(), close(), fstat(), read(), write()

3. Functions do not return error
The following functin will not return errors, so no error check is needed.
exit(), memcopy(), memset(), strcmp()

I hope this helps.


Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>> Writing lots of additional code simply to remove a parameter that
>> *might* be mis-interpreted doesn't sound useful to me, especially when
>> bugs may leak in that way. My take is that this is simple and useful
>> *and* we have it now; other ways don't yet exist, nor will they in time
>> for 8.3.
> The potential for misusing the switch is only one small part of the
> argument; the larger part is that this has been done in the wrong way
> and will cost performance unnecessarily.  The fact that it's ready
> now is not something that I think should drive our choices.
> I believe that it would be possible to make the needed core-server
> changes in time for 8.3, and then to work on compress/decompress
> on its own time scale and publish it on pgfoundry; with the hope
> that it would be merged to contrib or core in 8.4.  Frankly the
> compress/decompress code needs work anyway before it could be
> merged (eg, I noted a distinct lack of I/O error checking).
>                       regards, tom lane

Koichi Suzuki

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to