> On Sunday, October 07, 2012 1:25 PM Tatsuo Ishii wrote:
> Amit,
>
> > Today when I tried to build the latest code on my windows m/c, I got
> few errors from the checkin of this patch.
> >
> > lo_hton64 (due to -- unint32_t)
> > .\src\interfaces\libpq\fe-lobj.c(1049) : error C2065: 'uint32_t' :
Amit,
> Today when I tried to build the latest code on my windows m/c, I got few
> errors from the checkin of this patch.
>
> lo_hton64 (due to -- unint32_t)
> .\src\interfaces\libpq\fe-lobj.c(1049) : error C2065: 'uint32_t' :
> undeclared identifier
> inv_seek (due to -- MAX_LARGE_OBJECT_SI
>On Sunday, October 07, 2012 5:42 AM Tatsuo Ishii wrote:
>Ok, committed with minor editings(fix header comments in testlo64.c).
>Thank you Kaigai-san for review!
Hello Tatsuo Ishii San,
Today when I tried to build the latest code on my windows m/c, I got few errors
from the checkin of this pat
Ok, committed with minor editings(fix header comments in testlo64.c).
Thank you Kaigai-san for review!
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
> As a committer, I have looked into the patch and it seems it's good to
> comm
As a committer, I have looked into the patch and it seems it's good to
commit. However I want to make a small enhancement in the
documentation part:
1) lo_open section needs to mention about new 64bit APIs. Also it
should include description about lo_truncate, but this is not 64bit
APIs auth
Hi Anzai-san,
The latest patch is fair enough for me, so let me hand over its reviewing
for comitters.
Thanks,
2012/10/1 Nozomi Anzai :
> Here is 64-bit API for large object version 3 patch.
>
>> I checked this patch. It looks good, but here are still some points to be
>> discussed.
>>
>> * I ha
On 9/28/12 10:35 AM, Alvaro Herrera wrote:
> Now there is one more problem in this area which is that the patch
> defined a new type pg_int64 for frontend code (postgres_ext.h). This
> seems a bad idea to me. We already have int64 defined in c.h. Should
> we expose int64 to postgres_ext.h someho
Here is 64-bit API for large object version 3 patch.
> I checked this patch. It looks good, but here are still some points to be
> discussed.
>
> * I have a question. What is the meaning of INT64_IS_BUSTED?
> It seems to me a marker to indicate a platform without 64bit support.
> However, the
2012/9/30 Tatsuo Ishii :
>> * At inv_seek(), it seems to me it checks offset correctness with wrong way,
>> as follows:
>> | case SEEK_SET:
>> | if (offset < 0)
>> | elog(ERROR, "invalid seek offset: " INT64_FORMAT, offset);
>> | obj_desc->offse
Kaiai-san,
Thank you for review.
> I checked this patch. It looks good, but here are still some points to be
> discussed.
>
> * I have a question. What is the meaning of INT64_IS_BUSTED?
> It seems to me a marker to indicate a platform without 64bit support.
> However, the commit 901be0fad40
> Excerpts from Kohei KaiGai's message of jue sep 27 01:01:18 -0300 2012:
>
>> * I have a question. What is the meaning of INT64_IS_BUSTED?
>> It seems to me a marker to indicate a platform without 64bit support.
>> However, the commit 901be0fad4034c9cf8a3588fd6cf2ece82e4b8ce
>> says as foll
Excerpts from Kohei KaiGai's message of jue sep 27 01:01:18 -0300 2012:
> * I have a question. What is the meaning of INT64_IS_BUSTED?
> It seems to me a marker to indicate a platform without 64bit support.
> However, the commit 901be0fad4034c9cf8a3588fd6cf2ece82e4b8ce
> says as follows:
>
I checked this patch. It looks good, but here are still some points to be
discussed.
* I have a question. What is the meaning of INT64_IS_BUSTED?
It seems to me a marker to indicate a platform without 64bit support.
However, the commit 901be0fad4034c9cf8a3588fd6cf2ece82e4b8ce
says as follows
Here is 64-bit API for large object version 2 patch.
> I checked this patch. It can be applied onto the latest master branch
> without any problems. My comments are below.
>
> 2012/9/11 Tatsuo Ishii :
> > Ok, here is the patch to implement 64-bit API for large object, to
> > allow to use up to 4T
> 2012/9/22 Tatsuo Ishii :
>> Tom, Kaigai,
>>
>>> Kohei KaiGai writes:
Tom, could you give us a suggestion which manner is better approach;
whether
the PQfn should have responsibility for endian translation of
64bit-integer, or
callers (lo_tell64 or lo_seek64)?
>>>
>>> A
2012/9/22 Tatsuo Ishii :
> Tom, Kaigai,
>
>> Kohei KaiGai writes:
>>> Tom, could you give us a suggestion which manner is better approach; whether
>>> the PQfn should have responsibility for endian translation of
>>> 64bit-integer, or
>>> callers (lo_tell64 or lo_seek64)?
>>
>> Adding anything in
> Tom, Kaigai,
>
>> Kohei KaiGai writes:
>>> Tom, could you give us a suggestion which manner is better approach; whether
>>> the PQfn should have responsibility for endian translation of
>>> 64bit-integer, or
>>> callers (lo_tell64 or lo_seek64)?
>>
>> Adding anything inside pqFunctionCall is
Tom, Kaigai,
> Kohei KaiGai writes:
>> Tom, could you give us a suggestion which manner is better approach; whether
>> the PQfn should have responsibility for endian translation of 64bit-integer,
>> or
>> callers (lo_tell64 or lo_seek64)?
>
> Adding anything inside pqFunctionCall is useless, un
Kohei KaiGai writes:
> Tom, could you give us a suggestion which manner is better approach; whether
> the PQfn should have responsibility for endian translation of 64bit-integer,
> or
> callers (lo_tell64 or lo_seek64)?
Adding anything inside pqFunctionCall is useless, unless we were to add
an i
2012/9/21 Tatsuo Ishii :
>> Kohei KaiGai writes:
>>> My preference is nothing are changed both pg_getmsgint64() of the backend
>>> and routines under PQfn() of the libpq. Isn't it unavailable to deliver
>>> int64-
>>> value "after" the endian translation on the caller side?
>>
>> Right. If we ha
> Kohei KaiGai writes:
>> My preference is nothing are changed both pg_getmsgint64() of the backend
>> and routines under PQfn() of the libpq. Isn't it unavailable to deliver
>> int64-
>> value "after" the endian translation on the caller side?
>
> Right. If we had to change anything on the bac
Kohei KaiGai writes:
> My preference is nothing are changed both pg_getmsgint64() of the backend
> and routines under PQfn() of the libpq. Isn't it unavailable to deliver int64-
> value "after" the endian translation on the caller side?
Right. If we had to change anything on the backend side, it
> 2012/9/21 Tatsuo Ishii :
>> I thought pgPutInt64() takes care of endianness. No?
>>
> It works inside of the PGfn(), when isint = 1 towards pointer data type.
> In my sense, it is a bit problem specific solution.
>
> So, I'd like to see other person's opinion here.
>>
2012/9/21 Tatsuo Ishii :
> I thought pgPutInt64() takes care of endianness. No?
>
It works inside of the PGfn(), when isint = 1 towards pointer data type.
In my sense, it is a bit problem specific solution.
So, I'd like to see other person's opinion here.
>>>
>>> I think
I thought pgPutInt64() takes care of endianness. No?
>>> It works inside of the PGfn(), when isint = 1 towards pointer data type.
>>> In my sense, it is a bit problem specific solution.
>>>
>>> So, I'd like to see other person's opinion here.
>>
>> I think we cannot change this because we
2012/9/21 Tatsuo Ishii :
Hmm, I see. Please deliver the 64bit integer argument as reference,
and don't forget endian translations here.
>>>
>>> I thought pgPutInt64() takes care of endianness. No?
>>>
>> It works inside of the PGfn(), when isint = 1 towards pointer data type.
>> In my sen
>>> Hmm, I see. Please deliver the 64bit integer argument as reference,
>>> and don't forget endian translations here.
>>
>> I thought pgPutInt64() takes care of endianness. No?
>>
> It works inside of the PGfn(), when isint = 1 towards pointer data type.
> In my sense, it is a bit problem specific
2012/9/21 Tatsuo Ishii :
>>> I think Tom's point is, there are tons of applications which define
>>> their own "int64_t" (at least in 2005).
>>> Also pg_config.h has:
>>>
>>> #define HAVE_STDINT_H 1
>>>
>>> and this suggests that PostgreSQL adopts to platforms which does not
>>> have stdint.h. If
>> I think Tom's point is, there are tons of applications which define
>> their own "int64_t" (at least in 2005).
>> Also pg_config.h has:
>>
>> #define HAVE_STDINT_H 1
>>
>> and this suggests that PostgreSQL adopts to platforms which does not
>> have stdint.h. If so, we need to take care of such
> > Currently lo_initialize() throws an error if one of oids are not
> > available. I doubt we do the same way for 64-bit functions since this
> > will make 9.3 libpq unable to access large objects stored in pre-9.2
> > PostgreSQL servers.
> >
> It seems to me the situation to split the case of pr
> I think Tom's point is, there are tons of applications which define
> their own "int64_t" (at least in 2005).
> Also pg_config.h has:
>
> #define HAVE_STDINT_H 1
>
> and this suggests that PostgreSQL adopts to platforms which does not
> have stdint.h. If so, we need to take care of such platfor
Tatsuo Ishii writes:
> To pass 64-bit integer to PQfn, PQArgBlock is used like this: int *ptr
> is a pointer to 64-bit integer and actual data is placed somewhere
> else.
Yeah, I think we have to do it like that. Changing the size of
PQArgBlock would be a libpq ABI break, which IMO is sufficient
>> To pass 64-bit integer to PQfn, PQArgBlock is used like this: int *ptr
>> is a pointer to 64-bit integer and actual data is placed somewhere
>> else. There might be other way: add new member to union u to store
>> 64-bit integer:
>>
>> typedef struct
>> {
>> int len;
> > 3) Backend inv_api.c functions(Nozomi Anzai)
> >
> > No need to add new functions. Just extend them to handle 64-bit data.
> >
> > BTW , what will happen if older 32-bit libpq accesses large objects
> > over 2GB?
> >
> > lo_read and lo_write: they can read or write lobjs using 32-bit API as
> >
I checked this patch. It can be applied onto the latest master branch
without any problems. My comments are below.
2012/9/11 Tatsuo Ishii :
> Ok, here is the patch to implement 64-bit API for large object, to
> allow to use up to 4TB large objects(or 16TB if BLCKSZ changed to
> 32KB). The patch is
Ok, here is the patch to implement 64-bit API for large object, to
allow to use up to 4TB large objects(or 16TB if BLCKSZ changed to
32KB). The patch is based on Jeremy Drake's patch posted on September
23, 2005
(http://archives.postgresql.org/pgsql-hackers/2005-09/msg01026.php)
and reasonably upda
On Tue, Aug 28, 2012 at 10:51 PM, Tatsuo Ishii wrote:
>> pg_largeobject.pageno is a signed int, so I don't think we can let it go
>> past 2^31-1, so half that.
>>
>> We could buy back the other bit if we redefined the column as oid
>> instead of int4 (to make it unsigned), but I think that would c
> pg_largeobject.pageno is a signed int, so I don't think we can let it go
> past 2^31-1, so half that.
>
> We could buy back the other bit if we redefined the column as oid
> instead of int4 (to make it unsigned), but I think that would create
> fairly considerable risk of confusion between the l
Tatsuo Ishii writes:
> Correct me if I am wrong.
> After expanding large object API to 64-bit, the max size of a large
> object will be 8TB(assuming 8KB default BLKSZ).
> large object max size = pageno(int32) * LOBLKSIZE
> = (2^32-1) * (BLCKSZ / 4)
>
Correct me if I am wrong.
After expanding large object API to 64-bit, the max size of a large
object will be 8TB(assuming 8KB default BLKSZ).
large object max size = pageno(int32) * LOBLKSIZE
= (2^32-1) * (BLCKSZ / 4)
>> 1) Frontend lo_* libpq functions(fe-lobj.c)
>
>> lo_initialize() need to get backend 64-bit large object handling
>> function's oid, namely lo_lseek64, lo_tell64, lo_truncate64, loread64,
>> lowrite64(explained later). If they are not available, use older
>> 32-bit backend functions.
>
> I don
Tatsuo Ishii writes:
> Here are the list of functions think we need to change.
> 1) Frontend lo_* libpq functions(fe-lobj.c)
> lo_initialize() need to get backend 64-bit large object handling
> function's oid, namely lo_lseek64, lo_tell64, lo_truncate64, loread64,
> lowrite64(explained later). I
> Hi,
>
> I found this in the TODO list:
>
> Add API for 64-bit large object access
>
> If this is a still valid TODO item and nobody is working on this, I
> would like to work in this.
Here are the list of functions think we need to change.
1) Frontend lo_* libpq functions(fe-lobj.c)
lo_i
> On Wed, 2012-08-22 at 01:14 -0400, Tom Lane wrote:
>> Peter Eisentraut writes:
>> > On Wed, 2012-08-22 at 07:27 +0900, Tatsuo Ishii wrote:
>> >> I found this in the TODO list:
>> >> Add API for 64-bit large object access
>> >> If this is a still valid TODO item and nobody is working on this, I
On Wed, 2012-08-22 at 01:14 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On Wed, 2012-08-22 at 07:27 +0900, Tatsuo Ishii wrote:
> >> I found this in the TODO list:
> >> Add API for 64-bit large object access
> >> If this is a still valid TODO item and nobody is working on this, I
> >> wo
>> Large objects are limited to 2 GB in size, so a 64-bit API doesn't sound
>> very useful to me at the moment.
>
> Not entirely. pg_largeobject.pageno is int32, but that's still 2G pages
> not bytes, so there's three or so orders of magnitude that could be
> gotten by expanding the client-side A
Peter Eisentraut writes:
> On Wed, 2012-08-22 at 07:27 +0900, Tatsuo Ishii wrote:
>> I found this in the TODO list:
>> Add API for 64-bit large object access
>> If this is a still valid TODO item and nobody is working on this, I
>> would like to work in this.
> Large objects are limited to 2 GB
On Wed, 2012-08-22 at 07:27 +0900, Tatsuo Ishii wrote:
> I found this in the TODO list:
>
> Add API for 64-bit large object access
>
> If this is a still valid TODO item and nobody is working on this, I
> would like to work in this.
Large objects are limited to 2 GB in size, so a 64-bit API d
Hi,
I found this in the TODO list:
Add API for 64-bit large object access
If this is a still valid TODO item and nobody is working on this, I
would like to work in this.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
S
49 matches
Mail list logo
