public inbox for [email protected]
help / color / mirror / Atom feedRe: Documentation about PL transforms
4+ messages / 3 participants
[nested] [flat]
* Re: Documentation about PL transforms
@ 2022-02-08 19:03 Chapman Flack <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Chapman Flack @ 2022-02-08 19:03 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; pgsql-hackers
On 02/07/22 15:14, Chapman Flack wrote:
> It has since occurred to me that another benefit of having a
> transform_validator per PL would be immediate error reporting
> if someone, for whatever reason, tries out CREATE TRANSFORM
> for a PL that doesn't grok transforms.
The same could be achieved, I guess, by an event trigger, though that
would take positive effort to set up, where the benefit of a per-PL
transform_validator would be that if a given PL does not bother to
provide one, CREATE TRANSFORM for it would automatically fail. (And
such a validator would not have to spend most of its life ignoring
other DDL.)
That does reveal another documentation gap: table 40.1 does not show
CREATE or DROP TRANSFORM being supported for event triggers. I've
confirmed they work, though. I'll tack that onto the doc patch.
I notice our transforms lack the named groups of 9075-2. With those
(plus our LANGUAGE clause), I could write, for a made-up example:
CREATE TRANSFORM FOR hstore LANGUAGE plpython3u
asdict (
FROM SQL WITH FUNCTION hstore_to_plpython3dict,
TO SQL WITH FUNCTION plpython3dict_to_hstore)
asnamedtuple (
FROM SQL WITH FUNCTION hstore_to_plpython3namedtup,
TO SQL WITH FUNCTION plpython3namedtup_to_hstore);
CREATE FUNCTION f1(val hstore) RETURNS int
LANGUAGE plpython3u
TRANSFORM GROUP asdict FOR TYPE hstore
...
CREATE FUNCTION f2(val hstore) RETURNS int
LANGUAGE plpython3u
TRANSFORM GROUP asnamedtuple FOR TYPE hstore
...
It seems to me that could be useful, in cases where a PL offers
more than one good choice for representing a PostgreSQL type and
the preferred one could depend on the function.
Was that considered and rejected for our transforms, or were ours
just based on an earlier 9075-2 without the named groups?
Also, I am doubtful of our Compatibility note, "There is a CREATE
TRANSFORM command in the SQL standard, but it is for adapting data
types to client languages."
In my reading of 9075-2, I do see the transforms used for client
languages (all the <embedded SQL Foo program>s), but I also see
the to-sql and from-sql functions being applied in <routine invocation>
whenever "R is an external routine" and the type "is a user-defined type".
The latter doesn't seem much different from our usage. The differences
I see are (1) our LANGUAGE clause, (2) we don't have a special
"user-defined type" category limiting what types can have transforms
(and (3), we don't have the named groups). And we are applying them
/only/ for server-side routines, rather than for server and client code.
The ISO transforms work by mapping the ("user-defined") type to some
existing SQL type for which the PL has a standard mapping already. Ours
work by mapping the type directly to some suitable type in the PL.
Am I reading this accurately?
Regards,
-Chap
^ permalink raw reply [nested|flat] 4+ messages in thread
* [PATCH 04/19] doc: s/in local server/on local server/ 94c49d53402240ad7ddbcae9049ff2840a54b9c6
@ 2022-02-18 03:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Justin Pryzby @ 2022-02-18 03:08 UTC (permalink / raw)
many similar things were fixed in 410aa248e5a883fde4832999cc9b23c7ace0f2ff
---
doc/src/sgml/postgres-fdw.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/postgres-fdw.sgml b/doc/src/sgml/postgres-fdw.sgml
index d8dc7155874..92d89c0fc99 100644
--- a/doc/src/sgml/postgres-fdw.sgml
+++ b/doc/src/sgml/postgres-fdw.sgml
@@ -1040,7 +1040,7 @@ postgres=# SELECT postgres_fdw_disconnect_all();
<row>
<entry><literal>%C</literal></entry>
<entry>
- Cluster name in local server
+ Cluster name on local server
(see <xref linkend="guc-cluster-name"/> for details)
</entry>
</row>
--
2.17.1
--8X7/QrJGcKSMr1RN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0005-doc-pg_column_compression-we-say-method-not-algorith.patch"
^ permalink raw reply [nested|flat] 4+ messages in thread
* [PATCH 08/17] doc: s/in local server/on local server/ 94c49d53402240ad7ddbcae9049ff2840a54b9c6
@ 2022-02-18 03:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Justin Pryzby @ 2022-02-18 03:08 UTC (permalink / raw)
many similar things were fixed in 410aa248e5a883fde4832999cc9b23c7ace0f2ff
---
doc/src/sgml/postgres-fdw.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/postgres-fdw.sgml b/doc/src/sgml/postgres-fdw.sgml
index 88f564d7fd8..88a864eb57a 100644
--- a/doc/src/sgml/postgres-fdw.sgml
+++ b/doc/src/sgml/postgres-fdw.sgml
@@ -1040,7 +1040,7 @@ postgres=# SELECT postgres_fdw_disconnect_all();
<row>
<entry><literal>%C</literal></entry>
<entry>
- Cluster name in local server
+ Cluster name on local server
(see <xref linkend="guc-cluster-name"/> for details)
</entry>
</row>
--
2.17.1
--juZjCTNxrMaZdGZC
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0009-doc-pg_column_compression-we-say-method-not-algorith.patch"
^ permalink raw reply [nested|flat] 4+ messages in thread
* RE: WaitEventSetWaitBlock() can still hang on Windows due to connection reset
@ 2025-04-17 07:10 Hayato Kuroda (Fujitsu) <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Hayato Kuroda (Fujitsu) @ 2025-04-17 07:10 UTC (permalink / raw)
To: 'Alexander Lakhin' <[email protected]>; +Cc: pgsql-hackers; Thomas Munro <[email protected]>
Dear Alexander,
While analyzing the BF failure [1], I noticed that the same issue may happen here,
which means apply worker waited something. According to the log, apply worker (PID 2820)
stucked so that logical replication could not restart.
Regress log:
```
### Restarting node "pub"
# Running: pg_ctl --wait --pgdata C:\\prog\\bf\\root\\HEAD\\pgsql.build/...
waiting for server to shut down.... done
server stopped
waiting for server to start.... done
server started
# Postmaster PID for node "pub" is 980
timed out waiting for match: (?^:Streaming transactions committing after ([A-F0-9]+/[A-F0-9]+), ...
```
Subscriber log;
```
2025-04-12 05:08:44.630 UTC [2820:1] LOG: logical replication apply worker for subscription "sub" has started
2025-04-12 05:08:44.642 UTC [5652:6] LOG: background worker "logical replication apply worker" (PID 6344) exited with exit code 1
2025-04-12 05:13:27.352 UTC [3988:1] LOG: checkpoint starting: time
2025-04-12 05:13:36.825 UTC [3988:2] LOG: checkpoint complete: wrote 62 buffers ...
2025-04-12 05:15:01.265 UTC [5652:7] LOG: received immediate shutdown request
2025-04-12 05:15:01.353 UTC [5652:8] LOG: database system is shut down
```
Publisher log;
```
2025-04-12 05:08:44.634 UTC [1112:7] LOG: database system is shut down
2025-04-12 05:08:45.685 UTC [980:1] LOG: starting PostgreSQL 18devel on...
2025-04-12 05:08:45.687 UTC [980:2] LOG: listening on IPv4 address "127.0.0.1", port 18057
2025-04-12 05:08:46.225 UTC [4392:1] LOG: database system was shut down at 2025-04-12 05:08:43 UTC
2025-04-12 05:08:46.319 UTC [980:3] LOG: database system is ready to accept connections
2025-04-12 05:15:00.408 UTC [980:4] LOG: received immediate shutdown request
2025-04-12 05:15:00.942 UTC [980:5] LOG: database system is shut down
```
Now the report has been reported for both physical and logical replication,
but I suspected that this can happen for all the application.
[1]: https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=drongo&dt=2025-04-12%2003%3A59%3A3...
Best regards,
Hayato Kuroda
FUJITSU LIMITED
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2025-04-17 07:10 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-02-08 19:03 Re: Documentation about PL transforms Chapman Flack <[email protected]>
2022-02-18 03:08 [PATCH 08/17] doc: s/in local server/on local server/ 94c49d53402240ad7ddbcae9049ff2840a54b9c6 Justin Pryzby <[email protected]>
2022-02-18 03:08 [PATCH 04/19] doc: s/in local server/on local server/ 94c49d53402240ad7ddbcae9049ff2840a54b9c6 Justin Pryzby <[email protected]>
2025-04-17 07:10 RE: WaitEventSetWaitBlock() can still hang on Windows due to connection reset Hayato Kuroda (Fujitsu) <[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