From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pgbench - use pg logging capabilities |
Date: | 2020-01-06 12:36:23 |
Message-ID: | alpine.DEB.2.21.2001061050340.24609@pseudo |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bonjour Michaël,
>> Without looking at the context I thought that argv[0] was the program name,
>> which is not the case here. I put it back everywhere, including the DEBUG
>> message.
>
> The variable names in Command are confusing IMO...
Somehow, yes. Note that there is a logic, it will indeed be the argv of
the called shell command… And I do not think it is the point of this patch
to solve this possible confusion.
> + pg_log_error("gaussian parameter must be at least "
> + "%f (not %f)", MIN_GAUSSIAN_PARAM, param);
> I would keep all the error message strings to be on the same line.
> That makes grepping for them easier on the same, and that's the usual
> convention even if these are larger than 72-80 characters.
Ok. I also did other similar cases accordingly.
> #ifdef DEBUG
> Worth removing this ifdef?
Yep, especially as it is the only instance. Done.
> + pg_log_fatal("unexpected copy in result");
> + pg_log_error("%s", PQerrorMessage(con));
> + pg_log_fatal("cannot count number of branches");
> + pg_log_error("%s", PQerrorMessage(con));
> These are inconsistent with the rest, why not combining both?
Ok, done.
> I think that I would just remove the "debug" variable defined in
> pgbench.c all together, and switch the messages for the duration and the
> one in executeMetaCommand to use info-level logging..
Ok, done.
Patch v4 attached addresses all these points.
--
Fabien.
Attachment | Content-Type | Size |
---|---|---|
pgbench-logging-4.patch | text/x-diff | 39.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2020-01-06 12:43:16 | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |
Previous Message | Peter Eisentraut | 2020-01-06 12:32:53 | ALTER TABLE ... SET STORAGE does not propagate to indexes |