Re: [ADMIN] Transaction ID wrap limit is log entries

2013-05-21 Thread Armand du Plessis
On Mon, May 20, 2013 at 3:21 PM, Armand du Plessis wrote: > On Mon, May 20, 2013 at 3:11 PM, Tom Lane wrote: > >> Armand du Plessis writes: >> > The autovacuum completed (after many hours) however it didn't seem to >> have >> > frozen any old pages as it just kicks off again right away with the

Re: [ADMIN] Transaction ID wrap limit is log entries

2013-05-21 Thread Armand du Plessis
Just one thing to add, this is not a table that's gone for long periods without a vacuum, it's been autovacuumed regularly and still is without affecting the transaction id. Also double checked for storage parameters on the table that might affect it and nothing there. On Tue, May 21, 2013 at 10:3

Re: [ADMIN] pg_restore

2013-05-21 Thread McKinzie, Alan (Alan)
Does your database restore happen to perform a "Drop owned by" command as part of the restore process? If so, then PostgreSQL Bug #7748 is probably what you are referring to, and this is fixed in the latest patch version of 9.0 (and 9.1 I assume). Alan From: pgsql-admin-ow...@postgresql.org

[ADMIN] Question about maintenance_work_mem and shared_buffer

2013-05-21 Thread Rodrigo Barboza
Hi, everyone. I have a doubt. I have a 32-bit postrgesql running with 2.5gb of shared_buffer. And I have maintenance_work_mem = 1gb and autovacuum_max_workers = 3. How maintenance_work_mem is related to shared_buffer? If the 3 workers uses 1gb, will the database crash? Or their memory usage are sep

Re: [ADMIN] Question about maintenance_work_mem and shared_buffer

2013-05-21 Thread Amit Langote
On Wed, May 22, 2013 at 12:07 AM, Rodrigo Barboza wrote: > Hi, everyone. > I have a doubt. > I have a 32-bit postrgesql running with 2.5gb of shared_buffer. > And I have maintenance_work_mem = 1gb and autovacuum_max_workers = 3. > How maintenance_work_mem is related to shared_buffer? They are ind

Re: [ADMIN] Question about maintenance_work_mem and shared_buffer

2013-05-21 Thread Rodrigo Barboza
On Tue, May 21, 2013 at 1:03 PM, Amit Langote wrote: > On Wed, May 22, 2013 at 12:07 AM, Rodrigo Barboza > wrote: > > Hi, everyone. > > I have a doubt. > > I have a 32-bit postrgesql running with 2.5gb of shared_buffer. > > And I have maintenance_work_mem = 1gb and autovacuum_max_workers = 3. > >

[ADMIN] WAL files not following sequence

2013-05-21 Thread German Becker
Hi all, I have noticed a strange behaviour regarding WAL sequence numbers. I am populating a new DB with old data. To populate the largest part of the data I use wal_level=minimal and archive_mode=off. Then I stop the database and set wal_level=hotstandby and archive_mode=on. After I do that, I no

Re: [ADMIN] pg_restore

2013-05-21 Thread Kasia Tuszynska
Thank you both for your responses, We are not running into the #7748 problem. We are running into the following: Pg_restore seems to be performing the restore in a single transaction so, if one object is dependent on another, than the second object restore will fail b/c the creation of the first

Re: [ADMIN] WAL files not following sequence

2013-05-21 Thread Amit Langote
On Wed, May 22, 2013 at 3:28 AM, German Becker wrote: > Hi all, > > I have noticed a strange behaviour regarding WAL sequence numbers. I am > populating a new DB with old data. To populate the largest part of the data > I use wal_level=minimal and archive_mode=off. Then I stop the database and > s