mirror of
https://github.com/postgres/postgres.git
synced 2025-08-28 18:48:04 +03:00
Remove tabs after spaces in C comments
This was not changed in HEAD, but will be done later as part of a pgindent run. Future pgindent runs will also do this. Report by Tom Lane Backpatch through all supported branches, but not HEAD
This commit is contained in:
@@ -76,7 +76,7 @@ static void process_settings(Oid databaseid, Oid roleid);
|
||||
* GetDatabaseTuple -- fetch the pg_database row for a database
|
||||
*
|
||||
* This is used during backend startup when we don't yet have any access to
|
||||
* system catalogs in general. In the worst case, we can seqscan pg_database
|
||||
* system catalogs in general. In the worst case, we can seqscan pg_database
|
||||
* using nothing but the hard-wired descriptor that relcache.c creates for
|
||||
* pg_database. In more typical cases, relcache.c was able to load
|
||||
* descriptors for both pg_database and its indexes from the shared relcache
|
||||
@@ -100,7 +100,7 @@ GetDatabaseTuple(const char *dbname)
|
||||
CStringGetDatum(dbname));
|
||||
|
||||
/*
|
||||
* Open pg_database and fetch a tuple. Force heap scan if we haven't yet
|
||||
* Open pg_database and fetch a tuple. Force heap scan if we haven't yet
|
||||
* built the critical shared relcache entries (i.e., we're starting up
|
||||
* without a shared relcache cache file).
|
||||
*/
|
||||
@@ -143,7 +143,7 @@ GetDatabaseTupleByOid(Oid dboid)
|
||||
ObjectIdGetDatum(dboid));
|
||||
|
||||
/*
|
||||
* Open pg_database and fetch a tuple. Force heap scan if we haven't yet
|
||||
* Open pg_database and fetch a tuple. Force heap scan if we haven't yet
|
||||
* built the critical shared relcache entries (i.e., we're starting up
|
||||
* without a shared relcache cache file).
|
||||
*/
|
||||
@@ -184,7 +184,7 @@ PerformAuthentication(Port *port)
|
||||
* are loading them into the startup transaction's memory context, not
|
||||
* PostmasterContext, but that shouldn't matter.
|
||||
*
|
||||
* FIXME: [fork/exec] Ugh. Is there a way around this overhead?
|
||||
* FIXME: [fork/exec] Ugh. Is there a way around this overhead?
|
||||
*/
|
||||
#ifdef EXEC_BACKEND
|
||||
if (!load_hba())
|
||||
@@ -283,7 +283,7 @@ CheckMyDatabase(const char *name, bool am_superuser)
|
||||
name)));
|
||||
|
||||
/*
|
||||
* Check privilege to connect to the database. (The am_superuser test
|
||||
* Check privilege to connect to the database. (The am_superuser test
|
||||
* is redundant, but since we have the flag, might as well check it
|
||||
* and save a few cycles.)
|
||||
*/
|
||||
@@ -299,7 +299,7 @@ CheckMyDatabase(const char *name, bool am_superuser)
|
||||
* Check connection limit for this database.
|
||||
*
|
||||
* There is a race condition here --- we create our PGPROC before
|
||||
* checking for other PGPROCs. If two backends did this at about the
|
||||
* checking for other PGPROCs. If two backends did this at about the
|
||||
* same time, they might both think they were over the limit, while
|
||||
* ideally one should succeed and one fail. Getting that to work
|
||||
* exactly seems more trouble than it is worth, however; instead we
|
||||
@@ -444,7 +444,7 @@ BaseInit(void)
|
||||
* Initialize POSTGRES.
|
||||
*
|
||||
* The database can be specified by name, using the in_dbname parameter, or by
|
||||
* OID, using the dboid parameter. In the latter case, the actual database
|
||||
* OID, using the dboid parameter. In the latter case, the actual database
|
||||
* name can be returned to the caller in out_dbname. If out_dbname isn't
|
||||
* NULL, it must point to a buffer of size NAMEDATALEN.
|
||||
*
|
||||
@@ -838,7 +838,7 @@ InitPostgres(const char *in_dbname, Oid dboid, const char *username,
|
||||
|
||||
/*
|
||||
* Now process any command-line switches and any additional GUC variable
|
||||
* settings passed in the startup packet. We couldn't do this before
|
||||
* settings passed in the startup packet. We couldn't do this before
|
||||
* because we didn't know if client is a superuser.
|
||||
*/
|
||||
if (MyProcPort != NULL)
|
||||
|
Reference in New Issue
Block a user