pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Frost <jeff@pgexperts.com>
Cc: Andres Freund <andres@2ndquadrant.com>
Cc: Matheus de Oliveira <matioli.matheus@gmail.com>
Cc: Soni M <diptatapa@gmail.com>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: Postgres Replaying WAL slowly
Date: Mon, 30 Jun 2014 16:39:44 -0400
Message-ID: <21474.1404160784@sss.pgh.pa.us> (raw)
In-Reply-To: <943ECC8E-8899-422E-937C-50DE20E1F7AC@pgexperts.com>
References: <20140630171416.GK21422@awork2.anarazel.de>
	<CAAMgDXnT8cQbwxcNXfFKONrRVAKoGhR-3FWYSX_5gJcFrEMPMQ@mail.gmail.com>
	<8DA8C140-818D-4184-AAE6-CA37278B983C@pgexperts.com>
	<20140630183908.GT26930@awork2.anarazel.de>
	<0A7B96D4-DB10-49A8-A268-F28960F2E137@pgexperts.com>
	<F3E1168D-8D49-407E-A8B7-B3ED81C93DCB@pgexperts.com>
	<20300.1404156750@sss.pgh.pa.us>
	<C64129CF-D034-4311-AD32-09EF048C3E93@pgexperts.com>
	<CAJghg4Lq2rg7mMzRfEartAQK1c83veoW3TWroQsSvXMqBQ9h+w@mail.gmail.com>
	<B22B06CF-2BC0-4AB6-8E3C-FACDF8193F23@pgexperts.com>
	<20140630201523.GV26930@awork2.anarazel.de>
	<943ECC8E-8899-422E-937C-50DE20E1F7AC@pgexperts.com>
List-Unsubscribe:  <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>

Jeff Frost <jeff@pgexperts.com> writes:
> On Jun 30, 2014, at 1:15 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> So these are probably relations created in uncommitted
>> transactions. Possibly ON COMMIT DROP temp tables?

> That would make sense.  There are definitely quite a few of those being used.

Uh-huh.  I doubt that the mechanism that handles propagation of
AccessExclusiveLocks to the standby is smart enough to ignore locks
on temp tables :-(

> Another item of note is the system catalogs are quite bloated:
> Would that cause the replica to spin on StandbyReleaseLocks?

AFAIK, no.  It's an unsurprising consequence of heavy use of short-lived
temp tables though.

So it seems like we have a candidate explanation.  I'm a bit surprised
that StandbyReleaseLocks would get this slow if there are only a dozen
AccessExclusiveLocks in place at any one time, though.  Perhaps that
was a low point and there are often many more?

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance



view thread (33+ messages)  latest in thread

Message-ID: <21474.1404160784@sss.pgh.pa.us>
Permalink:  ../21474.1404160784@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/21474.1404160784@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: tgl@sss.pgh.pa.us, jeff@pgexperts.com, andres@2ndquadrant.com, matioli.matheus@gmail.com, diptatapa@gmail.com, hlinnakangas@vmware.com
  Subject: Re: Postgres Replaying WAL slowly
  In-Reply-To: <21474.1404160784@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox