Re: [PATCH] Expose port->authn_id to extensions and triggers

From: Jacob Champion <pchampion(at)vmware(dot)com>
To: "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "rjuju123(at)gmail(dot)com" <rjuju123(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "michael(at)paquier(dot)xyz" <michael(at)paquier(dot)xyz>, "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net>
Subject: Re: [PATCH] Expose port->authn_id to extensions and triggers
Date: 2022-03-31 21:49:00
Message-ID: 9152c293efbf705f7df3715c10c6c4276d3b89dd.camel@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2022-03-29 at 23:38 +0000, Jacob Champion wrote:
> v8 rebases over the recent SSL changes to get the cfbot green again.

I think the Windows failure [1] is unrelated to this patch, but for
posterity:

> [03:01:58.925] c:\cirrus>call "C:/Program Files/Git/usr/bin/timeout.exe" -v -k60s 15m perl src/tools/msvc/vcregress.pl recoverycheck
> [03:03:16.106] [03:03:16] t/001_stream_rep.pl .................. ok 76551 ms ( 0.00 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.00 CPU)
> [03:03:16.120] [03:03:16] t/002_archiving.pl ................... ok 0 ms ( 0.02 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.02 CPU)
> [03:03:16.128] [03:03:16] t/003_recovery_targets.pl ............ ok 0 ms ( 0.00 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.00 CPU)
> [03:03:16.138] [03:03:16] t/004_timeline_switch.pl ............. ok 0 ms ( 0.00 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.00 CPU)
> [03:03:16.141] [03:03:16] t/005_replay_delay.pl ................ ok 0 ms ( 0.00 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.00 CPU)
> [03:03:24.561] [03:03:24] t/006_logical_decoding.pl ............ ok 8416 ms ( 0.00 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.00 CPU)
> [03:03:32.496] [03:03:32] t/007_sync_rep.pl .................... ok 7895 ms ( 0.00 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.00 CPU)
> [03:03:32.496] [03:03:32] t/008_fsm_truncation.pl .............. ok 0 ms ( 0.00 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.00 CPU)
> [03:16:58.985] /usr/bin/timeout: sending signal TERM to command ‘perl’

The server and client logs don't quite match up; it looks like we get
partway through t/018_wal_optimize.pl, maybe to the end of the
`wal_level = minimal, SET TABLESPACE commit subtransaction` test,
before hanging.

I see that there's an active thread about a hang later in the recovery
suite [2]. That's suspicious since 019 is just the next test, but I
don't see any evidence in the logs that we actually started test 019 in
this run.

--Jacob

[1] https://cirrus-ci.com/task/5434752374145024
[2] https://www.postgresql.org/message-id/flat/83b46e5f-2a52-86aa-fa6c-8174908174b8%40iki.fi

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Cary Huang 2022-03-31 22:01:04 Re: pg_receivewal fail to streams when the partial file to write is not fully initialized present in the wal receiver directory
Previous Message Thomas Munro 2022-03-31 21:42:59 Re: A qsort template