Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers
Date
Msg-id CAA4eK1+nSab4hXqTUrnXkrnjS_Z3Z4Aaa=MFzoU26jc17aiybQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Mar 10, 2017 at 11:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapila16@gmail.com> writes:
>> Just to let you know that I think I have figured out the reason of
>> failure.  If we run the regressions with attached patch, it will make
>> the regression tests fail consistently in same way.  The patch just
>> makes all transaction status updates to go via group clog update
>> mechanism.
>
> This does *not* give me a warm fuzzy feeling that this patch was
> ready to commit.  Or even that it was tested to the claimed degree.
>

I think this is more of an implementation detail missed by me.  We
have done quite some performance/stress testing with a different
number of savepoints, but this could have been caught only by having
Rollback to Savepoint followed by a commit.  I agree that we could
have devised some simple way (like the one I shared above) to test the
wide range of tests with this new mechanism earlier.  This is a
learning from here and I will try to be more cautious about such
things in future.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers
Next
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] New CORRESPONDING clause design