← Back to branch summary

~ubuntu-branches/ubuntu/trusty/postgresql-9.3/trusty-proposed

« back to all changes in this revision

Viewing changes to src/backend/access/transam/varsup.c

  • Committer: Package Import Robot
  • Author(s): Martin Pitt
  • Date: 2014-07-24 16:13:59 UTC
  • mfrom: (1.1.8)
  • Revision ID: package-import@ubuntu.com-20140724161359-uk325qfv03euxuuh
Tags: 9.3.5-0ubuntu0.14.04.1
https://launchpad.net/bugs/1348176
* New upstream bug fix release: (LP: #1348176)
  - pg_upgrade: Users who upgraded to version 9.3 using pg_upgrade may have
    an issue with transaction information which causes VACUUM to eventually
    fail. These users should run the script provided in the release notes to
    determine if their installation is affected, and then take the remedy
    steps outlined there.
  - Various data integrity and other bug fixes.
  - Secure Unix-domain sockets of temporary postmasters started during make
    check.
    Any local user able to access the socket file could connect as the
    server's bootstrap superuser, then proceed to execute arbitrary code as
    the operating-system user running the test, as we previously noted in
    CVE-2014-0067. This change defends against that risk by placing the
    server's socket in a temporary, mode 0700 subdirectory of /tmp.
  - See release notes for details:
    http://www.postgresql.org/about/news/1534/
* Remove pg_regress patches to support --host=/path, obsolete with above
  upstream changes and not applicable any more.
* Drop tcl8.6 patch, applied upstream.
* Add missing logrotate test dependency.

Show diffs side-by-side

added added

removed removed

Lines of Context:
src/backend/access/transam/varsup.c
39
39
 *
40
40
 * Note: when this is called, we are actually already inside a valid
41
41
 * transaction, since XIDs are now not allocated until the transaction
42
 
 * does something.      So it is safe to do a database lookup if we want to
 
42
 * does something.  So it is safe to do a database lookup if we want to
43
43
 * issue a warning about XID wrap.
44
44
 */
45
45
TransactionId
165
165
        /*
166
166
         * Now advance the nextXid counter.  This must not happen until after we
167
167
         * have successfully completed ExtendCLOG() --- if that routine fails, we
168
 
         * want the next incoming transaction to try it again.  We cannot assign
 
168
         * want the next incoming transaction to try it again.  We cannot assign
169
169
         * more XIDs until there is CLOG space for them.
170
170
         */
171
171
        TransactionIdAdvance(ShmemVariableCache->nextXid);
172
172
 
173
173
        /*
174
174
         * We must store the new XID into the shared ProcArray before releasing
175
 
         * XidGenLock.  This ensures that every active XID older than
 
175
         * XidGenLock.  This ensures that every active XID older than
176
176
         * latestCompletedXid is present in the ProcArray, which is essential for
177
177
         * correct OldestXmin tracking; see src/backend/access/transam/README.
178
178
         *
179
179
         * XXX by storing xid into MyPgXact without acquiring ProcArrayLock, we
180
180
         * are relying on fetch/store of an xid to be atomic, else other backends
181
 
         * might see a partially-set xid here.  But holding both locks at once
 
181
         * might see a partially-set xid here.  But holding both locks at once
182
182
         * would be a nasty concurrency hit.  So for now, assume atomicity.
183
183
         *
184
184
         * Note that readers of PGXACT xid fields should be careful to fetch the
289
289
 
290
290
        /*
291
291
         * We'll start complaining loudly when we get within 10M transactions of
292
 
         * the stop point.      This is kind of arbitrary, but if you let your gas
 
292
         * the stop point.  This is kind of arbitrary, but if you let your gas
293
293
         * gauge get down to 1% of full, would you be looking for the next gas
294
294
         * station?  We need to be fairly liberal about this number because there
295
295
         * are lots of scenarios where most transactions are done by automatic
390
390
 * We primarily check whether oldestXidDB is valid.  The cases we have in
391
391
 * mind are that that database was dropped, or the field was reset to zero
392
392
 * by pg_resetxlog.  In either case we should force recalculation of the
393
 
 * wrap limit.  Also do it if oldestXid is old enough to be forcing
 
393
 * wrap limit.  Also do it if oldestXid is old enough to be forcing
394
394
 * autovacuums or other actions; this ensures we update our state as soon
395
395
 * as possible once extra overhead is being incurred.
396
396
 */