This check makes no sense since tde_heap will get a new oid every time
we install it so if there are any leftovers from last time we will not
find them anyway.
Additionally for this to happen something would need to be broken with
pg_depend which I do not see why we should expend this much effort with
trying to assert against.
A petty typo. It flew undetected all this time due to WAL is written
by pages, hence encryption start will always be a multiple of the page
size, and in most cases is read page-by-page, hence
decryption_offset == read_offest. But crashing the primary after some
writes and switching WAL encryption to "on" makes the beginning of the
encrypted section be in the middle of the walsender read. Which, in
turn, forces the replica to fail and reveals the bug.
Fixes PG-1574
The FILE_COPY strategy of CREATE DATABASE does not use the SMGR so it
cannot properly copy and re-encrypt encrypted relations. So we check for
such relations and error out if any are found.
We look for encrypted relations simply by counting the number of keys in
the key map file of the database. This simple approach is fine even with
the risk of a left-over key from a crash or a bug due to the FILE_COPY
method being rare and that we therefore want to keep this code minimal.
Using a database with encrypted relations as template works works with
the WAL_LOG strateg as long as you have configured a default principal
key. It is a bit hackish but works and since encrypted objects in a
template database is likely to be an uncommon use case this is fine for
now.
The test file is put last in the test run order since there is still no
good way to clean up default principal keys.
While these tests test our changes to pg_waldump they are quite easy to
overlook right now and where exactly should we draw the line? These
tests are not something we ever want to upstream and in the future when
we figure out how we want to make sure pg_waldump works with encrypted
WAL we likely will want to have the tests for that solution in the same
folder as our other tests anyway.
This enum was only used in one place and oscured the two dimensions of
provider types (database vs global) and principal keys (server vs
default vs database).
The purpose of the global TDE mode is to run PostgreSQL's normal test
suite but with our extension so running the pg_tde test suite when in
that mode makes no sense.
Meson supports disabling test suites with --no-suite so we only need to
do this for the Makefile.
The TDE_MODE environment variable disables tests we actually want to run
in our Github Actions. This change is also necessary to in a future
commit disable the pg_tde tests in the global TDE mode.
Instead of giving them numbers we call them pg_tde_ddl_start and
pg_tde_ddl_end. Since the triggers are not on the same event the names
do not matter for the order they are executed in.
HeapTupleIsValid() is actually just a null check but PostgreSQL's
codebase almost always uses this macro and we had a confusion where we
both had a null check and called this macro so we at least should pick
just one of the two ways to write it. And here I picked the most
commonly used way in the PostgreSQL codebase.
The name pg_tde_<OID>_keyring was confusing to users due to making it
sound like it would contain keys. And the name pg_tde_<OID>_map did not
tell a user anything. The new names are <OID>_providers for the key
providers and <OID>_keys for the relation/WAL keys.
While changing the suffixes to be more descriptive I also dropped the
pg_tde_ prefix since it is just noise when they all are in the pg_tde
directory.
Artem Gavrilov