Skip to content

feat: add pg_cron container image#143

Open
ardentperf wants to merge 4 commits into
cloudnative-pg:mainfrom
ardentperf:pr-cron
Open

feat: add pg_cron container image#143
ardentperf wants to merge 4 commits into
cloudnative-pg:mainfrom
ardentperf:pr-cron

Conversation

@ardentperf

Copy link
Copy Markdown

pg_cron is an open-source extension that provides a simple cron-based job scheduler for PostgreSQL, allowing you to schedule PostgreSQL commands directly from the database.

Closes #139

pg_cron is an open-source extension that provides a simple cron-based
job scheduler for PostgreSQL, allowing you to schedule PostgreSQL
commands directly from the database.

Closes cloudnative-pg#139

Signed-off-by: Jeremy Schneider <schneider@ardentperf.com>
@ardentperf ardentperf requested review from a team and NiccoloFei as code owners March 16, 2026 23:23
@GabriFedi97 GabriFedi97 mentioned this pull request Mar 23, 2026
4 tasks
@gbartolini

Copy link
Copy Markdown
Contributor

Hi @ardentperf, now that we've resolved the version issue, could you please revisit your initial attempt? Let me know your thoughts, or we may need to close this PR since it has significantly diverged from the main branch, and it might be better/easier to submit a new one.

@gbartolini

Copy link
Copy Markdown
Contributor

@ardentperf, are you willing to contribute to this PR? Otherwise, I am closing this, as it has drifted a lot from the current specification. Thanks.

updated to post-cloudnative-pg#149/cloudnative-pg#154 metadata format: nested version objects with
package+sql versions, set cron.database_name so CREATE EXTENSION works
during E2E tests, enables create_extension

Signed-off-by: Jeremy Schneider <schneider@ardentperf.com>
@gbartolini

Copy link
Copy Markdown
Contributor

Can a disclaimer be added for the pg_cron extension? It should indicate that writable workloads will be executed locally on the primary instance, bypassing the service. In the event of a network partition or if the primary instance becomes isolated, these workloads will continue to write on the primary until it self-fences. It’s important to warn users about this.

@ardentperf

Copy link
Copy Markdown
Author

