Re: Postgres, fsync, and OSs (specifically linux)
От | Ashutosh Bapat |
---|---|
Тема | Re: Postgres, fsync, and OSs (specifically linux) |
Дата | |
Msg-id | CAFjFpRfc=d4Ma-6Q6fG=d7h_cM4Yy-KrBnqDKwOfSbycUxYbUA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Postgres, fsync, and OSs (specifically linux) (Stephen Frost <sfrost@snowman.net>) |
Список | pgsql-hackers |
On Sat, May 19, 2018 at 6:31 AM, Stephen Frost <sfrost@snowman.net> wrote: > Greetings, > > * Abhijit Menon-Sen (ams@2ndQuadrant.com) wrote: >> At 2018-05-18 20:27:57 -0400, sfrost@snowman.net wrote: >> > >> > I don't agree with the general notion that we can't have a function >> > which handles the complicated bits about the kind of error because >> > someone grep'ing the source for PANIC might have to do an additional >> > lookup. >> >> Or we could just name the function promote_eio_to_PANIC. > > Ugh, I'm not thrilled with that either. > >> (I understood the objection to be about how 'grep PANIC' wouldn't find >> these lines at all, not that there would be an additional lookup.) > > ... and my point was that 'grep PANIC' would, almost certainly, find the > function promote_eio_to_panic(), and someone could trivially look up all > the callers of that function then. It's not just grep, but tools like cscope, tag. Although, I agree, that adding a function, if all necessary, is more important than convenience of finding all the instances of a certain token easily. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
В списке pgsql-hackers по дате отправления: