Jeff Janes wrote:
> On Fri, Sep 22, 2017 at 1:19 PM, Robert Haas wrote:
>
> > On Fri, Sep 22, 2017 at 3:39 PM, Jeff Janes wrote:
> > > It turns out it is not new in pg10. I spotted in the log file only by
> > > accident while looking for something
On Fri, Sep 22, 2017 at 1:19 PM, Robert Haas wrote:
> On Fri, Sep 22, 2017 at 3:39 PM, Jeff Janes wrote:
> > It turns out it is not new in pg10. I spotted in the log file only by
> > accident while looking for something else. Now that I am looking
On Fri, Sep 22, 2017 at 3:39 PM, Jeff Janes wrote:
> It turns out it is not new in pg10. I spotted in the log file only by
> accident while looking for something else. Now that I am looking for it, I
> do see it in 9.6 as well.
So I guess the next question is whether it
On Fri, Sep 22, 2017 at 8:47 AM, Alvaro Herrera
wrote:
> Jeff Janes wrote:
> > I am running some crash recovery testing against 10rc1 by injecting torn
> > page writes, using a test case which generates a lot of multixact, some
> > naturally by doing a lot fk updates,
On Fri, Sep 22, 2017 at 11:37 AM, Jeff Janes wrote:
> Is the presence of this log message something that needs to be investigated
> further?
I'd say yes. It sounds like we have a race condition someplace that
previous fixes in this area failed to adequately understand.
--
Jeff Janes wrote:
> I am running some crash recovery testing against 10rc1 by injecting torn
> page writes, using a test case which generates a lot of multixact, some
> naturally by doing a lot fk updates, but most artificially by calling
> the pg_burn_multixact function from one of the attached
I am running some crash recovery testing against 10rc1 by injecting torn
page writes, using a test case which generates a lot of multixact, some
naturally by doing a lot fk updates, but most artificially by calling
the pg_burn_multixact function from one of the attached patches.
In 22 hours of