On Thu, Feb 10, 2022 at 07:45:17PM -0300, Alvaro Herrera wrote:
> From what I hear in the container world, what they would *prefer* (but
> they don't often get) is to receive the JSON-format logs directly in
> stderr from the daemons they run; they capture stderr and they have the
> logs just in
Alvaro Herrera writes:
> So, thinking about this, there is one important piece that is missing
> here, which is the ability to change the default format for what we
> write to stderr. Right now, if you have stderr output, it is always in
> the "plain multiline" format, with no option to change
So, thinking about this, there is one important piece that is missing
here, which is the ability to change the default format for what we
write to stderr. Right now, if you have stderr output, it is always in
the "plain multiline" format, with no option to change it. If you want
a JSON log, you
On Mon, Jan 17, 2022 at 10:48:06AM +0900, Michael Paquier wrote:
> Okay, this last piece has been applied this morning, after more review
> and a couple of adjustments, mainly cosmetic (pg_current_logfile
> missed a refresh, incorrect copyright in jsonlog.c, etc.). Let's see
> what the buildfarm
On Wed, Jan 12, 2022 at 03:27:19PM +0900, Michael Paquier wrote:
> This part will have to wait a bit more, but yes, this piece should be
> straight-forward.
Okay, this last piece has been applied this morning, after more review
and a couple of adjustments, mainly cosmetic (pg_current_logfile
On Tue, Jan 11, 2022 at 08:34:26PM +, Bossart, Nathan wrote:
> I've been looking at the latest patch set intermittently and playing
> around with jsonlog a little. It seems to work well, and I don't have
> any significant comments about the code. 0001 and 0002 seem
> straightforward and
On 1/10/22, 4:51 AM, "Michael Paquier" wrote:
> The issue comes from an incorrect change in syslogger_parseArgs()
> where I missed that the incrementation of argv by 3 has no need to be
> changed. A build with -DEXEC_BACKEND is enough to show the failure,
> which caused a crash when starting up
On Fri, Jan 07, 2022 at 03:49:47PM +0900, Michael Paquier wrote:
> Yes, I was waiting for the latest results, but that did not help at
> all. Something is wrong with the patch, I am not sure what yet, but
> that seems like a mistake in the backend part of it rather than the
> tests. I have
On Thu, Jan 06, 2022 at 06:28:26PM -0500, Andrew Dunstan wrote:
> I have tested on an msys2 setup with your v8 patches and I am getting this:
>
> # Failed test 'current_logfiles is sane'
> # at t/004_logrotate.pl line 96.
> # 'stderr log/postgresql-2022-01-06_222419.log
> #
On 1/6/22 13:06, Andrew Dunstan wrote:
> On 1/5/22 02:32, Michael Paquier wrote:
>> On Sun, Jan 02, 2022 at 01:34:45PM -0800, Andres Freund wrote:
>>> The tests don't seem to pass on windows:
>>> https://cirrus-ci.com/task/5412456754315264?logs=test_bin#L47
>>>
On 1/5/22 02:32, Michael Paquier wrote:
> On Sun, Jan 02, 2022 at 01:34:45PM -0800, Andres Freund wrote:
>> The tests don't seem to pass on windows:
>> https://cirrus-ci.com/task/5412456754315264?logs=test_bin#L47
>>
On Sun, Jan 02, 2022 at 01:34:45PM -0800, Andres Freund wrote:
> The tests don't seem to pass on windows:
> https://cirrus-ci.com/task/5412456754315264?logs=test_bin#L47
> https://api.cirrus-ci.com/v1/artifact/task/5412456754315264/tap/src/bin/pg_ctl/tmp_check/log/regress_log_004_logrotate
>
>
Hi,
On 2021-11-10 22:44:49 +0900, Michael Paquier wrote:
> Patch 0003 has been heavily reworked, and it would be good to have an
> extra pair of eyes on it. So I have switched the CF entry as "Needs
> Review" and added my name to the list of authors (originally this
> stuff took code portions of
On Tue, Oct 19, 2021 at 08:02:02PM +0900, Michael Paquier wrote:
> 0001 and 0002, the refactoring bits, are in a rather committable
> shape, so I'd like to apply that as the last refactoring pieces I know
> of for this thread. 0003 still needs a closer lookup, and one part I
> do not like much in
On Fri, Oct 08, 2021 at 12:28:58PM +0900, Michael Paquier wrote:
> 0001 and 0003 have been applied independently, attached is a rebased
> version.
Attached are rebased versions of the patch set, where I have done a
cleaner split:
- 0001 includes all the refactoring of the routines from elog.c.
-
On Tue, Oct 05, 2021 at 04:18:17PM +0900, Michael Paquier wrote:
> 0002 and 0004 could be more polished and most of their pieces had
> better be squashed together. 0003, though, would improve the case of
> WIN32 where only csvlog is enabled so as log entries are properly
> redirected to the event
On Thu, Oct 07, 2021 at 06:00:08AM +, Bossart, Nathan wrote:
> The attached patch seems to fix it.
Thanks, sorry about that. I was able to see that once I compiled
without assertions.
--
Michael
signature.asc
Description: PGP signature
On Wed, Sep 29, 2021 at 11:02:10AM +0900, Michael Paquier wrote:
> This happens to not be a problem as only 32 bits are significant for
> handles for both Win32 and Win64. This also means that we should be
> able to remove the use for "long" in this code, making the routines
> more symmetric. I
On Tue, Sep 28, 2021 at 12:30:10PM +0900, Michael Paquier wrote:
> 0001 is in a rather commitable shape, and I have made the code
> consistent with HEAD. However, I think that its handling of
> _get_osfhandle() is clunky for 64-bit compilations as long is 32b in
> WIN32 but intptr_t is
On Fri, Sep 17, 2021 at 04:36:57PM -0400, Sehrope Sarkuni wrote:
> It was helpful to split them out while working on the patch but I see your
> point upon re-reading through the result.
>
> Attached version (renamed to 002) adds only three static functions for
> checking rotation size, performing
On Thu, Sep 16, 2021 at 9:36 PM Michael Paquier wrote:
> I am not really impressed by 0001 and the introduction of
> LOG_DESTINATIONS_WITH_FILES. So I would leave that out and keep the
> list of destinations listed instead. And we are talking about two
> places here, only within syslogger.c.
>
On Thu, Sep 16, 2021 at 05:27:20PM -0400, Sehrope Sarkuni wrote:
> Attached three patches refactor the syslogger handling of file based
> destinations a bit ... and then a lot.
>
> First patch adds a new constant to represent both file based destinations.
> This should make it easier to ensure
The previous patches failed on the cfbot Appveyor Windows build. That also
makes me question whether I did the EXEC_BACKEND testing correctly as it
should have caught that compile error. I'm going to look into that.
In the meantime the attached should correct that part of the build.
Regards,
--
Attached three patches refactor the syslogger handling of file based
destinations a bit ... and then a lot.
First patch adds a new constant to represent both file based destinations.
This should make it easier to ensure additional destinations are handled in
"For all file destinations..."
On Mon, Sep 13, 2021 at 11:56:52PM -0400, Sehrope Sarkuni wrote:
> Good catch. Staring at that piece again, that's tricky as it tries to
> aggressively free the buffer before calling write_cvslog(...). Which can't
> just be duplicated for additional destinations.
>
> I think we need to pull up
On Sun, Sep 12, 2021 at 10:22 PM Michael Paquier
wrote:
> On Fri, Sep 10, 2021 at 03:56:18PM +0900, Michael Paquier wrote:
> > And this part leads me to the attached, where the addition of the JSON
> > format would result in the addition of a couple of lines.
>
> Okay, I have worked through the
dType == B_LOGGER)
- write_syslogger_file(buf.data, buf.len, LOG_DESTINATION_CSVLOG);
- else
- write_pipe_chunks(buf.data, buf.len, LOG_DESTINATION_CSVLOG);
-
- pfree(buf.data);
-}
-
/*
* Unpack MAKE_SQLSTATE code. Note that this returns a pointer to a
On Fri, Sep 10, 2021 at 01:07:00PM +0900, Michael Paquier wrote:
> Forking a bit this thread while looking at 0002 that adds new tests
> for csvlog. While I agree that it would be useful to have more
> coverage with the syslogger message chunk protocol in this area, I
> think that having a
On Wed, Sep 01, 2021 at 04:39:43PM -0400, Sehrope Sarkuni wrote:
> This version splits out the existing csvlog code into its own file and
> centralizes the common helpers into a new elog-internal.h so that they're
> only included by the actual write_xyz sources.
>
> That makes the elog.c changes
On Thu, Sep 09, 2021 at 11:17:01AM +0900, Michael Paquier wrote:
> I was thinking to track stderr as a case where no bits are set in the
> flags for the area of the destinations, but that's a bit crazy if we
> have a lot of margin in what can be stored. I have looked at that and
> finished with
On Wed, Sep 08, 2021 at 10:58:51PM -0400, Greg Stark wrote:
> Please just put a "format" field (or "channel" field -- the logging
> daemon doesn't really care what format) with a list of defined formats
> that can easily be extended in the future. If you want to steal the
> high bit for "is last"
Fwiw I was shocked when I saw the t/f T/F kluge when I went to work on
jsonlogging. That's the kind of dead-end short-sighted hack that just
lays traps and barriers for future hackers to have to clean up before
they can do the work they want to do.
Please just put a "format" field (or "channel"
On Wed, Sep 08, 2021 at 08:46:44AM -0400, Andrew Dunstan wrote:
> Yeah. A very simple change would be to use two different values for json
> (say 'y' and 'n'). A slightly more principled scheme might use the top
> bit for the end marker and the bottom 3 bits for the dest type (so up to
> 8 types
On 9/8/21 2:58 AM, Michael Paquier wrote:
> On Wed, Sep 01, 2021 at 04:39:43PM -0400, Sehrope Sarkuni wrote:
>> That makes the elog.c changes in the JSON logging patch minimal as all it's
>> really doing is invoking the new write_jsonlog(...) function.
> Looking at 0001, to do things in order.
>
On Wed, Sep 01, 2021 at 04:39:43PM -0400, Sehrope Sarkuni wrote:
> That makes the elog.c changes in the JSON logging patch minimal as all it's
> really doing is invoking the new write_jsonlog(...) function.
Looking at 0001, to do things in order.
> @@ -46,8 +46,8 @@ typedef struct
> char
t-of-order,
+ * between ERROR and FATAL. Generally this is the right thing for testing
+ * whether a message should go to the postmaster log, whereas a simple >=
+ * test is correct for testing whether the message should go to the client.
+ */
+static inline bool
+is_log_level_output(int elevel, int log_min_l
On Tue, Aug 31, 2021 at 8:43 PM Michael Paquier wrote:
> On Tue, Aug 31, 2021 at 11:34:56AM -0400, Sehrope Sarkuni wrote:
> > The second commit adds a TAP test for log_destination "csvlog". This was
> > done to both confirm that the previous change didn't break anything and
> as
> > a skeleton
On Tue, Aug 31, 2021 at 11:34:56AM -0400, Sehrope Sarkuni wrote:
> The second commit adds a TAP test for log_destination "csvlog". This was
> done to both confirm that the previous change didn't break anything and as
> a skeleton for the test in the next commit.
+note "Before sleep";
mpts < $max_attempts; $attempts++)
+{
+ $second_logfile = slurp_file($node->data_dir . '/' . $lfname);
+ last if $second_logfile =~ m/syntax error/;
+ usleep(100_000);
+}
+
+like(
+ $second_logfile,
+ # Our log entry should have our bad string wrapped in quotes after the error
+ qr/syntax
39 matches
Mail list logo
