From: | Nozomi Anzai <anzai(at)sraoss(dot)co(dot)jp> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 64-bit API for large object |
Date: | 2012-09-21 01:34:31 |
Message-ID: | 20120921103431.a5f62e042a37eacfd99fb7ac@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > 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 requested read/write data length is smaller than 2GB. So I
> > think we can safely allow them to access over 2GB lobjs.
> >
> > lo_lseek: again as long as requested offset is smaller than 2GB, there
> > would be no problem.
> >
> > lo_tell:if current seek position is beyond 2GB, returns an error.
> >
> Even though iteration of lo_lseek() may move the offset to 4TB, it also
> makes unavailable to use lo_tell() to obtain the current offset, so I think
> it is reasonable behavior.
>
> However, error code is not an appropriate one.
>
> + if (INT_MAX < offset)
> + {
> + ereport(ERROR,
> + (errcode(ERRCODE_UNDEFINED_OBJECT),
> + errmsg("invalid large-object
> descriptor: %d", fd)));
> + PG_RETURN_INT32(-1);
> + }
>
> According to the manpage of lseek(2)
> EOVERFLOW
> The resulting file offset cannot be represented in an off_t.
>
> Please add a new error code such as ERRCODE_BLOB_OFFSET_OVERFLOW.
Agreed.
--
Nozomi Anzai
SRA OSS, Inc. Japan
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2012-09-21 02:05:46 | pg_reorg in core? |
Previous Message | Tom Lane | 2012-09-20 22:34:05 | Re: alter enum add value if not exists |