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 по дате отправления:

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Odd procedure resolution
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: Postgres, fsync, and OSs (specifically linux)