From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, vignesh C <vignesh21(at)gmail(dot)com>, Euler Taveira <euler(dot)taveira(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Log message for GSS connection is missing once connection authorization is successful. |
Date: | 2021-03-21 12:23:04 |
Message-ID: | CALj2ACVjc6ha8evW4Csz0y5Jkz5XGd51eM22j5+C_7s8z61C5g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Mar 20, 2021 at 4:59 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Sat, Mar 20, 2021 at 05:37:47PM +0900, Michael Paquier wrote:
> > It seems to me that this would make the tests faster, that the test
> > would not need to wait for the logging collector and that the code
> > could just use slurp_file($node->logfile) to get the data it wants to
> > check for a given pattern without looking at current_logfiles. I also
> > think that not using truncate() on the logfile generated has the
> > disadvantage to make the code fuzzy for its verification once we
> > introduce patterns close to each other, as there could easily be an
> > overlap. That's one problem that SQL pattern checks had to deal with
> > in the past. Thoughts?
>
> And, in terms of code, this really simplifies things. Please see the
> attached that I would like to apply.
+1 from me. So, after every call to test_access, the node's current
logfile gets truncated and we don't need the logging collector process
to step in for rotation of the logfile.
The patch looks good to me and the kerberos regression tests pass with it.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Gilles Darold | 2021-03-21 13:19:13 | Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace |
Previous Message | Andrew Dunstan | 2021-03-21 11:47:12 | Re: pg_upgrade failing for 200+ million Large Objects |