On Sun, Aug 2, 2020 at 9:07 AM Michail Nikolaev
wrote:
> Thanks for your work, the patch is looking better now.
Pushed -- thanks!
--
Peter Geoghegan
Hello, Peter.
> Attached is a revised version of your patch
Thanks for your work, the patch is looking better now.
Michail.
> On 1 Aug 2020, at 20:30, Peter Geoghegan wrote:
> This revised version is essentially the same as your original patch --
> I have only made superficial adjuments. I think that I will be able to
> commit this next week, barring objections.
As we're out of time for the July CF where this is regi
On Mon, Mar 16, 2020 at 7:08 AM Michail Nikolaev
wrote:
> While working on support for index hint bits on standby [1] I have
> started to getting
> "ERROR: could not find left sibling of block in index "
> during stress tests.
I reproduced the bug using your steps (including the pg_usle
Hello, Peter.
Thanks for the update.
Yes, it is the right decision.
I have started to spot that bug only while working on a faster scan
using hint bits on replicas [1], so it is unlikely to hit it in
production at the moment.
Thanks,
Michail.
[1]:
https://www.postgresql.org/message-id/CANtu0oj
Hi Michail,
On Sun, Apr 5, 2020 at 10:04 AM Michail Nikolaev
wrote:
> > I added
> > something about this to the nbtree README in commit 9f83468b353.
>
> I have added some updates to your notes in the updated patch version.
My apologies for the extended delay here.
My intention is to commit th
Hello, Peter.
> I added
> something about this to the nbtree README in commit 9f83468b353.
I have added some updates to your notes in the updated patch version.
I also was trying to keep the original wrapping of the paragraph, so
the patch looks too wordy.
Thanks,
Michail.
btree-race-and-do
On Mon, Mar 16, 2020 at 7:08 AM Michail Nikolaev
wrote:
> I was sure I have broken something in btree and spent a lot of time
> trying to figure what.
> And later... I realized what it is bug in btree since a very old times...
> Because of much faster scans with LP_DEAD support on a standby it
>
On Fri, Mar 27, 2020 at 8:58 AM Michail Nikolaev
wrote:
> I have spent some time trying to find any possible race condition
> between btree_xlog_split and _bt_walk_left… But I can’t find any.
> Also, I have tried to cause any issue by putting pg_sleep put into
> btree_xlog_split (between releasing
Hello.
> Probably, patch in this thread should fix this in btree_xlog_split() too?
I have spent some time trying to find any possible race condition
between btree_xlog_split and _bt_walk_left… But I can’t find any.
Also, I have tried to cause any issue by putting pg_sleep put into
btree_xlog_spl
> 18 марта 2020 г., в 00:37, Peter Geoghegan написал(а):
>
> On Mon, Mar 16, 2020 at 10:20 PM Andrey M. Borodin
> wrote:
>> It seems to me that it's exactly the same check that I was trying to verify
>> in amcheck patch [0].
>> But there it was verified inside amcheck, but here it is verifi
On Mon, Mar 16, 2020 at 10:20 PM Andrey M. Borodin wrote:
> It seems to me that it's exactly the same check that I was trying to verify
> in amcheck patch [0].
> But there it was verified inside amcheck, but here it is verified by index
> scan.
Maybe we can accept your patch after fixing this b
On Mon, Mar 16, 2020 at 7:08 AM Michail Nikolaev
wrote:
> -- ABSTRACT --
> There is a race condition between btree_xlog_unlink_page and _bt_walk_left.
> A lot of versions are affected including 12 and new-coming 13.
> Happens only on standby. Seems like could not cause invalid query result
Hi Michail!
Very interesting bug.
> 16 марта 2020 г., в 19:07, Michail Nikolaev
> написал(а):
>
> So, I think right way is to lock all three pages as it is done on the
> primary. As far as I can see it is not causes any real performance
> regression.
It seems to me that it's exactly the same
14 matches
Mail list logo
