Re: [HACKERS] Hot Backup Ability
От | Michael Richards |
---|---|
Тема | Re: [HACKERS] Hot Backup Ability |
Дата | |
Msg-id | Pine.BSF.4.10.9906300148380.12242-100000@scifair.acadiau.ca обсуждение исходный текст |
Ответ на | Re: [HACKERS] Hot Backup Ability (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Hot Backup Ability
|
Список | pgsql-hackers |
On Tue, 29 Jun 1999, Bruce Momjian wrote: > > Just out of curiosity, I did a DUMP on the database while running a script > > that ran a pile of updates. When I restored the database files, it was so > > corrupted that I couldn't even run a select. vacuum just core dumped... > > When you say DUMP, you mean pg_dump, right? Are you using 6.5? Erm. Well, no. I was running ufsdump. Once I read the section on mvcc and re-did the test with the pg_dump, I realised that it does work as documented... I should think this is a good feature to broadcast to everyone. I don't think other free systems support it. The thing I got confuzed with that blocked transactions was the pg_vacuum. Seeing as how it physically re-arranges data inside the tables and indexes, is there any hope for not blocking the table for a long time as it re-arranges a 15 gig table? Will re-usable page support (whenever it is expected) eliminate the need for vacuum? Would it be easy to come up with a scheme for the vacuum function defrag a set number of pages and such, release its locks if there is another process blocked and waiting, then resume after that process is finished? -Michael
В списке pgsql-hackers по дате отправления: