Compare commits

...

4 Commits

Author SHA1 Message Date
Heikki Linnakangas
5c9f35fc48 Fix documentation and comments on what happens after GSS rejection
The paragraph in the docs and the comment applied to
sslnegotiaton=direct, but not sslnegotiation=requiredirect. In
'requiredirect' mode, negotiated SSL is never used. Move the paragraph
in the docs under the description of 'direct' mode, and rephrase it.

Also the comment's reference to reusing a plaintext connection was
bogus. Authentication failure in plaintext mode only happens after
sending the startup packet, so the connection cannot be reused.

Reported-by: Jacob Champion
Discussion: https://www.postgresql.org/message-id/CAOYmi+=sj+1uydS0NR4nYzw-LRWp3Q-s5speBug5UCLSPMbvGA@mail.gmail.com
2024-04-28 22:39:35 +03:00
Tom Lane
42b041243c Throw a more on-point error for functions depending on columns.
ALTER COLUMN TYPE wasn't expecting to find any pg_proc objects
depending on the column whose type is to be altered.  That indeed
wasn't possible when this code was written, but it is possible
since we introduced new-style SQL function bodies.

It's about as difficult to fix this case as it is to fix dependent
views, and we've been punting on those for years, so I don't feel
too awful about punting for functions too.  (I sure wouldn't risk
back-patching such code.)  So just throw a more user-facing error.
Also, adjust some of the existing comments to reflect that these
are all pretty much the same issue.

(This patch also fixes it so we will tolerate finding such a
dependency during ALTER COLUMN SET EXPRESSION; in that, we need
not do anything to the function, so no error is wanted.  That
problem is new in HEAD.)

Per bug #18449 from Alexander Lakhin.  Back-patch to v14 where
we added new-style SQL functions.

Discussion: https://postgr.es/m/18449-f8248467aaa294d5@postgresql.org
2024-04-28 14:34:21 -04:00
Tom Lane
4019285c06 Detect more overflows in timestamp[tz]_pl_interval.
In commit 25cd2d640 I (tgl) opined that "The additions of the months
and microseconds fields could also overflow, of course.  However,
I believe we need no additional checks there; the existing range
checks should catch such cases".  This is demonstrably wrong however
for the microseconds field, and given that discovery it seems prudent
to be paranoid about the months addition as well.

