Hi,
On 2021-12-13 13:57:52 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2021-12-13 19:46:34 +0900, Michael Paquier wrote:
> >> +1 for the idea. Maybe it could be backpatched?
>
> > Not entirely trivially - the changes have some dependencies on other changes
> > (e.g. b1907d688, more on
Andres Freund writes:
> On 2021-12-13 19:46:34 +0900, Michael Paquier wrote:
>> +1 for the idea. Maybe it could be backpatched?
> Not entirely trivially - the changes have some dependencies on other changes
> (e.g. b1907d688, more on 741d7f104, but that was backpatched). I guess we
> could backp
Hi,
On 2021-12-13 19:46:34 +0900, Michael Paquier wrote:
> On Fri, Dec 10, 2021 at 05:20:52PM -0800, Andres Freund wrote:
> > These days isolationtester.c already prefixes log output with the session
> > name. How about doing the same for application_name? It's a *tad* more
> > complicated than I'
On Fri, Dec 10, 2021 at 05:20:52PM -0800, Andres Freund wrote:
> These days isolationtester.c already prefixes log output with the session
> name. How about doing the same for application_name? It's a *tad* more
> complicated than I'd like because isolationtester.c currently doesn't know the
> name
On 12/10/21 20:20, Andres Freund wrote:
> The attached patch executes
> SELECT set_config('application_name', current_setting('application_name')
> || '/' || $1, false);
> when establishing connections to deal with that.
Sounds good
>
> As attached this appends "control connection" for the
Hi,
When writing / debugging an isolation test it's sometimes useful to see which
session holds what lock etc. I find it kind of painful to map pg_stat_activity
/ pg_locks / log output to the isolationtester spec. Sometimes its easy enough
to infer identity based on a statement, but far from all t
