Re: [HACKERS] pg_upgrade may be mortally wounded
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] pg_upgrade may be mortally wounded |
Дата | |
Msg-id | 14739.933689027@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_upgrade may be mortally wounded (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] pg_upgrade may be mortally wounded
Re: [HACKERS] pg_upgrade may be mortally wounded Re: [HACKERS] pg_upgrade may be mortally wounded |
Список | pgsql-hackers |
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... regards, tom lane
В списке pgsql-hackers по дате отправления: