diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml index 3be66789ba7..8cdd2997d43 100644 --- a/doc/src/sgml/libpq.sgml +++ b/doc/src/sgml/libpq.sgml @@ -378,7 +378,7 @@ PostgresPollingStatusType PQconnectPoll(PGconn *conn); At any time during connection, the status of the connection can be checked by calling . If this call returns CONNECTION_BAD, then the - connection procedure has failed; if the call returns CONNECTION_OK, then the + connection procedure has failed; if the call returns CONNECTION_OK, then the connection is ready. Both of these states are equally detectable from the return value of PQconnectPoll, described above. Other states might also occur during (and only during) an asynchronous connection procedure. These @@ -1922,7 +1922,7 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname sslkeylogfile - This parameter specifies the location where libpq + This parameter specifies the location where libpq will log keys used in this SSL context. This is useful for debugging PostgreSQL protocol interactions or client connections using network inspection tools like @@ -1956,7 +1956,7 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname Enter PEM pass phrase: prompt that OpenSSL will emit by default when an encrypted client certificate key is provided to - libpq. + libpq. If the key is not encrypted this parameter is ignored. The parameter @@ -2811,14 +2811,14 @@ ConnStatusType PQstatus(const PGconn *conn); The status can be one of a number of values. However, only two of these are seen outside of an asynchronous connection procedure: - CONNECTION_OK and - CONNECTION_BAD. A good connection to the database - has the status CONNECTION_OK. A failed + CONNECTION_OK and + CONNECTION_BAD. A good connection to the database + has the status CONNECTION_OK. A failed connection attempt is signaled by status - CONNECTION_BAD. Ordinarily, an OK status will + CONNECTION_BAD. Ordinarily, an OK status will remain so until , but a communications failure might result in the status changing to - CONNECTION_BAD prematurely. In that case the + CONNECTION_BAD prematurely. In that case the application could try to recover by calling . @@ -6628,7 +6628,7 @@ PostgresPollingStatusType PQcancelPoll(PGcancelConn *cancelConn); checked by calling . If this call returns CONNECTION_BAD, then the cancel procedure has failed; if the call returns - CONNECTION_OK, then cancel request was + CONNECTION_OK, then cancel request was successfully dispatched. Both of these states are equally detectable from the return value of PQcancelPoll, described above. @@ -6750,15 +6750,15 @@ ConnStatusType PQcancelStatus(const PGcancelConn *cancelConn); The status can be one of a number of values. However, only three of these are seen outside of an asynchronous cancel procedure: - CONNECTION_ALLOCATED, - CONNECTION_OK and - CONNECTION_BAD. The initial state of a + CONNECTION_ALLOCATED, + CONNECTION_OK and + CONNECTION_BAD. The initial state of a PGcancelConn that's successfully created using - is CONNECTION_ALLOCATED. + is CONNECTION_ALLOCATED. A cancel request that was successfully dispatched - has the status CONNECTION_OK. A failed + has the status CONNECTION_OK. A failed cancel attempt is signaled by status - CONNECTION_BAD. An OK status will + CONNECTION_BAD. An OK status will remain so until or is called. @@ -8283,7 +8283,7 @@ size_t PQresultMemorySize(const PGresult *res); - Return the version of libpq that is being used. + Return the version of libpq that is being used. int PQlibVersion(void); @@ -8534,7 +8534,7 @@ typedef struct evtInfo pointer should be cast to a PGEventRegister *. This structure contains a PGconn that should be in the - CONNECTION_OK status; guaranteed if one calls + CONNECTION_OK status; guaranteed if one calls right after obtaining a good PGconn. When returning a failure code, all cleanup must be performed as no PGEVT_CONNDESTROY diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml index 1c4ae38f1b9..3f2bcd45a1e 100644 --- a/doc/src/sgml/logicaldecoding.sgml +++ b/doc/src/sgml/logicaldecoding.sgml @@ -898,7 +898,6 @@ typedef void (*LogicalDecodeMessageCB) (struct LogicalDecodingContext *ctx, callback might also error out due to simultaneous rollback of this very same transaction. In that case, the logical decoding of this aborted transaction is stopped gracefully. - The prefix is arbitrary null-terminated prefix which can be used for identifying interesting messages for the current plugin. And finally the message parameter holds