E.19. 2ndQuadrant Postgres 12.4r1.1.3

E.19.1. Migration
E.19.2. Changes

Release date: 2020-11-05

This release contains a variety of improvements over the previous release.

E.19.1. Migration

A dump/restore is not required for those running 2ndQPG 12.3r1.1.2 or community 12.X.

E.19.2. Changes

  • Rebase to the REL_12_4 tag of the community PostgreSQL code base.

  • Show a backtrace for PANIC messages by default even if guc is disabled

    Getting to know the stack trace for PANIC messages is handy for forensics. So show the backtrace for such messages regardless of if the pg2q.backtrace_on_internal_error configuration parameter is enabled or not.

  • Provide a way to skip checking of NOT VALID constraints.

    While NOT VALID constraints are normally checked and enforced for new rows being inserted/updated into the database, we provide an optional facility to skip the checks. This is useful for apply workers which may choose to skip the check, either because the check is done on the origin or because the check is known to potentially produce an ERROR and user instead wants to rely on subsequent VALIDATE CONSTRAINT to catch violations.

  • Add a table level option to control compression

    We now support a new table level option, compress_tuple_target, which can be set to decide when to trigger compression on a tuple. Prior to this, the toast_tuple_target (or the compile time default) was used to decide whether or not to compress a tuple. But this was detrimental when a tuple is large enough and has a good compression ratio, but not large enough to cross the toast threshold. We wouldn't compress such tuples, thus wasting a potentially good opportunity.

  • COPY FREEZE: Check if all tuples in a given page of a given table are frozen and visible, without doing any extensive checks.

    We will typically do this when we are doing table insertions in TABLE_INSERT_FROZEN mode (e.g. COPY FREEZE). Since the relation is not visible to any other transactions when running in this mode, we usually expect the pages to contain only tuples with frozen-xmin and invalid-xmax. But in order to guard against the case when our own transaction may has inserted regular tuples, which are not marked frozen, in the table and for abundance of caution, we do this check additionally.

  • Add 2ndQPostgres configuration parameters to limit max tuple size and max field size

    The new pg2q.max_tuple_size parameter restricts the maximum before-TOASTing size that may be written to a table. This is the total row width including the uncompressed width of all TOASTable VARLENA attributes.

    The new pg2q.max_tuple_field_size parameter restricts the maximum uncompressed size in bytes of any one VARLENA Datum that may be written to a table.