|From:||Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>|
|To:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|Cc:||Andres Freund <andres(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: initdb -S and tablespaces|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Thanks for taking a look at the patch.
At 2015-04-03 13:32:32 -0300, alvherre(at)2ndquadrant(dot)com wrote:
> But then, since the name is already telling us that it's all about
> PGDATA, maybe we can remove the "recursively" part of the name?
Sure, that makes sense too. Since you and Andres both like
«fsync_pgdata(data_directory)», I'll change it accordingly.
> I also noticed that walkdir() thinks it is completely agnostic on
> what the passed action is; except that the comment at the bottom talks
> about how fsync on directories is important, which seems out of place.
Yes. The function behaves as documented, but the comment is clearly too
specific. I'm not sure where to put it. I could make walkdir() NOT do
it, and instead do it in the caller with the same comment. Thoughts?
> Hmm ... Actually, since surely we must follow symlinks everywhere,
> why do we have to do this separately for pg_tblspc? Shouldn't that
> link-following occur automatically when walking PGDATA in the first
I'm not sure about that (and that's why I've not attached an updated
patch here). The original idea was to follow only those links that we
expect to be in PGDATA.
I suppose it would be easier in terms of the code to follow all links,
but I don't know if it's the right thing. If that's what you think we
should do, I can post a simplified patch.
> Maybe fsync_recursively should Assert() that it's only being called
> with enableFsync=on; or perhaps we can have it return early if it's
I prefer the latter. Will change.
|Next Message||Sawada Masahiko||2015-04-06 07:28:22||Re: Auditing extension for PostgreSQL (Take 2)|
|Previous Message||Sawada Masahiko||2015-04-06 06:46:58||Re: Freeze avoidance of very large table.|