Re: BUG #10675: alter database set tablespace and unlogged table
От | Pavan Deolasee |
---|---|
Тема | Re: BUG #10675: alter database set tablespace and unlogged table |
Дата | |
Msg-id | CABOikdN=3B7zXfOnPTjDzRu6SsuDJsYGE14cu7t2NRv3CffdVw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #10675: alter database set tablespace and unlogged table (Pavan Deolasee <pavan.deolasee@gmail.com>) |
Ответы |
Re: BUG #10675: alter database set tablespace and unlogged
table
Re: BUG #10675: alter database set tablespace and unlogged table Re: BUG #10675: alter database set tablespace and unlogged table Re: BUG #10675: alter database set tablespace and unlogged table |
Список | pgsql-bugs |
On Fri, Jun 20, 2014 at 11:34 PM, Pavan Deolasee <pavan.deolasee@gmail.com> wrote:
Anyone else has an opinion on this?Looks like there is no agreement on this. I agree with Andreas that given the current mechanism of truncating unlogged relations at the end of redo recovery, there is no danger in not flushing the dirty buffers belonging to unlogged relation at a normal checkpoint. Having said that, I find it confusing that we don't do that, for one reason that Tom explained and also because there is practically just no way to flush those dirty buffers to disk if the user wants so.Also, there had been discussions about altering unlogged tables to normal tables and we may also want to improve upon the current mechanism of truncating unlogged relations at the end of recovery even if the table was fully synced to the disk. It looks simpler to just flush everything instead of devising a new flag for checkpoint.
Since I did not hear anything on this, I created a patch that adds a new flag to tell checkpointer to flush all pages to the disk. Tom (and even I) have reservations about the approach, but I would nevertheless leave it to the committer to decide. IMV we must fix this bug one way or the other. Otherwise users face risk of failing to do clean shutdown.
Thanks,
Pavan
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
Вложения
В списке pgsql-bugs по дате отправления: