Skip to content

Releases: HexaCluster/pg_dbms_errlog

Version 2.2

20 Oct 10:59

Choose a tag to compare

Mon October 20 2025 - Version 2.2

This maintenance release fix PostgreSQL version compatibility issues and problems reported by users since last release.

  • Fix PG 17+ compatibility. Thanks to phomolka1 for the report.
  • Fix extension's schema that must be dbms_job instead of pg_dbms_job. Thanks to thomashelgi and phomolka1 for the report.
  • Update Copyrights.
  • Add GitHub CI tests with different PG versions.
  • Transfert Github repo to HexaCluster Github account to maintain the project.

Version 2.1

26 Dec 18:45

Choose a tag to compare

Mon December 26 2022 - Version 2.1

This maintenance release fix some issues reported by users since past six months.

  • Add missing PGDLLEXPORT markings. Thanks to Julien Rouhaud for the patch.
  • Remove useless call to position.
  • Fix function create_error_log() to use the schema of the table to log instead of default schema (public or from search_path). The function now also check that the table to log exists and use quote_ident() in the errorlog table creation.
  • Fix compatibility with pg15 new shmem_request_hook. Thanks to Julien Rouhaud for the patch.
  • Fix regression tests for pg15 since PUBLIC doesn't have CREATE privilege on the public schema by default. Thanks to Julien Rouhaud for the patch.
  • Remove _PG_fini(). Thanks to Julien Rouhaud for the patch.
  • Fix compatibility with pg14 new process utility hook prototype. Thanks to Julien Rouhaud for the patch.
  • Fix regression test with new warning format. Thanks to Julien Rouhaud for the patch.

Version 2.0

25 May 17:55

Choose a tag to compare

This major release replace pg_background with a custom infrastructure. It adds the following infrastructure:

  • queue in dynamic shared memory of error information that can be
    processed asynchronously

  • a main background worker that can process the queued error and
    insert the data in the corresponding error table, launching dynamic
    background workers that can process the data in batch

  • a notification system so the backends can ask the background worker
    to start processing queue items they just processed immediately,
    and be notified when the work is done to reduce the waiting time as
    much as possible

This fixes multiples issues with the pg_background approach:

  • we don't have to launch a dynamic bgworker per error anymore

  • if a dynamic bgworker can't be launched, the error data isn't lost
    and will be reprocessed until it's successful

  • various "synchronous" mode are implemented: [ off | query | transaction ],
    the bgworker also start processing queued error in the background before
    the commit if the queue becomes too large.

  • error logging can also be limited to a certain number of errors in the
    queue size, when the limit is reach no more error are logged.

For the complete list of changes see ChangeLog

Version 1.3

25 May 14:43

Choose a tag to compare

This release fix remaining issues on the v1.x branch. The development effort is now done on version 2.x, do not expect further development in this branch.

Version 1.2

10 May 14:53

Choose a tag to compare

This release adds logging of bind parameters values to error messages to be able to restore the failing statement and adds regression tests for partitioned table error logging.

Version 1.1

10 May 09:12

Choose a tag to compare

This release adds support to DROP SCHEMA + CASCADE to automatically unregister an error logged table when it is part of this schema. It also allows VIEWS be registered as error log table.

Version 1.0

09 May 08:41

Choose a tag to compare

The pg_dbms_errlog extension provides the infrastructure that enables you to create an error logging table so that DML operations can continue after encountering errors rather than abort and roll back. It requires the use of the pg_statement_rollback extension or to fully manage the SAVEPOINT in the DML script. Logging in the corresponding error table is done using extension pg_background, it is required that the extension must have been created in the database. Note that max_worker_processes must be high enough to support the pg_dbms_errlog extension, a pg_background process can be forked in each session using the pg_dbms_errlog extension.