From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alexey Bashtanov <bashtanov(at)imap(dot)cc> |
Cc: | pgsql-bugs(at)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Subject: | Re: pg_dump sometimes misses sequence parameters |
Date: | 2018-02-19 16:49:45 |
Message-ID: | 16276.1519058985@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Alexey Bashtanov <bashtanov(at)imap(dot)cc> writes:
> The bug affects REL_10_STABLE and master branches.
> 9.4..9.6 are unaffected.
> To reproduce:
> psql -c 'DROP SEQUENCE IF EXISTS foo'
> psql -c 'CREATE SEQUENCE foo INCREMENT BY -1 MINVALUE
> -9223372036854775808 MAXVALUE 9223372036854775807'
> pg_dump -t foo > tmp
> psql -c 'DROP SEQUENCE foo'
> psql <tmp
> The last psql call fails with "START value (9223372036854775807) cannot
> be greater than MAXVALUE (-1)",
> as pg_dump does not record MAXVALUE properly.
Ugh.
> The reason is atoi is used and those large numbers are interpreted as 0
> and -1 respectively.
> I'd propose to use atol instead of atoi, please see the patch attached.
That will only fix it on platforms where long is 64 bits. I think that
converting these strings to integer at all is a dumb idea. It would be
much better to write the first two tests like
if (is_ascending && strcmp(minv, "1") == 0)
minv = NULL;
if (!is_ascending && strcmp(maxv, "-1") == 0)
maxv = NULL;
It's tempting to try to make the remaining tests look similar, but
I'm not quite sure how without writing out the exact decimal values
of the constants, which probably isn't better. I experimented with
stuff like "strcmp(minv, CppAsString2(PG_INT32_MIN))" but that
doesn't quite do what we need.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-02-19 19:43:16 | Re: [BUGS] BUG #14870: wrong query results when using WITH with UPDATE |
Previous Message | Alexey Bashtanov | 2018-02-19 13:32:56 | pg_dump sometimes misses sequence parameters |