Report and patch by Joseph Koshakow.  As before, back-patch to all
supported branches.  (However, the test case doesn't work before
v15 because we didn't allow wider-than-int32 numbers in interval
literals.  A variant test could probably be built that fits within
that restriction, but it didn't seem worth the trouble.)

Discussion: https://postgr.es/m/CAAvxfHf77sRHKoEzUw9_cMYSpbpNS2C+J_+8Dq4+0oi8iKopeA@mail.gmail.com
2024-04-28 13:42:13 -04:00
David Rowley
310cd8ab38 Fix duplicated consecutive words in comments
Also, fix a comment incorrectly referencing the "streaming read API".
This was renamed to "read stream" shortly before being committed.

Discussion: https://postgr.es/m/CAApHDvq-2Zdqytm_Hf3RmVf0qg5PS9jTFAJ5QTc9xH9pwvwDTA@mail.gmail.com
2024-04-28 20:03:34 +12:00
11 changed files with 72 additions and 28 deletions

View File

@ -1803,6 +1803,15 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
process adds significant latency if the initial SSL connection process adds significant latency if the initial SSL connection
fails. fails.
</para> </para>
<para>
An exception is if <literal>gssencmode</literal> is set
to <literal>prefer</literal>, but the server rejects GSS encryption.
In that case, SSL is negotiated over the same TCP connection using
<productname>PostgreSQL</productname> protocol negotiation. In
other words, the direct SSL handshake is not used, if a TCP
connection has already been established and can be used for the
SSL handshake.
</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -1816,16 +1825,6 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
</listitem> </listitem>
</varlistentry> </varlistentry>
</variablelist> </variablelist>
<para>
Note that if <literal>gssencmode</literal> is set
to <literal>prefer</literal>, a <acronym>GSS</acronym> connection is
attempted first. If the server rejects GSS encryption, SSL is
negotiated over the same TCP connection using the traditional postgres
protocol, regardless of <literal>sslnegotiation</literal>. In other
words, the direct SSL handshake is not used, if a TCP connection has
already been established and can be used for the SSL handshake.
</para>
</listitem> </listitem>
</varlistentry> </varlistentry>

View File

@ -1122,7 +1122,7 @@ heap_beginscan(Relation relation, Snapshot snapshot,
/* /*
* Set up a read stream for sequential scans and TID range scans. This * Set up a read stream for sequential scans and TID range scans. This
* should be done after initscan() because initscan() allocates the * should be done after initscan() because initscan() allocates the
* BufferAccessStrategy object passed to the streaming read API. * BufferAccessStrategy object passed to the read stream API.
*/ */
if (scan->rs_base.rs_flags & SO_TYPE_SEQSCAN || if (scan->rs_base.rs_flags & SO_TYPE_SEQSCAN ||
scan->rs_base.rs_flags & SO_TYPE_TIDRANGESCAN) scan->rs_base.rs_flags & SO_TYPE_TIDRANGESCAN)

View File

@ -13,7 +13,7 @@
* autovacuum_work_mem) memory space to keep track of dead TIDs. If the * autovacuum_work_mem) memory space to keep track of dead TIDs. If the
* TID store is full, we must call lazy_vacuum to vacuum indexes (and to vacuum * TID store is full, we must call lazy_vacuum to vacuum indexes (and to vacuum
* the pages that we've pruned). This frees up the memory space dedicated to * the pages that we've pruned). This frees up the memory space dedicated to
* to store dead TIDs. * store dead TIDs.
* *
* In practice VACUUM will often complete its initial pass over the target * In practice VACUUM will often complete its initial pass over the target
* heap relation without ever running out of space to store TIDs. This means * heap relation without ever running out of space to store TIDs. This means

View File

@ -108,7 +108,7 @@
* (if one exists). * (if one exists).
* *
* activeSearchPath is always the actually active path; it points to * activeSearchPath is always the actually active path; it points to
* to baseSearchPath which is the list derived from namespace_search_path. * baseSearchPath which is the list derived from namespace_search_path.
* *
* If baseSearchPathValid is false, then baseSearchPath (and other derived * If baseSearchPathValid is false, then baseSearchPath (and other derived
* variables) need to be recomputed from namespace_search_path, or retrieved * variables) need to be recomputed from namespace_search_path, or retrieved

View File

@ -45,6 +45,7 @@
#include "catalog/pg_namespace.h" #include "catalog/pg_namespace.h"
#include "catalog/pg_opclass.h" #include "catalog/pg_opclass.h"
#include "catalog/pg_policy.h" #include "catalog/pg_policy.h"
#include "catalog/pg_proc.h"
#include "catalog/pg_rewrite.h" #include "catalog/pg_rewrite.h"
#include "catalog/pg_statistic_ext.h" #include "catalog/pg_statistic_ext.h"
#include "catalog/pg_tablespace.h" #include "catalog/pg_tablespace.h"
@ -14094,8 +14095,33 @@ RememberAllDependentForRebuilding(AlteredTableInfo *tab, AlterTableType subtype,
RememberConstraintForRebuilding(foundObject.objectId, tab); RememberConstraintForRebuilding(foundObject.objectId, tab);
break; break;
case ProcedureRelationId:
/*
* A new-style SQL function can depend on a column, if that
* column is referenced in the parsed function body. Ideally
* we'd automatically update the function by deparsing and
* reparsing it, but that's risky and might well fail anyhow.
* FIXME someday.
*
* This is only a problem for AT_AlterColumnType, not
* AT_SetExpression.
*/
if (subtype == AT_AlterColumnType)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot alter type of a column used by a function or procedure"),
errdetail("%s depends on column \"%s\"",
getObjectDescription(&foundObject, false),
colName)));
break;
case RewriteRelationId: case RewriteRelationId:
/* XXX someday see if we can cope with revising views */
/*
* View/rule bodies have pretty much the same issues as
* function bodies. FIXME someday.
*/
if (subtype == AT_AlterColumnType) if (subtype == AT_AlterColumnType)
ereport(ERROR, ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED), (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
@ -14112,9 +14138,9 @@ RememberAllDependentForRebuilding(AlteredTableInfo *tab, AlterTableType subtype,
* specified as an update target, or because the column is * specified as an update target, or because the column is
* used in the trigger's WHEN condition. The first case would * used in the trigger's WHEN condition. The first case would
* not require any extra work, but the second case would * not require any extra work, but the second case would
* require updating the WHEN expression, which will take a * require updating the WHEN expression, which has the same
* significant amount of new code. Since we can't easily tell * issues as above. Since we can't easily tell which case
* which case applies, we punt for both. FIXME someday. * applies, we punt for both. FIXME someday.
*/ */
if (subtype == AT_AlterColumnType) if (subtype == AT_AlterColumnType)
ereport(ERROR, ereport(ERROR,

View File

@ -599,7 +599,7 @@ update_and_persist_local_synced_slot(RemoteSlot *remote_slot, Oid remote_dbid)
* metadata of the slot as per the data received from the primary server. * metadata of the slot as per the data received from the primary server.
* *
* The slot is created as a temporary slot and stays in the same state until the * The slot is created as a temporary slot and stays in the same state until the
* the remote_slot catches up with locally reserved position and local slot is * remote_slot catches up with locally reserved position and local slot is
* updated. The slot is then persisted and is considered as sync-ready for * updated. The slot is then persisted and is considered as sync-ready for
* periodic syncs. * periodic syncs.
* *

View File

@ -244,7 +244,7 @@ smgropen(RelFileLocator rlocator, ProcNumber backend)
/* /*
* smgrpin() -- Prevent an SMgrRelation object from being destroyed at end of * smgrpin() -- Prevent an SMgrRelation object from being destroyed at end of
* of transaction * transaction
*/ */
void void
smgrpin(SMgrRelation reln) smgrpin(SMgrRelation reln)

View File

@ -3091,7 +3091,10 @@ timestamp_pl_interval(PG_FUNCTION_ARGS)
(errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE), (errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
errmsg("timestamp out of range"))); errmsg("timestamp out of range")));
tm->tm_mon += span->month; if (pg_add_s32_overflow(tm->tm_mon, span->month, &tm->tm_mon))
ereport(ERROR,
(errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
errmsg("timestamp out of range")));
if (tm->tm_mon > MONTHS_PER_YEAR) if (tm->tm_mon > MONTHS_PER_YEAR)
{ {
tm->tm_year += (tm->tm_mon - 1) / MONTHS_PER_YEAR; tm->tm_year += (tm->tm_mon - 1) / MONTHS_PER_YEAR;
@ -3143,7 +3146,10 @@ timestamp_pl_interval(PG_FUNCTION_ARGS)
errmsg("timestamp out of range"))); errmsg("timestamp out of range")));
} }
timestamp += span->time; if (pg_add_s64_overflow(timestamp, span->time, &timestamp))
ereport(ERROR,
(errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
errmsg("timestamp out of range")));
if (!IS_VALID_TIMESTAMP(timestamp)) if (!IS_VALID_TIMESTAMP(timestamp))
ereport(ERROR, ereport(ERROR,
@ -3233,7 +3239,10 @@ timestamptz_pl_interval_internal(TimestampTz timestamp,
(errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE), (errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
errmsg("timestamp out of range"))); errmsg("timestamp out of range")));
tm->tm_mon += span->month; if (pg_add_s32_overflow(tm->tm_mon, span->month, &tm->tm_mon))
ereport(ERROR,
(errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
errmsg("timestamp out of range")));
if (tm->tm_mon > MONTHS_PER_YEAR) if (tm->tm_mon > MONTHS_PER_YEAR)
{ {
tm->tm_year += (tm->tm_mon - 1) / MONTHS_PER_YEAR; tm->tm_year += (tm->tm_mon - 1) / MONTHS_PER_YEAR;
@ -3292,7 +3301,10 @@ timestamptz_pl_interval_internal(TimestampTz timestamp,
errmsg("timestamp out of range"))); errmsg("timestamp out of range")));
} }
timestamp += span->time; if (pg_add_s64_overflow(timestamp, span->time, &timestamp))
ereport(ERROR,
(errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
errmsg("timestamp out of range")));
if (!IS_VALID_TIMESTAMP(timestamp)) if (!IS_VALID_TIMESTAMP(timestamp))
ereport(ERROR, ereport(ERROR,

View File

@ -4430,11 +4430,12 @@ select_next_encryption_method(PGconn *conn, bool have_valid_connection)
/* /*
* If enabled, try direct SSL. Unless we have a valid TCP connection that * If enabled, try direct SSL. Unless we have a valid TCP connection that
* failed negotiating GSSAPI encryption or a plaintext connection in case * failed negotiating GSSAPI encryption; in that case we prefer to reuse
* of sslmode='allow'; in that case we prefer to reuse the connection with * the connection with negotiated SSL, instead of reconnecting to do
* negotiated SSL, instead of reconnecting to do direct SSL. The point of * direct SSL. The point of sslnegotiation=direct is to avoid the
* direct SSL is to avoid the roundtrip from the negotiation, but * roundtrip from the negotiation, but reconnecting would also incur a
* reconnecting would also incur a roundtrip. * roundtrip. (In sslnegotiation=requiredirect mode, negotiated SSL is not
* in the list of allowed methods and we will reconnect.)
*/ */
if (have_valid_connection) if (have_valid_connection)
SELECT_NEXT_METHOD(ENC_NEGOTIATED_SSL); SELECT_NEXT_METHOD(ENC_NEGOTIATED_SSL);

View File

@ -484,6 +484,8 @@ SELECT timestamp without time zone 'Jan 1, 4713 BC' + interval '109203489 days'
SELECT timestamp without time zone '2000-01-01' - interval '2483590 days' AS "out of range"; SELECT timestamp without time zone '2000-01-01' - interval '2483590 days' AS "out of range";
ERROR: timestamp out of range ERROR: timestamp out of range
SELECT timestamp without time zone '294276-12-31 23:59:59' + interval '9223372036854775807 microseconds' AS "out of range";
ERROR: timestamp out of range
SELECT timestamp without time zone '12/31/294276' - timestamp without time zone '12/23/1999' AS "106751991 Days"; SELECT timestamp without time zone '12/31/294276' - timestamp without time zone '12/23/1999' AS "106751991 Days";
106751991 Days 106751991 Days
------------------ ------------------
@ -746,6 +748,8 @@ SELECT timestamp with time zone '1999-12-01' + interval '1 month - 1 second' AS
SELECT timestamp with time zone '2000-01-01' - interval '2483590 days' AS "out of range"; SELECT timestamp with time zone '2000-01-01' - interval '2483590 days' AS "out of range";
ERROR: timestamp out of range ERROR: timestamp out of range
SELECT timestamp with time zone '294276-12-31 23:59:59 UTC' + interval '9223372036854775807 microseconds' AS "out of range";
ERROR: timestamp out of range
SELECT (timestamp with time zone 'today' = (timestamp with time zone 'yesterday' + interval '1 day')) as "True"; SELECT (timestamp with time zone 'today' = (timestamp with time zone 'yesterday' + interval '1 day')) as "True";
True True
------ ------

View File

@ -121,6 +121,7 @@ SELECT timestamp without time zone 'Jan 1, 4713 BC' + interval '106000000 days'
SELECT timestamp without time zone 'Jan 1, 4713 BC' + interval '107000000 days' AS "Jan 20, 288244"; SELECT timestamp without time zone 'Jan 1, 4713 BC' + interval '107000000 days' AS "Jan 20, 288244";
SELECT timestamp without time zone 'Jan 1, 4713 BC' + interval '109203489 days' AS "Dec 31, 294276"; SELECT timestamp without time zone 'Jan 1, 4713 BC' + interval '109203489 days' AS "Dec 31, 294276";
SELECT timestamp without time zone '2000-01-01' - interval '2483590 days' AS "out of range"; SELECT timestamp without time zone '2000-01-01' - interval '2483590 days' AS "out of range";
SELECT timestamp without time zone '294276-12-31 23:59:59' + interval '9223372036854775807 microseconds' AS "out of range";
SELECT timestamp without time zone '12/31/294276' - timestamp without time zone '12/23/1999' AS "106751991 Days"; SELECT timestamp without time zone '12/31/294276' - timestamp without time zone '12/23/1999' AS "106751991 Days";
-- Shorthand values -- Shorthand values
@ -153,6 +154,7 @@ SELECT timestamp with time zone '1999-03-01' - interval '1 second' AS "Feb 28";
SELECT timestamp with time zone '2000-03-01' - interval '1 second' AS "Feb 29"; SELECT timestamp with time zone '2000-03-01' - interval '1 second' AS "Feb 29";
SELECT timestamp with time zone '1999-12-01' + interval '1 month - 1 second' AS "Dec 31"; SELECT timestamp with time zone '1999-12-01' + interval '1 month - 1 second' AS "Dec 31";
SELECT timestamp with time zone '2000-01-01' - interval '2483590 days' AS "out of range"; SELECT timestamp with time zone '2000-01-01' - interval '2483590 days' AS "out of range";
SELECT timestamp with time zone '294276-12-31 23:59:59 UTC' + interval '9223372036854775807 microseconds' AS "out of range";
SELECT (timestamp with time zone 'today' = (timestamp with time zone 'yesterday' + interval '1 day')) as "True"; SELECT (timestamp with time zone 'today' = (timestamp with time zone 'yesterday' + interval '1 day')) as "True";
SELECT (timestamp with time zone 'today' = (timestamp with time zone 'tomorrow' - interval '1 day')) as "True"; SELECT (timestamp with time zone 'today' = (timestamp with time zone 'tomorrow' - interval '1 day')) as "True";