Re: [GENERAL] How to keep pg_largeobject from growing endlessly

> I'm routinely vacuumlo'ing to reap orphan OIDs. Is it necessary to > manually vacuum pg_largobject or is it handled by autovacuum? > It is handled by autovacuum. What we do is, we schedule a manual VACUUM ANALYZE nightly job on bigger tables to avoid burden on the autovacuum during the business

Re: [GENERAL] Where does vacuum FULL write temp-files?

> I'm planning to vacuum FULL a pg_largeobject relation (after vacuumlo'ing > it). The relation is 300GB large so I'm concerned the operation will write > full my pg_xlog directory which is on a 200GB (net) RAID1 SSD. > > Where does vacuum FULL rewrite to, does it use pg_xlog or some other > direct

[GENERAL] How to keep pg_largeobject from growing endlessly

Hi all   I'm routinely vacuumlo'ing to reap orphan OIDs. Is it necessary to manually vacuum pg_largobject or is it handled by autovacuum?   In a system where large objects are constantly added (and *some* rarely deleted, so it grows every day), would I gain space (freed to the OS) by VACUUM FULL

[GENERAL] Where does vacuum FULL write temp-files?

Hi all.   I'm planning to vacuum FULL a pg_largeobject relation (after vacuumlo'ing it). The relation is 300GB large so I'm concerned the operation will write full my pg_xlog directory which is on a 200GB (net) RAID1 SSD.   Where does vacuum FULL rewrite to, does it use pg_xlog or some other dir

Re: [GENERAL] Help with slow table update

On Tue, Apr 14, 2015 at 3:29 PM, Jim Nasby wrote: > On 4/14/15 4:44 PM, Pawel Veselov wrote: > >> On Tue, Apr 14, 2015 at 1:15 PM, Jim Nasby > > wrote: >> >> On 4/14/15 1:28 PM, Pawel Veselov wrote: >> >> >> I wonder if what I need to do, considering t

Re: [GENERAL] Help with slow table update

On 4/14/15 4:44 PM, Pawel Veselov wrote: On Tue, Apr 14, 2015 at 1:15 PM, Jim Nasby mailto:jim.na...@bluetreble.com>> wrote: On 4/14/15 1:28 PM, Pawel Veselov wrote: I wonder if what I need to do, considering that I update a lot of "the same" rows as I process this

Re: [GENERAL] Help with slow table update

On Tue, Apr 14, 2015 at 1:15 PM, Jim Nasby wrote: > On 4/14/15 1:28 PM, Pawel Veselov wrote: > >> >> I wonder if what I need to do, considering that I update a lot of "the >> same" rows as I process this queue, is to create a temp table, update >> the rows there, and then update the actual tables

Re: [GENERAL] Help with slow table update

On 4/14/15 1:28 PM, Pawel Veselov wrote: I wonder if what I need to do, considering that I update a lot of "the same" rows as I process this queue, is to create a temp table, update the rows there, and then update the actual tables once at the end... That's what I'd do. The other option would

[GENERAL] Re: Hot standby problems: consistent state not reached, no connection to master server.

On Tue, 14 Apr 2015 10:34:29 + Sameer Kumar wrote: Problem solved, thanks for attention. > On Tue, 14 Apr 2015 11:59 Ilya Ashchepkov wrote: > > On Mon, 13 Apr 2015 12:24:11 -0700 > Adrian Klaver wrote: > > > On 04/13/2015 11:25 AM, Ilya Ashchepkov wrote: > > > On Mon, 13 Apr 2015 10:06:

[GENERAL] Re: Hot standby problems: consistent state not reached, no connection to master server.

On Tue, 14 Apr 2015 07:08:50 -0700 Adrian Klaver wrote: > On 04/13/2015 01:05 PM, Guillaume Lelarge wrote: > > Le 12 avr. 2015 16:50, "Ilya Ashchepkov" > > a écrit : > > > > > > > restore_command = '/usr/lib/postgresql/9.3/bin/pg_standby -t > > /tmp/pgsql.trigger.5432

[GENERAL] Re: Hot standby problems: consistent state not reached, no connection to master server.

On Mon, 13 Apr 2015 22:05:40 +0200 Guillaume Lelarge wrote: Thank you! > Le 12 avr. 2015 16:50, "Ilya Ashchepkov" a écrit : > > > > Hello. > > > > I'm setting up hot standby slave. > > It recovers from wal archive files, but I can't connect to it: > > $ psql > > psql: FATAL: the database syst

Re: [GENERAL] Help with slow table update

On Mon, Apr 13, 2015 at 7:37 PM, Jim Nasby wrote: > On 4/13/15 7:01 PM, Pawel Veselov wrote: > >> Cursors tend to make things slow. Avoid them if you can. >> >> >> Is there an alternative to iterating over a number of rows, where a >> direct update query is not an option? >> >> I really doubt

Re: [GENERAL] Help with slow table update

On Mon, Apr 13, 2015 at 6:03 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Mon, Apr 13, 2015 at 5:01 PM, Pawel Veselov > wrote: > >> >> r_agrio_hourly - "good", r_agrio_total - "bad". >> >> Update on r_agrio_hourly (cost=0.42..970.32 rows=250 width=329) (actual >> time=2.248..

Re: [GENERAL] Hot standby problems: consistent state not reached, no connection to master server.

On 04/13/2015 01:05 PM, Guillaume Lelarge wrote: Le 12 avr. 2015 16:50, "Ilya Ashchepkov" mailto:koc...@gmail.com>> a écrit : > > restore_command = '/usr/lib/postgresql/9.3/bin/pg_standby -t /tmp/pgsql.trigger.5432 /media/psqlbak/101/wals/main/ %f %p %r' > Don't use pg_standby if you want

Re: [GENERAL] recovery of a windows archive in linux

Adrian, Jim: thanks a lot for your help. I'll replay my logs on a Windows machine very similar to the one that was hosting my db and see how it goes before I make a pg_dump for Linux. 2015-04-13 21:49 GMT-04:00 Adrian Klaver : > On 04/13/2015 04:37 PM, Guillaume Drolet wrote: > >> Dear list, >> >

Re: [GENERAL] Re: Hot standby problems: consistent state not reached, no connection to master server.

On Tue, 14 Apr 2015 11:59 Ilya Ashchepkov wrote: On Mon, 13 Apr 2015 12:24:11 -0700 Adrian Klaver wrote: > On 04/13/2015 11:25 AM, Ilya Ashchepkov wrote: > > On Mon, 13 Apr 2015 10:06:05 -0700 > > Adrian Klaver wrote: > > > >> On 04/13/2015 09:42 AM, Ilya Ashchepkov wrote: > >>> On Sun, 12 Ap