Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED
От | Andres Freund |
---|---|
Тема | Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED |
Дата | |
Msg-id | 20140716222629.GB21370@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED
|
Список | pgsql-hackers |
On 2014-07-16 20:53:06 +0200, Andres Freund wrote: > On 2014-07-16 20:25:42 +0200, Andres Freund wrote: > > Hi, > > > > I quickly looked at this patch and I think there's major missing pieces > > around buffer management and wal logging. > > > > a) Currently buffers that are in memory marked as > > permanent/non-permanent aren't forced out to disk/pruned from cache, > > not even when they're dirty. > > b) When converting from a unlogged to a logged table the relation needs > > to be fsynced. > > c) Currently a unlogged table changed into a logged one will be > > corrupted on a standby because its contents won't ever be WAL logged. > > Forget that, didn't notice that you're setting tab->rewrite = true. So, while that danger luckily isn't there I think there's something similar. Consider: CREATE TABLE blub(...); INSERT INTO blub ...; BEGIN; ALTER TABLE blub SET UNLOGGED; ROLLBACK; The rewrite will read in the 'old' contents - but because it's done after the pg_class.relpersistence is changed they'll all not be marked as BM_PERMANENT in memory. Then the ALTER TABLE is rolled back, including the relpersistence setting. Which will unfortunately leave pages with the wrong persistency setting in memory, right? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: