public inbox for [email protected]
help / color / mirror / Atom feedRe: RFC: Extension Packaging & Lookup
3+ messages / 3 participants
[nested] [flat]
* Re: RFC: Extension Packaging & Lookup
@ 2024-10-29 17:40 Tristan Partin <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Tristan Partin @ 2024-10-29 17:40 UTC (permalink / raw)
To: David E. Wheeler <[email protected]>; Christoph Berg <[email protected]>; +Cc: Paul Ramsey <[email protected]>; pgsql-hackers; Gabriele Bartolini <[email protected]>; Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>
On Tue Oct 29, 2024 at 12:03 PM CDT, David E. Wheeler wrote:
> On Oct 29, 2024, at 12:51, Christoph Berg <[email protected]> wrote:
>
>> I think this is where the whole idea of "provide binaries outside of
>> deb/rpm" is just going to die. You are trying to reinvent a wheel
>> that has been running well for decades, including lots of production
>> systems. I don't know anyone who would trust that new source of
>> binaries that doesn't integrate into their OS packaging system.
>
> That’s fine for Linux, but more challenging for macOS and Windows.
> It’s also an issue that the apt and yum repositories, while having
> a lot of stuff, don’t have all extensions.
Hey David,
I haven't worked on Linux packaging in a while, so take my input with
a grain of salt. Could we make distro packaging easier for extension
developers and take some of the load off of the packaging team?
I would imagine this workflow to be implemented as:
curl -X POST https://extensions.postgresql.org/package \
-H 'Content-Type: application/json' \
-d '{
"extension": "pgvector",
"tarball": "https://path.to.source.tarball";,
"build-system": "meson",
"postgres-versions": [
14,
15,
16
],
}'
The backend would create the packages and publish them to the various
repositories. We would probably need to come up with a dependency
manifest that listed both build and runtime dependencies.
This would need some massaging, and has various caveats like require
using a well-known build system like PGXS or meson. There are probably
security implications that need to be worked through. The packaging team
could maybe have some burden lifted off their shoulders.
Is that something people would be interested in? As someone who writes
software, I largely find reaching the distribution channels is always
the hardest part.
--
Tristan Partin
Neon (https://neon.tech)
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: RFC: Extension Packaging & Lookup
@ 2024-10-29 17:47 David E. Wheeler <[email protected]>
parent: Tristan Partin <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: David E. Wheeler @ 2024-10-29 17:47 UTC (permalink / raw)
To: Tristan Partin <[email protected]>; +Cc: Christoph Berg <[email protected]>; Paul Ramsey <[email protected]>; pgsql-hackers; Gabriele Bartolini <[email protected]>; Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>
On Oct 29, 2024, at 13:40, Tristan Partin <[email protected]> wrote:
> The backend would create the packages and publish them to the various repositories. We would probably need to come up with a dependency manifest that listed both build and runtime dependencies.
>
> This would need some massaging, and has various caveats like require using a well-known build system like PGXS or meson. There are probably security implications that need to be worked through. The packaging team could maybe have some burden lifted off their shoulders.
>
> Is that something people would be interested in? As someone who writes software, I largely find reaching the distribution channels is always the hardest part.
Yes, I’m hoping to provide the infrastructure to enable a pattern like this as part of the PGXN v2 project. Some details from the Architecture doc[1].
However, I think this is a bit off-topic for this thread, where I’d like to try to account for issues to be addressed by the proposed extension directory structure and search path.
Best,
David
[1]: https://wiki.postgresql.org/wiki/PGXN_v2/Architecture#Packaging
^ permalink raw reply [nested|flat] 3+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack
@ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw)
Currently, executing REPACK (CONCURRENTLY) without a table name inside a
transaction block throws the error "REPACK CONCURRENTLY requires explicit
table name" instead of the expected transaction block error. This occurs
because ExecRepack() validates the parsed options and missing relation
before verifying the transaction state.
This behavior is inconsistent with other utility commands like VACUUM
,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start
of their execution to properly reject execution inside user transactions
before validating targets.
Add PreventInTransactionBlock to the top of ExecRepack() to enforce the
transaction block restriction early. This prevents the user from fixing
a missing table error only to immediately hit a transaction block error,
and also ensures consistency with rest of the commands.
Author: Srinath Reddy Sadipiralla <[email protected]>
---
src/backend/commands/repack.c | 26 ++++++++++++--------------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index d6e446d582d..d4c1f0e7652 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel)
MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK;
ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags;
LWLockRelease(ProcArrayLock);
+
+ /*
+ * Make sure we're not in a transaction block.
+ *
+ * The reason is that repack_setup_logical_decoding() could wait
+ * indefinitely for our XID to complete. (The deadlock detector would
+ * not recognize it because we'd be waiting for ourselves, i.e. no
+ * real lock conflict.) It would be possible to run in a transaction
+ * block if we had no XID, but this restriction is simpler for users
+ * to understand and we don't lose anything.
+ */
+ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)");
}
/*
@@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid,
* replica index OID.
*/
if (concurrent)
- {
- /*
- * Make sure we're not in a transaction block.
- *
- * The reason is that repack_setup_logical_decoding() could wait
- * indefinitely for our XID to complete. (The deadlock detector would
- * not recognize it because we'd be waiting for ourselves, i.e. no
- * real lock conflict.) It would be possible to run in a transaction
- * block if we had no XID, but this restriction is simpler for users
- * to understand and we don't lose anything.
- */
- PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)");
-
check_repack_concurrently_requirements(OldHeap, &ident_idx);
- }
/* Check for user-requested abort. */
CHECK_FOR_INTERRUPTS();
--
2.47.3
--gp2pyozrd5pweboh
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch"
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-04-03 15:23 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-10-29 17:40 Re: RFC: Extension Packaging & Lookup Tristan Partin <[email protected]>
2024-10-29 17:47 ` David E. Wheeler <[email protected]>
2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox