Skip site navigation (1) Skip section navigation (2)

heap_update is broken in current sources

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: heap_update is broken in current sources
Date: 2001-01-07 21:38:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
heap_update() currently ends with

    if (newbuf != buffer)
        LockBuffer(newbuf, BUFFER_LOCK_UNLOCK);
    LockBuffer(buffer, BUFFER_LOCK_UNLOCK);

    /* invalidate caches */
    RelationInvalidateHeapTuple(relation, &oldtup);
    RelationMark4RollbackHeapTuple(relation, newtup);

    return HeapTupleMayBeUpdated;

This is broken because WriteBuffer releases our refcounts on the buffer
pages that are holding the old and new tuples.  By the time
RelationInvalidateHeapTuple gets to do its thing, some other backend may
have swapped a new disk page into the shared buffer that oldtup points
at.  catcache.c will then be using the wrong data to compute the hash
index of the old tuple.  This will at minimum result in failure to
invalidate the old tuple out of our catcache (because we'll be searching
the wrong hashchains), and can lead to a flat-out crash or Assert
failure due to invalid data being fed to the hashing code.

I have seen several nonrepeatable failures in the parallel regress tests
in recent weeks, which I now believe are all traceable to this error.

I will commit a fix for this error shortly, and have recommended to Marc
that he re-roll the beta2 tarball before announcing it...

			regards, tom lane


pgsql-hackers by date

Next:From: Emmanuel CharpentierDate: 2001-01-07 22:10:30
Subject: Re: A post-7.1 wish-list.
Previous:From: Lamar OwenDate: 2001-01-07 21:14:09
Subject: Re: Re: Beta2 ... ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group