Re: DDL result is lost by CREATE DATABASE with WAL_LOG strategy
Вложения
В списке pgsql-hackers по дате отправления:
| От | Nathan Bossart |
|---|---|
| Тема | Re: DDL result is lost by CREATE DATABASE with WAL_LOG strategy |
| Дата | |
| Msg-id | 20230216064120.GA2016097@nathanxps13 обсуждение исходный текст |
| Ответ на | Re: DDL result is lost by CREATE DATABASE with WAL_LOG strategy (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: DDL result is lost by CREATE DATABASE with WAL_LOG strategy
|
| Список | pgsql-hackers |
On Thu, Feb 16, 2023 at 02:26:55PM +0900, Michael Paquier wrote: > So, if I am understanding this stuff right, this issue can create data > corruption once a DDL updates any pages of pg_class stored in a > template database that gets copied by this routine. In this case, the > patch sent makes sure that any page copied will get written once a > checkpoint kicks in. Shouldn't we have at least a regression test for > such a scenario? The issue can happen when updating a template > database after creating a database from it, which is less worrying > than the initial impression I got, still I'd like to think that we > should have some coverage as of the special logic this code path > relies on for pg_class when reading its buffers. I was able to quickly hack together a TAP test that seems to reliably fail before the fix and pass afterwards. There's probably a better place for it, though... -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера