On Wed, Apr 30, 2014 at 9:59 AM, Elanchezhiyan Elango
wrote:
> Hi,
>
> I need help on deciding my vacuuming strategy. I need to know if I ever
> need to do 'vacuum full' for my tables.
>
>
Important and critical configuration is "fillfactor". "fillfactor" will
have a greater impact on VACUUMING s
On Thu, Apr 10, 2014 at 12:43 AM, Bala Venkat wrote:
> Hi all -
>
>We are running postgres 9.0 ( 32 bit ) + postgis 1.5.2 on Solaris
> Sparc M5000 with 64GB . Recently we are getting CPU utilitzation to 99% .
>
> In the config file
>
>
> shared_buffers=2GB.
> work_mem = 128MB
> effective
On Mon, Mar 24, 2014 at 10:58 AM, Álvaro Nunes Lemos Melo <
al_nu...@atua.com.br> wrote:
Hi,
>
> Recently, I've been trough a datacenter migration, and in this operation
> I'd also upgraded my PostgreSQL version from 9.2 to 9.3. My new hardware is
> slightly better than the old one, but the Postgr
>
> Yes, we do see statements being canceled from time to time, just not when
> we experience a lag situation with WALs not being applied. Is it just
> entirely possible that there is too much work for one of the slaves to do
> (hence the degraded query throughput we see) that it is unable to apply
On Thu, Mar 20, 2014 at 5:27 AM, Granthana Biswas wrote:
Hello All,
>
> Has anyone ever faced the issue of dead rows not getting removed during
> vacuum even if there are no open transactions/connections?
>
> We have been facing this during every scheduled vacuum which is done after
> closing all
On Thu, Mar 20, 2014 at 8:19 AM, Shaun Duncan wrote:
>
> On Mar 19, 2014 5:08 PM, "Venkata Balaji Nagothi"
> wrote:
> >
> >
> > On Thu, Mar 20, 2014 at 4:12 AM, Shaun Duncan
> wrote:
> >
> >> This is on a production 9.0.15 install with 1 ma
On Thu, Mar 20, 2014 at 4:12 AM, Shaun Duncan wrote:
This is on a production 9.0.15 install with 1 master, 5 hot standby read
> only slaves.
>
> We've been trying to look into a situation where we're seeing that hot
> standby read slaves are receiving WAL segments, but are exceeding
> max_standby_
On Wed, Mar 12, 2014 at 10:03 AM, AI Rumman wrote:
As I have very low wal_keep_segments compare to my wal generation, I am
> collecting archive wal files at slave.
> Now in order to clean up archive wal collection directory at slave, I used
> "archive_cleanup_command".
> I watched that after arch
On Tue, Mar 11, 2014 at 12:04 PM, Anand Kumar, Karthik <
karthik.anandku...@classmates.com> wrote:
> Hi all,
>
> We're running postgres 9.3.2, server configuration below.
>
> Seemingly randomly, we will see the number of active queries in postgres
> go up until we hit max_connections. The DB w
ender process postgres 192.168.122.54(48686) streaming 202/F996C000
>
> Is it the "writer process"? I was sure it was called the background
> writer before.
>
> -Matt
>
>
> On 11/03/14 12:03, Venkata Balaji Nagothi wrote:
>
>
> On Tue, Mar 11, 2014 at 8:30 AM
On Tue, Mar 11, 2014 at 8:30 AM, Matthew Chambers wrote:
> Hi, just wondering if this is normal, DB is operating just fine.
>
> I upped bgwriter_lru_maxpages to 200 and issued a reload. Normally, I'd
> see the bgwriter constantly churning as one of my main I/O using processes,
> but now I have:
>
On Wed, Mar 5, 2014 at 2:14 PM, leo wrote:
>I find a solution to short the recover time by configure parameter
> Synchronous Transfer. Refer to :
> https://wiki.postgresql.org/wiki/Synchronous_Transfer.
>But I don't which postgreSQL will enable this parameter, I install
> 9.3.3-1 on redha
On Tue, Mar 4, 2014 at 9:19 PM, David Janssens wrote:
> Hello,
> I would like to log statements that modify a small subset of tables in a
> databases.
> (not all tables, because the log files become too big in that case and I
> also worry about performance)
> I currently use log_statement='mod' bu
13 matches
Mail list logo
