From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Curious buildfarm failures |
Date: | 2013-01-14 22:37:44 |
Message-ID: | 50F488B8.9070402@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 15.01.2013 00:14, Heikki Linnakangas wrote:
> On 14.01.2013 23:35, Tom Lane wrote:
>> Since commit 2065dd2834e832eb820f1fbcd16746d6af1f6037, there have been
>> a few buildfarm failures along the lines of
>>
>> -- Commit table drop
>> COMMIT PREPARED 'regress-two';
>> ! PANIC: failed to re-find shared proclock object
>> ! PANIC: failed to re-find shared proclock object
>> ! connection to server was lost
>>
>> Evidently I bollixed something, but what? I've been unable to reproduce
>> this locally so far. Anybody see what's wrong?
>
> I was able to reproduce this by setting max_locks_per_transaction and
> max_connections to the minimum. My assumption is that there's something
> wrong in the way hash_update_hash_key() handles collisions.
The problem seems to be when the the old and the key hash to the same
bucket. In that case, hash_update_hash_key() tries to link the entry to
itself. The attached patch fixes it for me.
- Heikki
Attachment | Content-Type | Size |
---|---|---|
handle-same-bucket-key-update-1.patch | text/x-diff | 1.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2013-01-14 22:49:05 | Re: s/size_t/off_t/ in sendTimeLineHistory |
Previous Message | Gurjeet Singh | 2013-01-14 22:31:42 | Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT |