On 2016-04-15 13:42:34 -0400, Robert Haas wrote: > On Thu, Apr 14, 2016 at 1:39 AM, Abhijit Menon-Sen <a...@2ndquadrant.com> > wrote: > > At 2016-04-12 09:00:57 -0400, robertmh...@gmail.com wrote: > >> > >> On Mon, Apr 11, 2016 at 1:17 PM, Andres Freund <and...@anarazel.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
