2000-02-15 21:49:31 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* variable.c
|
2002-05-17 03:19:19 +02:00
|
|
|
* Routines for handling specialized SET variables.
|
|
|
|
*
|
2000-02-15 21:49:31 +01:00
|
|
|
*
|
2019-01-02 18:44:25 +01:00
|
|
|
* Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
|
2000-02-15 21:49:31 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
1997-04-17 15:50:57 +02:00
|
|
|
*
|
2000-02-15 21:49:31 +01:00
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/commands/variable.c
|
1997-04-17 15:50:57 +02:00
|
|
|
*
|
2000-02-15 21:49:31 +01:00
|
|
|
*-------------------------------------------------------------------------
|
1997-04-17 15:50:57 +02:00
|
|
|
*/
|
|
|
|
|
2000-10-25 21:44:44 +02:00
|
|
|
#include "postgres.h"
|
|
|
|
|
1997-06-20 19:17:03 +02:00
|
|
|
#include <ctype.h>
|
1999-07-16 07:00:38 +02:00
|
|
|
|
2012-08-30 22:15:44 +02:00
|
|
|
#include "access/htup_details.h"
|
2015-10-16 17:37:19 +02:00
|
|
|
#include "access/parallel.h"
|
1999-07-16 07:00:38 +02:00
|
|
|
#include "access/xact.h"
|
2014-11-06 12:52:08 +01:00
|
|
|
#include "access/xlog.h"
|
2005-06-28 07:09:14 +02:00
|
|
|
#include "catalog/pg_authid.h"
|
1998-01-05 19:43:18 +01:00
|
|
|
#include "commands/variable.h"
|
2019-11-12 04:00:16 +01:00
|
|
|
#include "mb/pg_wchar.h"
|
1999-07-16 07:00:38 +02:00
|
|
|
#include "miscadmin.h"
|
2005-07-26 00:12:34 +02:00
|
|
|
#include "utils/acl.h"
|
1999-07-16 07:00:38 +02:00
|
|
|
#include "utils/builtins.h"
|
2008-03-26 19:48:59 +01:00
|
|
|
#include "utils/snapmgr.h"
|
2019-11-12 04:00:16 +01:00
|
|
|
#include "utils/syscache.h"
|
2011-09-09 19:23:41 +02:00
|
|
|
#include "utils/timestamp.h"
|
2017-01-21 02:29:53 +01:00
|
|
|
#include "utils/varlena.h"
|
2000-02-15 21:49:31 +01:00
|
|
|
|
1998-10-14 07:10:12 +02:00
|
|
|
/*
|
2002-05-17 03:19:19 +02:00
|
|
|
* DATESTYLE
|
1998-10-14 07:10:12 +02:00
|
|
|
*/
|
1997-04-24 17:41:37 +02:00
|
|
|
|
1998-10-14 07:10:12 +02:00
|
|
|
/*
|
2011-04-07 06:11:01 +02:00
|
|
|
* check_datestyle: GUC check_hook for datestyle
|
1998-10-14 07:10:12 +02:00
|
|
|
*/
|
2011-04-07 06:11:01 +02:00
|
|
|
bool
|
|
|
|
check_datestyle(char **newval, void **extra, GucSource source)
|
1997-06-02 13:00:57 +02:00
|
|
|
{
|
2002-05-17 03:19:19 +02:00
|
|
|
int newDateStyle = DateStyle;
|
2003-07-29 02:03:19 +02:00
|
|
|
int newDateOrder = DateOrder;
|
2005-06-09 23:52:07 +02:00
|
|
|
bool have_style = false;
|
|
|
|
bool have_order = false;
|
2002-05-17 03:19:19 +02:00
|
|
|
bool ok = true;
|
|
|
|
char *rawstring;
|
2011-04-07 06:11:01 +02:00
|
|
|
int *myextra;
|
2002-05-17 03:19:19 +02:00
|
|
|
char *result;
|
|
|
|
List *elemlist;
|
2004-05-26 06:41:50 +02:00
|
|
|
ListCell *l;
|
1997-06-20 19:17:03 +02:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
/* Need a modifiable copy of string */
|
2011-04-07 06:11:01 +02:00
|
|
|
rawstring = pstrdup(*newval);
|
1997-11-07 07:43:16 +01:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
/* Parse string into list of identifiers */
|
|
|
|
if (!SplitIdentifierString(rawstring, ',', &elemlist))
|
1997-06-02 13:00:57 +02:00
|
|
|
{
|
2002-05-17 03:19:19 +02:00
|
|
|
/* syntax error in list */
|
2011-04-07 06:11:01 +02:00
|
|
|
GUC_check_errdetail("List syntax is invalid.");
|
2002-05-17 03:19:19 +02:00
|
|
|
pfree(rawstring);
|
2004-05-26 06:41:50 +02:00
|
|
|
list_free(elemlist);
|
2011-04-07 06:11:01 +02:00
|
|
|
return false;
|
2002-05-17 03:19:19 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
foreach(l, elemlist)
|
|
|
|
{
|
|
|
|
char *tok = (char *) lfirst(l);
|
|
|
|
|
1997-04-17 15:50:57 +02:00
|
|
|
/* Ugh. Somebody ought to write a table driven version -- mjl */
|
1997-06-20 19:17:03 +02:00
|
|
|
|
2004-05-07 02:24:59 +02:00
|
|
|
if (pg_strcasecmp(tok, "ISO") == 0)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2005-06-09 23:52:07 +02:00
|
|
|
if (have_style && newDateStyle != USE_ISO_DATES)
|
|
|
|
ok = false; /* conflicting styles */
|
2002-05-17 03:19:19 +02:00
|
|
|
newDateStyle = USE_ISO_DATES;
|
2005-06-09 23:52:07 +02:00
|
|
|
have_style = true;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2004-05-07 02:24:59 +02:00
|
|
|
else if (pg_strcasecmp(tok, "SQL") == 0)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2005-06-09 23:52:07 +02:00
|
|
|
if (have_style && newDateStyle != USE_SQL_DATES)
|
|
|
|
ok = false; /* conflicting styles */
|
2002-05-17 03:19:19 +02:00
|
|
|
newDateStyle = USE_SQL_DATES;
|
2005-06-09 23:52:07 +02:00
|
|
|
have_style = true;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2004-05-07 02:24:59 +02:00
|
|
|
else if (pg_strncasecmp(tok, "POSTGRES", 8) == 0)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2005-06-09 23:52:07 +02:00
|
|
|
if (have_style && newDateStyle != USE_POSTGRES_DATES)
|
|
|
|
ok = false; /* conflicting styles */
|
2002-05-17 03:19:19 +02:00
|
|
|
newDateStyle = USE_POSTGRES_DATES;
|
2005-06-09 23:52:07 +02:00
|
|
|
have_style = true;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2004-05-07 02:24:59 +02:00
|
|
|
else if (pg_strcasecmp(tok, "GERMAN") == 0)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2005-06-09 23:52:07 +02:00
|
|
|
if (have_style && newDateStyle != USE_GERMAN_DATES)
|
|
|
|
ok = false; /* conflicting styles */
|
2002-05-17 03:19:19 +02:00
|
|
|
newDateStyle = USE_GERMAN_DATES;
|
2005-06-09 23:52:07 +02:00
|
|
|
have_style = true;
|
2003-07-29 02:03:19 +02:00
|
|
|
/* GERMAN also sets DMY, unless explicitly overridden */
|
2005-06-09 23:52:07 +02:00
|
|
|
if (!have_order)
|
2003-07-29 02:03:19 +02:00
|
|
|
newDateOrder = DATEORDER_DMY;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2004-05-07 02:24:59 +02:00
|
|
|
else if (pg_strcasecmp(tok, "YMD") == 0)
|
1997-12-05 00:17:13 +01:00
|
|
|
{
|
2005-06-09 23:52:07 +02:00
|
|
|
if (have_order && newDateOrder != DATEORDER_YMD)
|
|
|
|
ok = false; /* conflicting orders */
|
2003-07-29 02:03:19 +02:00
|
|
|
newDateOrder = DATEORDER_YMD;
|
2005-06-09 23:52:07 +02:00
|
|
|
have_order = true;
|
1997-12-05 00:17:13 +01:00
|
|
|
}
|
2004-05-07 02:24:59 +02:00
|
|
|
else if (pg_strcasecmp(tok, "DMY") == 0 ||
|
|
|
|
pg_strncasecmp(tok, "EURO", 4) == 0)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2005-06-09 23:52:07 +02:00
|
|
|
if (have_order && newDateOrder != DATEORDER_DMY)
|
|
|
|
ok = false; /* conflicting orders */
|
2003-07-29 02:03:19 +02:00
|
|
|
newDateOrder = DATEORDER_DMY;
|
2005-06-09 23:52:07 +02:00
|
|
|
have_order = true;
|
2003-07-29 02:03:19 +02:00
|
|
|
}
|
2004-05-07 02:24:59 +02:00
|
|
|
else if (pg_strcasecmp(tok, "MDY") == 0 ||
|
|
|
|
pg_strcasecmp(tok, "US") == 0 ||
|
|
|
|
pg_strncasecmp(tok, "NONEURO", 7) == 0)
|
2003-07-29 02:03:19 +02:00
|
|
|
{
|
2005-06-09 23:52:07 +02:00
|
|
|
if (have_order && newDateOrder != DATEORDER_MDY)
|
|
|
|
ok = false; /* conflicting orders */
|
2003-07-29 02:03:19 +02:00
|
|
|
newDateOrder = DATEORDER_MDY;
|
2005-06-09 23:52:07 +02:00
|
|
|
have_order = true;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2004-05-07 02:24:59 +02:00
|
|
|
else if (pg_strcasecmp(tok, "DEFAULT") == 0)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2002-05-17 03:19:19 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Easiest way to get the current DEFAULT state is to fetch the
|
|
|
|
* DEFAULT string from guc.c and recursively parse it.
|
2002-05-17 03:19:19 +02:00
|
|
|
*
|
2011-04-07 06:11:01 +02:00
|
|
|
* We can't simply "return check_datestyle(...)" because we need
|
2005-11-22 19:17:34 +01:00
|
|
|
* to handle constructs like "DEFAULT, ISO".
|
2002-05-17 03:19:19 +02:00
|
|
|
*/
|
2011-04-10 17:42:00 +02:00
|
|
|
char *subval;
|
|
|
|
void *subextra = NULL;
|
2002-05-17 03:19:19 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
subval = strdup(GetConfigOptionResetString("datestyle"));
|
2002-05-17 03:19:19 +02:00
|
|
|
if (!subval)
|
|
|
|
{
|
|
|
|
ok = false;
|
|
|
|
break;
|
|
|
|
}
|
2011-04-07 06:11:01 +02:00
|
|
|
if (!check_datestyle(&subval, &subextra, source))
|
|
|
|
{
|
|
|
|
free(subval);
|
|
|
|
ok = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
myextra = (int *) subextra;
|
|
|
|
if (!have_style)
|
|
|
|
newDateStyle = myextra[0];
|
|
|
|
if (!have_order)
|
|
|
|
newDateOrder = myextra[1];
|
|
|
|
free(subval);
|
|
|
|
free(subextra);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
1997-04-17 15:50:57 +02:00
|
|
|
else
|
2002-05-17 03:19:19 +02:00
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
GUC_check_errdetail("Unrecognized key word: \"%s\".", tok);
|
|
|
|
pfree(rawstring);
|
|
|
|
list_free(elemlist);
|
|
|
|
return false;
|
2002-05-17 03:19:19 +02:00
|
|
|
}
|
1997-06-02 13:00:57 +02:00
|
|
|
}
|
1997-06-20 19:17:03 +02:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
pfree(rawstring);
|
2004-05-26 06:41:50 +02:00
|
|
|
list_free(elemlist);
|
2001-10-18 19:30:21 +02:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
if (!ok)
|
2002-04-21 21:12:46 +02:00
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
GUC_check_errdetail("Conflicting \"datestyle\" specifications.");
|
|
|
|
return false;
|
2002-05-17 03:19:19 +02:00
|
|
|
}
|
2002-04-21 21:12:46 +02:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Prepare the canonical string to return. GUC wants it malloc'd.
|
2002-05-17 03:19:19 +02:00
|
|
|
*/
|
|
|
|
result = (char *) malloc(32);
|
|
|
|
if (!result)
|
2011-04-07 06:11:01 +02:00
|
|
|
return false;
|
2002-04-21 21:12:46 +02:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
switch (newDateStyle)
|
|
|
|
{
|
|
|
|
case USE_ISO_DATES:
|
|
|
|
strcpy(result, "ISO");
|
|
|
|
break;
|
|
|
|
case USE_SQL_DATES:
|
|
|
|
strcpy(result, "SQL");
|
|
|
|
break;
|
|
|
|
case USE_GERMAN_DATES:
|
2003-07-15 21:19:56 +02:00
|
|
|
strcpy(result, "German");
|
2002-05-17 03:19:19 +02:00
|
|
|
break;
|
|
|
|
default:
|
2003-07-15 21:19:56 +02:00
|
|
|
strcpy(result, "Postgres");
|
2002-05-17 03:19:19 +02:00
|
|
|
break;
|
2002-04-21 21:12:46 +02:00
|
|
|
}
|
2003-07-29 02:03:19 +02:00
|
|
|
switch (newDateOrder)
|
|
|
|
{
|
|
|
|
case DATEORDER_YMD:
|
|
|
|
strcat(result, ", YMD");
|
|
|
|
break;
|
|
|
|
case DATEORDER_DMY:
|
|
|
|
strcat(result, ", DMY");
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
strcat(result, ", MDY");
|
|
|
|
break;
|
|
|
|
}
|
2002-05-17 03:19:19 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
free(*newval);
|
|
|
|
*newval = result;
|
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
/*
|
2011-04-07 06:11:01 +02:00
|
|
|
* Set up the "extra" struct actually used by assign_datestyle.
|
2002-05-17 03:19:19 +02:00
|
|
|
*/
|
2011-04-07 06:11:01 +02:00
|
|
|
myextra = (int *) malloc(2 * sizeof(int));
|
|
|
|
if (!myextra)
|
|
|
|
return false;
|
|
|
|
myextra[0] = newDateStyle;
|
|
|
|
myextra[1] = newDateOrder;
|
|
|
|
*extra = (void *) myextra;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* assign_datestyle: GUC assign_hook for datestyle
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
assign_datestyle(const char *newval, void *extra)
|
|
|
|
{
|
|
|
|
int *myextra = (int *) extra;
|
2001-10-18 19:30:21 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
DateStyle = myextra[0];
|
|
|
|
DateOrder = myextra[1];
|
2001-10-18 19:30:21 +02:00
|
|
|
}
|
|
|
|
|
2000-02-19 23:10:47 +01:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
/*
|
|
|
|
* TIMEZONE
|
1997-11-10 16:24:56 +01:00
|
|
|
*/
|
|
|
|
|
1998-10-14 07:10:12 +02:00
|
|
|
/*
|
2011-04-07 06:11:01 +02:00
|
|
|
* check_timezone: GUC check_hook for timezone
|
1997-11-10 16:37:15 +01:00
|
|
|
*/
|
2011-04-07 06:11:01 +02:00
|
|
|
bool
|
|
|
|
check_timezone(char **newval, void **extra, GucSource source)
|
1997-10-30 17:52:11 +01:00
|
|
|
{
|
2013-11-01 18:57:31 +01:00
|
|
|
pg_tz *new_tz;
|
|
|
|
long gmtoffset;
|
2002-05-17 03:19:19 +02:00
|
|
|
char *endptr;
|
|
|
|
double hours;
|
1997-10-30 17:52:11 +01:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
if (pg_strncasecmp(*newval, "interval", 8) == 0)
|
1997-10-30 17:52:11 +01:00
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Support INTERVAL 'foo'. This is for SQL spec compliance, not
|
2011-04-07 06:11:01 +02:00
|
|
|
* because it has any actual real-world usefulness.
|
|
|
|
*/
|
|
|
|
const char *valueptr = *newval;
|
2002-05-17 03:19:19 +02:00
|
|
|
char *val;
|
|
|
|
Interval *interval;
|
|
|
|
|
|
|
|
valueptr += 8;
|
|
|
|
while (isspace((unsigned char) *valueptr))
|
|
|
|
valueptr++;
|
|
|
|
if (*valueptr++ != '\'')
|
2011-04-07 06:11:01 +02:00
|
|
|
return false;
|
2002-05-17 03:19:19 +02:00
|
|
|
val = pstrdup(valueptr);
|
|
|
|
/* Check and remove trailing quote */
|
|
|
|
endptr = strchr(val, '\'');
|
|
|
|
if (!endptr || endptr[1] != '\0')
|
2001-10-18 19:30:21 +02:00
|
|
|
{
|
2002-05-17 03:19:19 +02:00
|
|
|
pfree(val);
|
2011-04-07 06:11:01 +02:00
|
|
|
return false;
|
2002-05-17 03:19:19 +02:00
|
|
|
}
|
|
|
|
*endptr = '\0';
|
2002-09-04 22:31:48 +02:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
/*
|
|
|
|
* Try to parse it. XXX an invalid interval format will result in
|
2014-05-06 18:12:18 +02:00
|
|
|
* ereport(ERROR), which is not desirable for GUC. We did what we
|
2007-12-28 01:23:23 +01:00
|
|
|
* could to guard against this in flatten_set_variable_args, but a
|
|
|
|
* string coming in from postgresql.conf might contain anything.
|
2002-05-17 03:19:19 +02:00
|
|
|
*/
|
|
|
|
interval = DatumGetIntervalP(DirectFunctionCall3(interval_in,
|
2005-10-15 04:49:52 +02:00
|
|
|
CStringGetDatum(val),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
ObjectIdGetDatum(InvalidOid),
|
2005-10-15 04:49:52 +02:00
|
|
|
Int32GetDatum(-1)));
|
2004-08-30 04:54:42 +02:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
pfree(val);
|
|
|
|
if (interval->month != 0)
|
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
GUC_check_errdetail("Cannot specify months in time zone interval.");
|
2002-05-17 03:19:19 +02:00
|
|
|
pfree(interval);
|
2011-04-07 06:11:01 +02:00
|
|
|
return false;
|
2002-05-17 03:19:19 +02:00
|
|
|
}
|
2005-07-20 18:42:32 +02:00
|
|
|
if (interval->day != 0)
|
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
GUC_check_errdetail("Cannot specify days in time zone interval.");
|
2005-07-20 18:42:32 +02:00
|
|
|
pfree(interval);
|
2011-04-07 06:11:01 +02:00
|
|
|
return false;
|
2005-07-20 18:42:32 +02:00
|
|
|
}
|
2011-04-07 06:11:01 +02:00
|
|
|
|
|
|
|
/* Here we change from SQL to Unix sign convention */
|
2013-11-01 18:57:31 +01:00
|
|
|
gmtoffset = -(interval->time / USECS_PER_SEC);
|
|
|
|
new_tz = pg_tzset_offset(gmtoffset);
|
2004-08-30 04:54:42 +02:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
pfree(interval);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Try it as a numeric number of hours (possibly fractional).
|
|
|
|
*/
|
2011-04-07 06:11:01 +02:00
|
|
|
hours = strtod(*newval, &endptr);
|
|
|
|
if (endptr != *newval && *endptr == '\0')
|
2002-05-17 03:19:19 +02:00
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
/* Here we change from SQL to Unix sign convention */
|
2013-11-01 18:57:31 +01:00
|
|
|
gmtoffset = -hours * SECS_PER_HOUR;
|
|
|
|
new_tz = pg_tzset_offset(gmtoffset);
|
2001-10-18 19:30:21 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2002-05-17 03:19:19 +02:00
|
|
|
/*
|
2005-04-19 05:13:59 +02:00
|
|
|
* Otherwise assume it is a timezone name, and try to load it.
|
2002-05-17 03:19:19 +02:00
|
|
|
*/
|
2011-04-07 06:11:01 +02:00
|
|
|
new_tz = pg_tzset(*newval);
|
2003-05-18 03:06:26 +02:00
|
|
|
|
2005-04-19 05:13:59 +02:00
|
|
|
if (!new_tz)
|
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
/* Doesn't seem to be any great value in errdetail here */
|
|
|
|
return false;
|
2005-04-19 05:13:59 +02:00
|
|
|
}
|
2003-05-18 03:06:26 +02:00
|
|
|
|
2011-09-09 23:59:11 +02:00
|
|
|
if (!pg_tz_acceptable(new_tz))
|
2001-10-18 19:30:21 +02:00
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
GUC_check_errmsg("time zone \"%s\" appears to use leap seconds",
|
|
|
|
*newval);
|
|
|
|
GUC_check_errdetail("PostgreSQL does not support leap seconds.");
|
|
|
|
return false;
|
2001-10-18 19:30:21 +02:00
|
|
|
}
|
|
|
|
}
|
1997-10-30 17:52:11 +01:00
|
|
|
}
|
|
|
|
|
2014-07-22 04:41:20 +02:00
|
|
|
/* Test for failure in pg_tzset_offset, which we assume is out-of-range */
|
|
|
|
if (!new_tz)
|
|
|
|
{
|
|
|
|
GUC_check_errdetail("UTC timezone offset is out of range.");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
/*
|
|
|
|
* Pass back data for assign_timezone to use
|
|
|
|
*/
|
2013-11-01 18:57:31 +01:00
|
|
|
*extra = malloc(sizeof(pg_tz *));
|
2011-04-07 06:11:01 +02:00
|
|
|
if (!*extra)
|
|
|
|
return false;
|
2013-11-01 18:57:31 +01:00
|
|
|
*((pg_tz **) *extra) = new_tz;
|
2011-04-07 06:11:01 +02:00
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* assign_timezone: GUC assign_hook for timezone
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
assign_timezone(const char *newval, void *extra)
|
|
|
|
{
|
2013-11-01 18:57:31 +01:00
|
|
|
session_timezone = *((pg_tz **) extra);
|
2002-05-17 03:19:19 +02:00
|
|
|
}
|
1997-10-30 17:52:11 +01:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
/*
|
|
|
|
* show_timezone: GUC show_hook for timezone
|
|
|
|
*/
|
|
|
|
const char *
|
2000-10-25 21:44:44 +02:00
|
|
|
show_timezone(void)
|
1997-10-30 17:52:11 +01:00
|
|
|
{
|
2004-08-29 07:07:03 +02:00
|
|
|
const char *tzn;
|
2001-10-18 19:30:21 +02:00
|
|
|
|
2013-11-01 18:57:31 +01:00
|
|
|
/* Always show the zone's canonical name */
|
|
|
|
tzn = pg_get_timezone_name(session_timezone);
|
2007-08-04 03:26:54 +02:00
|
|
|
|
|
|
|
if (tzn != NULL)
|
|
|
|
return tzn;
|
|
|
|
|
|
|
|
return "unknown";
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* LOG_TIMEZONE
|
|
|
|
*
|
|
|
|
* For log_timezone, we don't support the interval-based methods of setting a
|
|
|
|
* zone, which are only there for SQL spec compliance not because they're
|
|
|
|
* actually useful.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
2011-04-07 06:11:01 +02:00
|
|
|
* check_log_timezone: GUC check_hook for log_timezone
|
2007-08-04 03:26:54 +02:00
|
|
|
*/
|
2011-04-07 06:11:01 +02:00
|
|
|
bool
|
|
|
|
check_log_timezone(char **newval, void **extra, GucSource source)
|
2007-08-04 03:26:54 +02:00
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
pg_tz *new_tz;
|
2007-08-04 03:26:54 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
/*
|
2011-09-09 23:59:11 +02:00
|
|
|
* Assume it is a timezone name, and try to load it.
|
2011-04-07 06:11:01 +02:00
|
|
|
*/
|
|
|
|
new_tz = pg_tzset(*newval);
|
2007-08-04 03:26:54 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
if (!new_tz)
|
|
|
|
{
|
|
|
|
/* Doesn't seem to be any great value in errdetail here */
|
|
|
|
return false;
|
|
|
|
}
|
2007-08-04 03:26:54 +02:00
|
|
|
|
2011-09-09 23:59:11 +02:00
|
|
|
if (!pg_tz_acceptable(new_tz))
|
2011-04-07 06:11:01 +02:00
|
|
|
{
|
|
|
|
GUC_check_errmsg("time zone \"%s\" appears to use leap seconds",
|
|
|
|
*newval);
|
|
|
|
GUC_check_errdetail("PostgreSQL does not support leap seconds.");
|
|
|
|
return false;
|
2007-08-04 03:26:54 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2011-04-07 06:11:01 +02:00
|
|
|
* Pass back data for assign_log_timezone to use
|
2007-08-04 03:26:54 +02:00
|
|
|
*/
|
2011-04-07 06:11:01 +02:00
|
|
|
*extra = malloc(sizeof(pg_tz *));
|
|
|
|
if (!*extra)
|
|
|
|
return false;
|
2013-11-01 18:57:31 +01:00
|
|
|
*((pg_tz **) *extra) = new_tz;
|
2007-08-04 03:26:54 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* assign_log_timezone: GUC assign_hook for log_timezone
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
assign_log_timezone(const char *newval, void *extra)
|
|
|
|
{
|
|
|
|
log_timezone = *((pg_tz **) extra);
|
2007-08-04 03:26:54 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* show_log_timezone: GUC show_hook for log_timezone
|
|
|
|
*/
|
|
|
|
const char *
|
|
|
|
show_log_timezone(void)
|
|
|
|
{
|
|
|
|
const char *tzn;
|
|
|
|
|
2013-11-01 18:57:31 +01:00
|
|
|
/* Always show the zone's canonical name */
|
2007-08-04 03:26:54 +02:00
|
|
|
tzn = pg_get_timezone_name(log_timezone);
|
1997-10-30 17:52:11 +01:00
|
|
|
|
2001-10-18 19:30:21 +02:00
|
|
|
if (tzn != NULL)
|
2002-05-17 03:19:19 +02:00
|
|
|
return tzn;
|
1997-10-30 17:52:11 +01:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
return "unknown";
|
|
|
|
}
|
2000-02-15 21:49:31 +01:00
|
|
|
|
2000-03-17 06:29:07 +01:00
|
|
|
|
2011-01-23 02:51:32 +01:00
|
|
|
/*
|
|
|
|
* SET TRANSACTION READ ONLY and SET TRANSACTION READ WRITE
|
|
|
|
*
|
|
|
|
* We allow idempotent changes (r/w -> r/w and r/o -> r/o) at any time, and
|
|
|
|
* we also always allow changes from read-write to read-only. However,
|
2011-04-07 06:11:01 +02:00
|
|
|
* read-only may be changed to read-write only when in a top-level transaction
|
2017-08-07 23:42:47 +02:00
|
|
|
* that has not yet taken an initial snapshot. Can't do it in a hot standby,
|
|
|
|
* either.
|
Fix issues with checks for unsupported transaction states in Hot Standby.
The GUC check hooks for transaction_read_only and transaction_isolation
tried to check RecoveryInProgress(), so as to disallow setting read/write
mode or serializable isolation level (respectively) in hot standby
sessions. However, GUC check hooks can be called in many situations where
we're not connected to shared memory at all, resulting in a crash in
RecoveryInProgress(). Among other cases, this results in EXEC_BACKEND
builds crashing during child process start if default_transaction_isolation
is serializable, as reported by Heikki Linnakangas. Protect those calls
by silently allowing any setting when not inside a transaction; which is
okay anyway since these GUCs are always reset at start of transaction.
Also, add a check to GetSerializableTransactionSnapshot() to complain
if we are in hot standby. We need that check despite the one in
check_XactIsoLevel() because default_transaction_isolation could be
serializable. We don't want to complain any sooner than this in such
cases, since that would prevent running transactions at all in such a
state; but a transaction can be run, if SET TRANSACTION ISOLATION is done
before setting a snapshot. Per report some months ago from Robert Haas.
Back-patch to 9.1, since these problems were introduced by the SSI patch.
Kevin Grittner and Tom Lane, with ideas from Heikki Linnakangas
2012-08-24 19:09:04 +02:00
|
|
|
*
|
|
|
|
* If we are not in a transaction at all, just allow the change; it means
|
|
|
|
* nothing since XactReadOnly will be reset by the next StartTransaction().
|
|
|
|
* The IsTransactionState() test protects us against trying to check
|
|
|
|
* RecoveryInProgress() in contexts where shared memory is not accessible.
|
2016-03-08 16:27:03 +01:00
|
|
|
* (Similarly, if we're restoring state in a parallel worker, just allow
|
|
|
|
* the change.)
|
2011-01-23 02:51:32 +01:00
|
|
|
*/
|
|
|
|
bool
|
2011-04-07 06:11:01 +02:00
|
|
|
check_transaction_read_only(bool *newval, void **extra, GucSource source)
|
2011-01-23 02:51:32 +01:00
|
|
|
{
|
2016-03-08 16:27:03 +01:00
|
|
|
if (*newval == false && XactReadOnly && IsTransactionState() && !InitializingParallelWorker)
|
2011-01-23 02:51:32 +01:00
|
|
|
{
|
|
|
|
/* Can't go to r/w mode inside a r/o transaction */
|
|
|
|
if (IsSubTransaction())
|
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
GUC_check_errcode(ERRCODE_ACTIVE_SQL_TRANSACTION);
|
|
|
|
GUC_check_errmsg("cannot set transaction read-write mode inside a read-only transaction");
|
2011-01-23 02:51:32 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
/* Top level transaction can't change to r/w after first snapshot. */
|
|
|
|
if (FirstSnapshotSet)
|
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
GUC_check_errcode(ERRCODE_ACTIVE_SQL_TRANSACTION);
|
|
|
|
GUC_check_errmsg("transaction read-write mode must be set before any query");
|
2011-01-23 02:51:32 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
/* Can't go to r/w mode while recovery is still active */
|
|
|
|
if (RecoveryInProgress())
|
|
|
|
{
|
Fix issues with checks for unsupported transaction states in Hot Standby.
The GUC check hooks for transaction_read_only and transaction_isolation
tried to check RecoveryInProgress(), so as to disallow setting read/write
mode or serializable isolation level (respectively) in hot standby
sessions. However, GUC check hooks can be called in many situations where
we're not connected to shared memory at all, resulting in a crash in
RecoveryInProgress(). Among other cases, this results in EXEC_BACKEND
builds crashing during child process start if default_transaction_isolation
is serializable, as reported by Heikki Linnakangas. Protect those calls
by silently allowing any setting when not inside a transaction; which is
okay anyway since these GUCs are always reset at start of transaction.
Also, add a check to GetSerializableTransactionSnapshot() to complain
if we are in hot standby. We need that check despite the one in
check_XactIsoLevel() because default_transaction_isolation could be
serializable. We don't want to complain any sooner than this in such
cases, since that would prevent running transactions at all in such a
state; but a transaction can be run, if SET TRANSACTION ISOLATION is done
before setting a snapshot. Per report some months ago from Robert Haas.
Back-patch to 9.1, since these problems were introduced by the SSI patch.
Kevin Grittner and Tom Lane, with ideas from Heikki Linnakangas
2012-08-24 19:09:04 +02:00
|
|
|
GUC_check_errcode(ERRCODE_FEATURE_NOT_SUPPORTED);
|
2011-04-07 06:11:01 +02:00
|
|
|
GUC_check_errmsg("cannot set transaction read-write mode during recovery");
|
2011-01-23 02:51:32 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2001-10-18 19:30:21 +02:00
|
|
|
/*
|
2002-05-17 03:19:19 +02:00
|
|
|
* SET TRANSACTION ISOLATION LEVEL
|
2011-01-23 02:51:32 +01:00
|
|
|
*
|
|
|
|
* We allow idempotent changes at any time, but otherwise this can only be
|
2011-04-07 06:11:01 +02:00
|
|
|
* changed in a toplevel transaction that has not yet taken a snapshot.
|
Fix issues with checks for unsupported transaction states in Hot Standby.
The GUC check hooks for transaction_read_only and transaction_isolation
tried to check RecoveryInProgress(), so as to disallow setting read/write
mode or serializable isolation level (respectively) in hot standby
sessions. However, GUC check hooks can be called in many situations where
we're not connected to shared memory at all, resulting in a crash in
RecoveryInProgress(). Among other cases, this results in EXEC_BACKEND
builds crashing during child process start if default_transaction_isolation
is serializable, as reported by Heikki Linnakangas. Protect those calls
by silently allowing any setting when not inside a transaction; which is
okay anyway since these GUCs are always reset at start of transaction.
Also, add a check to GetSerializableTransactionSnapshot() to complain
if we are in hot standby. We need that check despite the one in
check_XactIsoLevel() because default_transaction_isolation could be
serializable. We don't want to complain any sooner than this in such
cases, since that would prevent running transactions at all in such a
state; but a transaction can be run, if SET TRANSACTION ISOLATION is done
before setting a snapshot. Per report some months ago from Robert Haas.
Back-patch to 9.1, since these problems were introduced by the SSI patch.
Kevin Grittner and Tom Lane, with ideas from Heikki Linnakangas
2012-08-24 19:09:04 +02:00
|
|
|
*
|
|
|
|
* As in check_transaction_read_only, allow it if not inside a transaction.
|
2001-10-18 19:30:21 +02:00
|
|
|
*/
|
2011-04-07 06:11:01 +02:00
|
|
|
bool
|
2018-10-09 21:21:57 +02:00
|
|
|
check_XactIsoLevel(int *newval, void **extra, GucSource source)
|
2000-02-15 21:49:31 +01:00
|
|
|
{
|
2018-10-09 21:21:57 +02:00
|
|
|
int newXactIsoLevel = *newval;
|
2011-04-07 06:11:01 +02:00
|
|
|
|
Fix issues with checks for unsupported transaction states in Hot Standby.
The GUC check hooks for transaction_read_only and transaction_isolation
tried to check RecoveryInProgress(), so as to disallow setting read/write
mode or serializable isolation level (respectively) in hot standby
sessions. However, GUC check hooks can be called in many situations where
we're not connected to shared memory at all, resulting in a crash in
RecoveryInProgress(). Among other cases, this results in EXEC_BACKEND
builds crashing during child process start if default_transaction_isolation
is serializable, as reported by Heikki Linnakangas. Protect those calls
by silently allowing any setting when not inside a transaction; which is
okay anyway since these GUCs are always reset at start of transaction.
Also, add a check to GetSerializableTransactionSnapshot() to complain
if we are in hot standby. We need that check despite the one in
check_XactIsoLevel() because default_transaction_isolation could be
serializable. We don't want to complain any sooner than this in such
cases, since that would prevent running transactions at all in such a
state; but a transaction can be run, if SET TRANSACTION ISOLATION is done
before setting a snapshot. Per report some months ago from Robert Haas.
Back-patch to 9.1, since these problems were introduced by the SSI patch.
Kevin Grittner and Tom Lane, with ideas from Heikki Linnakangas
2012-08-24 19:09:04 +02:00
|
|
|
if (newXactIsoLevel != XactIsoLevel && IsTransactionState())
|
2004-07-01 02:52:04 +02:00
|
|
|
{
|
2011-01-22 03:49:19 +01:00
|
|
|
if (FirstSnapshotSet)
|
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
GUC_check_errcode(ERRCODE_ACTIVE_SQL_TRANSACTION);
|
|
|
|
GUC_check_errmsg("SET TRANSACTION ISOLATION LEVEL must be called before any query");
|
|
|
|
return false;
|
2011-01-22 03:49:19 +01:00
|
|
|
}
|
|
|
|
/* We ignore a subtransaction setting it to the existing value. */
|
2011-01-23 02:51:32 +01:00
|
|
|
if (IsSubTransaction())
|
2011-01-22 03:49:19 +01:00
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
GUC_check_errcode(ERRCODE_ACTIVE_SQL_TRANSACTION);
|
|
|
|
GUC_check_errmsg("SET TRANSACTION ISOLATION LEVEL must not be called in a subtransaction");
|
|
|
|
return false;
|
2011-01-22 03:49:19 +01:00
|
|
|
}
|
Implement genuine serializable isolation level.
Until now, our Serializable mode has in fact been what's called Snapshot
Isolation, which allows some anomalies that could not occur in any
serialized ordering of the transactions. This patch fixes that using a
method called Serializable Snapshot Isolation, based on research papers by
Michael J. Cahill (see README-SSI for full references). In Serializable
Snapshot Isolation, transactions run like they do in Snapshot Isolation,
but a predicate lock manager observes the reads and writes performed and
aborts transactions if it detects that an anomaly might occur. This method
produces some false positives, ie. it sometimes aborts transactions even
though there is no anomaly.
To track reads we implement predicate locking, see storage/lmgr/predicate.c.
Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared
memory is finite, so when a transaction takes many tuple-level locks on a
page, the locks are promoted to a single page-level lock, and further to a
single relation level lock if necessary. To lock key values with no matching
tuple, a sequential scan always takes a relation-level lock, and an index
scan acquires a page-level lock that covers the search key, whether or not
there are any matching keys at the moment.
A predicate lock doesn't conflict with any regular locks or with another
predicate locks in the normal sense. They're only used by the predicate lock
manager to detect the danger of anomalies. Only serializable transactions
participate in predicate locking, so there should be no extra overhead for
for other transactions.
Predicate locks can't be released at commit, but must be remembered until
all the transactions that overlapped with it have completed. That means that
we need to remember an unbounded amount of predicate locks, so we apply a
lossy but conservative method of tracking locks for committed transactions.
If we run short of shared memory, we overflow to a new "pg_serial" SLRU
pool.
We don't currently allow Serializable transactions in Hot Standby mode.
That would be hard, because even read-only transactions can cause anomalies
that wouldn't otherwise occur.
Serializable isolation mode now means the new fully serializable level.
Repeatable Read gives you the old Snapshot Isolation level that we have
always had.
Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and
Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
|
|
|
/* Can't go to serializable mode while recovery is still active */
|
2011-04-07 06:11:01 +02:00
|
|
|
if (newXactIsoLevel == XACT_SERIALIZABLE && RecoveryInProgress())
|
Implement genuine serializable isolation level.
Until now, our Serializable mode has in fact been what's called Snapshot
Isolation, which allows some anomalies that could not occur in any
serialized ordering of the transactions. This patch fixes that using a
method called Serializable Snapshot Isolation, based on research papers by
Michael J. Cahill (see README-SSI for full references). In Serializable
Snapshot Isolation, transactions run like they do in Snapshot Isolation,
but a predicate lock manager observes the reads and writes performed and
aborts transactions if it detects that an anomaly might occur. This method
produces some false positives, ie. it sometimes aborts transactions even
though there is no anomaly.
To track reads we implement predicate locking, see storage/lmgr/predicate.c.
Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared
memory is finite, so when a transaction takes many tuple-level locks on a
page, the locks are promoted to a single page-level lock, and further to a
single relation level lock if necessary. To lock key values with no matching
tuple, a sequential scan always takes a relation-level lock, and an index
scan acquires a page-level lock that covers the search key, whether or not
there are any matching keys at the moment.
A predicate lock doesn't conflict with any regular locks or with another
predicate locks in the normal sense. They're only used by the predicate lock
manager to detect the danger of anomalies. Only serializable transactions
participate in predicate locking, so there should be no extra overhead for
for other transactions.
Predicate locks can't be released at commit, but must be remembered until
all the transactions that overlapped with it have completed. That means that
we need to remember an unbounded amount of predicate locks, so we apply a
lossy but conservative method of tracking locks for committed transactions.
If we run short of shared memory, we overflow to a new "pg_serial" SLRU
pool.
We don't currently allow Serializable transactions in Hot Standby mode.
That would be hard, because even read-only transactions can cause anomalies
that wouldn't otherwise occur.
Serializable isolation mode now means the new fully serializable level.
Repeatable Read gives you the old Snapshot Isolation level that we have
always had.
Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and
Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
|
|
|
{
|
Fix issues with checks for unsupported transaction states in Hot Standby.
The GUC check hooks for transaction_read_only and transaction_isolation
tried to check RecoveryInProgress(), so as to disallow setting read/write
mode or serializable isolation level (respectively) in hot standby
sessions. However, GUC check hooks can be called in many situations where
we're not connected to shared memory at all, resulting in a crash in
RecoveryInProgress(). Among other cases, this results in EXEC_BACKEND
builds crashing during child process start if default_transaction_isolation
is serializable, as reported by Heikki Linnakangas. Protect those calls
by silently allowing any setting when not inside a transaction; which is
okay anyway since these GUCs are always reset at start of transaction.
Also, add a check to GetSerializableTransactionSnapshot() to complain
if we are in hot standby. We need that check despite the one in
check_XactIsoLevel() because default_transaction_isolation could be
serializable. We don't want to complain any sooner than this in such
cases, since that would prevent running transactions at all in such a
state; but a transaction can be run, if SET TRANSACTION ISOLATION is done
before setting a snapshot. Per report some months ago from Robert Haas.
Back-patch to 9.1, since these problems were introduced by the SSI patch.
Kevin Grittner and Tom Lane, with ideas from Heikki Linnakangas
2012-08-24 19:09:04 +02:00
|
|
|
GUC_check_errcode(ERRCODE_FEATURE_NOT_SUPPORTED);
|
2011-04-07 06:11:01 +02:00
|
|
|
GUC_check_errmsg("cannot use serializable mode in a hot standby");
|
|
|
|
GUC_check_errhint("You can use REPEATABLE READ instead.");
|
Implement genuine serializable isolation level.
Until now, our Serializable mode has in fact been what's called Snapshot
Isolation, which allows some anomalies that could not occur in any
serialized ordering of the transactions. This patch fixes that using a
method called Serializable Snapshot Isolation, based on research papers by
Michael J. Cahill (see README-SSI for full references). In Serializable
Snapshot Isolation, transactions run like they do in Snapshot Isolation,
but a predicate lock manager observes the reads and writes performed and
aborts transactions if it detects that an anomaly might occur. This method
produces some false positives, ie. it sometimes aborts transactions even
though there is no anomaly.
To track reads we implement predicate locking, see storage/lmgr/predicate.c.
Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared
memory is finite, so when a transaction takes many tuple-level locks on a
page, the locks are promoted to a single page-level lock, and further to a
single relation level lock if necessary. To lock key values with no matching
tuple, a sequential scan always takes a relation-level lock, and an index
scan acquires a page-level lock that covers the search key, whether or not
there are any matching keys at the moment.
A predicate lock doesn't conflict with any regular locks or with another
predicate locks in the normal sense. They're only used by the predicate lock
manager to detect the danger of anomalies. Only serializable transactions
participate in predicate locking, so there should be no extra overhead for
for other transactions.
Predicate locks can't be released at commit, but must be remembered until
all the transactions that overlapped with it have completed. That means that
we need to remember an unbounded amount of predicate locks, so we apply a
lossy but conservative method of tracking locks for committed transactions.
If we run short of shared memory, we overflow to a new "pg_serial" SLRU
pool.
We don't currently allow Serializable transactions in Hot Standby mode.
That would be hard, because even read-only transactions can cause anomalies
that wouldn't otherwise occur.
Serializable isolation mode now means the new fully serializable level.
Repeatable Read gives you the old Snapshot Isolation level that we have
always had.
Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and
Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
|
|
|
return false;
|
|
|
|
}
|
2004-07-01 02:52:04 +02:00
|
|
|
}
|
2000-02-15 21:49:31 +01:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
return true;
|
|
|
|
}
|
2000-02-15 21:49:31 +01:00
|
|
|
|
Implement genuine serializable isolation level.
Until now, our Serializable mode has in fact been what's called Snapshot
Isolation, which allows some anomalies that could not occur in any
serialized ordering of the transactions. This patch fixes that using a
method called Serializable Snapshot Isolation, based on research papers by
Michael J. Cahill (see README-SSI for full references). In Serializable
Snapshot Isolation, transactions run like they do in Snapshot Isolation,
but a predicate lock manager observes the reads and writes performed and
aborts transactions if it detects that an anomaly might occur. This method
produces some false positives, ie. it sometimes aborts transactions even
though there is no anomaly.
To track reads we implement predicate locking, see storage/lmgr/predicate.c.
Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared
memory is finite, so when a transaction takes many tuple-level locks on a
page, the locks are promoted to a single page-level lock, and further to a
single relation level lock if necessary. To lock key values with no matching
tuple, a sequential scan always takes a relation-level lock, and an index
scan acquires a page-level lock that covers the search key, whether or not
there are any matching keys at the moment.
A predicate lock doesn't conflict with any regular locks or with another
predicate locks in the normal sense. They're only used by the predicate lock
manager to detect the danger of anomalies. Only serializable transactions
participate in predicate locking, so there should be no extra overhead for
for other transactions.
Predicate locks can't be released at commit, but must be remembered until
all the transactions that overlapped with it have completed. That means that
we need to remember an unbounded amount of predicate locks, so we apply a
lossy but conservative method of tracking locks for committed transactions.
If we run short of shared memory, we overflow to a new "pg_serial" SLRU
pool.
We don't currently allow Serializable transactions in Hot Standby mode.
That would be hard, because even read-only transactions can cause anomalies
that wouldn't otherwise occur.
Serializable isolation mode now means the new fully serializable level.
Repeatable Read gives you the old Snapshot Isolation level that we have
always had.
Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and
Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
|
|
|
/*
|
|
|
|
* SET TRANSACTION [NOT] DEFERRABLE
|
|
|
|
*/
|
|
|
|
|
|
|
|
bool
|
2011-04-07 06:11:01 +02:00
|
|
|
check_transaction_deferrable(bool *newval, void **extra, GucSource source)
|
Implement genuine serializable isolation level.
Until now, our Serializable mode has in fact been what's called Snapshot
Isolation, which allows some anomalies that could not occur in any
serialized ordering of the transactions. This patch fixes that using a
method called Serializable Snapshot Isolation, based on research papers by
Michael J. Cahill (see README-SSI for full references). In Serializable
Snapshot Isolation, transactions run like they do in Snapshot Isolation,
but a predicate lock manager observes the reads and writes performed and
aborts transactions if it detects that an anomaly might occur. This method
produces some false positives, ie. it sometimes aborts transactions even
though there is no anomaly.
To track reads we implement predicate locking, see storage/lmgr/predicate.c.
Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared
memory is finite, so when a transaction takes many tuple-level locks on a
page, the locks are promoted to a single page-level lock, and further to a
single relation level lock if necessary. To lock key values with no matching
tuple, a sequential scan always takes a relation-level lock, and an index
scan acquires a page-level lock that covers the search key, whether or not
there are any matching keys at the moment.
A predicate lock doesn't conflict with any regular locks or with another
predicate locks in the normal sense. They're only used by the predicate lock
manager to detect the danger of anomalies. Only serializable transactions
participate in predicate locking, so there should be no extra overhead for
for other transactions.
Predicate locks can't be released at commit, but must be remembered until
all the transactions that overlapped with it have completed. That means that
we need to remember an unbounded amount of predicate locks, so we apply a
lossy but conservative method of tracking locks for committed transactions.
If we run short of shared memory, we overflow to a new "pg_serial" SLRU
pool.
We don't currently allow Serializable transactions in Hot Standby mode.
That would be hard, because even read-only transactions can cause anomalies
that wouldn't otherwise occur.
Serializable isolation mode now means the new fully serializable level.
Repeatable Read gives you the old Snapshot Isolation level that we have
always had.
Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and
Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
|
|
|
{
|
|
|
|
if (IsSubTransaction())
|
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
GUC_check_errcode(ERRCODE_ACTIVE_SQL_TRANSACTION);
|
|
|
|
GUC_check_errmsg("SET TRANSACTION [NOT] DEFERRABLE cannot be called within a subtransaction");
|
Implement genuine serializable isolation level.
Until now, our Serializable mode has in fact been what's called Snapshot
Isolation, which allows some anomalies that could not occur in any
serialized ordering of the transactions. This patch fixes that using a
method called Serializable Snapshot Isolation, based on research papers by
Michael J. Cahill (see README-SSI for full references). In Serializable
Snapshot Isolation, transactions run like they do in Snapshot Isolation,
but a predicate lock manager observes the reads and writes performed and
aborts transactions if it detects that an anomaly might occur. This method
produces some false positives, ie. it sometimes aborts transactions even
though there is no anomaly.
To track reads we implement predicate locking, see storage/lmgr/predicate.c.
Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared
memory is finite, so when a transaction takes many tuple-level locks on a
page, the locks are promoted to a single page-level lock, and further to a
single relation level lock if necessary. To lock key values with no matching
tuple, a sequential scan always takes a relation-level lock, and an index
scan acquires a page-level lock that covers the search key, whether or not
there are any matching keys at the moment.
A predicate lock doesn't conflict with any regular locks or with another
predicate locks in the normal sense. They're only used by the predicate lock
manager to detect the danger of anomalies. Only serializable transactions
participate in predicate locking, so there should be no extra overhead for
for other transactions.
Predicate locks can't be released at commit, but must be remembered until
all the transactions that overlapped with it have completed. That means that
we need to remember an unbounded amount of predicate locks, so we apply a
lossy but conservative method of tracking locks for committed transactions.
If we run short of shared memory, we overflow to a new "pg_serial" SLRU
pool.
We don't currently allow Serializable transactions in Hot Standby mode.
That would be hard, because even read-only transactions can cause anomalies
that wouldn't otherwise occur.
Serializable isolation mode now means the new fully serializable level.
Repeatable Read gives you the old Snapshot Isolation level that we have
always had.
Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and
Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (FirstSnapshotSet)
|
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
GUC_check_errcode(ERRCODE_ACTIVE_SQL_TRANSACTION);
|
|
|
|
GUC_check_errmsg("SET TRANSACTION [NOT] DEFERRABLE must be called before any query");
|
Implement genuine serializable isolation level.
Until now, our Serializable mode has in fact been what's called Snapshot
Isolation, which allows some anomalies that could not occur in any
serialized ordering of the transactions. This patch fixes that using a
method called Serializable Snapshot Isolation, based on research papers by
Michael J. Cahill (see README-SSI for full references). In Serializable
Snapshot Isolation, transactions run like they do in Snapshot Isolation,
but a predicate lock manager observes the reads and writes performed and
aborts transactions if it detects that an anomaly might occur. This method
produces some false positives, ie. it sometimes aborts transactions even
though there is no anomaly.
To track reads we implement predicate locking, see storage/lmgr/predicate.c.
Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared
memory is finite, so when a transaction takes many tuple-level locks on a
page, the locks are promoted to a single page-level lock, and further to a
single relation level lock if necessary. To lock key values with no matching
tuple, a sequential scan always takes a relation-level lock, and an index
scan acquires a page-level lock that covers the search key, whether or not
there are any matching keys at the moment.
A predicate lock doesn't conflict with any regular locks or with another
predicate locks in the normal sense. They're only used by the predicate lock
manager to detect the danger of anomalies. Only serializable transactions
participate in predicate locking, so there should be no extra overhead for
for other transactions.
Predicate locks can't be released at commit, but must be remembered until
all the transactions that overlapped with it have completed. That means that
we need to remember an unbounded amount of predicate locks, so we apply a
lossy but conservative method of tracking locks for committed transactions.
If we run short of shared memory, we overflow to a new "pg_serial" SLRU
pool.
We don't currently allow Serializable transactions in Hot Standby mode.
That would be hard, because even read-only transactions can cause anomalies
that wouldn't otherwise occur.
Serializable isolation mode now means the new fully serializable level.
Repeatable Read gives you the old Snapshot Isolation level that we have
always had.
Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and
Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
2000-02-15 21:49:31 +01:00
|
|
|
|
2000-04-07 15:40:45 +02:00
|
|
|
/*
|
|
|
|
* Random number seed
|
2011-04-07 06:11:01 +02:00
|
|
|
*
|
|
|
|
* We can't roll back the random sequence on error, and we don't want
|
|
|
|
* config file reloads to affect it, so we only want interactive SET SEED
|
2014-05-06 18:12:18 +02:00
|
|
|
* commands to set it. We use the "extra" storage to ensure that rollbacks
|
2011-04-07 06:11:01 +02:00
|
|
|
* don't try to do the operation again.
|
2000-04-07 15:40:45 +02:00
|
|
|
*/
|
2002-04-21 21:12:46 +02:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
bool
|
2011-04-07 06:11:01 +02:00
|
|
|
check_random_seed(double *newval, void **extra, GucSource source)
|
2000-04-07 15:40:45 +02:00
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
*extra = malloc(sizeof(int));
|
|
|
|
if (!*extra)
|
|
|
|
return false;
|
|
|
|
/* Arm the assign only if source of value is an interactive SET */
|
|
|
|
*((int *) *extra) = (source >= PGC_S_INTERACTIVE);
|
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
return true;
|
2000-04-07 15:40:45 +02:00
|
|
|
}
|
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
void
|
|
|
|
assign_random_seed(double newval, void *extra)
|
|
|
|
{
|
|
|
|
/* We'll do this at most once for any setting of the GUC variable */
|
|
|
|
if (*((int *) extra))
|
|
|
|
DirectFunctionCall1(setseed, Float8GetDatum(newval));
|
|
|
|
*((int *) extra) = 0;
|
|
|
|
}
|
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
const char *
|
|
|
|
show_random_seed(void)
|
2000-04-07 15:40:45 +02:00
|
|
|
{
|
2002-05-17 03:19:19 +02:00
|
|
|
return "unavailable";
|
2000-04-07 15:40:45 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2000-10-25 21:44:44 +02:00
|
|
|
/*
|
2011-04-07 06:11:01 +02:00
|
|
|
* SET CLIENT_ENCODING
|
2000-10-25 21:44:44 +02:00
|
|
|
*/
|
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
bool
|
|
|
|
check_client_encoding(char **newval, void **extra, GucSource source)
|
2000-10-25 21:44:44 +02:00
|
|
|
{
|
2001-10-25 07:50:21 +02:00
|
|
|
int encoding;
|
2011-04-19 18:17:13 +02:00
|
|
|
const char *canonical_name;
|
2001-10-18 19:30:21 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
/* Look up the encoding by name */
|
|
|
|
encoding = pg_valid_client_encoding(*newval);
|
2000-10-25 21:44:44 +02:00
|
|
|
if (encoding < 0)
|
2011-04-07 06:11:01 +02:00
|
|
|
return false;
|
2002-09-04 22:31:48 +02:00
|
|
|
|
2011-04-19 18:17:13 +02:00
|
|
|
/* Get the canonical name (no aliases, uniform case) */
|
|
|
|
canonical_name = pg_encoding_to_char(encoding);
|
|
|
|
|
2002-09-04 22:31:48 +02:00
|
|
|
/*
|
2011-04-07 06:11:01 +02:00
|
|
|
* If we are not within a transaction then PrepareClientEncoding will not
|
|
|
|
* be able to look up the necessary conversion procs. If we are still
|
|
|
|
* starting up, it will return "OK" anyway, and InitializeClientEncoding
|
|
|
|
* will fix things once initialization is far enough along. After
|
|
|
|
* startup, we'll fail. This would only happen if someone tries to change
|
|
|
|
* client_encoding in postgresql.conf and then SIGHUP existing sessions.
|
|
|
|
* It seems like a bad idea for client_encoding to change that way anyhow,
|
|
|
|
* so we don't go out of our way to support it.
|
|
|
|
*
|
|
|
|
* Note: in the postmaster, or any other process that never calls
|
|
|
|
* InitializeClientEncoding, PrepareClientEncoding will always succeed,
|
|
|
|
* and so will SetClientEncoding; but they won't do anything, which is OK.
|
2002-05-17 03:19:19 +02:00
|
|
|
*/
|
2011-04-07 06:11:01 +02:00
|
|
|
if (PrepareClientEncoding(encoding) < 0)
|
2000-10-25 21:44:44 +02:00
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
if (IsTransactionState())
|
|
|
|
{
|
|
|
|
/* Must be a genuine no-such-conversion problem */
|
|
|
|
GUC_check_errcode(ERRCODE_FEATURE_NOT_SUPPORTED);
|
|
|
|
GUC_check_errdetail("Conversion between %s and %s is not supported.",
|
2011-04-19 18:17:13 +02:00
|
|
|
canonical_name,
|
2011-04-07 06:11:01 +02:00
|
|
|
GetDatabaseEncodingName());
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Provide a useful complaint */
|
|
|
|
GUC_check_errdetail("Cannot change \"client_encoding\" now.");
|
|
|
|
}
|
|
|
|
return false;
|
2000-10-25 21:44:44 +02:00
|
|
|
}
|
2011-04-07 06:11:01 +02:00
|
|
|
|
|
|
|
/*
|
2011-04-19 18:17:13 +02:00
|
|
|
* Replace the user-supplied string with the encoding's canonical name.
|
|
|
|
* This gets rid of aliases and case-folding variations.
|
|
|
|
*
|
|
|
|
* XXX Although canonicalizing seems like a good idea in the abstract, it
|
|
|
|
* breaks pre-9.1 JDBC drivers, which expect that if they send "UNICODE"
|
2011-06-09 20:32:50 +02:00
|
|
|
* as the client_encoding setting then it will read back the same way. As
|
|
|
|
* a workaround, don't replace the string if it's "UNICODE". Remove that
|
|
|
|
* hack when pre-9.1 JDBC drivers are no longer in use.
|
2011-04-07 06:11:01 +02:00
|
|
|
*/
|
2011-04-19 18:17:13 +02:00
|
|
|
if (strcmp(*newval, canonical_name) != 0 &&
|
|
|
|
strcmp(*newval, "UNICODE") != 0)
|
|
|
|
{
|
|
|
|
free(*newval);
|
|
|
|
*newval = strdup(canonical_name);
|
|
|
|
if (!*newval)
|
|
|
|
return false;
|
|
|
|
}
|
2011-04-07 06:11:01 +02:00
|
|
|
|
2011-04-19 18:17:13 +02:00
|
|
|
/*
|
|
|
|
* Save the encoding's ID in *extra, for use by assign_client_encoding.
|
|
|
|
*/
|
2011-04-07 06:11:01 +02:00
|
|
|
*extra = malloc(sizeof(int));
|
|
|
|
if (!*extra)
|
|
|
|
return false;
|
|
|
|
*((int *) *extra) = encoding;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
assign_client_encoding(const char *newval, void *extra)
|
|
|
|
{
|
|
|
|
int encoding = *((int *) extra);
|
|
|
|
|
Fix several mistakes around parallel workers and client_encoding.
Previously, workers sent data to the leader using the client encoding.
That mostly worked, but the leader the converted the data back to the
server encoding. Since not all encoding conversions are reversible,
that could provoke failures. Fix by using the database encoding for
all communication between worker and leader.
Also, while temporary changes to GUC settings, as from the SET clause
of a function, are in general OK for parallel query, changing
client_encoding this way inside of a parallel worker is not OK.
Previously, that would have confused the leader; with these changes,
it would not confuse the leader, but it wouldn't do anything either.
So refuse such changes in parallel workers.
Also, the previous code naively assumed that when it received a
NotifyResonse from the worker, it could pass that directly back to the
user. But now that worker-to-leader communication always uses the
database encoding, that's clearly no longer correct - though,
actually, the old way was always broken for V2 clients. So
disassemble and reconstitute the message instead.
Issues reported by Peter Eisentraut. Patch by me, reviewed by
Peter Eisentraut.
2016-07-01 00:35:32 +02:00
|
|
|
/*
|
|
|
|
* Parallel workers send data to the leader, not the client. They always
|
|
|
|
* send data using the database encoding.
|
|
|
|
*/
|
|
|
|
if (IsParallelWorker())
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* During parallel worker startup, we want to accept the leader's
|
|
|
|
* client_encoding setting so that anyone who looks at the value in
|
|
|
|
* the worker sees the same value that they would see in the leader.
|
|
|
|
*/
|
|
|
|
if (InitializingParallelWorker)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* A change other than during startup, for example due to a SET clause
|
|
|
|
* attached to a function definition, should be rejected, as there is
|
|
|
|
* nothing we can do inside the worker to make it take effect.
|
|
|
|
*/
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TRANSACTION_STATE),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
errmsg("cannot change client_encoding during a parallel operation")));
|
Fix several mistakes around parallel workers and client_encoding.
Previously, workers sent data to the leader using the client encoding.
That mostly worked, but the leader the converted the data back to the
server encoding. Since not all encoding conversions are reversible,
that could provoke failures. Fix by using the database encoding for
all communication between worker and leader.
Also, while temporary changes to GUC settings, as from the SET clause
of a function, are in general OK for parallel query, changing
client_encoding this way inside of a parallel worker is not OK.
Previously, that would have confused the leader; with these changes,
it would not confuse the leader, but it wouldn't do anything either.
So refuse such changes in parallel workers.
Also, the previous code naively assumed that when it received a
NotifyResonse from the worker, it could pass that directly back to the
user. But now that worker-to-leader communication always uses the
database encoding, that's clearly no longer correct - though,
actually, the old way was always broken for V2 clients. So
disassemble and reconstitute the message instead.
Issues reported by Peter Eisentraut. Patch by me, reviewed by
Peter Eisentraut.
2016-07-01 00:35:32 +02:00
|
|
|
}
|
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
/* We do not expect an error if PrepareClientEncoding succeeded */
|
|
|
|
if (SetClientEncoding(encoding) < 0)
|
|
|
|
elog(LOG, "SetClientEncoding(%d) failed", encoding);
|
2000-10-26 19:31:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
/*
|
|
|
|
* SET SESSION AUTHORIZATION
|
|
|
|
*/
|
2004-08-11 23:10:37 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
typedef struct
|
2002-05-06 21:47:30 +02:00
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
/* This is the "extra" state for both SESSION AUTHORIZATION and ROLE */
|
|
|
|
Oid roleid;
|
|
|
|
bool is_superuser;
|
|
|
|
} role_auth_extra;
|
2002-05-06 21:47:30 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
bool
|
|
|
|
check_session_authorization(char **newval, void **extra, GucSource source)
|
|
|
|
{
|
|
|
|
HeapTuple roleTup;
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
Form_pg_authid roleform;
|
2011-04-07 06:11:01 +02:00
|
|
|
Oid roleid;
|
|
|
|
bool is_superuser;
|
|
|
|
role_auth_extra *myextra;
|
2003-02-01 19:31:28 +01:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
/* Do nothing for the boot_val default of NULL */
|
|
|
|
if (*newval == NULL)
|
|
|
|
return true;
|
2003-02-01 19:31:28 +01:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
if (!IsTransactionState())
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Can't do catalog lookups, so fail. The result of this is that
|
2011-04-10 17:42:00 +02:00
|
|
|
* session_authorization cannot be set in postgresql.conf, which seems
|
|
|
|
* like a good thing anyway, so we don't work hard to avoid it.
|
2011-04-07 06:11:01 +02:00
|
|
|
*/
|
|
|
|
return false;
|
2002-05-17 03:19:19 +02:00
|
|
|
}
|
2003-02-01 19:31:28 +01:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
/* Look up the username */
|
|
|
|
roleTup = SearchSysCache1(AUTHNAME, PointerGetDatum(*newval));
|
|
|
|
if (!HeapTupleIsValid(roleTup))
|
2001-10-18 19:30:21 +02:00
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
GUC_check_errmsg("role \"%s\" does not exist", *newval);
|
|
|
|
return false;
|
2001-10-18 19:30:21 +02:00
|
|
|
}
|
2001-03-22 05:01:46 +01:00
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
roleform = (Form_pg_authid) GETSTRUCT(roleTup);
|
|
|
|
roleid = roleform->oid;
|
|
|
|
is_superuser = roleform->rolsuper;
|
2002-05-17 03:19:19 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
ReleaseSysCache(roleTup);
|
2003-02-01 19:31:28 +01:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
/* Set up "extra" struct for assign_session_authorization to use */
|
|
|
|
myextra = (role_auth_extra *) malloc(sizeof(role_auth_extra));
|
|
|
|
if (!myextra)
|
|
|
|
return false;
|
|
|
|
myextra->roleid = roleid;
|
|
|
|
myextra->is_superuser = is_superuser;
|
|
|
|
*extra = (void *) myextra;
|
2002-05-17 03:19:19 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
return true;
|
2001-03-22 05:01:46 +01:00
|
|
|
}
|
1997-06-20 19:17:03 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
void
|
|
|
|
assign_session_authorization(const char *newval, void *extra)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
role_auth_extra *myextra = (role_auth_extra *) extra;
|
2004-08-11 23:10:37 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
/* Do nothing for the boot_val default of NULL */
|
|
|
|
if (!myextra)
|
|
|
|
return;
|
2010-09-23 22:53:16 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
SetSessionAuthorization(myextra->roleid, myextra->is_superuser);
|
2001-03-22 05:01:46 +01:00
|
|
|
}
|
2005-07-26 00:12:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SET ROLE
|
|
|
|
*
|
|
|
|
* The SQL spec requires "SET ROLE NONE" to unset the role, so we hardwire
|
2011-04-07 06:11:01 +02:00
|
|
|
* a translation of "none" to InvalidOid. Otherwise this is much like
|
|
|
|
* SET SESSION AUTHORIZATION.
|
2005-07-26 00:12:34 +02:00
|
|
|
*/
|
|
|
|
extern char *role_string; /* in guc.c */
|
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
bool
|
|
|
|
check_role(char **newval, void **extra, GucSource source)
|
2005-07-26 00:12:34 +02:00
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
HeapTuple roleTup;
|
|
|
|
Oid roleid;
|
|
|
|
bool is_superuser;
|
|
|
|
role_auth_extra *myextra;
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
Form_pg_authid roleform;
|
2005-07-26 00:12:34 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
if (strcmp(*newval, "none") == 0)
|
2005-07-26 00:12:34 +02:00
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
/* hardwired translation */
|
|
|
|
roleid = InvalidOid;
|
|
|
|
is_superuser = false;
|
2005-07-26 00:12:34 +02:00
|
|
|
}
|
2011-04-07 06:11:01 +02:00
|
|
|
else
|
2005-07-26 00:12:34 +02:00
|
|
|
{
|
|
|
|
if (!IsTransactionState())
|
|
|
|
{
|
|
|
|
/*
|
2011-04-07 06:11:01 +02:00
|
|
|
* Can't do catalog lookups, so fail. The result of this is that
|
2005-10-15 04:49:52 +02:00
|
|
|
* role cannot be set in postgresql.conf, which seems like a good
|
2011-04-07 06:11:01 +02:00
|
|
|
* thing anyway, so we don't work hard to avoid it.
|
2005-07-26 00:12:34 +02:00
|
|
|
*/
|
2011-04-07 06:11:01 +02:00
|
|
|
return false;
|
2005-07-26 00:12:34 +02:00
|
|
|
}
|
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
/* Look up the username */
|
|
|
|
roleTup = SearchSysCache1(AUTHNAME, PointerGetDatum(*newval));
|
2005-07-26 00:12:34 +02:00
|
|
|
if (!HeapTupleIsValid(roleTup))
|
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
GUC_check_errmsg("role \"%s\" does not exist", *newval);
|
|
|
|
return false;
|
2005-07-26 00:12:34 +02:00
|
|
|
}
|
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
roleform = (Form_pg_authid) GETSTRUCT(roleTup);
|
|
|
|
roleid = roleform->oid;
|
|
|
|
is_superuser = roleform->rolsuper;
|
2005-07-26 00:12:34 +02:00
|
|
|
|
|
|
|
ReleaseSysCache(roleTup);
|
|
|
|
|
|
|
|
/*
|
2016-06-10 00:02:36 +02:00
|
|
|
* Verify that session user is allowed to become this role, but skip
|
|
|
|
* this in parallel mode, where we must blindly recreate the parallel
|
|
|
|
* leader's state.
|
2005-07-26 00:12:34 +02:00
|
|
|
*/
|
2015-10-16 17:37:19 +02:00
|
|
|
if (!InitializingParallelWorker &&
|
|
|
|
!is_member_of_role(GetSessionUserId(), roleid))
|
2005-07-26 00:12:34 +02:00
|
|
|
{
|
2011-04-07 06:11:01 +02:00
|
|
|
GUC_check_errcode(ERRCODE_INSUFFICIENT_PRIVILEGE);
|
|
|
|
GUC_check_errmsg("permission denied to set role \"%s\"",
|
|
|
|
*newval);
|
|
|
|
return false;
|
2005-07-26 00:12:34 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
/* Set up "extra" struct for assign_role to use */
|
|
|
|
myextra = (role_auth_extra *) malloc(sizeof(role_auth_extra));
|
|
|
|
if (!myextra)
|
|
|
|
return false;
|
|
|
|
myextra->roleid = roleid;
|
|
|
|
myextra->is_superuser = is_superuser;
|
|
|
|
*extra = (void *) myextra;
|
2005-07-26 00:12:34 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
return true;
|
|
|
|
}
|
2005-07-26 00:12:34 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
void
|
|
|
|
assign_role(const char *newval, void *extra)
|
|
|
|
{
|
|
|
|
role_auth_extra *myextra = (role_auth_extra *) extra;
|
2005-07-26 00:12:34 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
SetCurrentRoleId(myextra->roleid, myextra->is_superuser);
|
2005-07-26 00:12:34 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
const char *
|
|
|
|
show_role(void)
|
|
|
|
{
|
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Check whether SET ROLE is active; if not return "none". This is a
|
2011-04-07 06:11:01 +02:00
|
|
|
* kluge to deal with the fact that SET SESSION AUTHORIZATION logically
|
|
|
|
* resets SET ROLE to NONE, but we cannot set the GUC role variable from
|
|
|
|
* assign_session_authorization (because we haven't got enough info to
|
|
|
|
* call set_config_option).
|
2005-07-26 00:12:34 +02:00
|
|
|
*/
|
2011-04-07 06:11:01 +02:00
|
|
|
if (!OidIsValid(GetCurrentRoleId()))
|
2005-07-26 00:12:34 +02:00
|
|
|
return "none";
|
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
/* Otherwise we can just use the GUC string */
|
|
|
|
return role_string ? role_string : "none";
|
2005-07-26 00:12:34 +02:00
|
|
|
}
|