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_SIZE)
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' :
undeclared
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
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
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 an...@sraoss.co.jp:
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.
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
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
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 somehow?
2012/9/30 Tatsuo Ishii is...@postgresql.org:
* 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);
|
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:
|
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
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
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 is...@postgresql.org:
Ok, here is the patch to implement 64-bit API for large object, to
allow to
2012/9/22 Tatsuo Ishii is...@postgresql.org:
Tom, Kaigai,
Kohei KaiGai kai...@kaigai.gr.jp 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)?
2012/9/22 Tatsuo Ishii is...@postgresql.org:
Tom, Kaigai,
Kohei KaiGai kai...@kaigai.gr.jp 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
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 platforms
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 pre-9.2 and
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 platforms
2012/9/21 Tatsuo Ishii is...@postgresql.org:
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,
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 solution.
2012/9/21 Tatsuo Ishii is...@postgresql.org:
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
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 want to keep the
2012/9/21 Tatsuo Ishii is...@postgresql.org:
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
2012/9/21 Tatsuo Ishii is...@postgresql.org:
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
Kohei KaiGai kai...@kaigai.gr.jp 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
Kohei KaiGai kai...@kaigai.gr.jp 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
2012/9/21 Tatsuo Ishii is...@postgresql.org:
Kohei KaiGai kai...@kaigai.gr.jp 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
Kohei KaiGai kai...@kaigai.gr.jp 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
Tom, Kaigai,
Kohei KaiGai kai...@kaigai.gr.jp 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 kai...@kaigai.gr.jp 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
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
long as
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;
int
Tatsuo Ishii is...@postgresql.org 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
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 is...@postgresql.org:
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
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
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)
Tatsuo Ishii is...@postgresql.org 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) *
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 loid
On Tue, Aug 28, 2012 at 10:51 PM, Tatsuo Ishii is...@postgresql.org 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
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)
Tatsuo Ishii is...@postgresql.org 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,
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't
On Wed, 2012-08-22 at 01:14 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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 pete...@gmx.net 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 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
Peter Eisentraut pete...@gmx.net 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
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 API
48 matches
Mail list logo
