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 |
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 |