Re: Inconsistency in determining the timestamp of the db statfile.

On Fri, Sep 11, 2020 at 4:53 AM Amit Kapila wrote: > On Thu, Sep 10, 2020 at 6:42 PM Alvaro Herrera > wrote: > > > > On 2020-Sep-10, Amit Kapila wrote: > > > > > On Thu, Sep 10, 2020 at 1:03 PM Magnus Hagander > wrote: > > > > > The comments already say what you said in the second suggestion:"T

Re: Inconsistency in determining the timestamp of the db statfile.

On Thu, Sep 10, 2020 at 1:13 PM Amit Kapila wrote: > > > BTW, do we want to backpatch this? There is no user reported bug and > not sure if the user will encounter any problem. I think it is a minor > improvement and more of code consistency. So, making HEAD only change > should be okay. > Seeing

Re: Inconsistency in determining the timestamp of the db statfile.

On Thu, Sep 10, 2020 at 6:42 PM Alvaro Herrera wrote: > > On 2020-Sep-10, Amit Kapila wrote: > > > On Thu, Sep 10, 2020 at 1:03 PM Magnus Hagander wrote: > > > The comments already say what you said in the second suggestion:"The > > caller must rely on timestamp stored in *ts iff the function ret

Re: Inconsistency in determining the timestamp of the db statfile.

On 2020-Sep-10, Amit Kapila wrote: > On Thu, Sep 10, 2020 at 1:03 PM Magnus Hagander wrote: > The comments already say what you said in the second suggestion:"The > caller must rely on timestamp stored in *ts iff the function returns > true.". Read iff "as if and only if" I think "must" should

Re: Inconsistency in determining the timestamp of the db statfile.

On Thu, Sep 10, 2020 at 1:03 PM Magnus Hagander wrote: > > On Thu, Sep 10, 2020 at 9:05 AM Amit Kapila wrote: >> >> On Thu, Sep 10, 2020 at 11:52 AM Masahiko Sawada >> wrote: >> > >> > >> > Regarding the v2 patch, I think we should return false in the >> > following case too: >> > >> >

Re: Inconsistency in determining the timestamp of the db statfile.

