BUG #18107: "policy ... for table ... already exists" errors when restore postgres database from dump

From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: antoniok(dot)spb(at)gmail(dot)com
Subject: BUG #18107: "policy ... for table ... already exists" errors when restore postgres database from dump
Date: 2023-09-14 07:28:44
Message-ID: 18107-2668460d8c2804d2@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 18107
Logged by: AntonioK
Email address: antoniok(dot)spb(at)gmail(dot)com
PostgreSQL version: 15.4
Operating system: Debian GNU/Linux 12 (bookworm)
Description:

I'm restoring postgresql database from dump on a fresh new server. Source
database uses pgcron extension, target server have pgcron extension
installed.

This is how I create dumps on "source" server:
$ pg_dumpall -h hostname -p 5435 -U myuser --roles-only | bzip2 -c -z >
dump-role.sql.bz2
$ pg_dump -C -h hostname -p 5435 -U myuser mydatabase | bzip2 -c -z >
dump-data.sql.bz2

This is how I restore dumps on empty "target" server:
$ grep -Eiv '(CREATE ROLE postgres|ALTER ROLE postgres .*PASSWORD)'
dump-role.sql | psql -Upostgres > /dev/null
$ psql -Upostgres -f dump-data.sql > /dev/null

(`grep` on the first command is used to left "postgres" superuser untouched
on a target server.)

When restoring from dump, I got two errors:
psql:/path/to/dump-data.sql:18831791: ERROR: policy "cron_job_policy" for
table "job" already exists
psql:/path/to/dump-data.sql:18831798: ERROR: policy
"cron_job_run_details_policy" for table "job_run_details" already exists

They refers to the following lines of dump:
-- Name: job cron_job_policy; Type: POLICY; Schema: cron; Owner: some_user
CREATE POLICY cron_job_policy ON cron.job USING ((username =
CURRENT_USER));
-- Name: job_run_details cron_job_run_details_policy; Type: POLICY; Schema:
cron; Owner: some_user
CREATE POLICY cron_job_run_details_policy ON cron.job_run_details USING
((username = CURRENT_USER));

I never created those POLICY by hands on "source" database. The guess is
(@see https://dba.stackexchange.com/a/331198/82463) that 'CREATE EXTENSION
... pg_cron ...' statement in the dump file is implicitly executes POLICY
creation, so 'CREATE POLICY ... ON cron...' statements in the dump file are
redundant and unnecessary.

Should we consider this as pg_dump bug?

Source server:
# grep PRETTY_NAME /etc/*rel*
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"

# psql -V
psql (PostgreSQL) 15.3 (Debian 15.3-1.pgdg120+1)

# dpkg -l | grep postgresql
ii postgresql-15 15.3-1.pgdg120+1 amd64

ii postgresql-15-cron 1.5.2-1.pgdg120+1 amd64

ii postgresql-client-10 10.23-1.pgdg120+1+b2 amd64
ii postgresql-client-11 11.20-1.pgdg120+1 amd64

ii postgresql-client-12 12.15-1.pgdg120+1 amd64

ii postgresql-client-13 13.11-1.pgdg120+1 amd64

ii postgresql-client-14 14.8-1.pgdg120+1 amd64

ii postgresql-client-15 15.3-1.pgdg120+1 amd64

ii postgresql-client-common 250.pgdg120+1 all

ii postgresql-common 250.pgdg120+1 all

ii postgresql-plpython3-15 15.3-1.pgdg120+1 amd64

ii postgresql-server-dev-10 10.23-1.pgdg120+1+b2 amd64
ii postgresql-server-dev-11 11.20-1.pgdg120+1 amd64

ii postgresql-server-dev-12 12.15-1.pgdg120+1 amd64
ii postgresql-server-dev-13 13.11-1.pgdg120+1 amd64
ii postgresql-server-dev-14 14.8-1.pgdg120+1 amd64

ii postgresql-server-dev-15 15.3-1.pgdg120+1 amd64

ii postgresql-server-dev-all:amd64 250.pgdg120+1 amd64

Target server:
# grep PRETTY_NAME /etc/*rel*
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"

# psql -V
psql (PostgreSQL) 15.4 (Debian 15.4-1.pgdg120+1)

# dpkg -l | grep postgresql
ii postgresql-15 15.4-1.pgdg120+1 amd64

ii postgresql-15-cron 1.5.2-2.pgdg120+2 amd64

ii postgresql-client-15 15.4-1.pgdg120+1 amd64

ii postgresql-client-common 253.pgdg120+1 all

ii postgresql-common 253.pgdg120+1 all

ii postgresql-plpython3-15 15.4-1.pgdg120+1 amd64
ii postgresql-server-dev-15 15.4-1.pgdg120+1 amd64

Browse pgsql-bugs by date

  From Date Subject
Next Message David Rowley 2023-09-14 07:29:40 Re: BUG #18103: bugs of concurrent merge into when use different join plan
Previous Message Lepikhov Andrei 2023-09-14 04:58:39 Re: EXPLAIN Verbose issue - custom_scan_tlist can directly refer CTE and Subquery