From: | Antonin Houska <ah(at)cybertec(dot)at> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | michael(at)paquier(dot)xyz, tomas(dot)vondra(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: MarkBufferDirtyHint() and LSN update |
Date: | 2019-11-12 13:27:16 |
Message-ID: | 57161.1573565236@antos |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> At Mon, 11 Nov 2019 10:03:14 +0100, Antonin Houska <ah(at)cybertec(dot)at> wrote in
> > Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> > > Does something like the attached patch make sense? Reviews are
> > > welcome.
> >
> > This looks good to me.
>
> I have a qustion.
>
> The current code assumes that !BM_DIRTY means that the function is
> dirtying the page. But if !BM_JUST_DIRTIED, the function actually is
> going to re-dirty the page even if BM_DIRTY.
It makes sense to me. I can imagine the following:
1. FlushBuffer() cleared BM_JUST_DIRTIED, wrote the page to disk but hasn't
yet cleared BM_DIRTY.
2. Another backend changed a hint bit in shared memory and called
MarkBufferDirtyHint().
Thus FlushBuffer() missed the current hint bit change, so we need to dirty the
page again.
> If this is correct, the trigger for stats update is not !BM_DIRTY but
> !BM_JUST_DIRTIED, or the fact that we passed the line of
> XLogSaveBufferForHint() could be the trigger, regardless whether the
> LSN is valid or not.
I agree.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2019-11-12 13:28:22 | Re: Option to dump foreign data in pg_dump |
Previous Message | Ranier Vilela | 2019-11-12 13:07:04 | [PATCH][BUG_FIX] Potential null pointer dereferencing. |