← 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/storage/lmgr/lock.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/storage/lmgr/lock.c
187
187
 
188
188
/*
189
189
 * The fast-path lock mechanism is concerned only with relation locks on
190
 
 * unshared relations by backends bound to a database.  The fast-path
 
190
 * unshared relations by backends bound to a database.  The fast-path
191
191
 * mechanism exists mostly to accelerate acquisition and release of locks
192
192
 * that rarely conflict.  Because ShareUpdateExclusiveLock is
193
193
 * self-conflicting, it can't use the fast-path mechanism; but it also does
238
238
        uint32          count[FAST_PATH_STRONG_LOCK_HASH_PARTITIONS];
239
239
} FastPathStrongRelationLockData;
240
240
 
241
 
FastPathStrongRelationLockData *FastPathStrongRelationLocks;
 
241
volatile FastPathStrongRelationLockData *FastPathStrongRelationLocks;
242
242
 
243
243
 
244
244
/*
914
914
 
915
915
        /*
916
916
         * If lock requested conflicts with locks requested by waiters, must join
917
 
         * wait queue.  Otherwise, check for conflict with already-held locks.
 
917
         * wait queue.  Otherwise, check for conflict with already-held locks.
918
918
         * (That's last because most complex check.)
919
919
         */
920
920
        if (lockMethodTable->conflictTab[lockmode] & lock->waitMask)
995
995
 
996
996
                /*
997
997
                 * NOTE: do not do any material change of state between here and
998
 
                 * return.      All required changes in locktable state must have been
 
998
                 * return.  All required changes in locktable state must have been
999
999
                 * done when the lock was granted to us --- see notes in WaitOnLock.
1000
1000
                 */
1001
1001
 
1032
1032
        {
1033
1033
                /*
1034
1034
                 * Decode the locktag back to the original values, to avoid sending
1035
 
                 * lots of empty bytes with every message.      See lock.h to check how a
 
1035
                 * lots of empty bytes with every message.  See lock.h to check how a
1036
1036
                 * locktag is defined for LOCKTAG_RELATION
1037
1037
                 */
1038
1038
                LogAccessExclusiveLock(locktag->locktag_field1,
1290
1290
        }
1291
1291
 
1292
1292
        /*
1293
 
         * Rats.  Something conflicts.  But it could still be my own lock. We have
 
1293
         * Rats.  Something conflicts.  But it could still be my own lock. We have
1294
1294
         * to construct a conflict mask that does not reflect our own locks, but
1295
1295
         * only lock types held by other processes.
1296
1296
         */
1382
1382
 
1383
1383
        /*
1384
1384
         * We need only run ProcLockWakeup if the released lock conflicts with at
1385
 
         * least one of the lock types requested by waiter(s).  Otherwise whatever
 
1385
         * least one of the lock types requested by waiter(s).  Otherwise whatever
1386
1386
         * conflict made them wait must still exist.  NOTE: before MVCC, we could
1387
1387
         * skip wakeup if lock->granted[lockmode] was still positive. But that's
1388
1388
         * not true anymore, because the remaining granted locks might belong to
1402
1402
}
1403
1403
 
1404
1404
/*
1405
 
 * CleanUpLock -- clean up after releasing a lock.      We garbage-collect the
 
1405
 * CleanUpLock -- clean up after releasing a lock.  We garbage-collect the
1406
1406
 * proclock and lock objects if possible, and call ProcLockWakeup if there
1407
1407
 * are remaining requests and the caller says it's OK.  (Normally, this
1408
1408
 * should be called after UnGrantLock, and wakeupNeeded is the result from
1542
1542
        fasthashcode = FastPathStrongLockHashPartition(locallock->hashcode);
1543
1543
        Assert(locallock->holdsStrongLockCount == TRUE);
1544
1544
        SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
 
1545
        Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0);
1545
1546
        FastPathStrongRelationLocks->count[fasthashcode]--;
1546
1547
        locallock->holdsStrongLockCount = FALSE;
1547
1548
        StrongLockInProgress = NULL;
1823
1824
        }
1824
1825
 
1825
1826
        /*
1826
 
         * Decrease the total local count.      If we're still holding the lock, we're
 
1827
         * Decrease the total local count.  If we're still holding the lock, we're
1827
1828
         * done.
1828
1829
         */
1829
1830
        locallock->nLocks--;
1955
1956
#endif
1956
1957
 
1957
1958
        /*
1958
 
         * Get rid of our fast-path VXID lock, if appropriate.  Note that this is
 
1959
         * Get rid of our fast-path VXID lock, if appropriate.  Note that this is
1959
1960
         * the only way that the lock we hold on our own VXID can ever get
1960
1961
         * released: it is always and only released when a toplevel transaction
1961
1962
         * ends.
2042
2043
                         * fast-path data structures, we must acquire it before attempting
2043
2044
                         * to release the lock via the fast-path.  We will continue to
2044
2045
                         * hold the LWLock until we're done scanning the locallock table,
2045
 
                         * unless we hit a transferred fast-path lock.  (XXX is this
 
2046
                         * unless we hit a transferred fast-path lock.  (XXX is this
2046
2047
                         * really such a good idea?  There could be a lot of entries ...)
2047
2048
                         */
2048
2049
                        if (!have_fast_path_lwlock)
2061
2062
 
2062
2063
                        /*
2063
2064
                         * Our lock, originally taken via the fast path, has been
2064
 
                         * transferred to the main lock table.  That's going to require
 
2065
                         * transferred to the main lock table.  That's going to require
2065
2066
                         * some extra work, so release our fast-path lock before starting.
2066
2067
                         */
2067
2068
                        LWLockRelease(MyProc->backendLock);
2070
2071
                        /*
2071
2072
                         * Now dump the lock.  We haven't got a pointer to the LOCK or
2072
2073
                         * PROCLOCK in this case, so we have to handle this a bit
2073
 
                         * differently than a normal lock release.      Unfortunately, this
 
2074
                         * differently than a normal lock release.  Unfortunately, this
2074
2075
                         * requires an extra LWLock acquire-and-release cycle on the
2075
2076
                         * partitionLock, but hopefully it shouldn't happen often.
2076
2077
                         */
2503
2504
                 * acquiring proc->backendLock.  In particular, it's certainly safe to
2504
2505
                 * assume that if the target backend holds any fast-path locks, it
2505
2506
                 * must have performed a memory-fencing operation (in particular, an
2506
 
                 * LWLock acquisition) since setting proc->databaseId.  However, it's
 
2507
                 * LWLock acquisition) since setting proc->databaseId.  However, it's
