Re: FSM corruption leading to errors
От | Jim Nasby |
---|---|
Тема | Re: FSM corruption leading to errors |
Дата | |
Msg-id | 56ea6b2f-cad2-56ce-5785-c6415c422e34@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: FSM corruption leading to errors (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: FSM corruption leading to errors
|
Список | pgsql-hackers |
On 10/20/16 10:15 PM, Michael Paquier wrote: > 2) If anything is found, stop the server and delete the files manually. > 3) Re-start the server. > OK, that's troublesome and costly for large relations, but we know > that's the safest way to go for any versions, and there is no need to > complicate the code with any one-time repairing extensions. Wouldn't you need to run around to all your replicas and do that as well? > Speaking of which, I implemented a small extension able to truncate > the FSM up to the size of the relation as attached, but as I looked at > it SMGR_TRUNCATE_FSM has been introduced in 9.6 so its range of action > is rather limited... And I pushed as well a version on github: > https://github.com/michaelpq/pg_plugins/tree/master/pg_fix_truncation > The limitation range of such an extension is a argument good enough to > just rely on the stop/delete-FSM/start method to fix an instance and > let VACUUM do the rest of the work. That looks to work but use it at > your own risk. Shouldn't the truncation be logged before it's performed? -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) mobile: 512-569-9461
В списке pgsql-hackers по дате отправления: