Natalie Wenz wrote:
> I have a large database from our test environment that got into trouble with
> some high volume and some long-running queries about…six weeks ago? We have a
> buffer mechanism that has been storing the new data since the database stopped
> accepting connections, so we haven'
Okay, I guess it makes sense that I am at 16GB based on your explanation below.
I do not have a space constraint, so having 16GB is not the problem. The
problem is that we have experienced connectivity issues in the past where
replication would not startup. I would do a "manual" sync using rsync
Benjamin Krajmalnik wrote:
> During a maintenance window, we upgraded our systems to Postgres
> 9.0.13 from 9.0.3 running on FreeBSD 8.1 amd64.
> When we restarted the postgres server, I notices, and continue to
> notice, a recurrence of messages in the log.
>
> 2013-09-16 21:15:58 MDT LOG: aut
Dear all,
i would set a script timeout from a .net application. My problem regards how to
make sure that time out will be reset at the end of the script such as
SET statement_timeout 1000
SELECT pg_sleep(2);
trowhs exception
After that
SELECT pg_sleep(2);
wouldn't throw exception.
Can yo
On Sep 17, 2013, at 7:43 AM, Kevin Grittner wrote:
> Natalie Wenz wrote:
>
>> I have a large database from our test environment that got into trouble with
>> some high volume and some long-running queries about…six weeks ago? We have a
>> buffer mechanism that has been storing the new data sinc
No… the shared_buffers value is just a legacy value that never got changed
(the shmmax value in sysctl is still 1073741824). When I set up the new
database, I set the shared_buffers to 25% of system memory, so 12GB. (And since
the new database is on 9.3, I didn't have to adjust the sysctl valu
Hi,
I think your suggestion is
SELECT set_config('statement_timeout','1000 s',false); -- enable timeout
--
-- DO SQL Statements here
--
SELECT set_config('statement_timeout','0',false); -- disable timeout
Am I correct? Moreover what can happen if another query runs on the same
connection p
It occurs to me that asking for feedback on the tuning, I am asking about two
separate things:
Was there anything in the tuning below that contributed to the database getting
into trouble? And is there anything I should change in that tuning to make the
single-user vacuum as fast as it can be f
This should work.
SELECT set_config('statement_timeout','1000 s',false);
The set_config function is quite flexible as can accept dynamic values.
More info here
http://www.postgresql.org/docs/current/static/functions-admin.html
I've used successfully to change the script timeout for each statement
Natalie Wenz wrote:
> Sorry; my description of what is going on was a little unclear.
> We didn't upgrade the existing database. We moved it to different
> hardware, and just created a brand new database to accept the
> data that had been backing up in sqlite files while our original
> database w
On Tue, Sep 17, 2013 at 9:48 AM, Natalie Wenz wrote:
> maintenance_work_mem| 10GB
> shared_buffers | 128MB
>
maintenance_work_mem seems pretty high, and shared_buffers seems really
low. Out of curiousity, were those set as a product of internal testing
which determ
11 matches
Mail list logo