2507
2508
                 * less clear that our backend is certain to have performed a memory
2508
 
                 * fencing operation since the other backend set proc->databaseId.      So
 
2509
                 * fencing operation since the other backend set proc->databaseId.  So
2509
2510
                 * for now, we test it after acquiring the LWLock just to be safe.
2510
2511
                 */
2511
2512
                if (proc->databaseId != locktag->locktag_field1)
2952
2953
                uint32          fasthashcode = FastPathStrongLockHashPartition(hashcode);
2953
2954
 
2954
2955
                SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
 
2956
                Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0);
2955
2957
                FastPathStrongRelationLocks->count[fasthashcode]--;
2956
2958
                SpinLockRelease(&FastPathStrongRelationLocks->mutex);
2957
2959
        }
3018
3020
                        continue;
3019
3021
 
3020
3022
                /*
3021
 
                 * If we have both session- and transaction-level locks, fail.  This
 
3023
                 * If we have both session- and transaction-level locks, fail.  This
3022
3024
                 * should never happen with regular locks, since we only take those at
3023
3025
                 * session level in some special operations like VACUUM.  It's
3024
3026
                 * possible to hit this with advisory locks, though.
3027
3029
                 * the transactional hold to the prepared xact.  However, that would
3028
3030
                 * require two PROCLOCK objects, and we cannot be sure that another
3029
3031
                 * PROCLOCK will be available when it comes time for PostPrepare_Locks
3030
 
                 * to do the deed.      So for now, we error out while we can still do so
 
3032
                 * to do the deed.  So for now, we error out while we can still do so
3031
3033
                 * safely.
3032
3034
                 */
3033
3035
                if (haveSessionLock)
3214
3216
                        /*
3215
3217
                         * We cannot simply modify proclock->tag.myProc to reassign
3216
3218
                         * ownership of the lock, because that's part of the hash key and
3217
 
                         * the proclock would then be in the wrong hash chain.  Instead
 
3219
                         * the proclock would then be in the wrong hash chain.  Instead
3218
3220
                         * use hash_update_hash_key.  (We used to create a new hash entry,
3219
3221
                         * but that risks out-of-memory failure if other processes are
3220
3222
                         * busy making proclocks too.)  We must unlink the proclock from
3314
3316
 
3315
3317
        /*
3316
3318
         * First, we iterate through the per-backend fast-path arrays, locking
3317
 
         * them one at a time.  This might produce an inconsistent picture of the
 
3319
         * them one at a time.  This might produce an inconsistent picture of the
3318
3320
         * system state, but taking all of those LWLocks at the same time seems
3319
3321
         * impractical (in particular, note MAX_SIMUL_LWLOCKS).  It shouldn't
3320
3322
         * matter too much, because none of these locks can be involved in lock
3393
3395
         * will be self-consistent.
3394
3396
         *
3395
3397
         * Since this is a read-only operation, we take shared instead of
3396
 
         * exclusive lock.      There's not a whole lot of point to this, because all
 
3398
         * exclusive lock.  There's not a whole lot of point to this, because all
3397
3399
         * the normal operations require exclusive lock, but it doesn't hurt
3398
3400
         * anything either. It will at least allow two backends to do
3399
3401
         * GetLockStatusData in parallel.
3912
3914
 *              as MyProc->lxid, you might wonder if we really need both.  The
3913
3915
 *              difference is that MyProc->lxid is set and cleared unlocked, and
3914
3916
 *              examined by procarray.c, while fpLocalTransactionId is protected by
3915
 
 *              backendLock and is used only by the locking subsystem.  Doing it this
 
3917
 *              backendLock and is used only by the locking subsystem.  Doing it this
3916
3918
 *              way makes it easier to verify that there are no funny race conditions.
3917
3919
 *
3918
3920
 *              We don't bother recording this lock in the local lock table, since it's