On Thu, Mar 17, 2016 at 6:07 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Chapman Flack <c...@anastigmatix.net> writes:
>> On 03/17/16 17:29, Kevin Grittner wrote:
>>> A grep with a quick skim of the results to exclude references to
>>> particular people who are mentioned by name and then referred to
>>> with a pronoun (which I assume we can leave alone), suggest there
>>> are about 70 lines in the 1346667 line C code base that need work.
>>> Any word-smiths out there who want to volunteer to sort this out?
>> So that must be N affected files for some N <= 70 ...
>> what would you think of starting a wiki page with those N filenames
>> (so nobody has to repeat your grepping/skimming effort), and volunteers
>> can claim a file or five, marking them taken on that page, and wordsmith
>> away?
> Yeah, Kevin, could you post your results?  I'd have guessed there were
> more trouble spots than that.  If that really is the size of the problem,
> seems like we could fix all those instances in one patch and be done
> with it.  (At least till new ones sneak in :-()

I see others have also been scanning the sgml sources, while I was
just looking at .c and .h files.  FWIW, I've attached grep results
based on what I used for my initial count, which was just scanning
for the six gender-specific pronouns that came to mind at the time
-- I probably missed some, but this should be the bulk of it I
think.  This time I included a few lines around each pronoun for
context; hopefully that makes it easier for the word-smiths.  I
removed results where "he" was used as a local variable name for a
HeapEntry and those places where the pronoun referred back to a
person (e.g., Knuth) who was mentioned just above.

Note that since multiple lines with gender-specific pronouns
sometimes are near each other and thus show up in the same block,
there are 59 blocks in 42 files.

Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
kgrittn@Kevin-Desktop:~/pg/master$ find -type f -name '*.[hc]' | grep -v 
'/tmp_check/' | grep -v '/Debug/' | xargs egrep -i -B3 -A3 
./src/include/nodes/primnodes.h- *
./src/include/nodes/primnodes.h- * isNatural, usingClause, and quals are 
interdependent.  The user can write
./src/include/nodes/primnodes.h- * only one of NATURAL, USING(), or ON() (this 
is enforced by the grammar).
./src/include/nodes/primnodes.h: * If he writes NATURAL then parse analysis 
generates the equivalent USING()
./src/include/nodes/primnodes.h- * list, and from that fills in "quals" with 
the right equality comparisons.
./src/include/nodes/primnodes.h: * If he writes USING() then "quals" is filled 
with equality comparisons.
./src/include/nodes/primnodes.h: * If he writes ON() then only "quals" is set.  
./src/include/nodes/primnodes.h- * are not equivalent to ON() since they also 
affect the output column list.
./src/include/nodes/primnodes.h- *
./src/include/nodes/primnodes.h- * alias is an Alias node representing the AS 
alias-clause attached to the
./src/include/c.h- * MemSetAligned is the same as MemSet except it omits the 
test to see if
./src/include/c.h- * "start" is word-aligned.  This is okay to use if the 
caller knows a-priori
./src/include/c.h: * that the pointer is suitably aligned (typically, because 
he just got it
./src/include/c.h- * from palloc(), which always delivers a max-aligned 
./src/include/c.h- */
./src/include/c.h-#define MemSetAligned(start, val, len) \
./src/bin/pg_dump/pg_backup_directory.c-typedef struct
./src/bin/pg_dump/pg_backup_directory.c-        /*
./src/bin/pg_dump/pg_backup_directory.c:         * Our archive location. This 
is basically what the user specified as his
./src/bin/pg_dump/pg_backup_directory.c-         * backup file but of course 
here it is a directory.
./src/bin/pg_dump/pg_backup_directory.c-         */
./src/bin/pg_dump/pg_backup_directory.c-        char       *directory;
./src/backend/nodes/makefuncs.c-        tle->resname = resname;
./src/backend/nodes/makefuncs.c-        /*
./src/backend/nodes/makefuncs.c:         * We always set these fields to 0. If 
the caller wants to change them he
./src/backend/nodes/makefuncs.c-         * must do so explicitly.  Few callers 
do that, so omitting these
./src/backend/nodes/makefuncs.c-         * arguments reduces the chance of 
./src/backend/nodes/makefuncs.c-         */
./src/backend/parser/parse_clause.c-     *        we may as well accept this 
common extension.
./src/backend/parser/parse_clause.c-     *
./src/backend/parser/parse_clause.c-     * Note that pre-existing resjunk 
targets must not be used in either case,
./src/backend/parser/parse_clause.c:     * since the user didn't write them in 
his SELECT list.
./src/backend/parser/parse_clause.c-     *
./src/backend/parser/parse_clause.c-     * If neither special case applies, 
fall through to treat the item as
./src/backend/parser/parse_clause.c-     * an expression per SQL99.
./src/backend/parser/parse_clause.c-             * by the ORDER BY.  There are 
two reasons to do this: it improves the
./src/backend/parser/parse_clause.c-             * odds that we can implement 
both GROUP BY and ORDER BY with a single
./src/backend/parser/parse_clause.c-             * sort step, and it allows the 
user to choose the equality semantics
./src/backend/parser/parse_clause.c:             * used by GROUP BY, should she 
be working with a datatype that has
./src/backend/parser/parse_clause.c-             * more than one equality 
./src/backend/parser/parse_clause.c-             *
./src/backend/parser/parse_clause.c-             * If we're in a grouping set, 
though, we force our requested ordering
./src/backend/parser/parse_clause.c- * As with GROUP BY, we absorb the sorting 
semantics of ORDER BY as much as
./src/backend/parser/parse_clause.c- * possible into the distinctClause.  This 
avoids a possible need to re-sort,
./src/backend/parser/parse_clause.c- * and allows the user to choose the 
equality semantics used by DISTINCT,
./src/backend/parser/parse_clause.c: * should she be working with a datatype 
that has more than one equality
./src/backend/parser/parse_clause.c- * operator.
./src/backend/parser/parse_clause.c- *
./src/backend/parser/parse_clause.c- * is_agg is true if we are transforming an 
aggregate(DISTINCT ...)
./src/backend/parser/parse_clause.c- * As with GROUP BY, we absorb the sorting 
semantics of ORDER BY as much as
./src/backend/parser/parse_clause.c- * possible into the distinctClause.  This 
avoids a possible need to re-sort,
./src/backend/parser/parse_clause.c- * and allows the user to choose the 
equality semantics used by DISTINCT,
./src/backend/parser/parse_clause.c: * should she be working with a datatype 
that has more than one equality
./src/backend/parser/parse_clause.c- * operator.
./src/backend/parser/parse_clause.c- */
./src/backend/parser/parse_clause.c-List *
./src/backend/storage/buffer/freelist.c-        /*
./src/backend/storage/buffer/freelist.c-         * If the slot hasn't been 
filled yet, tell the caller to allocate a new
./src/backend/storage/buffer/freelist.c:         * buffer with the normal 
allocation strategy.  He will then fill this
./src/backend/storage/buffer/freelist.c-         * slot by calling 
AddBufferToRing with the new buffer.
./src/backend/storage/buffer/freelist.c-         */
./src/backend/storage/buffer/freelist.c-        bufnum = 
./src/backend/storage/buffer/freelist.c-        /*
./src/backend/storage/buffer/freelist.c-         * Tell caller to allocate a 
new buffer with the normal allocation
./src/backend/storage/buffer/freelist.c:         * strategy.  He'll then 
replace this ring element via AddBufferToRing.
./src/backend/storage/buffer/freelist.c-         */
./src/backend/storage/buffer/freelist.c-        strategy->current_was_in_ring = 
./src/backend/storage/buffer/freelist.c-        return NULL;
./src/backend/storage/buffer/bufmgr.c- * In some scenarios there are race 
conditions in which multiple backends
./src/backend/storage/buffer/bufmgr.c- * could attempt the same I/O operation 
concurrently.  If someone else
./src/backend/storage/buffer/bufmgr.c- * has already started I/O on this buffer 
then we will block on the
./src/backend/storage/buffer/bufmgr.c: * io_in_progress lock until he's done.
./src/backend/storage/buffer/bufmgr.c- *
./src/backend/storage/buffer/bufmgr.c- * Input operations are only attempted on 
buffers that are not BM_VALID,
./src/backend/storage/buffer/bufmgr.c- * and output operations only on buffers 
that are BM_VALID and BM_DIRTY,
./src/backend/storage/buffer/bufmgr.c-           * The only way 
BM_IO_IN_PROGRESS could be set when the io_in_progress
./src/backend/storage/buffer/bufmgr.c-           * lock isn't held is if the 
process doing the I/O is recovering from
./src/backend/storage/buffer/bufmgr.c-           * an error (see 
AbortBufferIO).  If that's the case, we must wait for
./src/backend/storage/buffer/bufmgr.c:           * him to get unwedged.
./src/backend/storage/buffer/bufmgr.c-           */
./src/backend/storage/buffer/bufmgr.c-          UnlockBufHdr(buf);
./src/backend/storage/lmgr/lock.c-       * conflict made them wait must still 
exist.  NOTE: before MVCC, we could
./src/backend/storage/lmgr/lock.c-       * skip wakeup if 
lock->granted[lockmode] was still positive. But that's
./src/backend/storage/lmgr/lock.c-       * not true anymore, because the 
remaining granted locks might belong to
./src/backend/storage/lmgr/lock.c:       * some waiter, who could now be 
awakened because he doesn't conflict with
./src/backend/storage/lmgr/lock.c:       * his own locks.
./src/backend/storage/lmgr/lock.c-       */
./src/backend/storage/lmgr/lock.c-      if 
(lockMethodTable->conflictTab[lockmode] & lock->waitMask)
./src/backend/storage/lmgr/lock.c-              wakeupNeeded = true;
./src/backend/storage/lmgr/proc.c- *      So, now we grab enough semaphores to 
support the desired max number
./src/backend/storage/lmgr/proc.c- *      of backends immediately at 
initialization --- if the sysadmin has set
./src/backend/storage/lmgr/proc.c- *      MaxConnections, max_worker_processes, 
or autovacuum_max_workers higher
./src/backend/storage/lmgr/proc.c: *      than his kernel will support, he'll 
find out sooner rather than later.
./src/backend/storage/lmgr/proc.c- *
./src/backend/storage/lmgr/proc.c- *      Another reason for creating 
semaphores here is that the semaphore
./src/backend/storage/lmgr/proc.c- *      implementation typically requires us 
to create semaphores in the
./src/backend/storage/lmgr/proc.c-                              proc = (PGPROC 
*) proc->links.next;
./src/backend/storage/lmgr/proc.c-                              continue;
./src/backend/storage/lmgr/proc.c-                      }
./src/backend/storage/lmgr/proc.c:                      /* Must he wait for me? 
./src/backend/storage/lmgr/proc.c-                      if 
(lockMethodTable->conflictTab[proc->waitLockMode] & myHeldLocks)
./src/backend/storage/lmgr/proc.c-                      {
./src/backend/storage/lmgr/proc.c:                              /* Must I wait 
for him ? */
./src/backend/storage/lmgr/proc.c-                              if 
(lockMethodTable->conflictTab[lockmode] & proc->heldLocks)
./src/backend/storage/lmgr/proc.c-                              {
./src/backend/storage/lmgr/proc.c-                                      /*
./src/backend/storage/lmgr/proc.c-                                      return 
./src/backend/storage/lmgr/proc.c-                              }
./src/backend/storage/lmgr/proc.c:                              /* Break out of 
loop to put myself before him */
./src/backend/storage/lmgr/proc.c-                              break;
./src/backend/storage/lmgr/proc.c-                      }
./src/backend/storage/lmgr/proc.c-                      /* Nope, so advance to 
next waiter */
./src/backend/storage/lmgr/proc.c-              else
./src/backend/storage/lmgr/proc.c-              {
./src/backend/storage/lmgr/proc.c-                      /*
./src/backend/storage/lmgr/proc.c:                       * Cannot wake this 
guy. Remember his request for later checks.
./src/backend/storage/lmgr/proc.c-                       */
./src/backend/storage/lmgr/proc.c-                      aheadRequests |= 
./src/backend/storage/lmgr/proc.c-                      proc = (PGPROC *) 
./src/backend/storage/ipc/sinvaladt.c-          /*
./src/backend/storage/ipc/sinvaladt.c-           * If we must free some space 
and this backend is preventing it, force
./src/backend/storage/ipc/sinvaladt.c:           * him into reset state and 
then ignore until he catches up.
./src/backend/storage/ipc/sinvaladt.c-           */
./src/backend/storage/ipc/sinvaladt.c-          if (n < lowbound)
./src/backend/storage/ipc/sinvaladt.c-          {
./src/backend/storage/ipc/sinvaladt.c-                  stateP->resetState = 
./src/backend/storage/ipc/sinvaladt.c:                  /* no point in 
signaling him ... */
./src/backend/storage/ipc/sinvaladt.c-                  continue;
./src/backend/storage/ipc/sinvaladt.c-          }
./src/backend/port/sysv_sema.c-         /*
./src/backend/port/sysv_sema.c-          * Can only get here if some other 
process managed to create the same
./src/backend/port/sysv_sema.c:          * sema key before we did.  Let him 
have that one, loop around to try
./src/backend/port/sysv_sema.c-          * next key.
./src/backend/port/sysv_sema.c-          */
./src/backend/port/sysv_sema.c- }
./src/backend/port/sysv_shmem.c-                /*
./src/backend/port/sysv_shmem.c-                 * Can only get here if some 
other process managed to create the same
./src/backend/port/sysv_shmem.c:                 * shmem key before we did.  
Let him have that one, loop around to try
./src/backend/port/sysv_shmem.c-                 * next key.
./src/backend/port/sysv_shmem.c-                 */
./src/backend/port/sysv_shmem.c-        }
./src/backend/commands/user.c-          InvokeObjectDropHook(AuthIdRelationId, 
roleid, 0);
./src/backend/commands/user.c-          /*
./src/backend/commands/user.c:           * Lock the role, so nobody can add 
dependencies to her while we drop
./src/backend/commands/user.c:           * her.  We keep the lock until the end 
of transaction.
./src/backend/commands/user.c-           */
./src/backend/commands/user.c-          LockSharedObject(AuthIdRelationId, 
roleid, 0, AccessExclusiveLock);
./src/backend/commands/vacuum.c-        /*
./src/backend/commands/vacuum.c-         * Check permissions.
./src/backend/commands/vacuum.c-         *
./src/backend/commands/vacuum.c:         * We allow the user to vacuum a table 
if he is superuser, the table
./src/backend/commands/vacuum.c-         * owner, or the database owner (but in 
the latter case, only if it's not
./src/backend/commands/vacuum.c-         * a shared relation).  
pg_class_ownercheck includes the superuser case.
./src/backend/commands/vacuum.c-         *
./src/backend/commands/indexcmds.c-      *
./src/backend/commands/indexcmds.c-      * We could find more than one 
binary-compatible match.  If just one is
./src/backend/commands/indexcmds.c-      * for a preferred type, use that one; 
otherwise we fail, forcing the user
./src/backend/commands/indexcmds.c:      * to specify which one he wants.  (The 
preferred-type special case is a
./src/backend/commands/indexcmds.c-      * kluge for varchar: it's 
binary-compatible to both text and bpchar, so
./src/backend/commands/indexcmds.c-      * we need a tiebreaker.)  If we find 
more than one exact match, then
./src/backend/commands/indexcmds.c-      * someone put bogus entries in 
./src/backend/catalog/aclchk.c-         /*
./src/backend/catalog/aclchk.c-          * Grant options can only be granted to 
individual roles, not PUBLIC.
./src/backend/catalog/aclchk.c:          * The reason is that if a user would 
re-grant a privilege that he
./src/backend/catalog/aclchk.c-          * held through PUBLIC, and later the 
user is removed, the situation
./src/backend/catalog/aclchk.c-          * is impossible to clean up.
./src/backend/catalog/aclchk.c-          */
./src/backend/catalog/aclchk.c-                 /*
./src/backend/catalog/aclchk.c-                  * We insist that calling user 
be a member of each target role. If
./src/backend/catalog/aclchk.c:                  * he has that, he could become 
that role anyway via SET ROLE, so
./src/backend/catalog/aclchk.c-                  * FOR ROLE is just a syntactic 
convenience and doesn't give any
./src/backend/catalog/aclchk.c-                  * special privileges.
./src/backend/catalog/aclchk.c-                  */
./src/backend/catalog/aclchk.c-                  * and it also caused certain 
database states to not be
./src/backend/catalog/aclchk.c-                  * dumpable/restorable, since 
revoking CREATE doesn't cause
./src/backend/catalog/aclchk.c-                  * default privileges for the 
schema to go away.  So now, we just
./src/backend/catalog/aclchk.c:                  * allow the ALTER; if the user 
lacks CREATE he'll find out when
./src/backend/catalog/aclchk.c:                  * he tries to create an object.
./src/backend/catalog/aclchk.c-                  */
./src/backend/catalog/aclchk.c-                 SetDefaultACL(iacls);
./src/backend/catalog/pg_shdepend.c-                    Oid                     
roleid = newmembers[i];
./src/backend/catalog/pg_shdepend.c-                    /*
./src/backend/catalog/pg_shdepend.c:                     * Skip the owner: he 
has an OWNER shdep entry instead. (This is
./src/backend/catalog/pg_shdepend.c-                     * not just a space 
optimization; it makes ALTER OWNER easier. See
./src/backend/catalog/pg_shdepend.c-                     * notes in 
./src/backend/catalog/pg_shdepend.c-                     */
./src/backend/utils/adt/ruleutils.c-     * We always use dollar quoting.  
Figure out a suitable delimiter.
./src/backend/utils/adt/ruleutils.c-     *
./src/backend/utils/adt/ruleutils.c-     * Since the user is likely to be 
editing the function body string, we
./src/backend/utils/adt/ruleutils.c:     * shouldn't use a short delimiter that 
he might easily create a conflict
./src/backend/utils/adt/ruleutils.c-     * with.  Hence prefer "$function$", 
but extend if needed.
./src/backend/utils/adt/ruleutils.c-     */
./src/backend/utils/adt/ruleutils.c-    initStringInfo(&dq);
./src/backend/utils/adt/acl.c-  /*
./src/backend/utils/adt/acl.c-   * Note that the owner's entry shows all 
ordinary privileges but no grant
./src/backend/utils/adt/acl.c:   * options.  This is because his grant options 
come "from the system" and
./src/backend/utils/adt/acl.c:   * not from his own efforts.  (The SQL spec 
says that the owner's rights
./src/backend/utils/adt/acl.c-   * come from a "_SYSTEM" authid.)  However, we 
do consider that the
./src/backend/utils/adt/acl.c:   * owner's ordinary privileges are 
self-granted; this lets him revoke
./src/backend/utils/adt/acl.c-   * them.  We implement the owner's grant 
options without any explicit
./src/backend/utils/adt/acl.c-   * "_SYSTEM"-like ACL entry, by internally 
special-casing the owner
./src/backend/utils/adt/acl.c-   * wherever we are testing grant options.
./src/backend/utils/adt/acl.c-           * administrative maintenance.  Suppose 
Alice owns a database, has
./src/backend/utils/adt/acl.c-           * issued "GRANT alice TO bob", and 
runs a daily ANALYZE.  Bob creates
./src/backend/utils/adt/acl.c-           * an alice-owned SECURITY DEFINER 
function that issues "REVOKE alice
./src/backend/utils/adt/acl.c:           * FROM carol".  If he creates an 
expression index calling that
./src/backend/utils/adt/acl.c-           * function, Alice will attempt the 
REVOKE during each ANALYZE.
./src/backend/utils/adt/acl.c-           * Checking 
InSecurityRestrictedOperation() thwarts that attack.
./src/backend/utils/adt/acl.c-           *
./src/backend/utils/fmgr/fmgr.c- * particular function and that the user has 
access to both the language and
./src/backend/utils/fmgr/fmgr.c- * the function.  All validators should call 
this before doing anything
./src/backend/utils/fmgr/fmgr.c- * substantial.  Doing so ensures a user cannot 
achieve anything with explicit
./src/backend/utils/fmgr/fmgr.c: * calls to validators that he could not 
achieve with CREATE FUNCTION or by
./src/backend/utils/fmgr/fmgr.c- * simply calling an existing function.
./src/backend/utils/fmgr/fmgr.c- *
./src/backend/utils/fmgr/fmgr.c- * When this function returns false, callers 
should skip all validation work
./src/backend/utils/cache/plancache.c-  if (plansource->is_oneshot)
./src/backend/utils/cache/plancache.c-          elog(ERROR, "cannot move a 
one-shot cached plan to another context");
./src/backend/utils/cache/plancache.c:  /* OK, let the caller keep the plan 
where he wishes */
MemoryContextSetParent(plansource->context, newcontext);
./src/backend/utils/cache/plancache.c-  /*
./src/backend/libpq/hba.c- * hba.c
./src/backend/libpq/hba.c- *      Routines to handle host based authentication 
(that's the scheme
./src/backend/libpq/hba.c- *      wherein you authenticate a user by seeing 
what IP address the system
./src/backend/libpq/hba.c: *      says he comes from and choosing 
authentication method based on it).
./src/backend/libpq/hba.c- *
./src/backend/libpq/hba.c- * Portions Copyright (c) 1996-2016, PostgreSQL 
Global Development Group
./src/backend/libpq/hba.c- * Portions Copyright (c) 1994, Regents of the 
University of California
./src/backend/libpq/auth.c- *   Talk to the ident server on host 
"remote_ip_addr" and find out who
./src/backend/libpq/auth.c: *   owns the tcp connection from his port 
"remote_port" to port
./src/backend/libpq/auth.c- *   "local_port_addr" on host "local_ip_addr".  
Return the user name the
./src/backend/libpq/auth.c- *   ident server gives as "*ident_user".
./src/backend/libpq/auth.c- *
./src/backend/executor/execQual.c- *            may reference the contents of 
the exprContext's scan tuples
./src/backend/executor/execQual.c- *            and/or temporary results 
constructed in the exprContext.
./src/backend/executor/execQual.c- *            If the caller wishes the result 
to be valid longer than that
./src/backend/executor/execQual.c: *            data will be valid, he must 
call ExecMaterializeSlot on the
./src/backend/executor/execQual.c- *            result slot.
./src/backend/executor/execQual.c- */
./src/backend/executor/execQual.c-TupleTableSlot *
./src/backend/executor/functions.c- *
./src/backend/executor/functions.c- * The return value of a sql function is the 
value returned by the last
./src/backend/executor/functions.c- * canSetTag query in the function.  We do 
some ad-hoc type checking here
./src/backend/executor/functions.c: * to be sure that the user is returning the 
type he claims.  There are
./src/backend/executor/functions.c- * also a couple of strange-looking features 
to assist callers in dealing
./src/backend/executor/functions.c- * with allowed special cases, such as 
binary-compatible result types.
./src/backend/executor/functions.c- *
./src/backend/access/transam/xlog.c-     * its commit record into XLOG just 
before the REDO point, then a crash
./src/backend/access/transam/xlog.c-     * restart from the REDO point would 
not replay that record, which means
./src/backend/access/transam/xlog.c-     * that our flushing had better include 
the xact's update of pg_clog.  So
./src/backend/access/transam/xlog.c:     * we wait till he's out of his commit 
critical section before proceeding.
./src/backend/access/transam/xlog.c-     * See notes in 
./src/backend/access/transam/xlog.c-     *
./src/backend/access/transam/xlog.c-     * Because we've already released the 
insertion locks, this test is a bit
./src/backend/access/transam/xlog.c-     * minimizing lock contention.)
./src/backend/access/transam/xlog.c-     *
./src/backend/access/transam/xlog.c-     * A transaction that has not yet set 
delayChkpt when we look cannot be at
./src/backend/access/transam/xlog.c:     * risk, since he's not inserted his 
commit record yet; and one that's
./src/backend/access/transam/xlog.c:     * already cleared it is not at risk 
either, since he's done fixing clog
./src/backend/access/transam/xlog.c-     * and we will correctly flush the 
update below.  So we cannot miss any
./src/backend/access/transam/xlog.c-     * xacts we need to wait for.
./src/backend/access/transam/xlog.c-     */
./src/backend/access/transam/xlog.c-     * needs to be transported via 
streaming replication (hopefully with
./src/backend/access/transam/xlog.c-     * wal_keep_segments set high enough), 
or some more exotic mechanism like
./src/backend/access/transam/xlog.c-     * polling and copying files from 
pg_xlog with script. We have no
./src/backend/access/transam/xlog.c:     * knowledge of those mechanisms, so 
it's up to the user to ensure that he
./src/backend/access/transam/xlog.c-     * gets all the required WAL.
./src/backend/access/transam/xlog.c-     *
./src/backend/access/transam/xlog.c-     * We wait until both the last WAL file 
filled during backup and the
./src/backend/access/transam/xlog.c-     * archived as well.
./src/backend/access/transam/xlog.c-     *
./src/backend/access/transam/xlog.c-     * We wait forever, since 
archive_command is supposed to work and we
./src/backend/access/transam/xlog.c:     * assume the admin wanted his backup 
to work completely. If you don't
./src/backend/access/transam/xlog.c-     * wish to wait, you can set 
statement_timeout.  Also, some notices are
./src/backend/access/transam/xlog.c-     * issued to clue in anyone who might 
be doing this interactively.
./src/backend/access/transam/xlog.c-     */
./src/backend/access/transam/xact.c-                    /*
./src/backend/access/transam/xact.c-                     * If we are in 
TBLOCK_BEGIN it means something screwed up right
./src/backend/access/transam/xact.c-                     * after reading "BEGIN 
TRANSACTION".  We assume that the user
./src/backend/access/transam/xact.c:                     * will interpret the 
error as meaning the BEGIN failed to get him
./src/backend/access/transam/xact.c-                     * into a transaction 
block, so we should abort and return to idle
./src/backend/access/transam/xact.c-                     * state.
./src/backend/access/transam/xact.c-                     */
./src/backend/access/transam/twophase.c- * structures, to minimize the time we 
need to hold the TwoPhaseStateLock.
./src/backend/access/transam/twophase.c- *
./src/backend/access/transam/twophase.c- * WARNING -- we return even those 
transactions that are not fully prepared
./src/backend/access/transam/twophase.c: * yet.  The caller should filter them 
out if he doesn't want them.
./src/backend/access/transam/twophase.c- *
./src/backend/access/transam/twophase.c- * The returned array is palloc'd.
./src/backend/access/transam/twophase.c- */
./src/backend/access/index/genam.c- *
./src/backend/access/index/genam.c- *           The intent is that an AM 
implementor will define a beginscan routine
./src/backend/access/index/genam.c- *           that calls 
RelationGetIndexScan, to fill in the scan, and then does
./src/backend/access/index/genam.c: *           whatever kind of locking he 
./src/backend/access/index/genam.c- *
./src/backend/access/index/genam.c- *           At the end of a scan, the AM's 
endscan routine undoes the locking,
./src/backend/access/index/genam.c- *           but does *not* call 
IndexScanEnd --- the higher-level index_endscan
./src/backend/access/heap/heapam.c-     else if (old_infomask & 
./src/backend/access/heap/heapam.c-     {
./src/backend/access/heap/heapam.c-             /*
./src/backend/access/heap/heapam.c:              * It's a committed update, so 
we need to preserve him as updater of
./src/backend/access/heap/heapam.c-              * the tuple.
./src/backend/access/heap/heapam.c-              */
./src/backend/access/heap/heapam.c-             MultiXactStatus status;
./src/backend/access/heap/heapam.c-     {
./src/backend/access/heap/heapam.c-             /*
./src/backend/access/heap/heapam.c:              * It's a committed update, so 
we gotta preserve him as updater of the
./src/backend/access/heap/heapam.c-              * tuple.
./src/backend/access/heap/heapam.c-              */
./src/backend/access/heap/heapam.c-             MultiXactStatus status;
./src/backend/access/heap/heapam.c- * TransactionId read/write is assumed 
atomic anyway.  However there is a race
./src/backend/access/heap/heapam.c- * condition: someone who just fetched an 
old XID that we overwrite here could
./src/backend/access/heap/heapam.c- * conceivably not finish checking the XID 
against pg_clog before we finish
./src/backend/access/heap/heapam.c: * the VACUUM and perhaps truncate off the 
part of pg_clog he needs.  Getting
./src/backend/access/heap/heapam.c- * exclusive lock ensures no other backend 
is in process of checking the
./src/backend/access/heap/heapam.c- * tuple status.  Also, getting exclusive 
lock makes it safe to adjust the
./src/backend/access/heap/heapam.c- * infomask bits.
./src/backend/regex/regerror.c-                 if (r->code >= 0)
./src/backend/regex/regerror.c-                         msg = r->name;
./src/backend/regex/regerror.c-                 else
./src/backend/regex/regerror.c:                 {                               
        /* unknown; tell him the number */
./src/backend/regex/regerror.c-                         sprintf(convbuf, 
"REG_%u", (unsigned) icode);
./src/backend/regex/regerror.c-                         msg = convbuf;
./src/backend/regex/regerror.c-                 }
./src/backend/postmaster/postmaster.c-   * Note: AuthenticationTimeout is 
applied here while waiting for the
./src/backend/postmaster/postmaster.c-   * startup packet, and then again in 
InitPostgres for the duration of any
./src/backend/postmaster/postmaster.c-   * authentication operations.  So a 
hostile client could tie up the
./src/backend/postmaster/postmaster.c:   * process for nearly twice 
AuthenticationTimeout before we kick him off.
./src/backend/postmaster/postmaster.c-   *
./src/backend/postmaster/postmaster.c-   * Note: because PostgresMain will call 
InitializeTimeouts again, the
./src/backend/postmaster/postmaster.c-   * registration of 
STARTUP_PACKET_TIMEOUT will be lost.  This is okay
./src/backend/postmaster/pgstat.c-/* ----------
./src/backend/postmaster/pgstat.c- * pgstat_vacuum_stat() -
./src/backend/postmaster/pgstat.c- *
./src/backend/postmaster/pgstat.c: *    Will tell the collector about objects 
he can get rid of.
./src/backend/postmaster/pgstat.c- * ----------
./src/backend/postmaster/pgstat.c- */
./src/backend/postmaster/autovacuum.c-          LWLockAcquire(AutovacuumLock, 
./src/backend/postmaster/autovacuum.c-          /*
./src/backend/postmaster/autovacuum.c:           * Wake the launcher up so that 
he can launch a new worker immediately
./src/backend/postmaster/autovacuum.c-           * if required.  We only save 
the launcher's PID in local memory here;
./src/backend/postmaster/autovacuum.c-           * the actual signal will be 
sent when the PGPROC is recycled.  Note
./src/backend/postmaster/autovacuum.c-           * that we always do this, so 
that the launcher can rebalance the cost
./src/backend/postmaster/autovacuum.c- * autovac_init
./src/backend/postmaster/autovacuum.c- *                This is called at 
postmaster initialization.
./src/backend/postmaster/autovacuum.c- *
./src/backend/postmaster/autovacuum.c: * All we do here is annoy the user if he 
got it wrong.
./src/backend/postmaster/autovacuum.c- */
./src/backend/postmaster/pgarch.c-      /*
./src/backend/postmaster/pgarch.c-       * There shouldn't be anything for the 
archiver to do except to wait for a
./src/backend/postmaster/pgarch.c:       * signal ... however, the archiver 
exists to protect our data, so she
./src/backend/postmaster/pgarch.c-       * wakes up occasionally to allow 
herself to be proactive.
./src/backend/postmaster/pgarch.c-       */
./src/backend/postmaster/pgarch.c-      do
./src/backend/optimizer/plan/planner.c- {
./src/backend/optimizer/plan/planner.c-         /*
./src/backend/optimizer/plan/planner.c-          * We have no real idea how 
many tuples the user will ultimately FETCH
./src/backend/optimizer/plan/planner.c:          * from a cursor, but it is 
often the case that he doesn't want 'em
./src/backend/optimizer/plan/planner.c:          * all, or would prefer a 
fast-start plan anyway so that he can
./src/backend/optimizer/plan/planner.c-          * process some of the tuples 
sooner.  Use a GUC parameter to decide
./src/backend/optimizer/plan/planner.c-          * what fraction to optimize 
./src/backend/optimizer/plan/planner.c-          */
./src/backend/tcop/pquery.c-            portal->strategy = 
./src/backend/tcop/pquery.c-            /*
./src/backend/tcop/pquery.c:             * Fire her up according to the strategy
./src/backend/tcop/pquery.c-             */
./src/backend/tcop/pquery.c-            switch (portal->strategy)
./src/backend/tcop/pquery.c-            {
./src/interfaces/libpq/fe-secure-openssl.c- * In threadsafe mode, this includes 
setting up libcrypto callback functions
./src/interfaces/libpq/fe-secure-openssl.c- * to do thread locking.
./src/interfaces/libpq/fe-secure-openssl.c- *
./src/interfaces/libpq/fe-secure-openssl.c: * If the caller has told us 
(through PQinitOpenSSL) that he's taking care
./src/interfaces/libpq/fe-secure-openssl.c- * of libcrypto, we expect that 
callbacks are already set, and won't try to
./src/interfaces/libpq/fe-secure-openssl.c- * override it.
./src/interfaces/libpq/fe-secure-openssl.c- *
./src/interfaces/libpq/fe-lobj.c-        * signed int32 length.  So throw error 
if the given value overflows
./src/interfaces/libpq/fe-lobj.c-        * int32.  (A possible alternative is 
to automatically redirect the call
./src/interfaces/libpq/fe-lobj.c-        * to lo_truncate64; but if the caller 
wanted to rely on that backend
./src/interfaces/libpq/fe-lobj.c:        * function being available, he could 
have called lo_truncate64 for
./src/interfaces/libpq/fe-lobj.c-        * himself.)
./src/interfaces/libpq/fe-lobj.c-        */
./src/interfaces/libpq/fe-lobj.c-       if (len > (size_t) INT_MAX)
./src/common/pg_lzcompress.c- *                 amount of copy information to 
code into a tag. If so, a tag
./src/common/pg_lzcompress.c- *                 is omitted and all the input 
bytes covered by that are just
./src/common/pg_lzcompress.c- *                 scanned for the history add's, 
otherwise a literal character
./src/common/pg_lzcompress.c: *                 is omitted and only his history 
entry added.
./src/common/pg_lzcompress.c- *
./src/common/pg_lzcompress.c- *         Acknowledgements:
./src/common/pg_lzcompress.c- *
./contrib/postgres_fdw/postgres_fdw.c-  /*
./contrib/postgres_fdw/postgres_fdw.c-   * If user is willing to estimate cost 
for a scan of either of the joining
./contrib/postgres_fdw/postgres_fdw.c:   * relations using EXPLAIN, he intends 
to estimate scans on that relation
./contrib/postgres_fdw/postgres_fdw.c-   * more accurately. Then, it makes 
sense to estimate the cost the join
./contrib/postgres_fdw/postgres_fdw.c-   * with that relation more accurately 
using EXPLAIN.
./contrib/postgres_fdw/postgres_fdw.c-   */
./contrib/postgres_fdw/connection.c-            /*
./contrib/postgres_fdw/connection.c-             * Check that non-superuser has 
used password to establish connection;
./contrib/postgres_fdw/connection.c:             * otherwise, he's piggybacking 
on the postgres server's user
./contrib/postgres_fdw/connection.c-             * identity. See also 
dblink_security_check() in contrib/dblink.
./contrib/postgres_fdw/connection.c-             */
./contrib/postgres_fdw/connection.c-            if (!superuser() && 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to