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
|
|
|
*
|
2024-01-04 02:49:05 +01:00
|
|
|
* Portions Copyright (c) 1996-2024, 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"
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
|
|
|
#include "access/xlogprefetcher.h"
|
2005-06-28 07:09:14 +02:00
|
|
|
#include "catalog/pg_authid.h"
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
|
|
|
#include "common/string.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"
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
|
|
|
#include "postmaster/postmaster.h"
|
|
|
|
#include "postmaster/syslogger.h"
|
|
|
|
#include "storage/bufmgr.h"
|
2005-07-26 00:12:34 +02:00
|
|
|
#include "utils/acl.h"
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
|
|
|
#include "utils/backend_status.h"
|
|
|
|
#include "utils/datetime.h"
|
2024-03-04 12:00:11 +01:00
|
|
|
#include "utils/fmgrprotos.h"
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
|
|
|
#include "utils/guc_hooks.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"
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
|
|
|
#include "utils/tzparser.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-04-17 15:50:57 +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-04-17 15:50:57 +02:00
|
|
|
}
|
2004-05-07 02:24:59 +02:00
|
|
|
else if (pg_strcasecmp(tok, "SQL") == 0)
|
1997-04-17 15:50:57 +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-04-17 15:50:57 +02:00
|
|
|
}
|
2004-05-07 02:24:59 +02:00
|
|
|
else if (pg_strncasecmp(tok, "POSTGRES", 8) == 0)
|
1997-04-17 15:50:57 +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-04-17 15:50:57 +02:00
|
|
|
}
|
2004-05-07 02:24:59 +02:00
|
|
|
else if (pg_strcasecmp(tok, "GERMAN") == 0)
|
To: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
Subject: Re: [PATCHES] SET DateStyle patches
On Tue, 22 Apr 1997, Thomas Lockhart wrote:
> Some more patches! These (try to) finish implementing SET variable TO value
> for "DateStyle" (changed the name from simply "date" to be more descriptive).
> This is based on code from Martin and Bruce (?), which was easy to modify.
> The syntax is
>
> SET DateStyle TO 'iso'
> SET DateStyle TO 'postgres'
> SET DateStyle TO 'sql'
> SET DateStyle TO 'european'
> SET DateStyle TO 'noneuropean'
> SET DateStyle TO 'us' (same as "noneuropean")
> SET DateStyle TO 'default' (current same as "postgres,us")
>
> ("european" is just compared for the first 4 characters, and "noneuropean"
> is compared for the first 7 to allow less typing).
>
> Multiple arguments are allowed, so SET datestyle TO 'sql,euro' is valid.
>
> My mods also try to implement "SHOW variable" and "RESET variable", but
> that part just core dumps at the moment. I would guess that my errors
> are obvious to someone who knows what they are doing with the parser stuff,
> so if someone (Bruce and/or Martin??) could have it do the right thing
> we will have a more complete set of what we need.
>
> Also, I would like to have a floating point precision global variable to
> implement "SET precision TO 10" and perhaps "SET precision TO 10,2" for
> float8 and float4, but I don't know how to do that for integer types rather
> than strings. If someone is fixing the SHOW and RESET code, perhaps they can
> add some hooks for me to do the floats while they are at it.
>
> I've left some remnants of variable structures in the source code which
> I did not use in the interests of getting something working for v6.1.
> We'll have time to clean things up for the next release...
1997-04-23 05:18:27 +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;
|
To: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
Subject: Re: [PATCHES] SET DateStyle patches
On Tue, 22 Apr 1997, Thomas Lockhart wrote:
> Some more patches! These (try to) finish implementing SET variable TO value
> for "DateStyle" (changed the name from simply "date" to be more descriptive).
> This is based on code from Martin and Bruce (?), which was easy to modify.
> The syntax is
>
> SET DateStyle TO 'iso'
> SET DateStyle TO 'postgres'
> SET DateStyle TO 'sql'
> SET DateStyle TO 'european'
> SET DateStyle TO 'noneuropean'
> SET DateStyle TO 'us' (same as "noneuropean")
> SET DateStyle TO 'default' (current same as "postgres,us")
>
> ("european" is just compared for the first 4 characters, and "noneuropean"
> is compared for the first 7 to allow less typing).
>
> Multiple arguments are allowed, so SET datestyle TO 'sql,euro' is valid.
>
> My mods also try to implement "SHOW variable" and "RESET variable", but
> that part just core dumps at the moment. I would guess that my errors
> are obvious to someone who knows what they are doing with the parser stuff,
> so if someone (Bruce and/or Martin??) could have it do the right thing
> we will have a more complete set of what we need.
>
> Also, I would like to have a floating point precision global variable to
> implement "SET precision TO 10" and perhaps "SET precision TO 10,2" for
> float8 and float4, but I don't know how to do that for integer types rather
> than strings. If someone is fixing the SHOW and RESET code, perhaps they can
> add some hooks for me to do the floats while they are at it.
>
> I've left some remnants of variable structures in the source code which
> I did not use in the interests of getting something working for v6.1.
> We'll have time to clean things up for the next release...
1997-04-23 05:18:27 +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-04-17 15:50:57 +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-04-17 15:50:57 +02:00
|
|
|
}
|
2004-05-07 02:24:59 +02:00
|
|
|
else if (pg_strcasecmp(tok, "DEFAULT") == 0)
|
1997-04-17 15:50:57 +02:00
|
|
|
{
|
2002-05-17 03:19:19 +02:00
|
|
|
/*
|
|
|
|
* Easiest way to get the current DEFAULT state is to fetch the
|
|
|
|
* DEFAULT string from guc.c and recursively parse it.
|
|
|
|
*
|
2011-04-07 06:11:01 +02:00
|
|
|
* We can't simply "return check_datestyle(...)" because we need
|
2002-05-17 03:19:19 +02:00
|
|
|
* to handle constructs like "DEFAULT, ISO".
|
|
|
|
*/
|
2011-04-07 06:11:01 +02:00
|
|
|
char *subval;
|
|
|
|
void *subextra = NULL;
|
2002-05-17 03:19:19 +02:00
|
|
|
|
2022-10-14 18:10:48 +02:00
|
|
|
subval = guc_strdup(LOG, 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))
|
|
|
|
{
|
2022-10-14 18:10:48 +02:00
|
|
|
guc_free(subval);
|
2011-04-07 06:11:01 +02:00
|
|
|
ok = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
myextra = (int *) subextra;
|
|
|
|
if (!have_style)
|
|
|
|
newDateStyle = myextra[0];
|
|
|
|
if (!have_order)
|
|
|
|
newDateOrder = myextra[1];
|
2022-10-14 18:10:48 +02:00
|
|
|
guc_free(subval);
|
|
|
|
guc_free(subextra);
|
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
|
|
|
/*
|
2022-10-14 18:10:48 +02:00
|
|
|
* Prepare the canonical string to return. GUC wants it guc_malloc'd.
|
2002-05-17 03:19:19 +02:00
|
|
|
*/
|
2022-10-14 18:10:48 +02:00
|
|
|
result = (char *) guc_malloc(LOG, 32);
|
2002-05-17 03:19:19 +02:00
|
|
|
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
|
|
|
|
2022-10-14 18:10:48 +02:00
|
|
|
guc_free(*newval);
|
2011-04-07 06:11:01 +02:00
|
|
|
*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
|
|
|
*/
|
2022-10-14 18:10:48 +02:00
|
|
|
myextra = (int *) guc_malloc(LOG, 2 * sizeof(int));
|
2011-04-07 06:11:01 +02:00
|
|
|
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
|
|
|
/*
|
|
|
|
* Support INTERVAL 'foo'. This is for SQL spec compliance, not
|
|
|
|
* 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
|
2007-12-28 01:23:23 +01:00
|
|
|
* ereport(ERROR), which is not desirable for GUC. We did what we
|
|
|
|
* 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,
|
|
|
|
CStringGetDatum(val),
|
|
|
|
ObjectIdGetDatum(InvalidOid),
|
|
|
|
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
|
|
|
|
*/
|
2022-10-14 18:10:48 +02:00
|
|
|
*extra = guc_malloc(LOG, 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-05-21 07:08:06 +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
|
|
|
*/
|
2022-10-14 18:10:48 +02:00
|
|
|
*extra = guc_malloc(LOG, 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;
|
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
|
|
|
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
|
|
|
/*
|
|
|
|
* TIMEZONE_ABBREVIATIONS
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GUC check_hook for assign_timezone_abbreviations
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
check_timezone_abbreviations(char **newval, void **extra, GucSource source)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* The boot_val for timezone_abbreviations is NULL. When we see that we
|
|
|
|
* just do nothing. If the value isn't overridden from the config file
|
|
|
|
* then pg_timezone_abbrev_initialize() will eventually replace it with
|
|
|
|
* "Default". This hack has two purposes: to avoid wasting cycles loading
|
|
|
|
* values that might soon be overridden from the config file, and to avoid
|
|
|
|
* trying to read the timezone abbrev files during InitializeGUCOptions().
|
|
|
|
* The latter doesn't work in an EXEC_BACKEND subprocess because
|
|
|
|
* my_exec_path hasn't been set yet and so we can't locate PGSHAREDIR.
|
|
|
|
*/
|
|
|
|
if (*newval == NULL)
|
|
|
|
{
|
|
|
|
Assert(source == PGC_S_DEFAULT);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2022-10-14 18:10:48 +02:00
|
|
|
/* OK, load the file and produce a guc_malloc'd TimeZoneAbbrevTable */
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
|
|
|
*extra = load_tzoffsets(*newval);
|
|
|
|
|
|
|
|
/* tzparser.c returns NULL on failure, reporting via GUC_check_errmsg */
|
|
|
|
if (!*extra)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GUC assign_hook for assign_timezone_abbreviations
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
assign_timezone_abbreviations(const char *newval, void *extra)
|
|
|
|
{
|
|
|
|
/* Do nothing for the boot_val default of NULL */
|
|
|
|
if (!extra)
|
|
|
|
return;
|
|
|
|
|
|
|
|
InstallTimeZoneAbbrevs((TimeZoneAbbrevTable *) extra);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
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
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
|
|
|
check_transaction_isolation(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
|
|
|
|
* commands to set it. We use the "extra" storage to ensure that rollbacks
|
|
|
|
* 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
|
|
|
{
|
2022-10-14 18:10:48 +02:00
|
|
|
*extra = guc_malloc(LOG, sizeof(int));
|
2011-04-07 06:11:01 +02:00
|
|
|
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-18 19:30: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);
|
|
|
|
|
I have committed many support files for CREATE CONVERSION. Default
conversion procs and conversions are added in initdb. Currently
supported conversions are:
UTF-8(UNICODE) <--> SQL_ASCII, ISO-8859-1 to 16, EUC_JP, EUC_KR,
EUC_CN, EUC_TW, SJIS, BIG5, GBK, GB18030, UHC,
JOHAB, TCVN
EUC_JP <--> SJIS
EUC_TW <--> BIG5
MULE_INTERNAL <--> EUC_JP, SJIS, EUC_TW, BIG5
Note that initial contents of pg_conversion system catalog are created
in the initdb process. So doing initdb required is ideal, it's
possible to add them to your databases by hand, however. To accomplish
this:
psql -f your_postgresql_install_path/share/conversion_create.sql your_database
So I did not bump up the version in cataversion.h.
TODO:
Add more conversion procs
Add [CASCADE|RESTRICT] to DROP CONVERSION
Add tuples to pg_depend
Add regression tests
Write docs
Add SQL99 CONVERT command?
--
Tatsuo Ishii
2002-07-18 04:02:30 +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 */
|
2023-11-30 06:11:45 +01:00
|
|
|
GUC_check_errdetail("Cannot change client_encoding now.");
|
2011-04-07 06:11:01 +02:00
|
|
|
}
|
|
|
|
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"
|
|
|
|
* 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)
|
|
|
|
{
|
2022-10-14 18:10:48 +02:00
|
|
|
guc_free(*newval);
|
|
|
|
*newval = guc_strdup(LOG, canonical_name);
|
2011-04-19 18:17:13 +02:00
|
|
|
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.
|
|
|
|
*/
|
2022-10-14 18:10:48 +02:00
|
|
|
*extra = guc_malloc(LOG, sizeof(int));
|
2011-04-07 06:11:01 +02:00
|
|
|
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),
|
2017-06-04 17:41:16 +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
|
|
|
|
* session_authorization cannot be set in postgresql.conf, which seems
|
|
|
|
* like a good thing anyway, so we don't work hard to avoid it.
|
|
|
|
*/
|
|
|
|
return false;
|
2002-05-17 03:19:19 +02:00
|
|
|
}
|
2003-02-01 19:31:28 +01:00
|
|
|
|
2023-07-14 06:10:36 +02:00
|
|
|
/*
|
|
|
|
* When source == PGC_S_TEST, we don't throw a hard error for a
|
|
|
|
* nonexistent user name or insufficient privileges, only a NOTICE. See
|
|
|
|
* comments in guc.h.
|
|
|
|
*/
|
|
|
|
|
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
|
|
|
{
|
Fix some inappropriately-disallowed uses of ALTER ROLE/DATABASE SET.
Most GUC check hooks that inspect database state have special checks
that prevent them from throwing hard errors for state-dependent issues
when source == PGC_S_TEST. This allows, for example,
"ALTER DATABASE d SET default_text_search_config = foo" when the "foo"
configuration hasn't been created yet. Without this, we have problems
during dump/reload or pg_upgrade, because pg_dump has no idea about
possible dependencies of GUC values and can't ensure a safe restore
ordering.
However, check_role() and check_session_authorization() hadn't gotten
the memo about that, and would throw hard errors anyway. It's not
entirely clear what is the use-case for "ALTER ROLE x SET role = y",
but we've now heard two independent complaints about that bollixing
an upgrade, so apparently some people are doing it.
Hence, fix these two functions to act more like other check hooks
with similar needs. (But I did not change their insistence on
being inside a transaction, as it's still not apparent that setting
either GUC from the configuration file would be wise.)
Also fix check_temp_buffers, which had a different form of the disease
of making state-dependent checks without any exception for PGC_S_TEST.
A cursory survey of other GUC check hooks did not find any more issues
of this ilk. (There are a lot of interdependencies among
PGC_POSTMASTER and PGC_SIGHUP GUCs, which may be a bad idea, but
they're not relevant to the immediate concern because they can't be
set via ALTER ROLE/DATABASE.)
Per reports from Charlie Hornsby and Nathan Bossart. Back-patch
to all supported branches.
Discussion: https://postgr.es/m/HE1P189MB0523B31598B0C772C908088DB7709@HE1P189MB0523.EURP189.PROD.OUTLOOK.COM
Discussion: https://postgr.es/m/20160711223641.1426.86096@wrigleys.postgresql.org
2021-04-13 21:10:18 +02:00
|
|
|
if (source == PGC_S_TEST)
|
|
|
|
{
|
|
|
|
ereport(NOTICE,
|
|
|
|
(errcode(ERRCODE_UNDEFINED_OBJECT),
|
|
|
|
errmsg("role \"%s\" does not exist", *newval)));
|
|
|
|
return true;
|
|
|
|
}
|
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
|
|
|
|
2023-07-14 06:10:36 +02:00
|
|
|
/*
|
|
|
|
* Only superusers may SET SESSION AUTHORIZATION a role other than itself.
|
|
|
|
* Note that in case of multiple SETs in a single session, the original
|
|
|
|
* authenticated user's superuserness is what matters.
|
|
|
|
*/
|
|
|
|
if (roleid != GetAuthenticatedUserId() &&
|
2023-07-14 06:13:45 +02:00
|
|
|
!superuser_arg(GetAuthenticatedUserId()))
|
2023-07-14 06:10:36 +02:00
|
|
|
{
|
|
|
|
if (source == PGC_S_TEST)
|
|
|
|
{
|
|
|
|
ereport(NOTICE,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
|
|
|
|
errmsg("permission will be denied to set session authorization \"%s\"",
|
|
|
|
*newval)));
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
GUC_check_errcode(ERRCODE_INSUFFICIENT_PRIVILEGE);
|
|
|
|
GUC_check_errmsg("permission denied to set session authorization \"%s\"",
|
|
|
|
*newval);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
/* Set up "extra" struct for assign_session_authorization to use */
|
2022-10-14 18:10:48 +02:00
|
|
|
myextra = (role_auth_extra *) guc_malloc(LOG, sizeof(role_auth_extra));
|
2011-04-07 06:11:01 +02:00
|
|
|
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;
|
2000-05-31 02:28:42 +02: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)
|
To: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
Subject: Re: [PATCHES] SET DateStyle patches
On Tue, 22 Apr 1997, Thomas Lockhart wrote:
> Some more patches! These (try to) finish implementing SET variable TO value
> for "DateStyle" (changed the name from simply "date" to be more descriptive).
> This is based on code from Martin and Bruce (?), which was easy to modify.
> The syntax is
>
> SET DateStyle TO 'iso'
> SET DateStyle TO 'postgres'
> SET DateStyle TO 'sql'
> SET DateStyle TO 'european'
> SET DateStyle TO 'noneuropean'
> SET DateStyle TO 'us' (same as "noneuropean")
> SET DateStyle TO 'default' (current same as "postgres,us")
>
> ("european" is just compared for the first 4 characters, and "noneuropean"
> is compared for the first 7 to allow less typing).
>
> Multiple arguments are allowed, so SET datestyle TO 'sql,euro' is valid.
>
> My mods also try to implement "SHOW variable" and "RESET variable", but
> that part just core dumps at the moment. I would guess that my errors
> are obvious to someone who knows what they are doing with the parser stuff,
> so if someone (Bruce and/or Martin??) could have it do the right thing
> we will have a more complete set of what we need.
>
> Also, I would like to have a floating point precision global variable to
> implement "SET precision TO 10" and perhaps "SET precision TO 10,2" for
> float8 and float4, but I don't know how to do that for integer types rather
> than strings. If someone is fixing the SHOW and RESET code, perhaps they can
> add some hooks for me to do the floats while they are at it.
>
> I've left some remnants of variable structures in the source code which
> I did not use in the interests of getting something working for v6.1.
> We'll have time to clean things up for the next release...
1997-04-23 05:18:27 +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);
|
2000-05-31 02:28:42 +02: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
|
|
|
*/
|
2023-03-02 13:49:39 +01:00
|
|
|
extern char *role_string; /* in guc_tables.c */
|
2005-07-26 00:12:34 +02:00
|
|
|
|
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-07-26 00:12:34 +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
|
|
|
}
|
|
|
|
|
Fix some inappropriately-disallowed uses of ALTER ROLE/DATABASE SET.
Most GUC check hooks that inspect database state have special checks
that prevent them from throwing hard errors for state-dependent issues
when source == PGC_S_TEST. This allows, for example,
"ALTER DATABASE d SET default_text_search_config = foo" when the "foo"
configuration hasn't been created yet. Without this, we have problems
during dump/reload or pg_upgrade, because pg_dump has no idea about
possible dependencies of GUC values and can't ensure a safe restore
ordering.
However, check_role() and check_session_authorization() hadn't gotten
the memo about that, and would throw hard errors anyway. It's not
entirely clear what is the use-case for "ALTER ROLE x SET role = y",
but we've now heard two independent complaints about that bollixing
an upgrade, so apparently some people are doing it.
Hence, fix these two functions to act more like other check hooks
with similar needs. (But I did not change their insistence on
being inside a transaction, as it's still not apparent that setting
either GUC from the configuration file would be wise.)
Also fix check_temp_buffers, which had a different form of the disease
of making state-dependent checks without any exception for PGC_S_TEST.
A cursory survey of other GUC check hooks did not find any more issues
of this ilk. (There are a lot of interdependencies among
PGC_POSTMASTER and PGC_SIGHUP GUCs, which may be a bad idea, but
they're not relevant to the immediate concern because they can't be
set via ALTER ROLE/DATABASE.)
Per reports from Charlie Hornsby and Nathan Bossart. Back-patch
to all supported branches.
Discussion: https://postgr.es/m/HE1P189MB0523B31598B0C772C908088DB7709@HE1P189MB0523.EURP189.PROD.OUTLOOK.COM
Discussion: https://postgr.es/m/20160711223641.1426.86096@wrigleys.postgresql.org
2021-04-13 21:10:18 +02:00
|
|
|
/*
|
|
|
|
* When source == PGC_S_TEST, we don't throw a hard error for a
|
|
|
|
* nonexistent user name or insufficient privileges, only a NOTICE.
|
|
|
|
* See comments in guc.h.
|
|
|
|
*/
|
|
|
|
|
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))
|
|
|
|
{
|
Fix some inappropriately-disallowed uses of ALTER ROLE/DATABASE SET.
Most GUC check hooks that inspect database state have special checks
that prevent them from throwing hard errors for state-dependent issues
when source == PGC_S_TEST. This allows, for example,
"ALTER DATABASE d SET default_text_search_config = foo" when the "foo"
configuration hasn't been created yet. Without this, we have problems
during dump/reload or pg_upgrade, because pg_dump has no idea about
possible dependencies of GUC values and can't ensure a safe restore
ordering.
However, check_role() and check_session_authorization() hadn't gotten
the memo about that, and would throw hard errors anyway. It's not
entirely clear what is the use-case for "ALTER ROLE x SET role = y",
but we've now heard two independent complaints about that bollixing
an upgrade, so apparently some people are doing it.
Hence, fix these two functions to act more like other check hooks
with similar needs. (But I did not change their insistence on
being inside a transaction, as it's still not apparent that setting
either GUC from the configuration file would be wise.)
Also fix check_temp_buffers, which had a different form of the disease
of making state-dependent checks without any exception for PGC_S_TEST.
A cursory survey of other GUC check hooks did not find any more issues
of this ilk. (There are a lot of interdependencies among
PGC_POSTMASTER and PGC_SIGHUP GUCs, which may be a bad idea, but
they're not relevant to the immediate concern because they can't be
set via ALTER ROLE/DATABASE.)
Per reports from Charlie Hornsby and Nathan Bossart. Back-patch
to all supported branches.
Discussion: https://postgr.es/m/HE1P189MB0523B31598B0C772C908088DB7709@HE1P189MB0523.EURP189.PROD.OUTLOOK.COM
Discussion: https://postgr.es/m/20160711223641.1426.86096@wrigleys.postgresql.org
2021-04-13 21:10:18 +02:00
|
|
|
if (source == PGC_S_TEST)
|
|
|
|
{
|
|
|
|
ereport(NOTICE,
|
|
|
|
(errcode(ERRCODE_UNDEFINED_OBJECT),
|
|
|
|
errmsg("role \"%s\" does not exist", *newval)));
|
|
|
|
return true;
|
|
|
|
}
|
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);
|
|
|
|
|
|
|
|
/*
|
2015-10-16 17:37:19 +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 &&
|
Add a SET option to the GRANT command.
Similar to how the INHERIT option controls whether or not the
permissions of the granted role are automatically available to the
grantee, the new SET permission controls whether or not the grantee
may use the SET ROLE command to assume the privileges of the granted
role.
In addition, the new SET permission controls whether or not it
is possible to transfer ownership of objects to the target role
or to create new objects owned by the target role using commands
such as CREATE DATABASE .. OWNER. We could alternatively have made
this controlled by the INHERIT option, or allow it when either
option is given. An advantage of this approach is that if you
are granted a predefined role with INHERIT TRUE, SET FALSE, you
can't go and create objects owned by that role.
The underlying theory here is that the ability to create objects
as a target role is not a privilege per se, and thus does not
depend on whether you inherit the target role's privileges. However,
it's surely something you could do anyway if you could SET ROLE
to the target role, and thus making it contingent on whether you
have that ability is reasonable.
Design review by Nathan Bossat, Wolfgang Walther, Jeff Davis,
Peter Eisentraut, and Stephen Frost.
Discussion: http://postgr.es/m/CA+Tgmob+zDSRS6JXYrgq0NWdzCXuTNzT5eK54Dn2hhgt17nm8A@mail.gmail.com
2022-11-18 18:32:50 +01:00
|
|
|
!member_can_set_role(GetSessionUserId(), roleid))
|
2005-07-26 00:12:34 +02:00
|
|
|
{
|
Fix some inappropriately-disallowed uses of ALTER ROLE/DATABASE SET.
Most GUC check hooks that inspect database state have special checks
that prevent them from throwing hard errors for state-dependent issues
when source == PGC_S_TEST. This allows, for example,
"ALTER DATABASE d SET default_text_search_config = foo" when the "foo"
configuration hasn't been created yet. Without this, we have problems
during dump/reload or pg_upgrade, because pg_dump has no idea about
possible dependencies of GUC values and can't ensure a safe restore
ordering.
However, check_role() and check_session_authorization() hadn't gotten
the memo about that, and would throw hard errors anyway. It's not
entirely clear what is the use-case for "ALTER ROLE x SET role = y",
but we've now heard two independent complaints about that bollixing
an upgrade, so apparently some people are doing it.
Hence, fix these two functions to act more like other check hooks
with similar needs. (But I did not change their insistence on
being inside a transaction, as it's still not apparent that setting
either GUC from the configuration file would be wise.)
Also fix check_temp_buffers, which had a different form of the disease
of making state-dependent checks without any exception for PGC_S_TEST.
A cursory survey of other GUC check hooks did not find any more issues
of this ilk. (There are a lot of interdependencies among
PGC_POSTMASTER and PGC_SIGHUP GUCs, which may be a bad idea, but
they're not relevant to the immediate concern because they can't be
set via ALTER ROLE/DATABASE.)
Per reports from Charlie Hornsby and Nathan Bossart. Back-patch
to all supported branches.
Discussion: https://postgr.es/m/HE1P189MB0523B31598B0C772C908088DB7709@HE1P189MB0523.EURP189.PROD.OUTLOOK.COM
Discussion: https://postgr.es/m/20160711223641.1426.86096@wrigleys.postgresql.org
2021-04-13 21:10:18 +02:00
|
|
|
if (source == PGC_S_TEST)
|
|
|
|
{
|
|
|
|
ereport(NOTICE,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
|
|
|
|
errmsg("permission will be denied to set role \"%s\"",
|
|
|
|
*newval)));
|
|
|
|
return true;
|
|
|
|
}
|
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 */
|
2022-10-14 18:10:48 +02:00
|
|
|
myextra = (role_auth_extra *) guc_malloc(LOG, sizeof(role_auth_extra));
|
2011-04-07 06:11:01 +02:00
|
|
|
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)
|
|
|
|
{
|
|
|
|
/*
|
2011-04-07 06:11:01 +02:00
|
|
|
* Check whether SET ROLE is active; if not return "none". This is a
|
|
|
|
* 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
|
|
|
}
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* PATH VARIABLES
|
|
|
|
*
|
|
|
|
* check_canonical_path is used for log_directory and some other GUCs where
|
|
|
|
* all we want to do is canonicalize the represented path name.
|
|
|
|
*/
|
|
|
|
|
|
|
|
bool
|
|
|
|
check_canonical_path(char **newval, void **extra, GucSource source)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Since canonicalize_path never enlarges the string, we can just modify
|
|
|
|
* newval in-place. But watch out for NULL, which is the default value
|
|
|
|
* for external_pid_file.
|
|
|
|
*/
|
|
|
|
if (*newval)
|
|
|
|
canonicalize_path(*newval);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* MISCELLANEOUS
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GUC check_hook for application_name
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
check_application_name(char **newval, void **extra, GucSource source)
|
|
|
|
{
|
|
|
|
char *clean;
|
2022-10-01 12:48:24 +02:00
|
|
|
char *ret;
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
|
|
|
|
|
|
|
/* Only allow clean ASCII chars in the application name */
|
|
|
|
clean = pg_clean_ascii(*newval, MCXT_ALLOC_NO_OOM);
|
|
|
|
if (!clean)
|
|
|
|
return false;
|
|
|
|
|
2022-10-01 12:48:24 +02:00
|
|
|
ret = guc_strdup(WARNING, clean);
|
|
|
|
if (!ret)
|
|
|
|
{
|
|
|
|
pfree(clean);
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
|
|
|
return false;
|
2022-10-01 12:48:24 +02:00
|
|
|
}
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
|
|
|
|
2022-10-01 12:48:24 +02:00
|
|
|
pfree(clean);
|
|
|
|
*newval = ret;
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GUC assign_hook for application_name
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
assign_application_name(const char *newval, void *extra)
|
|
|
|
{
|
|
|
|
/* Update the pg_stat_activity view */
|
|
|
|
pgstat_report_appname(newval);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GUC check_hook for cluster_name
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
check_cluster_name(char **newval, void **extra, GucSource source)
|
|
|
|
{
|
|
|
|
char *clean;
|
2022-10-01 12:48:24 +02:00
|
|
|
char *ret;
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
|
|
|
|
|
|
|
/* Only allow clean ASCII chars in the cluster name */
|
|
|
|
clean = pg_clean_ascii(*newval, MCXT_ALLOC_NO_OOM);
|
|
|
|
if (!clean)
|
|
|
|
return false;
|
|
|
|
|
2022-10-01 12:48:24 +02:00
|
|
|
ret = guc_strdup(WARNING, clean);
|
|
|
|
if (!ret)
|
|
|
|
{
|
|
|
|
pfree(clean);
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
|
|
|
return false;
|
2022-10-01 12:48:24 +02:00
|
|
|
}
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
|
|
|
|
2022-10-01 12:48:24 +02:00
|
|
|
pfree(clean);
|
|
|
|
*newval = ret;
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GUC assign_hook for maintenance_io_concurrency
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
assign_maintenance_io_concurrency(int newval, void *extra)
|
|
|
|
{
|
|
|
|
#ifdef USE_PREFETCH
|
|
|
|
/*
|
|
|
|
* Reconfigure recovery prefetching, because a setting it depends on
|
|
|
|
* changed.
|
|
|
|
*/
|
|
|
|
maintenance_io_concurrency = newval;
|
|
|
|
if (AmStartupProcess())
|
|
|
|
XLogPrefetchReconfigure();
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* These show hooks just exist because we want to show the values in octal.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GUC show_hook for data_directory_mode
|
|
|
|
*/
|
|
|
|
const char *
|
|
|
|
show_data_directory_mode(void)
|
|
|
|
{
|
|
|
|
static char buf[12];
|
|
|
|
|
|
|
|
snprintf(buf, sizeof(buf), "%04o", data_directory_mode);
|
|
|
|
return buf;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GUC show_hook for log_file_mode
|
|
|
|
*/
|
|
|
|
const char *
|
|
|
|
show_log_file_mode(void)
|
|
|
|
{
|
|
|
|
static char buf[12];
|
|
|
|
|
|
|
|
snprintf(buf, sizeof(buf), "%04o", Log_file_mode);
|
|
|
|
return buf;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GUC show_hook for unix_socket_permissions
|
|
|
|
*/
|
|
|
|
const char *
|
|
|
|
show_unix_socket_permissions(void)
|
|
|
|
{
|
|
|
|
static char buf[12];
|
|
|
|
|
|
|
|
snprintf(buf, sizeof(buf), "%04o", Unix_socket_permissions);
|
|
|
|
return buf;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* These check hooks do nothing more than reject non-default settings
|
|
|
|
* in builds that don't support them.
|
|
|
|
*/
|
|
|
|
|
|
|
|
bool
|
|
|
|
check_bonjour(bool *newval, void **extra, GucSource source)
|
|
|
|
{
|
|
|
|
#ifndef USE_BONJOUR
|
|
|
|
if (*newval)
|
|
|
|
{
|
|
|
|
GUC_check_errmsg("Bonjour is not supported by this build");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
check_default_with_oids(bool *newval, void **extra, GucSource source)
|
|
|
|
{
|
|
|
|
if (*newval)
|
|
|
|
{
|
|
|
|
/* check the GUC's definition for an explanation */
|
|
|
|
GUC_check_errcode(ERRCODE_FEATURE_NOT_SUPPORTED);
|
|
|
|
GUC_check_errmsg("tables declared WITH OIDS are not supported");
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
check_effective_io_concurrency(int *newval, void **extra, GucSource source)
|
|
|
|
{
|
|
|
|
#ifndef USE_PREFETCH
|
|
|
|
if (*newval != 0)
|
|
|
|
{
|
|
|
|
GUC_check_errdetail("effective_io_concurrency must be set to 0 on platforms that lack posix_fadvise().");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
#endif /* USE_PREFETCH */
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
check_maintenance_io_concurrency(int *newval, void **extra, GucSource source)
|
|
|
|
{
|
|
|
|
#ifndef USE_PREFETCH
|
|
|
|
if (*newval != 0)
|
|
|
|
{
|
|
|
|
GUC_check_errdetail("maintenance_io_concurrency must be set to 0 on platforms that lack posix_fadvise().");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
#endif /* USE_PREFETCH */
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
check_ssl(bool *newval, void **extra, GucSource source)
|
|
|
|
{
|
|
|
|
#ifndef USE_SSL
|
|
|
|
if (*newval)
|
|
|
|
{
|
|
|
|
GUC_check_errmsg("SSL is not supported by this build");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
return true;
|
|
|
|
}
|