Re: pg_stat_replication in 9.3

From: Torsten Förtsch <torsten(dot)foertsch(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andy Colson <andy(at)squeakycode(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: pg_stat_replication in 9.3
Date: 2014-09-14 20:47:41
Message-ID: 5415FEED.9000000@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 14/09/14 18:55, Tom Lane wrote:
> Are you watching the state in a loop inside a single plpgsql function?
> If so, I wonder whether the problem is that the plpgsql function's
> snapshot isn't changing. From memory, marking the function VOLATILE
> would help if that's the issue.

The function is VOLATILE. I attached 2 versions of it. fn-old.sql does
not work because once a slave has disconnected it drops out and does not
come back. fn.sql uses dblink to work around the problem. But it
consumes 2 db connections.

The intent of the function is to be called between operations that may
cause slaves to lag behind. If the lag is below a certain limit, it
simply returns. Otherwise, it waits until the lag drops below a second
limit.

If it were a VOLATILE problem, the functions would not be able to see
when a slave drops out nor changes in the data. But it does see these
changes. Only when a slave comes back online, it is not seen in the
current transaction.

Torsten

Attachment Content-Type Size
fn-old.sql text/x-sql 2.1 KB
fn.sql text/x-sql 2.8 KB

In response to

Browse pgsql-general by date

  From Date Subject
Next Message cowwoc 2014-09-14 21:01:54 Feature request: temporary schemas
Previous Message Tom Lane 2014-09-14 16:55:29 Re: pg_stat_replication in 9.3