Hi!
I have a few questions regarding vacuum behavior. But first, some background:
We're running Postgres version 9.1.2 on FreeBSD 8.2 stable.
We did a large data-only single table dump (table was 12TB when we dumped it)
and restored it on a new machine while our database was live in the new
l
Hi all,
I have a few questions related to recovering from a near-miss with
transactionid wraparound.
I'm currently running a vacuum freeze in single user mode on our largest
database (about 36 TB). It's been running for about 10 days (since the
database shut itself down to avoid xid wraparoun
choice? In other words, what is the fastest way to get a
database back online when this occurs? Maybe a plain vacuum would have been
better?
Thanks!
Natalie
On Aug 12, 2013, at 11:15 PM, Tom Lane wrote:
> Natalie Wenz writes:
>> ... With the speed postgres is capable of, and
Hi all,
Background:
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't rea
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 b
left it that way afterward anyway.
On Sep 17, 2013, at 2:02 PM, bricklen wrote:
> 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_
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
On Sep 17, 2013, at 3:46 PM, Kevin Grittner wrote:
> 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 t
