Re: fsync-pgdata-on-recovery tries to write to more files than previously
От | Robert Haas |
---|---|
Тема | Re: fsync-pgdata-on-recovery tries to write to more files than previously |
Дата | |
Msg-id | CA+TgmobfS=KCfOXymEqAZHY_63akaXn6VNUcWB++iqdbnA=Fwg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: fsync-pgdata-on-recovery tries to write to more files than previously (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, May 28, 2015 at 1:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Thu, May 28, 2015 at 10:26 AM, Abhijit Menon-Sen <ams@2ndquadrant.com> wrote: >>> 2. Robert, are you comfortable with what fsync_pgdata() does in xlog.c? >>> I wasn't sure if I should move that to fd.c as well. I think it's >>> borderline OK for now. > >> I think if the function is specific as fsync_pgdata(), fd.c is not the >> right place. I'm not sure xlog.c is either, though. > > ISTM xlog.c is clearly the *wrong* place; if this behavior has anything > to do with WAL logging as such, it's not apparent to me. fd.c is not > a great place perhaps, but in view of the fact that we have things like > RemovePgTempFiles() in there, it's not unreasonable to see fsync_pgdata > as something to put there as well (perhaps with a name more chosen to > match fd.c names...) OK, sure, makes sense. > Since Robert appears to be busy worrying about the multixact issue > reported by Steve Kehlet, I suggest he focus on that and I'll take > care of getting this thing committed. AFAICT we have consensus on > what it should do and we're down to arguing about code style. Thanks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: