|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Joe Conway <joe(at)crunchydata(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>|
|Subject:||Re: New Object Access Type hooks|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2022-03-22 18:41:45 -0400, Tom Lane wrote:
> Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> writes:
> >> On Mar 22, 2022, at 3:20 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> >> Seems like it might actually be good to test that object access hooks work
> >> well in a parallel worker. How about going the other way and explicitly setting
> >> force_parallel_mode = disabled for parts of the test and to enabled for
> >> others?
> > Wouldn't we get differing numbers of NOTICE messages depending on how
> > many parallel workers there are? Or would you propose setting the
> > number of workers to a small, fixed value?
> The value would have to be "1", else you are going to have issues
> with notices from different workers being interleaved differently
> from run to run.
Yea. Possible one could work around those with some effort (using multiple
notification channels maybe), but there seems little to glean from multiple
workers that a single worker wouldn't show.
> You might have that anyway, due to interleaving of leader and worker
That part could perhaps be addressed by setting parallel_leader_participation
|Next Message||Justin Pryzby||2022-03-22 23:13:11||Re: New Object Access Type hooks|
|Previous Message||Nathan Bossart||2022-03-22 23:06:40||Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)|