[BUGS] BUG #14280: Error in PostgreSQL - could not extend file "base...": File too large

[prik...@cadence.com]

The following bug has been logged on the website:

Bug reference: 14280
Logged by: Prikshat Heera
Email address: prik...@cadence.com
PostgreSQL version: 9.2.16
Operating system: Linux
Description:

A table has 400 columns. While inserting data into this table, We are
getting the error - "could not extend file "base/16385/16872": File too
large".
After that, we vacuumm'ed and reindex'ed the table and insert worked fine.
Please evaluate and let us know if this has been fixed in 9.3 ?

--
Sent via pgsql-bugs mailing list (pgsql...@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[David G. Johnston]

On Fri, Aug 5, 2016 at 2:41 AM, <prik...@cadence.com> wrote:

The following bug has been logged on the website:

Bug reference:      14280
Logged by:          Prikshat Heera
Email address:      prik...@cadence.com
PostgreSQL version: 9.2.16
Operating system:   Linux
Description:

A table has 400 columns. While inserting data into this table, We are
getting the error - "could not extend file "base/16385/16872": File too
large".
After that, we vacuumm'ed and reindex'ed the table and insert worked fine.
Please evaluate and let us know if this has been fixed in 9.3 ?

​Most likely whatever "it" is has not been fixed.  9.2 is still active ​so any fix would have been back-patched to it.  If "the problem" goes away in 9.3 is would be purely coincidental.

With the information provided diagnostics seems problematic - since it would likely first require getting a machine into the failing mode which your's no longer is and there is no obvious reproduction approach.

Which Linux?

Possibly a bit more guessing could be had from someone knowledgeable with the code surrounding that error path but this is awfully light, transient, and potentially machine specific, to track down.  Working toward reproduction or posting back while the machine is failing (if it ever comes up again) seem like necessary next steps.

David J.

[Tom Lane]

"David G. Johnston" <david.g....@gmail.com> writes:
> On Fri, Aug 5, 2016 at 2:41 AM, <prik...@cadence.com> wrote:
>> A table has 400 columns. While inserting data into this table, We are
>> getting the error - "could not extend file "base/16385/16872": File too
>> large".

> Possibly a bit more guessing could be had from someone knowledgeable with
> the code surrounding that error path but this is awfully light, transient,
> and potentially machine specific, to track down.

"File too large" is EFBIG, which ordinarily I'd say is impossible because
we don't let individual files exceed 1GB, precisely to avoid the type of
filesystem limitation that would be reported with this error code.
However, the man page for write(2) on my Linux box saith

EFBIG An attempt was made to write a file that exceeds the implementa-
tion-defined maximum file size or the process's file size limit,
or to write at a position past the maximum allowed offset.

So that gives us a plausible explanation after all: you have an active file
size limit imposed on the backend processes, and it was reached by this
particular process. What made the error go away was simply using a fresh
backend session. You'll want to turn off the restriction before starting
the postmaster, though. See ulimit.

regards, tom lane