1996-08-28 03:59:28 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* pg_database.h
|
2018-04-19 23:14:09 +02:00
|
|
|
* definition of the "database" system catalog (pg_database)
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
|
*
|
2024-01-04 02:49:05 +01:00
|
|
|
* Portions Copyright (c) 1996-2024, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/catalog/pg_database.h
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
|
* NOTES
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
* The Catalog.pm module reads this file and derives schema
|
|
|
|
|
* information.
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef PG_DATABASE_H
|
|
|
|
|
#define PG_DATABASE_H
|
|
|
|
|
|
2008-03-27 04:57:34 +01:00
|
|
|
#include "catalog/genbki.h"
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
#include "catalog/pg_database_d.h"
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
|
/* ----------------
|
|
|
|
|
* pg_database definition. cpp turns this into
|
|
|
|
|
* typedef struct FormData_pg_database
|
|
|
|
|
* ----------------
|
|
|
|
|
*/
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
CATALOG(pg_database,1262,DatabaseRelationId) BKI_SHARED_RELATION BKI_ROWTYPE_OID(1248,DatabaseRelation_Rowtype_Id) BKI_SCHEMA_MACRO
|
1996-08-28 03:59:28 +02:00
|
|
|
{
|
2019-03-12 17:30:35 +01:00
|
|
|
/* oid */
|
|
|
|
|
Oid oid;
|
|
|
|
|
|
|
|
|
|
/* database name */
|
|
|
|
|
NameData datname;
|
|
|
|
|
|
|
|
|
|
/* owner of database */
|
2021-02-03 18:01:48 +01:00
|
|
|
Oid datdba BKI_DEFAULT(POSTGRES) BKI_LOOKUP(pg_authid);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
|
/* character encoding */
|
|
|
|
|
int32 encoding;
|
|
|
|
|
|
2022-03-17 11:11:21 +01:00
|
|
|
/* locale provider, see pg_collation.collprovider */
|
|
|
|
|
char datlocprovider;
|
|
|
|
|
|
2019-03-12 17:30:35 +01:00
|
|
|
/* allowed as CREATE DATABASE template? */
|
|
|
|
|
bool datistemplate;
|
|
|
|
|
|
|
|
|
|
/* new connections allowed? */
|
|
|
|
|
bool datallowconn;
|
|
|
|
|
|
Add support event triggers on authenticated login
This commit introduces trigger on login event, allowing to fire some actions
right on the user connection. This can be useful for logging or connection
check purposes as well as for some personalization of environment. Usage
details are described in the documentation included, but shortly usage is
the same as for other triggers: create function returning event_trigger and
then create event trigger on login event.
In order to prevent the connection time overhead when there are no triggers
the commit introduces pg_database.dathasloginevt flag, which indicates database
has active login triggers. This flag is set by CREATE/ALTER EVENT TRIGGER
command, and unset at connection time when no active triggers found.
Author: Konstantin Knizhnik, Mikhail Gribkov
Discussion: https://postgr.es/m/0d46d29f-4558-3af9-9c85-7774e14a7709%40postgrespro.ru
Reviewed-by: Pavel Stehule, Takayuki Tsunakawa, Greg Nancarrow, Ivan Panchenko
Reviewed-by: Daniel Gustafsson, Teodor Sigaev, Robert Haas, Andres Freund
Reviewed-by: Tom Lane, Andrey Sokolov, Zhihong Yu, Sergey Shinderuk
Reviewed-by: Gregory Stark, Nikita Malakhov, Ted Yu
2023-10-16 02:16:55 +02:00
|
|
|
/* database has login event triggers? */
|
|
|
|
|
bool dathasloginevt;
|
|
|
|
|
|
Handle DROP DATABASE getting interrupted
Until now, when DROP DATABASE got interrupted in the wrong moment, the removal
of the pg_database row would also roll back, even though some irreversible
steps have already been taken. E.g. DropDatabaseBuffers() might have thrown
out dirty buffers, or files could have been unlinked. But we continued to
allow connections to such a corrupted database.
To fix this, mark databases invalid with an in-place update, just before
starting to perform irreversible steps. As we can't add a new column in the
back branches, we use pg_database.datconnlimit = -2 for this purpose.
An invalid database cannot be connected to anymore, but can still be
dropped.
Unfortunately we can't easily add output to psql's \l to indicate that some
database is invalid, it doesn't fit in any of the existing columns.
Add tests verifying that a interrupted DROP DATABASE is handled correctly in
the backend and in various tools.
Reported-by: Evgeny Morozov <postgresql3@realityexists.net>
Author: Andres Freund <andres@anarazel.de>
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>
Discussion: https://postgr.es/m/20230509004637.cgvmfwrbht7xm7p6@awork3.anarazel.de
Discussion: https://postgr.es/m/20230314174521.74jl6ffqsee5mtug@awork3.anarazel.de
Backpatch: 11-, bug present in all supported versions
2023-07-13 22:03:28 +02:00
|
|
|
/*
|
|
|
|
|
* Max connections allowed. Negative values have special meaning, see
|
|
|
|
|
* DATCONNLIMIT_* defines below.
|
|
|
|
|
*/
|
2019-03-12 17:30:35 +01:00
|
|
|
int32 datconnlimit;
|
|
|
|
|
|
|
|
|
|
/* all Xids < this are frozen in this DB */
|
|
|
|
|
TransactionId datfrozenxid;
|
|
|
|
|
|
|
|
|
|
/* all multixacts in the DB are >= this */
|
|
|
|
|
TransactionId datminmxid;
|
|
|
|
|
|
|
|
|
|
/* default table space for this DB */
|
|
|
|
|
Oid dattablespace BKI_LOOKUP(pg_tablespace);
|
2012-06-10 21:20:04 +02:00
|
|
|
|
2012-01-27 19:16:17 +01:00
|
|
|
#ifdef CATALOG_VARLEN /* variable-length fields start here */
|
2022-01-27 08:44:31 +01:00
|
|
|
/* LC_COLLATE setting */
|
|
|
|
|
text datcollate BKI_FORCE_NOT_NULL;
|
|
|
|
|
|
|
|
|
|
/* LC_CTYPE setting */
|
|
|
|
|
text datctype BKI_FORCE_NOT_NULL;
|
|
|
|
|
|
2022-03-17 11:11:21 +01:00
|
|
|
/* ICU locale ID */
|
2024-03-09 23:48:18 +01:00
|
|
|
text datlocale;
|
2022-03-17 11:11:21 +01:00
|
|
|
|
2023-03-08 16:35:42 +01:00
|
|
|
/* ICU collation rules */
|
|
|
|
|
text daticurules;
|
|
|
|
|
|
2022-02-14 08:09:04 +01:00
|
|
|
/* provider-dependent version of collation data */
|
|
|
|
|
text datcollversion BKI_DEFAULT(_null_);
|
|
|
|
|
|
2019-03-12 17:30:35 +01:00
|
|
|
/* access permissions */
|
|
|
|
|
aclitem datacl[1];
|
2012-01-27 19:16:17 +01:00
|
|
|
#endif
|
1996-08-28 03:59:28 +02:00
|
|
|
} FormData_pg_database;
|
1998-09-01 06:40:42 +02:00
|
|
|
|
1996-08-28 03:59:28 +02:00
|
|
|
/* ----------------
|
|
|
|
|
* Form_pg_database corresponds to a pointer to a tuple with
|
|
|
|
|
* the format of pg_database relation.
|
|
|
|
|
* ----------------
|
|
|
|
|
*/
|
|
|
|
|
typedef FormData_pg_database *Form_pg_database;
|
|
|
|
|
|
2022-04-21 18:02:23 +02:00
|
|
|
DECLARE_TOAST_WITH_MACRO(pg_database, 4177, 4178, PgDatabaseToastTable, PgDatabaseToastIndex);
|
2020-11-07 12:11:40 +01:00
|
|
|
|
2023-08-31 08:14:57 +02:00
|
|
|
DECLARE_UNIQUE_INDEX(pg_database_datname_index, 2671, DatabaseNameIndexId, pg_database, btree(datname name_ops));
|
|
|
|
|
DECLARE_UNIQUE_INDEX_PKEY(pg_database_oid_index, 2672, DatabaseOidIndexId, pg_database, btree(oid oid_ops));
|
2020-11-07 12:11:40 +01:00
|
|
|
|
2024-01-23 07:13:38 +01:00
|
|
|
MAKE_SYSCACHE(DATABASEOID, pg_database_oid_index, 4);
|
|
|
|
|
|
Rethink method for assigning OIDs to the template0 and postgres DBs.
Commit aa0105141 assigned fixed OIDs to template0 and postgres
in a very ad-hoc way. Notably, instead of teaching Catalog.pm
about these OIDs, the unused_oids script was just hacked to
not show them as unused. That's problematic since, for example,
duplicate_oids wouldn't report any future conflict. Hence,
invent a macro DECLARE_OID_DEFINING_MACRO() that can be used to
define an OID that is known to Catalog.pm and will participate
in duplicate-detection as well as renumbering by renumber_oids.pl.
(We don't anticipate renumbering these particular OIDs, but we
might as well build out all the Catalog.pm infrastructure while
we're here.)
Another issue is that aa0105141 neglected to touch IsPinnedObject,
with the result that it now claimed template0 and postgres are
pinned. The right thing to do there seems to be to teach it that
no database is pinned, since in fact DROP DATABASE doesn't check
for pinned-ness (and at least for these cases, that is an
intentional choice). It's not clear whether this wrong answer
had any visible effect, but perhaps it could have resulted in
erroneous management of dependency entries.
In passing, rename the TemplateDbOid macro to Template1DbOid
to reduce confusion (likely we should have done that way back
when we invented template0, but we didn't), and rename the
OID macros for template0 and postgres to have a similar style.
There are no changes to postgres.bki here, so no need for a
catversion bump.
Discussion: https://postgr.es/m/2935358.1650479692@sss.pgh.pa.us
2022-04-21 22:23:12 +02:00
|
|
|
/*
|
|
|
|
|
* pg_database.dat contains an entry for template1, but not for the template0
|
|
|
|
|
* or postgres databases, because those are created later in initdb.
|
|
|
|
|
* However, we still want to manually assign the OIDs for template0 and
|
|
|
|
|
* postgres, so declare those here.
|
|
|
|
|
*/
|
|
|
|
|
DECLARE_OID_DEFINING_MACRO(Template0DbOid, 4);
|
|
|
|
|
DECLARE_OID_DEFINING_MACRO(PostgresDbOid, 5);
|
|
|
|
|
|
Handle DROP DATABASE getting interrupted
Until now, when DROP DATABASE got interrupted in the wrong moment, the removal
of the pg_database row would also roll back, even though some irreversible
steps have already been taken. E.g. DropDatabaseBuffers() might have thrown
out dirty buffers, or files could have been unlinked. But we continued to
allow connections to such a corrupted database.
To fix this, mark databases invalid with an in-place update, just before
starting to perform irreversible steps. As we can't add a new column in the
back branches, we use pg_database.datconnlimit = -2 for this purpose.
An invalid database cannot be connected to anymore, but can still be
dropped.
Unfortunately we can't easily add output to psql's \l to indicate that some
database is invalid, it doesn't fit in any of the existing columns.
Add tests verifying that a interrupted DROP DATABASE is handled correctly in
the backend and in various tools.
Reported-by: Evgeny Morozov <postgresql3@realityexists.net>
Author: Andres Freund <andres@anarazel.de>
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>
Discussion: https://postgr.es/m/20230509004637.cgvmfwrbht7xm7p6@awork3.anarazel.de
Discussion: https://postgr.es/m/20230314174521.74jl6ffqsee5mtug@awork3.anarazel.de
Backpatch: 11-, bug present in all supported versions
2023-07-13 22:03:28 +02:00
|
|
|
/*
|
|
|
|
|
* Special values for pg_database.datconnlimit. Normal values are >= 0.
|
|
|
|
|
*/
|
|
|
|
|
#define DATCONNLIMIT_UNLIMITED -1 /* no limit */
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* A database is set to invalid partway through being dropped. Using
|
|
|
|
|
* datconnlimit=-2 for this purpose isn't particularly clean, but is
|
|
|
|
|
* backpatchable.
|
|
|
|
|
*/
|
|
|
|
|
#define DATCONNLIMIT_INVALID_DB -2
|
|
|
|
|
|
|
|
|
|
extern bool database_is_invalid_form(Form_pg_database datform);
|
|
|
|
|
extern bool database_is_invalid_oid(Oid dboid);
|
|
|
|
|
|
1996-08-28 03:59:28 +02:00
|
|
|
#endif /* PG_DATABASE_H */
|
