On Mon, Apr 5, 2021 at 5:00 AM Arseny Sher wrote:
>
>
> On Fri, Apr 2, 2021 at 9:46 AM Michael Paquier wrote:
>
> > Okay, applied and back-patched down to 12 then.
>
> Thank you both. Unfortunately and surprisingly, the test still fails
> (perhaps even rarer, once in several hundred runs) under
>
On Fri, Apr 2, 2021 at 9:46 AM Michael Paquier wrote:
> Okay, applied and back-patched down to 12 then.
Thank you both. Unfortunately and surprisingly, the test still fails
(perhaps even rarer, once in several hundred runs) under
multimaster. After scratching the head for some more time, it see
On Fri, Apr 2, 2021 at 9:46 AM Michael Paquier wrote:
>
> On Thu, Apr 01, 2021 at 10:54:29PM +0900, Masahiko Sawada wrote:
> > Looks good to me too.
>
> Okay, applied and back-patched down to 12 then.
Thank you!
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Thu, Apr 01, 2021 at 10:54:29PM +0900, Masahiko Sawada wrote:
> Looks good to me too.
Okay, applied and back-patched down to 12 then.
--
Michael
signature.asc
Description: PGP signature
On Thu, Apr 1, 2021 at 5:49 PM Michael Paquier wrote:
>
> On Thu, Apr 01, 2021 at 10:58:25AM +0300, Arseny Sher wrote:
> > How about the attached?
Thank you for updating the patch!
> Sounds fine to me. Sawada-san?
Looks good to me too.
Regards,
--
Masahiko Sawada
EDB: https://www.enterpris
On Thu, Apr 01, 2021 at 10:58:25AM +0300, Arseny Sher wrote:
> How about the attached?
Sounds fine to me. Sawada-san?
--
Michael
signature.asc
Description: PGP signature
Michael Paquier writes:
> On Thu, Apr 01, 2021 at 12:52:21PM +0900, Masahiko Sawada wrote:
>> Just to be clear the context, I’m mentioning the following test case:
Sorry, I misremembered the test and assumed the table is non-empty there
while it is empty but vacuum_truncate is disabled. Still,
On Thu, Apr 01, 2021 at 12:52:21PM +0900, Masahiko Sawada wrote:
> Just to be clear the context, I’m mentioning the following test case:
(Coming back a couple of emails later, where indeed I forgot about the
business with lazy_check_needs_freeze() that could cause a page to be
skipped even if DISA
On Thu, Apr 1, 2021 at 12:08 PM Arseny Sher wrote:
>
>
> Masahiko Sawada writes:
>
> >> I don't think this matters much, as it tests the contrary and the
> >> probability of
> >> successful test passing (in case of theoretical bug making vacuum to
> >> truncate
> >> non-empty relation) becomes st
Arseny Sher writes:
> as currently the chance of its failure is close to 1.
A typo, to 0 too, of course.
Masahiko Sawada writes:
>> I don't think this matters much, as it tests the contrary and the
>> probability of
>> successful test passing (in case of theoretical bug making vacuum to
>> truncate
>> non-empty relation) becomes stunningly small. But adding it wouldn't hurt
>> either.
>
> I was co
On Wed, Mar 31, 2021 at 10:39 PM Arseny Sher wrote:
>
>
> On 3/31/21 4:17 PM, Masahiko Sawada wrote:
>
> > Is it better to add FREEZE to the first "VACUUM reloptions_test;" as
> well?
>
> I don't think this matters much, as it tests the contrary and the
> probability of
> successful test passing
On 3/31/21 4:17 PM, Masahiko Sawada wrote:
> Is it better to add FREEZE to the first "VACUUM reloptions_test;" as
well?
I don't think this matters much, as it tests the contrary and the
probability of
successful test passing (in case of theoretical bug making vacuum to
truncate
non-empty
On Tue, Mar 30, 2021 at 10:22 PM Arseny Sher wrote:
>
> On 3/30/21 10:12 AM, Michael Paquier wrote:
>
> > Yep, this is the same problem as the one discussed for c2dc1a7, where
> > a concurrent checkpoint may cause a page to be skipped, breaking the
> > test.
>
> Indeed, Alexander Lakhin pointed
On 3/30/21 10:12 AM, Michael Paquier wrote:
> Yep, this is the same problem as the one discussed for c2dc1a7, where
> a concurrent checkpoint may cause a page to be skipped, breaking the
> test.
Indeed, Alexander Lakhin pointed me to that commit after I wrote the
message.
> Why not just using
On Tue, Mar 30, 2021 at 01:58:50AM +0300, Arseny Sher wrote:
> Intimate reading of lazy_scan_heap says that the failure indeed might
> happen; if ConditionalLockBufferForCleanup couldn't lock the buffer and
> either the buffer doesn't need freezing or vacuum is not aggressive, we
> don't insist on
16 matches
Mail list logo
