Hello,
On 2024-Aug-14, Jelte Fennema-Nio wrote:
> The following removed comments seems useful to keep (I realize I
> already removed them in a previous version of the patch, but I don't
> think I did that on purpose)
> [...]
Ah, yeah, I agree. I put them back, and pushed 0005, 6 and 7 as a
sing
On Wed, 14 Aug 2024 at 19:37, Alvaro Herrera wrote:
> - to 0005 I change your pqTraceOutputEncryptionRequestResponse()
> function name to pqTraceOutputCharResponse and instead of attaching
> the "Response" literal in the outpuer to the name given in the
> function call, just pass the whole s
I gave another look to the remaining patches; here they are again. I
propose some changes:
- to 0005 I change your pqTraceOutputEncryptionRequestResponse()
function name to pqTraceOutputCharResponse and instead of attaching
the "Response" literal in the outpuer to the name given in the
func
On 2024-Aug-10, Jelte Fennema-Nio wrote:
> On Sat, 10 Aug 2024 at 01:08, Alvaro Herrera wrote:
> > I propose something like the attached, but it's as yet untested. What
> > do you think?
>
> Looks good, but I haven't tested it yet either.
I tested the SASL exchange and it looks OK. Didn't te
On Sat, 10 Aug 2024 at 01:08, Alvaro Herrera wrote:
> I don't want to add 4 bytes to struct pg_conn for tracing support. I'm
> tempted to make the new struct member a plain 'char' to reduce overhead
> for a feature that almost nobody is going to use. According to pahole
> we have a 3 bytes hole
Regarding 0004:
I don't want to add 4 bytes to struct pg_conn for tracing support. I'm
tempted to make the new struct member a plain 'char' to reduce overhead
for a feature that almost nobody is going to use. According to pahole
we have a 3 bytes hole in that position of the struct, so if we mak
Pushed 0002 and 0003. On the latter: I decided against using int32 to
print the request identifiers; by splitting into two int16's, we see
that the numbers match the values in the PG_PROTOCOL() declarations:
2024-08-09 17:37:38.364622 F 8 SSLRequest 1234 5679
and
2024-08-09
On Thu, 27 Jun 2024 at 07:39, Michael Paquier wrote:
> Looking at the whole, the rest of the patch set qualifies as a new
> feature, even if they're aimed at closing existing gaps.
Alright, seems reasonable. To be clear, I don't care at all about this
being backported personally.
> Particularly,
On Wed, Jun 26, 2024 at 10:02:08PM +0200, Jelte Fennema-Nio wrote:
> On Wed, 26 Jun 2024 at 18:36, Alvaro Herrera wrote:
> > Thanks, Nathan. I'm holding myself responsible for the rest ... will
> > handle soon after the branch.
>
> Sounds great. Out of curiosity, what is the backpatching policy
On Wed, 26 Jun 2024 at 18:36, Alvaro Herrera wrote:
> Thanks, Nathan. I'm holding myself responsible for the rest ... will
> handle soon after the branch.
Sounds great. Out of curiosity, what is the backpatching policy for
something like this? Honestly most of these patches could be
considered b
On 2024-Jun-26, Nathan Bossart wrote:
> On Fri, Jun 21, 2024 at 04:01:55PM -0500, Nathan Bossart wrote:
> > On Fri, Jun 21, 2024 at 11:22:05AM +0200, Jelte Fennema-Nio wrote:
> >> 0001 is some cleanup after f4b54e1ed9
> >
> > Oops. I'll plan on committing this after the 17beta2 release freeze is
On Fri, Jun 21, 2024 at 04:01:55PM -0500, Nathan Bossart wrote:
> On Fri, Jun 21, 2024 at 11:22:05AM +0200, Jelte Fennema-Nio wrote:
>> 0001 is some cleanup after f4b54e1ed9
>
> Oops. I'll plan on committing this after the 17beta2 release freeze is
> lifted.
Committed 0001.
--
nathan
On Fri, Jun 21, 2024 at 11:22:05AM +0200, Jelte Fennema-Nio wrote:
> 0001 is some cleanup after f4b54e1ed9
Oops. I'll plan on committing this after the 17beta2 release freeze is
lifted.
--
nathan
After initially trying to add trace support for
StartupMessage/SSLRequest/GSSENCRequest[1] I realized there were many
more cases where PQtrace was not correctly tracing messages, or not
even tracing them at all. These patches fix all of the issues that I
was able to find.
0001 is some cleanup afte
14 matches
Mail list logo
