Re: Recovery inconsistencies, standby much larger than primary

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Recovery inconsistencies, standby much larger than primary
Дата
Msg-id 20140215000130.GC11943@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: Recovery inconsistencies, standby much larger than primary  (Greg Stark <stark@mit.edu>)
Ответы Re: Recovery inconsistencies, standby much larger than primary  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2014-02-14 20:46:01 +0000, Greg Stark wrote:
> Going over this I think this is still a potential issue:
> 
> On 31 Jan 2014 15:56, "Andres Freund" <andres@2ndquadrant.com> wrote:
> 
> >
> > I am not sure that explains the issue, but I think the redo action for
> > truncation is not safe across crashes.  A XLOG_SMGR_TRUNCATE will just
> > do a smgrtruncate() (and then mdtruncate) which will iterate over the
> > segments starting at 0 till mdnblocks()/segment_size and *truncate* but
> > not delete individual segment files that are not needed anymore, right?
> > If we crash in the midst of that a new mdtruncate() will be issued, but
> > it will get a shorter value back from mdnblocks().
> >
> > Am I missing something?
> >
> 
> I'm not too familiar with md.c but my reading of the code is that we
> truncate the files in reverse order?

That's what I had assumed as well, but it doesn't look that way:
   v = mdopen(reln, forknum, EXTENSION_FAIL);
   priorblocks = 0; /* <- initial value */   while (v != NULL)   {       MdfdVec    *ov = v;
       if (priorblocks > nblocks)       {           /* truncate entire segment */       }       else if (priorblocks +
((BlockNumber)RELSEG_SIZE) > nblocks)       {           /* truncate entire segment */       }       else       {
  /* nothing to do, all needed */       }       priorblocks += RELSEG_SIZE;   }
 

So, according to that we start at segment 0, right?

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: New hook after raw parsing, before analyze
Следующее
От: Hiroshi Inoue
Дата:
Сообщение: Re: narwhal and PGDLLIMPORT