From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [BUGS] Breakage with VACUUM ANALYSE + partitions |
Date: | 2016-04-21 13:45:05 |
Message-ID: | 20160421134505.fgubzggi6vyz4zmd@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On 2016-04-15 13:42:34 -0400, Robert Haas wrote:
> On Thu, Apr 14, 2016 at 1:39 AM, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com> wrote:
> > At 2016-04-12 09:00:57 -0400, robertmhaas(at)gmail(dot)com wrote:
> >>
> >> On Mon, Apr 11, 2016 at 1:17 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> >> >
> >> > 3) Actually handle the case of the last open segment not being
> >> > RELSEG_SIZE properly in _mdfd_getseg() - mdnblocks() does so.
> >>
> >> #3 seems like it's probably about 15 years overdue, so let's do that
> >> anyway.
> >
> > Do I understand correctly that the case of the "last open segment"
> > (i.e., the one for which mdfd_chain == NULL) not being RELSEG_SIZE
> > (i.e., _mdnblocks(reln, forknum, v) < RELSEG_SIZE) should not call
> > _mfdf_openseg on nextsegno if behaviour is not EXTENSION_CREATE or
> > InRecovery?
> >
> > And that "We won't create segment if not existent" should happen, but
> > doesn't only because the next segment file wasn't removed earlier, so
> > we have to add an extra check for that case?
> >
> > In other words, is something like the following what's needed here, or
> > is there more to it?
Yes, I think that should solve the bug reported here. Did you check?
What makes me rather worried about solely using this as a solution right
now is the InRecovery check, which triggers segment extensions/creations
even with EXTENSION_RETURN_NULL. Afaics it's more or less a dormant bug
that _mdfd_getseg() ignores RETURN_NULL in the InRecovery case, because
mdopen() (and other places) do *not* behave that way!
> Something like that is what I was thinking about, but I notice it has
> the disadvantage of adding lseeks to cater to a shouldn't-happen
> condition. Not sure if we should care.
I'm not particularly concerned about that, my gues sit'd barely impact
the number of lseeks, because most callers will have called mdnblocks()
before anyway.
> My attempts to test things were also singularly unrewarding. Even
> after messing with the filesystem in various ways, I couldn't figure
> out exactly how this makes a difference.
What do you mean by this? You couldn't reproduce the bug? Or not how to
trigger such a test?
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-04-21 18:11:39 | Re: [BUGS] Breakage with VACUUM ANALYSE + partitions |
Previous Message | AbdulShukoor Mohammed | 2016-04-21 13:28:01 | DATA RESTORE PGADMINIII |
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2016-04-21 13:47:58 | pgsql: Inline initial comparisons in TestForOldSnapshot() |
Previous Message | Shulgin, Oleksandr | 2016-04-21 13:40:52 | Re: Wire protocol compression |