| 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: | Whole Thread | Raw Message | 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 |