pgbench --unlogged-tables silently ignored for branches/tellers/history when --partitions is used
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t254494psql -h localhost -U postgresBuilt from patchset v3 (message #3), November 02, 2026 at 09:25 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t254494_3 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t254494_3 && git checkout t254494_3Patchset v3 (message #3) is on t254494_3
Hi hackers!
While testing pgbench initialization on current master with Kirill,
we noticed that the --unlogged-tables tweak from [0]https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=e2bab2d7920 with
--partitions=N silently downgrades not only pgbench_accounts'
partitioned parent, but also the plain tables pgbench_branches,
pgbench_tellers and pgbench_history to PERMANENT. So
the option's documented meaning silently depends on an unrelated
option:
$ pgbench -i -I dt --unlogged-tables --partitions=2 -s 1 pq
$ psql -d pq -tc "select relname, relpersistence from pg_class
where relname like 'pgbench_%' order by relname"
pgbench_accounts | p
pgbench_accounts_1 | u
pgbench_accounts_2 | u
pgbench_branches | p <- three plain tables should be unlogged
pgbench_tellers | p <-
pgbench_history | p <-
The obvious fix - restrict the PART_NONE exception to pgbench_accounts
- is however incomplete: it makes pgbench_branches unlogged, while the
accounts foreign key is declared on the permanent partitioned parent,
and "constraints on permanent tables may reference only permanent
tables". The combination --unlogged-tables --partitions --foreign-keys
then fails.
So the attached patch keeps PERMANENT, when partitioning is in use, for
exactly two tables: pgbench_accounts and pgbench_branches. Seems like
making the branches exception conditional on --foreign-keys would brake
separately-runnable init steps ('... -I dt' then '... -I f')..
[0]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=e2bab2d7920
--
Best regards,
Roman Khapov
On Sat, Oct 31, 2026 at 7:58 PM Roman Khapov <rkhapov@yandex-team.ru> wrote:
So the attached patch keeps PERMANENT, when partitioning is in use, for
exactly two tables: pgbench_accounts and pgbench_branches.
Thanks for the report and patch!
Users who specify --unlogged-tables would expect all data tables to be
unlogged, so keeping pgbench_branches logged seems undesirable to me.
When using --partitions, --unlogged-tables, and --foreign-keys together,
users would expect partitioned accounts, unlogged data tables,
and working foreign keys, as documented. So, isn't it better to keep
all data tables unlogged and define the foreign key from each accounts
partition to pgbench_branches instead of from the partitioned parent?
Regards,
--
Fujii Masao
Hi! Thanks for review!
So, isn't it better to keep
all data tables unlogged and define the foreign key from each accounts
partition to pgbench_branches instead of from the partitioned parent?
Yes, it is... There is no point in keeping the patch simpler at the
cost of the option's meaning, so I did V2 that does:
- keep the PERMANENT exception for pgbench_accounts only: it cannot
be unlogged when partitioned
- accounts -> branches FKs are now created on the partitions
(pgbench_accounts_%) if the unlogged option is on and there are
partitions
--
Best regards,
Roman Khapov