On Mon, Mar 05, 2018 at 04:34:09PM -0800, Andres Freund wrote:
> Scratch that, we should be going down the
> /* If caller supplied OID, there's nothing we need do here. */
> if (OidIsValid(vrel->oid))
> {
> oldcontext = MemoryContextSwitchTo(vac_context);
>
On 2018-03-05 19:53:23 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Scratch that, we should be going down the
> > /* If caller supplied OID, there's nothing we need do here. */
> > branch in expand_vacuum_rel() for autovacuum, so this shouldn't
> > matter. Sorry for the noise
>
> But yo
Andres Freund writes:
> Scratch that, we should be going down the
> /* If caller supplied OID, there's nothing we need do here. */
> branch in expand_vacuum_rel() for autovacuum, so this shouldn't
> matter. Sorry for the noise
But you said you'd seen blocking behind AEL with NOWAIT, so ther
Andres Freund writes:
> On 2017-09-29 20:26:42 +, Tom Lane wrote:
>> get_rel_oids used to not take any relation locks at all, but that stopped
>> being a good idea with commit 3c3bb9933, which inserted a syscache lookup
>> into the function. A concurrent DROP TABLE could now produce "cache lo
On 2018-03-05 16:11:52 -0800, Andres Freund wrote:
> Hi Tom,
>
> On 2017-09-29 20:26:42 +, Tom Lane wrote:
> > get_rel_oids used to not take any relation locks at all, but that stopped
> > being a good idea with commit 3c3bb9933, which inserted a syscache lookup
> > into the function. A concu
Hi Tom,
On 2017-09-29 20:26:42 +, Tom Lane wrote:
> get_rel_oids used to not take any relation locks at all, but that stopped
> being a good idea with commit 3c3bb9933, which inserted a syscache lookup
> into the function. A concurrent DROP TABLE could now produce "cache lookup
> failed", whi
