Thanks for the ti
On Sat, May 11, 2019 at 9:15 AM Jeremy Schneider
wrote:
> Just a quick footnote: If autovac truncations are frequently causing
> replica lag, and if this is a problem for you, IIUC one way you can stop
> autovac from doing the truncations even on older versions is setting
> old
Just a quick footnote: If autovac truncations are frequently causing replica
lag, and if this is a problem for you, IIUC one way you can stop autovac from
doing the truncations even on older versions is setting old_snapshot_threshold
to any value at all besides zero. (On 12+ you can directly co
On Fri, May 10, 2019 at 12:41 PM Tom Lane wrote:
> Andres Freund writes:
> > On 2019-05-09 13:03:50 -0700, Erik Jones wrote:
> >> The question then is: Why would these user queries be waiting on an
> >> AccessShare lock on pg_attribute?
>
> > Queries that access a table for the *first* time afte
Andres Freund writes:
> On 2019-05-09 13:03:50 -0700, Erik Jones wrote:
>> The question then is: Why would these user queries be waiting on an
>> AccessShare lock on pg_attribute?
> Queries that access a table for the *first* time after DDL happened
> (including truncating the relation), need an
Hi Andres,
Thank you very much! That's exactly what I needed.
On Fri, May 10, 2019 at 12:14 PM Andres Freund wrote:
> Hi,
>
> On 2019-05-09 13:03:50 -0700, Erik Jones wrote:
> > The question then is: Why would these user queries be waiting on an
> > AccessShare lock on pg_attribute? Thus far
Hi,
On 2019-05-09 13:03:50 -0700, Erik Jones wrote:
> The question then is: Why would these user queries be waiting on an
> AccessShare lock on pg_attribute? Thus far we've been unable to recreate
> any transacitons with the above query (and others) that show any
> pg_attribute locks. There is n
