[BUG FIX] Version number expressed in octal form by mistake

Yes, we got temp licence key from them and will provide full report.

On Wed, Dec 25, 2013 at 4:38 PM, Joel Jacobson <joel@trustly.com> wrote:

As reported by Andrey Karpov in his article
http://www.viva64.com/en/b/0227/, the version number is expressed in
octal form 070100 should be changed to 70100.

Attached patch fixes the reported issue.

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

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

Joel Jacobson <joel@trustly.com> wrote:

As reported by Andrey Karpov in his article
http://www.viva64.com/en/b/0227/
the version number is expressed in octal form 070100 should be
changed to 70100.

Attached patch fixes the reported issue.

This is a bug, but it's not clear what the correct patch should be.
If you look at our docs:

http://www.postgresql.org/docs/devel/static/app-pgdump.html#PG-DUMP-NOTES

It says, "(Currently, servers back to version 7.0 are supported.)"
The source code seems to be trying to support back to 7.1.0, but
because of the leading zero making it an octal literal it is taken
as version 2.87.36.  Do we want to make the code match the docs, or
make both match what the code appears to have been attempting?

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Kevin Grittner <kgrittn@ymail.com> wrote:

Joel Jacobson <joel@trustly.com> wrote:

As reported by Andrey Karpov in his article
http://www.viva64.com/en/b/0227/
the version number is expressed in octal form 070100 should be
changed to 70100.

Attached patch fixes the reported issue.

This is a bug, but it's not clear what the correct patch should
be.

Oh, I just noticed that this is for the *pg_restore* code, not the
pg_dump code, so there isn't necessarily a conflict with the docs.
The pg_dump code does match the docs on its version check. The
question becomes, for each supported version, what do we want to
set into AHX->minRemoteVersion before opening the connection to the
target database?  Do we really want a 9.4 executable to be
attempting to restore to a 7.1 database cluster?  What about
backpatching?

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Kevin Grittner <kgrittn@ymail.com> writes:

Oh, I just noticed that this is for the *pg_restore* code, not the
pg_dump code, so there isn't necessarily a conflict with the docs.
The pg_dump code does match the docs on its version check. The
question becomes, for each supported version, what do we want to
set into AHX->minRemoteVersion before opening the connection to the
target database?� Do we really want a 9.4 executable to be
attempting to restore to a 7.1 database cluster?� What about
backpatching?

On reflection, I'm not sure that pg_restore as such should be applying any
server version check at all. pg_restore itself has precious little to do
with whether there will be a compatibility problem; that's mostly down to
the DDL that pg_dump put into the archive file. And we don't have enough
information to be very sure about whether it will work, short of actually
trying it. So why should the code arbitrarily refuse to try?

So I'm inclined to propose that we set min/max to 0 and 999999 here.

regards, tom lane

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

Tom Lane <tgl@sss.pgh.pa.us> wrote:

On reflection, I'm not sure that pg_restore as such should be applying any
server version check at all.  pg_restore itself has precious little to do
with whether there will be a compatibility problem; that's mostly down to
the DDL that pg_dump put into the archive file.  And we don't have enough
information to be very sure about whether it will work, short of actually
trying it.  So why should the code arbitrarily refuse to try?

So I'm inclined to propose that we set min/max to 0 and 999999 here.

Something like the attached back-patched to 8.4?

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Kevin Grittner <kgrittn@ymail.com> writes:

Tom Lane <tgl@sss.pgh.pa.us> wrote:

So I'm inclined to propose that we set min/max to 0 and 999999 here.

Something like the attached back-patched to 8.4?

Works for me.

regards, tom lane

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

Tom Lane <tgl@sss.pgh.pa.us> wrote:

Kevin Grittner <kgrittn@ymail.com> writes:

Tom Lane <tgl@sss.pgh.pa.us> wrote:

So I'm inclined to propose that we set min/max to 0 and 999999
here.

Something like the attached back-patched to 8.4?

Works for me.

Done.

Thanks for the report, Joel!

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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