Re: [HACKERS] pg_upgrade may be mortally wounded
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] pg_upgrade may be mortally wounded |
Дата | |
Msg-id | 199909281311.JAA15766@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_upgrade may be mortally wounded (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > > Tom, did we address this. I forgot. > > No, it's still an open issue as far as I'm concerned. I was hoping to > hear something from Vadim about how pg_upgrade could work safely under > MVCC... > > regards, tom lane Would a solution to this be to add instructions to pg_upgrade to require the user to stop and restart the postmaster? Seems like that is the only solution unless we do that stop of postmater inside pg_upgrade, but that seems risky. > > > >> Bruce Momjian <maillist@candle.pha.pa.us> writes: > >>>>> BTW, it seems to me that it is a good idea to kill and restart the > >>>>> postmaster immediately after pg_upgrade finishes. Otherwise there might > >>>>> be buffers in shared memory that do not reflect the actual contents of > >>>>> the corresponding pages of the relation files (now that pg_upgrade > >>>>> overwrote the files with other data). > >> > >>>> Your issue with buffer cache is a major one. Clearly, this would be a > >>>> problem. However, it is my understanding that the buffer cache after > >>>> initdb would only contain system table info, so if they pg_upgrade after > >>>> that, there is no way they have bad stuf in the cache, right? > >> > >> Cached copies of system tables obviously are no problem, since > >> pg_upgrade doesn't overwrite those. I'm concerned whether there can > >> be cached copies of pages from user tables or indexes. Since we've > >> just done a bunch of CREATE INDEXes (and a VACUUM, if my latest hack > >> is right), it seems at least possible that this would happen. > >> > >> Now all those user tables will be empty (zero-length files), so there is > >> nothing to cache. But the user indexes are *not* zero-length --- it looks > >> like they are at least 2 pages long even when empty. So there seems > >> to be a real risk of having a cached copy of one of the pages of a user > >> index while pg_upgrade is overwriting the index file with new data... > -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-hackers по дате отправления: