← 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/port/sysv_sema.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/port/sysv_sema.c
253
253
 
254
254
                /*
255
255
                 * Can only get here if some other process managed to create the same
256
 
                 * sema key before we did.      Let him have that one, loop around to try
 
256
                 * sema key before we did.  Let him have that one, loop around to try
257
257
                 * next key.
258
258
                 */
259
259
        }
278
278
 *
279
279
 * This is called during postmaster start or shared memory reinitialization.
280
280
 * It should do whatever is needed to be able to support up to maxSemas
281
 
 * subsequent PGSemaphoreCreate calls.  Also, if any system resources
 
281
 * subsequent PGSemaphoreCreate calls.  Also, if any system resources
282
282
 * are acquired here or in PGSemaphoreCreate, register an on_shmem_exit
283
283
 * callback to release them.
284
284
 *
285
285
 * The port number is passed for possible use as a key (for SysV, we use
286
 
 * it to generate the starting semaphore key).  In a standalone backend,
 
286
 * it to generate the starting semaphore key).  In a standalone backend,
287
287
 * zero will be passed.
288
288
 *
289
289
 * In the SysV implementation, we acquire semaphore sets on-demand; the
378
378
         * from the operation prematurely because we were sent a signal.  So we
379
379
         * try and lock the semaphore again.
380
380
         *
381
 
         * Each time around the loop, we check for a cancel/die interrupt.      On
 
381
         * Each time around the loop, we check for a cancel/die interrupt.  On
382
382
         * some platforms, if such an interrupt comes in while we are waiting, it
383
383
         * will cause the semop() call to exit with errno == EINTR, allowing us to
384
384
         * service the interrupt (if not in a critical section already) during the
396
396
         * do CHECK_FOR_INTERRUPTS; then, a die() interrupt in this interval will
397
397
         * execute directly.  However, there is a huge pitfall: there is another
398
398
         * window of a few instructions after the semop() before we are able to
399
 
         * reset ImmediateInterruptOK.  If an interrupt occurs then, we'll lose
 
399
         * reset ImmediateInterruptOK.  If an interrupt occurs then, we'll lose
400
400
         * control, which means that the lock has been acquired but our caller did
401
401
         * not get a chance to record the fact. Therefore, we only set
402
402
         * ImmediateInterruptOK if the caller tells us it's OK to do so, ie, the
409
409
         * On some platforms, signals marked SA_RESTART (which is most, for us)
410
410
         * will not interrupt the semop(); it will just keep waiting.  Therefore
411
411
         * it's necessary for cancel/die interrupts to be serviced directly by the
412
 
         * signal handler.      On these platforms the behavior is really the same
 
412
         * signal handler.  On these platforms the behavior is really the same
413
413
         * whether the signal arrives just before the semop() begins, or while it
414
 
         * is waiting.  The loop on EINTR is thus important only for platforms
 
414
         * is waiting.  The loop on EINTR is thus important only for platforms
415
415
         * without SA_RESTART.
416
416
         */
417
417
        do