BUG #17008: pg_dump doesn't dump a sequence with bigint type

On Thu, May 13, 2021 at 9:04 AM PG Bug reporting form <
noreply@postgresql.org> wrote:

The following bug has been logged on the website:

Bug reference: 17008
Logged by: Jaime Acevedo
Email address: jacevedo@we-techs.com
PostgreSQL version: 12.6
Operating system: ubuntu 20.04
Description:

I'm using pg_dump to dump my database version 12.5 (RDS), pg_dump version
12.6 but I have a the following table

CREATE TABLE public.projects_historydata
(
id bigint NOT NULL DEFAULT
nextval('projects_historydata_id_seq'::regclass),
[...]
this table make references to the sequence projects_historydata_id_seq
-- SEQUENCE: public.projects_project_id_seq

-- DROP SEQUENCE public.projects_project_id_seq;

CREATE SEQUENCE public.projects_project_id_seq
INCREMENT 1
START 1
MINVALUE 1
MAXVALUE 9223372036854775807
CACHE 1;
[...]

At the moment to do a pg_dump the pg_dump doesn't make the script for the
sequence, then the restore fail to create the table.

Please see that the id value for the table (the value handle by the
sequences is not an integer is biginteger)

I'm confused regarding the complaint. I see that the sequence used by the
history table is different from the single sequence shown in the email. Is
the script in the email the entire dump script? What dump command did you
use?

The sequence you show is a bigint sequence since that is the default and
there is nothing overriding it. Though since you seem to be showing
mis-matched information that observation is only a general one.

David J.

On 2021-May-13, PG Bug reporting form wrote:

I'm using pg_dump to dump my database version 12.5 (RDS), pg_dump version
12.6 but I have a the following table

CREATE TABLE public.projects_historydata
(
id bigint NOT NULL DEFAULT
nextval('projects_historydata_id_seq'::regclass),
value double precision NOT NULL,
value_at timestamp with time zone NOT NULL,
var_id integer NOT NULL,
created timestamp with time zone NOT NULL,
CONSTRAINT projects_historydata_pkey PRIMARY KEY (id),
CONSTRAINT projects_historydata_var_id_21f99477_fk_projects_var_id
FOREIGN KEY (var_id)
REFERENCES public.projects_var (id) MATCH SIMPLE
ON UPDATE NO ACTION
ON DELETE NO ACTION
DEFERRABLE INITIALLY DEFERRED
)

WITH (
autovacuum_enabled = TRUE
)
TABLESPACE pg_default;

Hello Jaime

How did you get this table definition?

I suggest to run this:
ALTER SEQUENCE projects_historydata_id_seq OWNED BY public.projects_historydata.id
and then things will work better.

Cheers

--
�lvaro Herrera Valdivia, Chile

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

On 2021-May-13, PG Bug reporting form wrote:

I'm using pg_dump to dump my database version 12.5 (RDS), pg_dump version
12.6 but I have a the following table

How did you get this table definition?

Indeed. It seems unlikely to me that this is pg_dump's fault;
I think it's just reporting the way things are in the source
database. If projects_historydata_id_seq is the wrong width,
that's probably because it was manually created that way and
then manually attached to projects_historydata.id.

I suggest to run this:
ALTER SEQUENCE projects_historydata_id_seq OWNED BY public.projects_historydata.id
and then things will work better.

This won't in itself fix the sequence's width; you'd need
to do some additional ALTERs if that's wrong.

regards, tom lane

Sorry, I made a mistake at the moment to copy & paste the sequences.

But this finally the problems was the filter to do dump, when I use
--exclude-table option with pattern projects_historydata_* for some reason
the sequences was excluded finally I used the pattern
projects_historydata_[0-9]* to exclude only the tables that I want to
exclude.

I don´t know if that behavior is right.

Regards,
Jaime Acevedo E.

El jue, 13 may 2021 a las 14:11, Tom Lane (<tgl@sss.pgh.pa.us>) escribió:

On 2021-May-13, Tom Lane wrote:

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

I suggest to run this:
ALTER SEQUENCE projects_historydata_id_seq OWNED BY public.projects_historydata.id
and then things will work better.

This won't in itself fix the sequence's width; you'd need
to do some additional ALTERs if that's wrong.

True.

What I'm thinking is that Jaime misunderstood what the actual problem
is; note that he posted the CREATE SEQUENCE statement for an unrelated
sequence, and didn't post any statement for the correct one. He thinks
the problem is related to the sequence being bigint, but I doubt it
really is.

--
�lvaro Herrera Valdivia, Chile
"No tengo por qu� estar de acuerdo con lo que pienso"
(Carlos Caszeli)

On 2021-May-13, Jaime Acevedo wrote:

Sorry, I made a mistake at the moment to copy & paste the sequences.

But this finally the problems was the filter to do dump, when I use
--exclude-table option with pattern projects_historydata_* for some reason
the sequences was excluded finally I used the pattern
projects_historydata_[0-9]* to exclude only the tables that I want to
exclude.

Ah, that makes sense.

I don�t know if that behavior is right.

Hmm, I think --exclude-tables should exclude tables only, not sequences.
And it does behave like that for me, in a quick test with version 10.
What version of Postgres are you using?

--
�lvaro Herrera 39�49'30"S 73�17'W
"Estoy de acuerdo contigo en que la verdad absoluta no existe...
El problema es que la mentira s� existe y tu est�s mintiendo" (G. Lama)

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

Hmm, I think --exclude-tables should exclude tables only, not sequences.
And it does behave like that for me, in a quick test with version 10.

Probably your original thought is right: the sequence isn't properly owned
by the table column, so it doesn't get dumped in a selective dump.

regards, tom lane

Ok, thanks.

El jue, 13 may 2021 a las 14:34, Tom Lane (<tgl@sss.pgh.pa.us>) escribió: