On Wed, Aug 24, 2016 at 11:44 AM, Mark Kirkwood
wrote:
> On 24/08/16 17:01, Mark Kirkwood wrote:
>>
>>
>> ...actually I was wrong there, only 2 of them were the same. So I've
>> attached a new log of bt's of them all.
>>
>>
>>
>
> And I can reproduce with only 1 session, figured that might be a he
On 24/08/16 17:01, Mark Kirkwood wrote:
...actually I was wrong there, only 2 of them were the same. So I've
attached a new log of bt's of them all.
And I can reproduce with only 1 session, figured that might be a helpful
piece of the puzzle (trace attached).
$ pgbench -c 1 -T600 benc
On 24/08/16 16:52, Mark Kirkwood wrote:
On 24/08/16 16:33, Amit Kapila wrote:
On Wed, Aug 24, 2016 at 9:53 AM, Mark Kirkwood
wrote:
On 24/08/16 15:36, Amit Kapila wrote:
On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood
wrote:
Can you get the call stacks?
For every stuck backend? (just double
On Wed, Aug 24, 2016 at 2:37 AM, Jeff Janes wrote:
> Hi Amit,
>
> Thanks for working on this.
>
> When building with --enable-cassert, I get compiler warning:
>
> hash.c: In function 'hashbucketcleanup':
> hash.c:722: warning: 'new_bucket' may be used uninitialized in this function
>
This warning
On 24/08/16 16:33, Amit Kapila wrote:
On Wed, Aug 24, 2016 at 9:53 AM, Mark Kirkwood
wrote:
On 24/08/16 15:36, Amit Kapila wrote:
On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood
wrote:
Can you get the call stacks?
For every stuck backend? (just double checking)...
Yeah.
Cool,
I managed
On Wed, Aug 24, 2016 at 9:53 AM, Mark Kirkwood
wrote:
> On 24/08/16 15:36, Amit Kapila wrote:
>>
>> On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood
>> wrote:
>>>
>>
>> Can you get the call stacks?
>>
>
> For every stuck backend? (just double checking)...
Yeah.
--
With Regards,
Amit Kapila.
Ente
On 24/08/16 15:36, Amit Kapila wrote:
On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood
wrote:
On 24/08/16 12:09, Mark Kirkwood wrote:
On 23/08/16 15:24, Amit Kapila wrote:
Thoughts?
Note - To use this patch, first apply latest version of concurrent
hash index patch [2].
[1] - https://commitf
On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood
wrote:
> On 24/08/16 12:09, Mark Kirkwood wrote:
>>
>> On 23/08/16 15:24, Amit Kapila wrote:
>>>
>>>
>>> Thoughts?
>>>
>>> Note - To use this patch, first apply latest version of concurrent
>>> hash index patch [2].
>>>
>>> [1] - https://commitfest.po
On 24/08/16 12:09, Mark Kirkwood wrote:
On 23/08/16 15:24, Amit Kapila wrote:
Thoughts?
Note - To use this patch, first apply latest version of concurrent
hash index patch [2].
[1] - https://commitfest.postgresql.org/10/647/
[2] -
https://www.postgresql.org/message-id/caa4ek1lkq_udism-z2dq6c
On 23/08/16 15:24, Amit Kapila wrote:
Thoughts?
Note - To use this patch, first apply latest version of concurrent
hash index patch [2].
[1] - https://commitfest.postgresql.org/10/647/
[2] -
https://www.postgresql.org/message-id/caa4ek1lkq_udism-z2dq6cuvjh3db5fnfnnezzbpsrjw0ha...@mail.gmail.c
Hi Amit,
Thanks for working on this.
When building with --enable-cassert, I get compiler warning:
hash.c: In function 'hashbucketcleanup':
hash.c:722: warning: 'new_bucket' may be used uninitialized in this function
After an intentionally created crash, I get an Assert triggering:
TRAP: Faile
Hi All,
Following are the steps that i have followed to verify the WAL Logging
of hash index,
1. I used Mithun's patch to improve coverage of hash index code [1] to
verify the WAL Logging of hash index. Firstly i have confirmed if all
the XLOG records associated with hash index are being covered
On Tue, Aug 23, 2016 at 8:54 AM, Amit Kapila wrote:
> $SUBJECT will make hash indexes reliable and usable on standby.
> AFAIU, currently hash indexes are not recommended to be used in
> production mainly because they are not crash-safe and with this patch,
> I hope we can address that limitation a
101 - 113 of 113 matches
Mail list logo