Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Full page writes improvement, code update

From: Koichi Suzuki <suzuki(dot)koichi(at)oss(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Zeugswetter Andreas ADI SD <ZeugswetterA(at)spardat(dot)at>, Hannu Krosing <hannu(at)skype(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Full page writes improvement, code update
Date: 2007-04-20 09:19:40
Message-ID: 462885AC.6080407@oss.ntt.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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.

Regards;

Tom Lane wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)com> 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

In response to

pgsql-hackers by date

Next:From: Marcin WaldowskiDate: 2007-04-20 10:59:51
Subject: Re: BUG #3242: FATAL: could not unlock semaphore: error code 298
Previous:From: Koichi SuzukiDate: 2007-04-20 09:13:52
Subject: Re: [HACKERS] Full page writes improvement, code update

pgsql-patches by date

Next:From: Simon RiggsDate: 2007-04-20 12:56:09
Subject: Re: [HACKERS] Full page writes improvement, code update
Previous:From: Koichi SuzukiDate: 2007-04-20 09:13:52
Subject: Re: [HACKERS] Full page writes improvement, code update

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group