Re: initdb -S and tablespaces

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: initdb -S and tablespaces
Дата
Msg-id CA+TgmoazKw=HEH=CKNJpgE847n5qCCLJR_XwKZq+hAJ5fKJ7+A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: initdb -S and tablespaces  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Ответы Re: initdb -S and tablespaces  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: initdb -S and tablespaces  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Список pgsql-hackers
On Thu, Apr 16, 2015 at 9:24 AM, Abhijit Menon-Sen <ams@2ndquadrant.com> wrote:
> Here's a variation of the earlier patch that follows all links in
> PGDATA. Does this look more like what you had in mind?

I'm really confused by the additional control-file field.  It is
documented as indicating whether fsync was ever disabled while the
server was running.  But:

1. It doesn't do that.  As soon as we fsync the data directory, we
reset the flag.  That's not what "ever disabled" means to me.

2. I don't know why it's part of this patch.  Tracking whether fsync
was ever disabled could be useful forensically, but isn't related to
fsync-ing the data directory after a crash, so I dunno why we'd put
that in this patch.  Tracking whether fsync was disabled recently, as
the patch actually does, doesn't seem to be of any obvious value in
preventing corruption either.

Also, it seems awfully unfortunate to me that we're duplicating a
whole pile of code into xlog.c here.  Maybe there's no way to avoid
the code duplication, but pre_sync_fname() seems like it'd more
naturally go in fd.c than here.  I dunno where walkdir should go, but
again, not in xlog.c.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: parallel mode and parallel contexts
Следующее
От: Robert Haas
Дата:
Сообщение: Re: EvalPlanQual behaves oddly for FDW queries involving system columns