Hi,
I'm looking into this patch as a reviewer.
(2013/05/24 10:33), Heikki Linnakangas wrote:
> On 23.05.2013 19:10, Greg Smith wrote:
>> On 5/20/13 7:51 AM, Heikki Linnakangas wrote:
>> It strikes me as kind of weird that the read side and write side are
>> not more symmetrical.
>
> It might seem weird if you expect the API to be similar to POSIX read()
> and write(), where you can read() an arbitrary block at any location,
> and write() an arbitrary block at any location. A better comparison
> would be e.g open() and close(). open() returns a file descriptor, which
> you pass to other functions to operate on the file. When you're done,
> you call close(fd). The file descriptor is completely opaque to the user
> program, you do all the operations through the functions that take the
> fd as argument. Similarly, ReadBuffer() returns a Buffer, which is
> completely opaque to the caller, and you do all the operations through
> various functions and macros that operate on the Buffer. When you're
> done, you release the buffer with ReleaseBuffer().
>
> (sorry for the digression from the original topic, I don't have any
> problem with what adding an optional Relation argument to MarkBuffer if
> you need that :-) )
Or should we add some pointer, which is accociated with the Relation,
into BufferDesc? Maybe OID?
I'm thinking of FlushBuffer() too. How can we count physical write
for each relation in FlushBuffer()? Or any other appropriate place?
BTW, Greg's first patch could not be applied to the latest HEAD.
I guess it need to have some fix, I couldn't clafiry it though.
Regards,
--
Satoshi Nagayasu <snaga@uptime.jp>
Uptime Technologies, LLC. http://www.uptime.jp