| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: FastPathStrongRelationLocks still has an issue in HEAD |
| Date: | 2014-04-07 15:20:21 |
| Message-ID: | CA+TgmoZFfmQVZg88CoqSA-qnb6+t4zAKBs7nPXx=TKSuV3ZJdg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Apr 7, 2014 at 10:54 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> [ LockRefindAndRelease ] lacks an
>> Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0). I think
>> we should add one.
>
> Absolutely.
Turns out there were two places missing such an assertion: the 2PC
path, and the abort-strong-lock-acquire path. I added an assertion to
both. In theory, if the problem is coming from either of those
places, this might even increase the frequency of buildfarm failures,
since it removes the necessity for another normal-path release to hit
the same partition afterwards.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-04-07 15:37:36 | Re: B-Tree support function number 3 (strxfrm() optimization) |
| Previous Message | Tom Lane | 2014-04-07 14:54:25 | Re: FastPathStrongRelationLocks still has an issue in HEAD |