| From: | Chris Bandy <bandy(dot)chris(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Subject: | Re: Lost logs with csvlog redirected to stderr under WIN32 service |
| Date: | 2021-10-07 02:33:24 |
| Message-ID: | 30a3cd02-5fc3-4956-1dbb-05bee26be158@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 10/6/21 12:10 AM, Michael Paquier wrote:
> I have thought about various ways to
> fix that, and finished with a solution where we handle csvlog first,
> and fallback to stderr after so as there is only one code path for
> stderr, as of the attached. This reduces a bit the confusion around
> the handling of the stderr data that gets free()'d in more code paths
> than really needed.
I don't have a windows machine to test, but this refactor looks good to me.
> + /* Write to CSV log, if enabled */
> + if ((Log_destination & LOG_DESTINATION_CSVLOG) != 0)
This was originally "if (Log_destination & LOG_DESTINATION_CSVLOG)" and
other conditions nearby still lack the "!= 0". Whatever the preferred
style, the lines touched by this patch should probably do this consistently.
-- Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2021-10-07 02:44:30 | Re: strange case of "if ((a & b))" |
| Previous Message | Masahiko Sawada | 2021-10-07 02:18:24 | Re: strange case of "if ((a & b))" |