pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedxmin value from pg_stat_replication
4+ messages / 4 participants
[nested] [flat]
* xmin value from pg_stat_replication
@ 2019-07-17 18:31 S. Bob <sbob@quadratum-braccas.com>
2019-07-17 18:38 ` Re: xmin value from pg_stat_replication Jerry Sievers <gsievers19@comcast.net>
2019-07-17 20:32 ` Re: xmin value from pg_stat_replication Andres Freund <andres@anarazel.de>
0 siblings, 2 replies; 4+ messages in thread
From: S. Bob @ 2019-07-17 18:31 UTC (permalink / raw)
To: pgsql-admin@lists.postgresql.org
All;
We have a master and a standby (Streaming replication).
This query produces a value of approx 1.5million on the master and
approx 80million on the standby:
select slot_name, slot_type, database, xmin from pg_replication_slots
order by age(xmin);
We are running replication in async mode.
A couple of questions:
- Is it unusual for the master & standby to differ dramatically like this?
- could the replication slot (i.e. the xmin on the standby) be
preventing vacuum from cleaning up row versions on the master?
Thanks in advance
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: xmin value from pg_stat_replication
2019-07-17 18:31 xmin value from pg_stat_replication S. Bob <sbob@quadratum-braccas.com>
@ 2019-07-17 18:38 ` Jerry Sievers <gsievers19@comcast.net>
1 sibling, 0 replies; 4+ messages in thread
From: Jerry Sievers @ 2019-07-17 18:38 UTC (permalink / raw)
To: S. Bob <sbob@quadratum-braccas.com>; +Cc: pgsql-admin@lists.postgresql.org
"S. Bob" <sbob@quadratum-braccas.com> writes:
> All;
>
>
> We have a master and a standby (Streaming replication).
>
> This query produces a value of approx 1.5million on the master and
> approx 80million on the standby:
>
>
> select slot_name, slot_type, database, xmin from pg_replication_slots
> order by age(xmin);
Why does your standby have rep slots? Is it also feeding lower
subordinate standbys?
>
>
> We are running replication in async mode.
>
>
> A couple of questions:
>
>
> - Is it unusual for the master & standby to differ dramatically like this?
>
> - could the replication slot (i.e. the xmin on the standby) be
> preventing vacuum from cleaning up row versions on the master?
>
>
> Thanks in advance
>
>
>
>
>
>
>
>
>
--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consulting@comcast.net
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: xmin value from pg_stat_replication
2019-07-17 18:31 xmin value from pg_stat_replication S. Bob <sbob@quadratum-braccas.com>
@ 2019-07-17 20:32 ` Andres Freund <andres@anarazel.de>
2019-07-17 23:03 ` Re: xmin value from pg_stat_replication SBob <sbob@quadratum-braccas.com>
1 sibling, 1 reply; 4+ messages in thread
From: Andres Freund @ 2019-07-17 20:32 UTC (permalink / raw)
To: S. Bob <sbob@quadratum-braccas.com>; +Cc: pgsql-admin@lists.postgresql.org
Hi,
On 2019-07-17 12:31:29 -0600, S. Bob wrote:
> We have a master and a standby (Streaming replication).
>
> This query produces a value of approx 1.5million on the master and approx
> 80million on the standby:
>
>
> select slot_name, slot_type, database, xmin from pg_replication_slots order
> by age(xmin);
I'd suggest using age(xmin) in the output as well, not just in the ORDER
BY, otherwise it's hard to make sense of the value.
When you say a value of '1.5 million' on the master, how did you
determine that? Because the above doesn't return anything for the
master. The simplest way to determine that is probably:
SELECT max(age(backend_xmin)) FROM pg_stat_activity;
When you say '80 million', do you mean that pg_replication_slots.xmin
was 80 million, or age(pg_replication_slots.xmin)? If it's the former,
then that would indicate that the standby is *not* a problem, but that
you have a long-running transaction or such on the primary.
Basically, age(xmin) has to be large, not xmin itself.
> We are running replication in async mode.
>
>
> A couple of questions:
>
>
> - Is it unusual for the master & standby to differ dramatically like this?
Do you have very longrunning queries on the standby or primary? That's
typically the reason why xmin is old.
> - could the replication slot (i.e. the xmin on the standby) be preventing
> vacuum from cleaning up row versions on the master?
Yes.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: xmin value from pg_stat_replication
2019-07-17 18:31 xmin value from pg_stat_replication S. Bob <sbob@quadratum-braccas.com>
2019-07-17 20:32 ` Re: xmin value from pg_stat_replication Andres Freund <andres@anarazel.de>
@ 2019-07-17 23:03 ` SBob <sbob@quadratum-braccas.com>
0 siblings, 0 replies; 4+ messages in thread
From: SBob @ 2019-07-17 23:03 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: pgsql-admin@lists.postgresql.org
Thanks for the feedva k,
It turns out we were not looking at master & skave. The slave has no replication slot. We are seeing lots of row versions not getting cleaned up, trying toinvestigate all the possible causes. Is there a way to determine which connections (on the master or the slave) are the cause of the row versions not getting cleaned up?
Thanks
On Wed, Jul 17, 2019, at 4:32 PM, Andres Freund wrote:
> Hi,
>
> On 2019-07-17 12:31:29 -0600, S. Bob wrote:
> > We have a master and a standby (Streaming replication).
> >
> > This query produces a value of approx 1.5million on the master and approx
> > 80million on the standby:
> >
> >
> > select slot_name, slot_type, database, xmin from pg_replication_slots order
> > by age(xmin);
>
> I'd suggest using age(xmin) in the output as well, not just in the ORDER
> BY, otherwise it's hard to make sense of the value.
>
> When you say a value of '1.5 million' on the master, how did you
> determine that? Because the above doesn't return anything for the
> master. The simplest way to determine that is probably:
>
> SELECT max(age(backend_xmin)) FROM pg_stat_activity;
>
>
> When you say '80 million', do you mean that pg_replication_slots.xmin
> was 80 million, or age(pg_replication_slots.xmin)? If it's the former,
> then that would indicate that the standby is *not* a problem, but that
> you have a long-running transaction or such on the primary.
>
> Basically, age(xmin) has to be large, not xmin itself.
>
>
> > We are running replication in async mode.
> >
> >
> > A couple of questions:
> >
> >
> > - Is it unusual for the master & standby to differ dramatically like this?
>
> Do you have very longrunning queries on the standby or primary? That's
> typically the reason why xmin is old.
>
>
> > - could the replication slot (i.e. the xmin on the standby) be preventing
> > vacuum from cleaning up row versions on the master?
>
> Yes.
>
> Greetings,
>
> Andres Freund
>
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2019-07-17 23:03 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2019-07-17 18:31 xmin value from pg_stat_replication S. Bob <sbob@quadratum-braccas.com>
2019-07-17 18:38 ` Jerry Sievers <gsievers19@comcast.net>
2019-07-17 20:32 ` Andres Freund <andres@anarazel.de>
2019-07-17 23:03 ` SBob <sbob@quadratum-braccas.com>
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