On Thu, Sep 10, 2020 at 9:05 AM Amit Kapila wrote: > On Thu, Sep 10, 2020 at 11:52 AM Masahiko Sawada > wrote: > > > > > > Regarding the v2 patch, I think we should return false in the > > following case too: > > > > default: > > ereport(pgStatRunningInCollector ? LOG

Re: Inconsistency in determining the timestamp of the db statfile.

On Thu, Sep 10, 2020 at 11:52 AM Masahiko Sawada wrote: > > > Regarding the v2 patch, I think we should return false in the > following case too: > > default: > ereport(pgStatRunningInCollector ? LOG : WARNING, > (errmsg("corrupted statistics fil

Re: Inconsistency in determining the timestamp of the db statfile.

On Thu, 10 Sep 2020 at 14:24, Amit Kapila wrote: > > On Wed, Sep 9, 2020 at 9:37 PM Fujii Masao > wrote: > > > > On 2020/09/09 22:57, Magnus Hagander wrote: > > > On Wed, Sep 9, 2020 at 3:56 PM Tomas Vondra > > > wrote: > > > > > > On Wed, Sep 09, 2020 a

Re: Inconsistency in determining the timestamp of the db statfile.

On Wed, Sep 9, 2020 at 9:37 PM Fujii Masao wrote: > > On 2020/09/09 22:57, Magnus Hagander wrote: > > On Wed, Sep 9, 2020 at 3:56 PM Tomas Vondra > > wrote: > > > > On Wed, Sep 09, 2020 at 03:53:40PM +0530, Amit Kapila wrote: > > >On Wed, Sep 9, 2020

Re: Inconsistency in determining the timestamp of the db statfile.

On 2020/09/09 22:57, Magnus Hagander wrote: On Wed, Sep 9, 2020 at 3:56 PM Tomas Vondra mailto:tomas.von...@2ndquadrant.com>> wrote: On Wed, Sep 09, 2020 at 03:53:40PM +0530, Amit Kapila wrote: >On Wed, Sep 9, 2020 at 3:15 PM Magnus Hagander mailto:mag...@hagander.net>> wrote: >

Re: Inconsistency in determining the timestamp of the db statfile.

On 2020-Sep-09, Amit Kapila wrote: > I have included Alvaro as he is a committer for 187492b6, so he might > remember something and let us know if this is a mistake or there is > some reason for doing so (return true even when the db entry we are > trying to read is corrupt). Thanks -- I have to

Re: Inconsistency in determining the timestamp of the db statfile.

On Wed, Sep 9, 2020 at 3:56 PM Tomas Vondra wrote: > On Wed, Sep 09, 2020 at 03:53:40PM +0530, Amit Kapila wrote: > >On Wed, Sep 9, 2020 at 3:15 PM Magnus Hagander > wrote: > >> > >> On Wed, Sep 9, 2020 at 5:04 AM Amit Kapila > wrote: > >>> > >> > >> Though in fact the one inconsistent place in

Re: Inconsistency in determining the timestamp of the db statfile.

On Wed, Sep 09, 2020 at 03:53:40PM +0530, Amit Kapila wrote: On Wed, Sep 9, 2020 at 3:15 PM Magnus Hagander wrote: On Wed, Sep 9, 2020 at 5:04 AM Amit Kapila wrote: Though in fact the one inconsistent place in the code now is that if it is corrupt in the db entry part of the file it retu

Re: Inconsistency in determining the timestamp of the db statfile.

On Wed, Sep 9, 2020 at 3:17 PM Magnus Hagander wrote: > > On Wed, Sep 9, 2020 at 9:11 AM Amit Kapila wrote: >> >> On Wed, Sep 9, 2020 at 10:54 AM Fujii Masao >> wrote: >> > >> > On 2020/09/09 12:04, Amit Kapila wrote: >> > > >> > > No, before patch as well, if we can't read the DB entry say bec

Re: Inconsistency in determining the timestamp of the db statfile.

On Wed, Sep 9, 2020 at 3:15 PM Magnus Hagander wrote: > > On Wed, Sep 9, 2020 at 5:04 AM Amit Kapila wrote: >> > > Though in fact the one inconsistent place in the code now is that if it is > corrupt in the db entry part of the file it returns true and the global > timestamp, which I would argu

Re: Inconsistency in determining the timestamp of the db statfile.

On Wed, Sep 9, 2020 at 9:11 AM Amit Kapila wrote: > On Wed, Sep 9, 2020 at 10:54 AM Fujii Masao > wrote: > > > > On 2020/09/09 12:04, Amit Kapila wrote: > > > > > > No, before patch as well, if we can't read the DB entry say because > > > the file is corrupt, we return true and use timestamp of

Re: Inconsistency in determining the timestamp of the db statfile.

On Wed, Sep 9, 2020 at 5:04 AM Amit Kapila wrote: > On Tue, Sep 8, 2020 at 7:03 PM Magnus Hagander > wrote: > > > > On Tue, Sep 8, 2020 at 3:11 PM Fujii Masao > wrote: > >> > >> > >> > >> On 2020/09/08 19:28, Magnus Hagander wrote: > >> > > >> > > >> > On Tue, Sep 8, 2020 at 8:10 AM Amit Kapila

Re: Inconsistency in determining the timestamp of the db statfile.

On Wed, Sep 9, 2020 at 10:54 AM Fujii Masao wrote: > > On 2020/09/09 12:04, Amit Kapila wrote: > > > > No, before patch as well, if we can't read the DB entry say because > > the file is corrupt, we return true and use timestamp of global stats > > file and this is what is established by the origi

Re: Inconsistency in determining the timestamp of the db statfile.

On 2020/09/09 12:04, Amit Kapila wrote: On Tue, Sep 8, 2020 at 7:03 PM Magnus Hagander wrote: On Tue, Sep 8, 2020 at 3:11 PM Fujii Masao wrote: On 2020/09/08 19:28, Magnus Hagander wrote: On Tue, Sep 8, 2020 at 8:10 AM Amit Kapila mailto:amit.kapil...@gmail.com>> wrote: We use

Re: Inconsistency in determining the timestamp of the db statfile.

On Tue, Sep 8, 2020 at 7:03 PM Magnus Hagander wrote: > > On Tue, Sep 8, 2020 at 3:11 PM Fujii Masao > wrote: >> >> >> >> On 2020/09/08 19:28, Magnus Hagander wrote: >> > >> > >> > On Tue, Sep 8, 2020 at 8:10 AM Amit Kapila > > > wrote: >> > >> > We use the ti

Re: Inconsistency in determining the timestamp of the db statfile.

On Tue, Sep 8, 2020 at 3:11 PM Fujii Masao wrote: > > > On 2020/09/08 19:28, Magnus Hagander wrote: > > > > > > On Tue, Sep 8, 2020 at 8:10 AM Amit Kapila > wrote: > > > > We use the timestamp of the global statfile if we are not able to > > determine it f

Re: Inconsistency in determining the timestamp of the db statfile.

On 2020/09/08 19:28, Magnus Hagander wrote: On Tue, Sep 8, 2020 at 8:10 AM Amit Kapila mailto:amit.kapil...@gmail.com>> wrote: We use the timestamp of the global statfile if we are not able to determine it for a particular database either because the entry for that database does

Re: Inconsistency in determining the timestamp of the db statfile.

On Tue, Sep 8, 2020 at 8:10 AM Amit Kapila wrote: > We use the timestamp of the global statfile if we are not able to > determine it for a particular database either because the entry for > that database doesn't exist or there is an error while reading the > specific database entry. This was not

Inconsistency in determining the timestamp of the db statfile.

We use the timestamp of the global statfile if we are not able to determine it for a particular database either because the entry for that database doesn't exist or there is an error while reading the specific database entry. This was not taken care of while reading other entries like ArchiverStats