pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedVacuum Issues
16+ messages / 8 participants
[nested] [flat]
* Vacuum Issues
@ 2004-03-19 17:46 Mark M. Huber <MHuber@VMdirect.com>
0 siblings, 1 reply; 16+ messages in thread
From: Mark M. Huber @ 2004-03-19 17:46 UTC (permalink / raw)
To: pgsql-admin
Hi all
I have had this issue a couple of times now. on Solaris, and on 7.3 of the db.
I was did a normal vacuum and then I did a full which hung on a table, I waited for over an hour but there were no activity going on so I ctrl'cd the job in a terminal window, kill off all associated processes and try to do another normal vacuum which hung at the same spot. So I once again killed the processes. I went into the db and query the pg_tables tables and found the order of the tables, I vacuumed the ones just before and just after and they went fine but the offending table would not vacuum, Next I thought I could just pg_dump that table but the db would not allow me to do that either, I found a copy of the table from a restore I did on another box( the table has only 7 rows.) So I try to drop it but that would work either. So the only alternative was to stop and restart the db which is totally unacceptable in a 24x7 shop.
Does any one else see what I have done wrong or could do differently next time. Oh yes and after the stop and start I could do a full vacuum on that table as well as the whole database.
I know it's after st. Patrick's day but I did not find any green men lurking around to be causing this, any ideas?, hints?, suggestions?
I am at my wits ends as to where to turn next, I most certainly do not want to another vacuum full.
________________________________________
Mark M. Huber
Database Administrator
(702)-938-9300
markh@vmdirect.com
http://www.vmdirect.com
3035 E. Patrick Lane
Suite #1
Las Vegas, NV 89120
<<Mark M. Huber.vcf>>
Attachments:
Mark M. Huber.vcf (text/x-vcard, 132B) download
BEGIN:VCARD
VERSION:2.1
N:Huber;Mark
FN:Mark M. Huber
EMAIL;PREF;INTERNET:MHuber@VMdirect.com
REV:20040220T180108Z
END:VCARD
* Re: Vacuum Issues
@ 2004-03-22 16:39 Tom Lane <tgl@sss.pgh.pa.us>
parent: Mark M. Huber <MHuber@VMdirect.com>
0 siblings, 0 replies; 16+ messages in thread
From: Tom Lane @ 2004-03-22 16:39 UTC (permalink / raw)
To: Mark M. Huber <MHuber@VMdirect.com>; +Cc: pgsql-admin
"Mark M. Huber" <MHuber@VMdirect.com> writes:
> I was did a normal vacuum and then I did a full which hung on a table,
Sounds to me like some other transaction is holding a lock on that
table.
In recent releases you can look in the pg_locks system view to see
who's got the lock.
regards, tom lane
^ permalink raw reply [nested|flat] 16+ messages in thread
* Vacuum issues..
@ 2006-08-21 18:42 Eamonn Kent <ekent@xsigo.com>
0 siblings, 1 reply; 16+ messages in thread
From: Eamonn Kent @ 2006-08-21 18:42 UTC (permalink / raw)
To: pgsql-admin
Hi,
I am using PostgreSQL 8.1.4 for an embedded application. For some
reason, vacuum is not able to identify rows that are candidates for
removal (i.e., mark space as available).
Background Info:
I observed some performance problems - our database seemed to be using
an unusually high amount of cpu. Further investigation of the problem
revealed a very bloated database; the database was around 300M when it
should have been about 150M. A number of the database files were quite
large, however, the tables that they stored information for were very
small. For example, we had one table that had only 46 rows, but was
using up more than 17M of disk space. We had a number of other tables
that were similarly large.
We run auto vacuum and I can see from the logs that it is running quite
frequently. When I run vacuum full from the psql, I can see that space
is not being recovered. I have run vacuum full with the verbose flag
set, I can see that messages that indicate the existence of "dead row
versions that cannot be removed yet.
<--- CUT FROM VACUUM OUTPUT --->
CPU 0.00s/0.00u sec elapsed 0.18 sec.
INFO: "ibportreceivestatsca": found 0 removable, 88017 nonremovable row
versions in 4001 pages
DETAIL: 87957 dead row versions cannot be removed yet.
There were 1 unused item pointers.
<--- CUT FROM VACUUM OUTPUT --->
If I shutdown our application and run a vacuum full, the space is
recovered and the database size goes down to 150M.
So, my best guess is that something in our application is preventing
vacuum from removing dead rows. What could cause this? Would it be
caused by a long-living transaction? What is the best way to track the
problem down...right now, I am looking through pg_stat_activity and
pg_locks to find processes that are "in transaction" and what locks they
are holding.
Has anyone had a similar problem? If so, how did you resolve it?
Thanks
Ike
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Vacuum issues..
@ 2006-08-21 23:20 Matthew T. O'Connor <matthew@zeut.net>
parent: Eamonn Kent <ekent@xsigo.com>
0 siblings, 0 replies; 16+ messages in thread
From: Matthew T. O'Connor @ 2006-08-21 23:20 UTC (permalink / raw)
To: Eamonn Kent <ekent@xsigo.com>; +Cc: pgsql-admin
Eamonn Kent wrote:
> I am using PostgreSQL 8.1.4 for an embedded application. For some
> reason, vacuum is not able to identify rows that are candidates for
> removal (i.e., mark space as available).
[snip]
>
> If I shutdown our application and run a vacuum full, the space is
> recovered and the database size goes down to 150M.
The most common answer to this is that your application is leaving open
transactions just sitting there. VACUUM can't remove tuples that may
still need to be visible to a transaction that's been open for days.
^ permalink raw reply [nested|flat] 16+ messages in thread
* Vacuum Issues
@ 2020-03-26 18:10 Darron Harrison <darron@realtyserver.com>
0 siblings, 1 reply; 16+ messages in thread
From: Darron Harrison @ 2020-03-26 18:10 UTC (permalink / raw)
To: pgsql-admin <pgsql-admin@lists.postgresql.org>
Hi All,
Having an issue where vacuum has been unable to clear dead rows since March 12. We are running an older version 9.2.4 with three hot standby servers.
We have standby feedback enabled, but according to pg_stat_activity there are no long running queries on the master or standby servers.
Also, we have no hung transactions on the master server:
SELECT * FROM pg_stat_activity where xact_start < (now() - interval '5 mins') ORDER BY xact_start NULLS LAST LIMIT 1;
Produces no results.
Anyone have any thoughts on what we should be checking next?
Thanks,
Darron Harrison
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Vacuum Issues
@ 2020-03-26 18:50 Rui DeSousa <rui@crazybean.net>
parent: Darron Harrison <darron@realtyserver.com>
0 siblings, 1 reply; 16+ messages in thread
From: Rui DeSousa @ 2020-03-26 18:50 UTC (permalink / raw)
To: Darron Harrison <darron@realtyserver.com>; +Cc: pgsql-admin <pgsql-admin@lists.postgresql.org>
> On Mar 26, 2020, at 2:10 PM, Darron Harrison <darron@realtyserver.com> wrote:
>
>
> Anyone have any thoughts on what we should be checking next?
>
Check the backend_xmin in pg_stat_activity; is the holdup in one of replicas or on the master?
select pid
, usename
, client_addr
, state
, backend_type
, backend_xid
, backend_xmin
from pg_stat_activity
where backend_xmin is not null
order by age(backend_xmin) desc
limit 10
;
Two-phase transactions:
select * from pg_prepared_xacts;
Replication slots:
select * from pg_replication_slots;
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Vacuum Issues
@ 2020-03-26 19:01 Darron Harrison <darron@realtyserver.com>
parent: Rui DeSousa <rui@crazybean.net>
0 siblings, 1 reply; 16+ messages in thread
From: Darron Harrison @ 2020-03-26 19:01 UTC (permalink / raw)
To: Rui DeSousa <rui@crazybean.net>; +Cc: pgsql-admin <pgsql-admin@lists.postgresql.org>
Unable to run the first query and third query. I believe it's a version issue, as we are running 9.2.4.
No results from select * from pg_prepared_xacts on any of the servers.
Darron
---- On Thu, 26 Mar 2020 11:50:10 -0700 Rui DeSousa <rui@crazybean.net> wrote ----
On Mar 26, 2020, at 2:10 PM, Darron Harrison <mailto:darron@realtyserver.com> wrote:
Anyone have any thoughts on what we should be checking next?
Check the backend_xmin in pg_stat_activity; is the holdup in one of replicas or on the master?
select pid
, usename
, client_addr
, state
, backend_type
, backend_xid
, backend_xmin
from pg_stat_activity
where backend_xmin is not null
order by age(backend_xmin) desc
limit 10
;
Two-phase transactions:
select * from pg_prepared_xacts;
Replication slots:
select * from pg_replication_slots;
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Vacuum Issues
@ 2020-03-26 19:22 Rui DeSousa <rui@crazybean.net>
parent: Darron Harrison <darron@realtyserver.com>
0 siblings, 1 reply; 16+ messages in thread
From: Rui DeSousa @ 2020-03-26 19:22 UTC (permalink / raw)
To: Darron Harrison <darron@realtyserver.com>; +Cc: pgsql-admin <pgsql-admin@lists.postgresql.org>
> On Mar 26, 2020, at 3:01 PM, Darron Harrison <darron@realtyserver.com> wrote:
>
> Unable to run the first query and third query. I believe it's a version issue, as we are running 9.2.4.
>
Looks like backend_xmin was added in 9.4; shoot
Replication slots was added in 9.4, too; no slots to worry about.
Since you don’t have access to backend_xmin; you have check the master and all the replicas as you have feedback enabled.
I would look at all non “idle” sessions — i.e. “idle in tran” could be holding on to an old xmin.
select pid
, usename
, client_addr
, client_port
, state
, age(now(), state_change) as state_time
, age(now(), xact_start) as xact_time
from pg_stat_activity
where state != 'idle'
order by xact_time desc
;=
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Vacuum Issues
@ 2020-03-26 20:18 Darron Harrison <darron@realtyserver.com>
parent: Rui DeSousa <rui@crazybean.net>
0 siblings, 1 reply; 16+ messages in thread
From: Darron Harrison @ 2020-03-26 20:18 UTC (permalink / raw)
To: Rui DeSousa <rui@crazybean.net>; +Cc: pgsql-admin <pgsql-admin@lists.postgresql.org>
I am not seeing anything suspicious on the master or slaves.
master:
pid | usename | client_addr | client_port | state | state_time | xact_time
-------+------------------+---------------+-------------+--------+------------------+------------------
17627 | xposure | 64.40.104.231 | 13231 | active | 00:00:02.11561 | 00:00:02.116436
31197 | vancouver_island | 64.40.104.242 | 8174 | active | 00:00:00.067581 | 00:00:00.068289
17616 | xposure | 64.40.104.231 | 13216 | active | 00:00:00.015216 | 00:00:00.015392
17631 | xposure | 64.40.104.231 | 13230 | active | 00:00:00.007903 | 00:00:00.010017
4589 | postgres | | -1 | active | -00:00:00.000002 | 00:00:00
31578 | south_okanagan | 64.40.104.230 | 32926 | active | -00:00:00.00138 | -00:00:00.001307
Slave:
pid | usename | client_addr | client_port | state | state_time | xact_time
-------+------------------+---------------+-------------+--------+------------------+-----------------
187058 | postgres | | -1 | active | -00:00:00.000004 | 00:00:00
Slave:
pid | usename | client_addr | client_port | state | state_time | xact_time
-------+------------------+---------------+-------------+--------+------------------+-----------------
19411 | vancouver_island | 64.40.104.242 | 30274 | active | 00:00:00.08489 | 00:00:00.085521
18180 | pgsql | | -1 | active | -00:00:00.000003 | 00:00:00
Slave:
pid | usename | client_addr | client_port | state | state_time | xact_time
-------+----------+-------------+-------------+--------+------------------+-----------
29524 | postgres | | -1 | active | -00:00:00.000004 | 00:00:00
Darron
---- On Thu, 26 Mar 2020 12:22:57 -0700 Rui DeSousa <rui@crazybean.net> wrote ----
On Mar 26, 2020, at 3:01 PM, Darron Harrison <mailto:darron@realtyserver.com> wrote:
Unable to run the first query and third query. I believe it's a version issue, as we are running 9.2.4.
Looks like backend_xmin was added in 9.4; shoot
Replication slots was added in 9.4, too; no slots to worry about.
Since you don’t have access to backend_xmin; you have check the master and all the replicas as you have feedback enabled.
I would look at all non “idle” sessions — i.e. “idle in tran” could be holding on to an old xmin.
select pid
, usename
, client_addr
, client_port
, state
, age(now(), state_change) as state_time
, age(now(), xact_start) as xact_time
from pg_stat_activity
where state != 'idle'
order by xact_time desc
;
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Vacuum Issues
@ 2020-03-26 20:47 Rui DeSousa <rui@crazybean.net>
parent: Darron Harrison <darron@realtyserver.com>
0 siblings, 1 reply; 16+ messages in thread
From: Rui DeSousa @ 2020-03-26 20:47 UTC (permalink / raw)
To: Darron Harrison <darron@realtyserver.com>; +Cc: pgsql-admin <pgsql-admin@lists.postgresql.org>
> On Mar 26, 2020, at 4:18 PM, Darron Harrison <darron@realtyserver.com> wrote:
>
> I am not seeing anything suspicious on the master or slaves.
I would ask what replication timeout values are but those where added in 9.3 (wal_reciver_timeout and wal_sender_timeout).
Are all the replicas receiving updates and current or are they lagging? Does replication traverse any firewalls?
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Vacuum Issues
@ 2020-03-26 21:40 Darron Harrison <darron@realtyserver.com>
parent: Rui DeSousa <rui@crazybean.net>
0 siblings, 1 reply; 16+ messages in thread
From: Darron Harrison @ 2020-03-26 21:40 UTC (permalink / raw)
To: Rui DeSousa <rui@crazybean.net>; +Cc: pgsql-admin <pgsql-admin@lists.postgresql.org>
There is no current lag on the replicas. Replication does traverse a firewall, but we have made no changes recently.
I will say that one of the hot standbys was only recently attached, and it seems like the issues started when we began sending some longer running queries it's way. We have since placed those queries back on the master, but the vacuum issues remain.
One side effect of whatever is happening, is that nightly backups are taking twice as long as normal.
Darron
---- On Thu, 26 Mar 2020 13:47:21 -0700 Rui DeSousa <rui@crazybean.net> wrote ----
On Mar 26, 2020, at 4:18 PM, Darron Harrison <mailto:darron@realtyserver.com> wrote:
I am not seeing anything suspicious on the master or slaves.
I would ask what replication timeout values are but those where added in 9.3 (wal_reciver_timeout and wal_sender_timeout).
Are all the replicas receiving updates and current or are they lagging? Does replication traverse any firewalls?
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Vacuum Issues
@ 2020-03-26 22:26 Rui DeSousa <rui@crazybean.net>
parent: Darron Harrison <darron@realtyserver.com>
0 siblings, 1 reply; 16+ messages in thread
From: Rui DeSousa @ 2020-03-26 22:26 UTC (permalink / raw)
To: Darron Harrison <darron@realtyserver.com>; +Cc: pgsql-admin <pgsql-admin@lists.postgresql.org>
> On Mar 26, 2020, at 5:40 PM, Darron Harrison <darron@realtyserver.com> wrote:
>
> There is no current lag on the replicas. Replication does traverse a firewall, but we have made no changes recently.
>
> I will say that one of the hot standbys was only recently attached, and it seems like the issues started when we began sending some longer running queries it's way. We have since placed those queries back on the master, but the vacuum issues remain.
>
> One side effect of whatever is happening, is that nightly backups are taking twice as long as normal.
It could sill be a bad/sale replication session. If the firewall drops the replication stream and does not send a reset packets (bad pratice) then the replication session might still be lingering on the Postgres server and holding on to a very old xmin. Do you know if you have TCP/IP Keepalive enabled? I don’t think in 9.2 replication sessions are listed in pg_stat_activity; thus, you’ll have to look for TCP/IP connections to the replics that should not exist.
Check all the upstream servers for stale TCP/IP replication connections; using netstat. I would also look at the system’s process list for walsender processes to see if there more more than there should be; i.e. two of them for single replica.
If you do find one; the best way to terminate it is to drop the TCP/IP connection. i.e. In FreeBSD it would be the command “tcpdrop”; for Linux there are few utilities that do same -- I just don’t recall the name of them.
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Vacuum Issues
@ 2020-03-26 23:24 Darron Harrison <darron@realtyserver.com>
parent: Rui DeSousa <rui@crazybean.net>
0 siblings, 2 replies; 16+ messages in thread
From: Darron Harrison @ 2020-03-26 23:24 UTC (permalink / raw)
To: Rui DeSousa <rui@crazybean.net>; +Cc: pgsql-admin <pgsql-admin@lists.postgresql.org>
I am currently seeing three WAL sender processes on the master, and no stale replication connections on the slaves.
To clarify, are you saying there should be two WAL sender processes for each slave for a total of six?
Darron
---- On Thu, 26 Mar 2020 15:26:01 -0700 Rui DeSousa <rui@crazybean.net> wrote ----
On Mar 26, 2020, at 5:40 PM, Darron Harrison <mailto:darron@realtyserver.com> wrote:
There is no current lag on the replicas. Replication does traverse a firewall, but we have made no changes recently.
I will say that one of the hot standbys was only recently attached, and it seems like the issues started when we began sending some longer running queries it's way. We have since placed those queries back on the master, but the vacuum issues remain.
One side effect of whatever is happening, is that nightly backups are taking twice as long as normal.
It could sill be a bad/sale replication session. If the firewall drops the replication stream and does not send a reset packets (bad pratice) then the replication session might still be lingering on the Postgres server and holding on to a very old xmin. Do you know if you have TCP/IP Keepalive enabled? I don’t think in 9.2 replication sessions are listed in pg_stat_activity; thus, you’ll have to look for TCP/IP connections to the replics that should not exist.
Check all the upstream servers for stale TCP/IP replication connections; using netstat. I would also look at the system’s process list for walsender processes to see if there more more than there should be; i.e. two of them for single replica.
If you do find one; the best way to terminate it is to drop the TCP/IP connection. i.e. In FreeBSD it would be the command “tcpdrop”; for Linux there are few utilities that do same -- I just don’t recall the name of them.
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Vacuum Issues
@ 2020-03-27 00:04 Jerry Sievers <gsievers19@comcast.net>
parent: Darron Harrison <darron@realtyserver.com>
1 sibling, 1 reply; 16+ messages in thread
From: Jerry Sievers @ 2020-03-27 00:04 UTC (permalink / raw)
To: Darron Harrison <darron@realtyserver.com>; +Cc: Rui DeSousa <rui@crazybean.net>; pgsql-admin <pgsql-admin@lists.postgresql.org>
Darron Harrison <darron@realtyserver.com> writes:
> I am currently seeing three WAL sender processes on the master, and
> no stale replication connections on the slaves.
>
> To clarify, are you saying there should be two WAL sender processes
> for each slave for a total of six?
>
Silly question...
Have you verified that autovac is actually running? launcher still
alive, not malconfig'd as to do nothing... etc?
Silly question #2; supposing autovac is trying to do as intended, have
you inspected the logs to insure that it's not erroring out on one or
more tables, catalogs, indexes... etc?
I've reade most of this thread and not seeing any indication if the
problem is confined to just one object or several.
FWIW
> Darron
>
>
> ---- On Thu, 26 Mar 2020 15:26:01 -0700 Rui DeSousa
> <rui@crazybean.net> wrote ----
>
>
>
>
>
> On Mar 26, 2020, at 5:40 PM, Darron Harrison <
> darron@realtyserver.com> wrote:
>
> There is no current lag on the replicas. Replication does
> traverse a firewall, but we have made no changes recently.
>
> I will say that one of the hot standbys was only recently
> attached, and it seems like the issues started when we began
> sending some longer running queries it's way. We have since
> placed those queries back on the master, but the vacuum
> issues remain.
>
> One side effect of whatever is happening, is that nightly
> backups are taking twice as long as normal.
>
>
> It could sill be a bad/sale replication session. If the firewall
> drops the replication stream and does not send a reset packets
> (bad pratice) then the replication session might still be
> lingering on the Postgres server and holding on to a very old
> xmin. Do you know if you have TCP/IP Keepalive enabled? I don’t
> think in 9.2 replication sessions are listed in pg_stat_activity;
> thus, you’ll have to look for TCP/IP connections to the replics
> that should not exist.
>
> Check all the upstream servers for stale TCP/IP replication
> connections; using netstat. I would also look at the system’s
> process list for walsender processes to see if there more more
> than there should be; i.e. two of them for single replica.
>
> If you do find one; the best way to terminate it is to drop the
> TCP/IP connection. i.e. In FreeBSD it would be the command
> “tcpdrop”; for Linux there are few utilities that do same -- I
> just don’t recall the name of them.
>
>
>
>
>
>
>
>
--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consulting@comcast.net
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Vacuum Issues
@ 2020-03-27 01:35 Keith <keith@keithf4.com>
parent: Jerry Sievers <gsievers19@comcast.net>
0 siblings, 0 replies; 16+ messages in thread
From: Keith @ 2020-03-27 01:35 UTC (permalink / raw)
To: Jerry Sievers <gsievers19@comcast.net>; +Cc: Darron Harrison <darron@realtyserver.com>; Rui DeSousa <rui@crazybean.net>; pgsql-admin <pgsql-admin@lists.postgresql.org>
On Thu, Mar 26, 2020 at 8:05 PM Jerry Sievers <gsievers19@comcast.net>
wrote:
> Darron Harrison <darron@realtyserver.com> writes:
>
> > I am currently seeing three WAL sender processes on the master, and
> > no stale replication connections on the slaves.
> >
> > To clarify, are you saying there should be two WAL sender processes
> > for each slave for a total of six?
> >
>
> Silly question...
>
> Have you verified that autovac is actually running? launcher still
> alive, not malconfig'd as to do nothing... etc?
>
> Silly question #2; supposing autovac is trying to do as intended, have
> you inspected the logs to insure that it's not erroring out on one or
> more tables, catalogs, indexes... etc?
>
> I've reade most of this thread and not seeing any indication if the
> problem is confined to just one object or several.
>
> FWIW
>
>
>
>
Also, to clarify, are you seeing actual dead rows not being recycled or
just free space not being recovered? These are two completely different
things. Actual dead tuples will show up for tables in the
pg_stat_all_tables system catalog under the n_dead_tup column. Note also
that this is just an estimate since the last time an analyze was run on
that table, also available from the same system catalog via the
last_analyze or last_autoanalyze columns. I'd recommend running an ANALYZE
on the table(s) in question and checking this catalog again.
For actual data on dead rows or whether this is just free space, you can
use the pgstattuple contrib module:
https://www.postgresql.org/docs/current/pgstattuple.html
For large tables, this can take a while to run because it is gathering the
actual statistics of used space, dead rows and free space, not just the
estimates that analyze does.
If it's actual dead tuples and vacuum is not clearing it up, you are
running an early version of 9.2 which is 20 release behind the latest
(9.2.24). There could very well be a bug if you've exhausted all other
possible reasons for the dead tuples sticking around. If you're not able to
upgrade to a more recent major version, I would highly recommend at least
upgrading to the latest 9.2.
If it's just free space (also called bloat), you will have to perform a
VACUUM FULL to full return the disk space to the operating system. This
will lock the table for the duration and completely rewrite it and all its
indexes. However, once complete, if the table was bloated you should see
your backups return to their normal runtimes.
I've also written another tool for making bloat monitoring easier if you
find this is a frequent problem: https://github.com/keithf4/pg_bloat_check
Keith
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Vacuum Issues
@ 2020-03-27 06:11 Rui DeSousa <rui@crazybean.net>
parent: Darron Harrison <darron@realtyserver.com>
1 sibling, 0 replies; 16+ messages in thread
From: Rui DeSousa @ 2020-03-27 06:11 UTC (permalink / raw)
To: Darron Harrison <darron@realtyserver.com>; +Cc: pgsql-admin <pgsql-admin@lists.postgresql.org>
> On Mar 26, 2020, at 7:24 PM, Darron Harrison <darron@realtyserver.com> wrote:
>
> To clarify, are you saying there should be two WAL sender processes for each slave for a total of six?
Nope, only should see one process for each slave.
^ permalink raw reply [nested|flat] 16+ messages in thread
end of thread, other threads:[~2020-03-27 06:11 UTC | newest]
Thread overview: 16+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2004-03-19 17:46 Vacuum Issues Mark M. Huber <MHuber@VMdirect.com>
2004-03-22 16:39 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-08-21 18:42 Vacuum issues.. Eamonn Kent <ekent@xsigo.com>
2006-08-21 23:20 ` Re: Vacuum issues.. Matthew T. O'Connor <matthew@zeut.net>
2020-03-26 18:10 Vacuum Issues Darron Harrison <darron@realtyserver.com>
2020-03-26 18:50 ` Rui DeSousa <rui@crazybean.net>
2020-03-26 19:01 ` Darron Harrison <darron@realtyserver.com>
2020-03-26 19:22 ` Rui DeSousa <rui@crazybean.net>
2020-03-26 20:18 ` Darron Harrison <darron@realtyserver.com>
2020-03-26 20:47 ` Rui DeSousa <rui@crazybean.net>
2020-03-26 21:40 ` Darron Harrison <darron@realtyserver.com>
2020-03-26 22:26 ` Rui DeSousa <rui@crazybean.net>
2020-03-26 23:24 ` Darron Harrison <darron@realtyserver.com>
2020-03-27 00:04 ` Jerry Sievers <gsievers19@comcast.net>
2020-03-27 01:35 ` Keith <keith@keithf4.com>
2020-03-27 06:11 ` Rui DeSousa <rui@crazybean.net>
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