Re: 64-bit API for large object - Mailing list pgsql-hackers

From Nozomi Anzai
Subject Re: 64-bit API for large object
Date
Msg-id 20120921103431.a5f62e042a37eacfd99fb7ac@sraoss.co.jp
Whole thread Raw
In response to Re: 64-bit API for large object  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: alter enum add value if not exists
Next
From: Michael Paquier
Date:
Subject: pg_reorg in core?