Re: [HACKERS] [QUESTIONS] lo_write cannot > 640Kb? memory leaks? - Mailing list pgsql-hackers

From Chul Su Park
Subject Re: [HACKERS] [QUESTIONS] lo_write cannot > 640Kb? memory leaks?
Date
Msg-id 199805212047.FAA27332@bwg02.kek.jp
Whole thread Raw
In response to Re: [HACKERS] [QUESTIONS] lo_write cannot > 640Kb? memory leaks?  (dg@illustra.com (David Gould))
Responses Re: [HACKERS] [QUESTIONS] lo_write cannot > 640Kb? memory leaks?  (dg@illustra.com (David Gould))
List pgsql-hackers
Hi,

> Have you tried increasing the number of postgres buffer cache buffers? I am
> speculating that the lo_write() is using these buffers but perhaps not
> flushing them. As the default configuration has way too few buffers anyway
> this might be the problem. Could you try increasing the buffers to say 1024 or
> so and rerun your test and post the results?
>
> -dg

    Thanks for your reply, but as I posted I tested many different size of
buffers in lotest.c, e.g. 1Kb, 4Kb, 8Kb, 9Kb, 10Kb, 16Kb, 32Kb, 64Kb, 640Kb,
1Mb, 10Mb, ...  or your "cache" or "buffer" size have some diffferent meaning?

but lo_write cannot exceed 640kb always, only open/write(less than
640kb)/close looping OR open LOOP lo_write(buffer<640Kb)) , lo_lseek to
SEEK_END, write, ... seems to solve this problem(as in my last email),  and I
found that 16Kb buffer seems to be the optimal buffer size for the SPEED(not
8Kb) for network & socket connections why?...

and I think that above lo_lseek write loop is not a real solution, because
lo_read seems does not have such defects(but 16kb buffer seems to be the
optimal size also), there must be some problems in lo_write or buffer
managing...  does anybody have some guess or fixes?

c.s.park



pgsql-hackers by date:

Previous
From: dg@illustra.com (David Gould)
Date:
Subject: Re: [HACKERS] [QUESTIONS] lo_write cannot > 640Kb? memory leaks?
Next
From: dg@illustra.com (David Gould)
Date:
Subject: Re: [HACKERS] [QUESTIONS] lo_write cannot > 640Kb? memory leaks?