Re: pg_dump: dumpBlobs(): could not open large object: ERROR: large object 27729547 does not exist - Mailing list pgsql-general

From Alban Hertroys
Subject Re: pg_dump: dumpBlobs(): could not open large object: ERROR: large object 27729547 does not exist
Date
Msg-id 928737EA-D281-4D99-9267-AE2BBDF716F6@gmail.com
Whole thread Raw
In response to Re: pg_dump: dumpBlobs(): could not open large object: ERROR: large object 27729547 does not exist  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: pg_dump: dumpBlobs(): could not open large object: ERROR: large object 27729547 does not exist  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-general
On 26 Jan 2014, at 2:34, Michael Paquier <michael.paquier@gmail.com> wrote:

> On Fri, Jan 24, 2014 at 10:33 PM, Manoj Agarwal <ma@ockham.be> wrote:
>> Hi,
>>
>> I have a Postgresql-7.4.19  database in SQL_ASCII Encoding format.
> You should really consider an upgrade first... As mentioned by Kevin
> this version is outdated. The latest versions of pg_dump support
> servers down to 7.4 so an upgrade is doable.

That raises an interesting question: How far back will support for older versions in pg_dump go?
I assume at some point it will no longer be feasible for pg_dump to still support PG 7.4 and support will be dropped.
Atthat point, if you’re still running on such an old version of the database server, not only will you be out of
support(for a long time already), but your upgrade path will be barred. 

Of course, you could then do an intermediary upgrade to an older version than what’s current that still supports
dumpingfrom the version of the database that you’re on, but at some point you will find it difficult to obtain those
versionsas well. 

Would it help to put such bottom line version numbers on the Postgres site as a warning, so that people have a number
toverify that they never ever should get below, no matter what? Perhaps the lowest version supported by pg_dump could
beadded as a column to the EOL dates or something? 

Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.



pgsql-general by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: Fully-automatic streaming replication failover when master dies?
Next
From: Scott Ribe
Date:
Subject: fastest dump/restore