Re: proposal: CREATE DATABASE vs. (partial) CHECKPOINT

Поиск
Список
Период
Сортировка
От Atri Sharma
Тема Re: proposal: CREATE DATABASE vs. (partial) CHECKPOINT
Дата
Msg-id CAOeZVicDgcFgwHB99ma9MpQ03HJMPY2ridF-n8GNkRtgk7FEgw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: CREATE DATABASE vs. (partial) CHECKPOINT  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers


On Mon, Oct 27, 2014 at 4:44 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
On 10/27/2014 01:06 PM, Atri Sharma wrote:



To solve #1, we could redesign CREATE DATABASE so that replaying the
DBASE_CREATE record doesn't zap the old directory, and also doesn't copy
any files. We could instead just assume that if the transaction commits,
all the files have been copied and fsync'd already, like we assume that if
a CREATE INDEX commits in wal_level=minimal, the underlying file was
fsync'd before the commit.


Do you mean that during a recovery, we just let the database directory be
and assume that it is in good shape since the transaction committed
originally?

Right.

It does make sense, however, with the checkpoint after creating the files gone, the window between the creation of files and actual commit might be increased, increasing the possibility of a crash during that period and causing an orphan database. However, my understanding of the consequences of removing the checkpoint might be incorrect, so my fears might be wrong.

Regards,

Atri

В списке pgsql-hackers по дате отправления:

Предыдущее
От: sudalai
Дата:
Сообщение: Master ip from hot_standby..
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Directory/File Access Permissions for COPY and Generic File Access Functions