My own view is that CNPG should move toward making synchronous replication the default configuration (cf. cloudnative-pg/cloudnative-pg#10783 ) and failoverQuorum: true. in this configuration, core postgres ensures that no durable writes will be allowed by postgres at any time during a network partition - even from pg_cron jobs.

Kubernetes Services are a traffic routing mechanism, but IMO we shouldn't generally think of services as a fencing mechanism - they aren't intended for that.

@GabriFedi97 GabriFedi97 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The CODEOWNERS file needs to be updated accordingly.

Comment thread pg-cron/metadata.hcl
name = "pg-cron"
image_name = "pg-cron"

licenses = ["PostgreSQL"]

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can see, the package is not distributed under PostgreSQL license but under citus and cron licenses, which have slightly different restrictions:

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: pg_cron
Source: https://github.com/citusdata/pg_cron

Files: *
Copyright: Copyright (c) 2015-2017 Citus Data
License: citus
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without a written agreement is
hereby granted, provided that the above copyright notice and this paragraph
and the following two paragraphs appear in all copies.
.
IN NO EVENT SHALL CITUS DATA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT,
SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING
OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF CITUS DATA HAS
BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.
CITUS DATA SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND CITUS
DATA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES,
ENHANCEMENTS, OR MODIFICATIONS.

Files: src/entry.c src/misc.c
Copyright: Copyright 1988,1990,1993,1994 by Paul Vixie
License: cron
All rights reserved
.
Distribute freely, except: don't remove my name from the source or
documentation (don't take credit for my work), mark your changes (don't
get me blamed for your possible bugs), don't alter or remove this
notice. May be sold if buildable source is provided to buyer. No
warrantee of any kind, express or implied, is included with this
software; use at your own risk, responsibility for damages (if any) to
anyone resulting from the use of this software rests entirely with the
user.

I think the actual SPDX license here is Vixie-Cron

@ardentperf ardentperf Jun 9, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "citus" license is the PostgreSQL license. It's exactly the same, except that "University of California" is changed to "Citus Data" which is the normal process when the Postgres License is being used by someone other than the University of California.

https://www.postgresql.org/about/licence/

I missed the Vixie-Cron license, you're right that it also needs to be added for those two files. I'll update the PR

@GabriFedi97 GabriFedi97 Jun 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm afraid this might go against one of the latest requirement that was added for new extensions proposals, which is that each listed license must fall into the CNCF Allowlist in order to be accepted.

https://github.com/cloudnative-pg/postgres-extensions-containers/blob/90ecbbad1a1923419de1419d0fa571a2c7ae8be0/README.md#extension-requirements

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I agree with @GabriFedi97. Unfortunately, we must comply with that list. As I said with other extensions, that doesn't prevent anyone from distributing that extension image, but it cannot be done through the official CNPG project for licensing reasons.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CNCF rejecting code under the Vixie-Cron license seems... pretty astounding... (that license should be compatible)

But I guess they would want to pay a lawyer to sign off on it, and maybe not worth legal fees and all the time sending emails to coordinate for two small files (?)

Probably need some non-CNCF place to host extensions sooner than later

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, we are unable to request exceptions for each extension or obtain a waiver for the Vixie-Cron license, which I believe should be acceptable (but it is not in that list, and that's what matters now).

Regarding the non-CNCF host, the PostgreSQL community could be a good place for that.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, afaik pg community has never yet done official, authoritative hosting on GH and there's a strong bias toward own infra for historical reasons. I think hosting on GH is ideal for CNPG extensions, so that the build and test and distribution processes can be as close as possible to the CNCF-compliant, CNPG-hosted extensions.

We almost need an equivalent of debian nonfree or ubuntu restricted/multiverse. One you get into the extension space, Postgres needs to solve distribution-style problems.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I presume there will be no extra test coverage within CNPG repo for these extensions. So then the only convenience is the GH hosting of the images itself? With the reoccuring supply chain attacks that has happened (npm, GH), pulling any image not built by yourself / your trusted security domain should be done with care and thought anyhow. That's 2 cent

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI and integrations - GH actions, unit tests, security scans, renovate integration

are we rewriting everything for jenkins then trying to keep it all in sync as CNPG extensions repo gets additions over time?

and even with hosting - would community want to run their own container registry? many questions here

it's a lot easier to just have another GH org that's not CNCF, which functions as a popular place for non-CNCF-license-friendly postgres extensions. who knows maybe i'll set something up myself for fun

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had an AI agent check licenses for all extensions currently packaged for Debian


PostgreSQL Debian Team Extensions — CNCF License Audit

Audit of all extensions in the Debian Salsa PostgreSQL group
against the CNCF Allowed Third-Party License Policy.

Date: 2026-06-11
Method: Debian copyright files fetched from Salsa; runtime dependencies checked via apt-cache inside ghcr.io/cloudnative-pg/postgresql:18-minimal-trixie.

Officially packaged by upstream CNPG (cloudnative-pg/postgres-extensions-containers) and excluded from this audit:
pgaudit, pg-crash, pgvector, postgis, timescaledb-oss, wal2json

The following extensions were worked on by ardentperf but are not yet in upstream CNPG and are therefore included in this audit:
hll, hypopg, pg-cron, pg-hint-plan, pgnodemx, pg-partman, pg-repack, pgsentinel


✅ Clean — 69 extensions (PG18+ only)

All licenses (extension + runtime dependencies) are on the CNCF allowlist.

Extensions marked with (ardentperf) are worked on by ardentperf but not yet in upstream CNPG.

Note: Many extensions use a custom license label (e.g. "cybertec", "PLJS", "PostgreSQL-EDB") that is
word-for-word identical to the PostgreSQL License with only the copyright holder name substituted.
These are treated as equivalent to the PostgreSQL License.

Extension License Runtime dependencies
hll (ardentperf) Apache-2.0 none
hypopg (ardentperf) PostgreSQL none
pg-hint-plan (ardentperf) BSD-3-Clause (NTT) + PostgreSQL none
pgnodemx (ardentperf) PostgreSQL (Crunchy) + Apache-2.0 none
pg-partman (ardentperf) PostgreSQL python3, python3-psycopg2 (LGPL-2+ on debian/* only)
pg-repack (ardentperf) BSD-3-Clause (NTT/Reorg) none
pgsentinel (ardentperf) PostgreSQL (name-swap: PgSentinel) none
auto-failover PostgreSQL + MIT pg-auto-failover-cli (PostgreSQL + MIT)
bgw-replstatus PostgreSQL none
credcheck MIT none
db2fce PostgreSQL none
decoderbufs MIT libprotobuf-c1 (BSD-2-Clause)
dirtyread PostgreSQL none
extra-window-functions PostgreSQL none
first-last-agg PostgreSQL none
http MIT libcurl4 (MIT + OpenSSL)
icu-ext PostgreSQL (name-swap: Daniel Vérité) libicu76 (MIT)
ip4r PostgreSQL none
jsquery PostgreSQL none
mimeo PostgreSQL none
numeral PostgreSQL none
orafce BSD none
periods PostgreSQL none
pg-background PostgreSQL none
pg-catcheck PostgreSQL none
pg-csv MIT none
pg-failover-slots PostgreSQL none
pg-hint-plan BSD-3-Clause (NTT) + PostgreSQL none
pg-ivm PostgreSQL none
pg-permissions PostgreSQL (name-swap: Cybertec) none
pg-pwhash MIT libargon2-1 (CC0/Apache-2.0), libcrypt1 (LGPL-2+ — system crypto, not shipped), libscrypt-dev (BSD-2-Clause), libssl3 (OpenSSL)
pg-qualstats PostgreSQL none
pg-rewrite PostgreSQL (name-swap: Cybertec) none
pg-stat-kcache PostgreSQL + BSD none
pg-stat-log PostgreSQL none
pg-stat-plans PostgreSQL (name-swap: Duboce Labs) libzstd1 (BSD-3-Clause)
pg-statviz PostgreSQL (name-swap: Jimmy Angelakos) none
pg-track-settings PostgreSQL none
pg-wait-sampling PostgreSQL none
pgauditlogtofile PostgreSQL postgresql-18-pgaudit
pgextwlist PostgreSQL none
pgfaceting BSD-3-Clause postgresql-18-roaringbitmap
pgfincore BSD-3-Clause none
pglogical PostgreSQL none
pgnodemx PostgreSQL (Crunchy) + Apache-2.0 none
pgpcre PostgreSQL libpcre2-8-0 (BSD-3-Clause)
pgq3 ISC pgqd
pgsentinel PostgreSQL (name-swap: PgSentinel) none
pgtap PostgreSQL (name-swap: David E. Wheeler) none
pgtt ISC (Darold) none
pljs PostgreSQL (name-swap: PLJS Development Group) none
pllua MIT liblua5.3-0 (MIT)
plpgsql-check MIT none
plproxy ISC none
plsh BSD none
pointcloud BSD-3-Clause libxml2 (MIT), zlib1g (Zlib)
powa PostgreSQL none
prefix BSD none
prioritize PostgreSQL none
rational MIT none
roaringbitmap Apache-2.0 none
rum PostgreSQL none
semver PostgreSQL none
set-user PostgreSQL (name-swap: Crunchy Data) none
show-plans PostgreSQL (name-swap: Cybertec) none
similarity BSD-3-Clause none
squeeze PostgreSQL none
stat-log PostgreSQL none
tablelog PostgreSQL none
tdigest PostgreSQL none
timestamp9 MIT none
toastinfo PostgreSQL none
unit PostgreSQL none

❌ Blocked — 20 extensions

Extensions marked with (ardentperf) are worked on by ardentperf but not yet in upstream CNPG.

Extension Blocker Reason
pg-cron (ardentperf) Vixie-Cron license (src/entry.c, src/misc.c) Not on CNCF allowlist; no exception available
pldebugger Artistic-2.0 Not on CNCF allowlist
plprofiler Artistic + CDDL Neither on CNCF allowlist
pg-uuidv7 MPL-2.0 Weak copyleft; not on allowlist; no blanket exception
oracle-fdw oracle-libs → Oracle proprietary Runtime dependency not on allowlist
pgagent libboost-filesystem1.74.0 → BSL-1.0 Runtime dependency not on allowlist
pgmemcache libmemcached11 → Paul-Hsieh + RSA-Data-Security custom licenses Runtime dependency contains non-allowlist licenses
postgresql-age LGPL-2.1 Covers src/backend/utils/load/libcsv.c and src/include/utils/load/csv.h
postgresql-pgmp LGPL-3+ Main module license
mongo-fdw LGPL-3 Present alongside PostgreSQL license in source
tds-fdw libsybdb5 (FreeTDS) → LGPL-2+ Runtime dependency not on allowlist
pg-rrule libical3 → LGPL-2.1 or MPL-2.0 Runtime dependency not on allowlist
mysql-fdw libmariadb3 → LGPL-2.1 Runtime dependency not on allowlist; extension itself is clean
snakeoil libclamav12 → LGPL-2+ Runtime dependency not on allowlist
h3-pg libh3-1 → AGPL-3+ (coordijk.c, README.md) Runtime dependency not on allowlist
postgresql-q3c GPL-2+ Covers entire upstream source
plr GPL-2+ Covers entire package
pgsphere GPL-3+ Covers src/sparse.c and src/sparse.h
postgresql-debversion GPL-3+ Covers entire package
mobilitydb GPL-2+, GPL-3+, CC-BY-SA-3.0, 3D-SC-SLA-1 Multiple non-allowlist licenses in source files

Notes

  • GPL-2+ on debian/ only*: Several clean extensions have GPL-2+ on their Debian packaging
    scripts (debian/*). These scripts are never redistributed in container images and do not
    affect compliance.
  • LGPL blanket exception: As of 2026-06-11 there is no CNCF blanket exception for any LGPL
    version. Individual project-specific LGPL exceptions exist (e.g. paramiko for oscal-compass)
    but do not apply here.
  • MPL-2.0: There are project-specific MPL-2.0 exceptions for specific Go packages (Vault,
    Consul, etc.) but no general MPL-2.0 blanket exception.
  • Container image policy: The CNCF allowlist policy text refers to "third-party components"
    and "dependencies" and does not explicitly address container base images (cncf/foundation #362).
    This audit applies the same standard to runtime library dependencies shipped in the image.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[New Extension]: pg_cron

4 participants