Re: Two sequences associated with one identity column - Mailing list pgsql-general
| From | kurt thepw.com |
|---|---|
| Subject | Re: Two sequences associated with one identity column |
| Date | |
| Msg-id | BN8PR07MB5905FE3F05381DDBFFDEDA9FD3FAA@BN8PR07MB5905.namprd07.prod.outlook.com Whole thread Raw |
| In response to | Re: Two sequences associated with one identity column ("Colin 't Hart" <colinthart@gmail.com>) |
| Responses |
Re: Two sequences associated with one identity column
|
| List | pgsql-general |
<
< CREATE TABLE <schema>.<tablename> (
< <other columns>,
< id bigint NOT NULL
< );
<
I've never seen a plaintext pg_dump output where the sequence associated with a column in a table was not mentioned in s "DEFAULT nextval(..." modifier in that column's line of the CREATE TABLE statement, ex:
<
< CREATE TABLE <schema>.<tbl> (
I've never seen a plaintext pg_dump output where the sequence associated with a column in a table was not mentioned in s "DEFAULT nextval(..." modifier in that column's line of the CREATE TABLE statement, ex:
<
< CREATE TABLE <schema>.<tbl> (
< id integer DEFAULT nextval('<schema>.<seqname>'::regclass) NOT NULL,
< <next column>...,
< . . . . .
< );
With the sequence already created earlier in the dump file. But then, I've never before seen a table column with two associated sequences. Maybe that is what makes pg_dump generate the
"ALTER TABLE <schema>.<tablename> ALTER COLUMN id ADD GENERATED..."
Statements.
<
With the sequence already created earlier in the dump file. But then, I've never before seen a table column with two associated sequences. Maybe that is what makes pg_dump generate the
"ALTER TABLE <schema>.<tablename> ALTER COLUMN id ADD GENERATED..."
Statements.
<
< 1. The id column is last, so quite possibly added later (instead of
< the original PK which was dropped?)
<
That seems likely, and probably the 2nd sequence was added in by someone who didn't know (or forgot) about the first one.
<
That seems likely, and probably the 2nd sequence was added in by someone who didn't know (or forgot) about the first one.
<
< 2. The two sequences are just dumped -- which causes an error when importing.
<
I'd be curious to know if simple editing out the 2nd "ALTER TABLE...ADD GENERATED.." statement would allow a restore of the database to succeed. pg_restore dorsn't work with plaintext files, you have to cat them into psql or use the '-f' switch.
<
I'd be curious to know if simple editing out the 2nd "ALTER TABLE...ADD GENERATED.." statement would allow a restore of the database to succeed. pg_restore dorsn't work with plaintext files, you have to cat them into psql or use the '-f' switch.
<
< A third thing that is interesting is that I can drop the table just
< fine -- and both sequences get dropped along with it.
< The table seems to be relatively small -- and has no foreign keys --
< so I think the solution will be to recreate the table (create table as
< select), drop the original table and finally rename the new table the
< same as the old one.
<
That's probably the quickest way to fix it, though if you are "create table as select.."-ing from the old table you might get the two sequences again. I've never used "create table as select" .
An alternative might be to pg_dump just that table, edit the .sql file, drop the table, and then restore.
Kurt
That's probably the quickest way to fix it, though if you are "create table as select.."-ing from the old table you might get the two sequences again. I've never used "create table as select" .
An alternative might be to pg_dump just that table, edit the .sql file, drop the table, and then restore.
Kurt
From: Colin 't Hart <colinthart@gmail.com>
Sent: Wednesday, October 29, 2025 9:40 AM
To: PostgreSQL General <pgsql-general@lists.postgresql.org>
Subject: Re: Two sequences associated with one identity column
Sent: Wednesday, October 29, 2025 9:40 AM
To: PostgreSQL General <pgsql-general@lists.postgresql.org>
Subject: Re: Two sequences associated with one identity column
As expected the dump contains:
CREATE TABLE <schema>.<tablename> (
<other columns>,
id bigint NOT NULL
);
<snip>
--
-- Name: <sequence1>; Type: SEQUENCE; Schema: <schema>; Owner: <owner>
--
ALTER TABLE <schema>.<tablename> ALTER COLUMN id ADD GENERATED ALWAYS
AS IDENTITY (
SEQUENCE NAME <schema>.<sequence1>
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1
);
--
-- Name: <sequence2>; Type: SEQUENCE; Schema: <schema>; Owner: <owner>
--
ALTER TABLE <schema>.<tablename> ALTER COLUMN id ADD GENERATED ALWAYS
AS IDENTITY (
SEQUENCE NAME <schema>.<sequence2>
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1
);
Two things are interesting:
1. The id column is last, so quite possibly added later (instead of
the original PK which was dropped?)
2. The two sequences are just dumped -- which causes an error when importing.
A third thing that is interesting is that I can drop the table just
fine -- and both sequences get dropped along with it.
The table seems to be relatively small -- and has no foreign keys --
so I think the solution will be to recreate the table (create table as
select), drop the original table and finally rename the new table the
same as the old one.
Also checking to see if the problem extends to the other environments.
/Colin
On Wed, 29 Oct 2025 at 13:07, hubert depesz lubaczewski
<depesz@depesz.com> wrote:
>
> On Wed, Oct 29, 2025 at 01:04:48PM +0100, Colin 't Hart wrote:
> > Thanks. But as I wrote above, trying to alter either of the two
> > sequences and specifying "owned by none" results in the error.
>
> Sorry, missed that.
>
> Can you please provide pg_dump output from this db, just schema, just
> this one table, and both sequences?
>
> Or, how did you arrive at this situation?
>
> Did you try to alter table … alter column … drop identity;
>
> Best regards,
>
> depesz
>
CREATE TABLE <schema>.<tablename> (
<other columns>,
id bigint NOT NULL
);
<snip>
--
-- Name: <sequence1>; Type: SEQUENCE; Schema: <schema>; Owner: <owner>
--
ALTER TABLE <schema>.<tablename> ALTER COLUMN id ADD GENERATED ALWAYS
AS IDENTITY (
SEQUENCE NAME <schema>.<sequence1>
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1
);
--
-- Name: <sequence2>; Type: SEQUENCE; Schema: <schema>; Owner: <owner>
--
ALTER TABLE <schema>.<tablename> ALTER COLUMN id ADD GENERATED ALWAYS
AS IDENTITY (
SEQUENCE NAME <schema>.<sequence2>
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1
);
Two things are interesting:
1. The id column is last, so quite possibly added later (instead of
the original PK which was dropped?)
2. The two sequences are just dumped -- which causes an error when importing.
A third thing that is interesting is that I can drop the table just
fine -- and both sequences get dropped along with it.
The table seems to be relatively small -- and has no foreign keys --
so I think the solution will be to recreate the table (create table as
select), drop the original table and finally rename the new table the
same as the old one.
Also checking to see if the problem extends to the other environments.
/Colin
On Wed, 29 Oct 2025 at 13:07, hubert depesz lubaczewski
<depesz@depesz.com> wrote:
>
> On Wed, Oct 29, 2025 at 01:04:48PM +0100, Colin 't Hart wrote:
> > Thanks. But as I wrote above, trying to alter either of the two
> > sequences and specifying "owned by none" results in the error.
>
> Sorry, missed that.
>
> Can you please provide pg_dump output from this db, just schema, just
> this one table, and both sequences?
>
> Or, how did you arrive at this situation?
>
> Did you try to alter table … alter column … drop identity;
>
> Best regards,
>
> depesz
>
pgsql-general by date: