Re: [HACKERS] bytea_output vs make installcheck

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: [HACKERS] bytea_output vs make installcheck
Дата
Msg-id CAMkU=1xGzr4nTgkFd7mCjwqJqd62DViwQRMEn_h1YwwE7f9MVg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] bytea_output vs make installcheck  (Andres Freund <andres@anarazel.de>)
Ответы Re: [HACKERS] bytea_output vs make installcheck  (neha khatri <nehakhatri5@gmail.com>)
Re: [HACKERS] bytea_output vs make installcheck  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Tue, Feb 14, 2017 at 9:17 PM, Andres Freund <andres@anarazel.de> wrote:


On February 14, 2017 9:02:14 PM PST, neha khatri <nehakhatri5@gmail.com> wrote:
>On Wed, Feb 15, 2017 at 10:04 AM, neha khatri <nehakhatri5@gmail.com>
> wrote:.
>>
>>
>>> Attached are two options for doing that.  One overrides bytea_output
>>> locally where-ever needed, and the other overrides it for the entire
>>> 'regression' database.
>>>
>>
>> The solution that overrides bytea_output locally looks appropriate.
>It may
>> not be required to change the format for entire database.
>> Had there been a way to convert  bytea_output from 'hex' to 'escape'
>> internally, that could have simplified this customization even more.
>>
>
>Well, the conversion from 'hex' to 'escape' is available using the
>function
>encode().
>So the queries that are failing due to the setting bytea_output =
>escape,
>can be wrapped under encode(), to obtain the result in 'escape' format.
>Here is another way to resolve the same problem. The patch is attached.

I don't quite see the point of this - there's a lot of settings that cause spurious test failures. I don't see any point fixing random cases of that.  And I don't think the continual cost of doing so overall is worth the minimal gain.

What's your reason to get this fixed?

More testing is better than less testing, and a good way to get less testing is requiring the tester to memorize a list of false positives they might encounter.  I'd like to systematically clone my production system, run it through pg_upgrade, and then do installcheck (plus my own app-specific) on the result, and I'd like others to do that as well with their own production systems.

I don't really see the cost here.  It took me longer to satisfy myself that this was not actually a real bug than it did to write the patch.  Now much of that time was just because there were 3 other problems as well, which makes isolating and evaluating them exponentially harder--which itself is a good reason for fixing the ones that are easy to fix, so we don't have to get distracted by those while investigating the other ones.  And if we go with the option 2 patch, it is one line which seems pretty self-documenting and easy to maintain. I'd rather light a candle than to curse the darkness, at least when the candle is this easy to light.

Cheers,

Jeff

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitraryvacuum flags
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Sum aggregate calculation for single precsion real