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

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),
    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;

ALTER TABLE public.projects_historydata
    OWNER to wedbmaster;

GRANT SELECT ON TABLE public.projects_historydata TO read_only_user;

GRANT SELECT ON TABLE public.projects_historydata TO readaccess;

GRANT ALL ON TABLE public.projects_historydata TO wedbmaster;
-- Index: projects_historydata_db9d0193

-- DROP INDEX public.projects_historydata_db9d0193;

CREATE INDEX projects_historydata_db9d0193
    ON public.projects_historydata USING btree
    (var_id ASC NULLS LAST)
    TABLESPACE pg_default;
-- Index: projects_historydata_var_id_value_at_idx

-- DROP INDEX public.projects_historydata_var_id_value_at_idx;

CREATE INDEX projects_historydata_var_id_value_at_idx
    ON public.projects_historydata USING btree
    (var_id ASC NULLS LAST, value_at ASC NULLS LAST)
    TABLESPACE pg_default;

-- Trigger: after_insert_projects_historydata_trigger

-- DROP TRIGGER after_insert_projects_historydata_trigger ON
public.projects_historydata;

CREATE TRIGGER after_insert_projects_historydata_trigger
    AFTER INSERT
    ON public.projects_historydata
    FOR EACH ROW
    EXECUTE FUNCTION public.projects_historydata_delete_master();

-- Trigger: before_insert_projects_historydata_trigger

-- DROP TRIGGER before_insert_projects_historydata_trigger ON
public.projects_historydata;

CREATE TRIGGER before_insert_projects_historydata_trigger
    BEFORE INSERT
    ON public.projects_historydata
    FOR EACH ROW
    EXECUTE FUNCTION public.projects_historydata_insert_child();

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;

ALTER SEQUENCE public.projects_project_id_seq
    OWNER TO wedbmaster;

GRANT SELECT ON SEQUENCE public.projects_project_id_seq TO read_only_user;

GRANT ALL ON SEQUENCE public.projects_project_id_seq TO wedbmaster;

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)

Regards,
Jaime Acevedo E.

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

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