| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Erik Jones <mage2k(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Hot Standby Conflict on pg_attribute |
| Date: | 2019-05-10 19:40:55 |
| Message-ID: | 14290.1557517255@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Andres Freund <andres(at)anarazel(dot)de> 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 AccessShareLock on
> pg_attribute (and pg_class, pg_index, ...) for a short time.
Also, it seems likely that what's really triggering the issue is
autovacuum on pg_attribute trying to truncate off empty pages
in pg_attribute (after a bunch of dead rows were generated there
by DDL activity). That requires exclusive lock on pg_attribute,
which would propagate down to the standby.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Erik Jones | 2019-05-10 19:46:58 | Re: Hot Standby Conflict on pg_attribute |
| Previous Message | Erik Jones | 2019-05-10 19:23:38 | Re: Hot Standby Conflict on pg_attribute |