event-trigger.sgml.20231016.diff
text/x-patch
Filename: event-trigger.sgml.20231016.diff
Type: text/x-patch
Part: 0
Message:
event trigger sgml touch-up
Patch
Same data as JSON:
GET /api/v1/attachments/:id/patch
the parsed metadata as JSON — format, series position, per-file stats; never the diff bytes.
API reference →
Format: unified
| File | + | − |
|---|---|---|
| doc/src/sgml/event-trigger.sgml | 4 | 4 |
--- doc/src/sgml/event-trigger.sgml.orig 2023-10-16 17:16:00.017452340 +0200
+++ doc/src/sgml/event-trigger.sgml 2023-10-16 17:22:32.965450992 +0200
@@ -40,7 +40,7 @@
The <literal>login</literal> event occurs when an authenticated user logs
into the system. Any bug in a trigger procedure for this event may
prevent successful login to the system. Such bugs may be fixed by
- setting <xref linkend="guc-event-triggers"/> is set to <literal>false</literal>
+ setting <xref linkend="guc-event-triggers"/> to <literal>false</literal>
either in a connection string or configuration file. Alternative is
restarting the system in single-user mode (as event triggers are
disabled in this mode). See the <xref linkend="app-postgres"/> reference
@@ -49,8 +49,8 @@
To prevent servers from becoming inaccessible, such triggers must avoid
writing anything to the database when running on a standby.
Also, it's recommended to avoid long-running queries in
- <literal>login</literal> event triggers. Notes that, for instance,
- cancelling connection in <application>psql</application> wouldn't cancel
+ <literal>login</literal> event triggers. Note that, for instance,
+ cancelling a connection in <application>psql</application> wouldn't cancel
the in-progress <literal>login</literal> trigger.
</para>
@@ -1359,7 +1359,7 @@
END IF;
-- The checks below cannot be performed on standby servers so
--- ensure the database is not in recovery before we perform any
+-- ensure the database is not in recovery before performing any
-- operations.
SELECT pg_is_in_recovery() INTO rec;
IF rec THEN