On Mon, Mar 29, 2010 at 4:50 PM, Ramiro Barreca wrote:
> As this is a very heterogeneous platform (from Oracle 10g, SQL Server 2008,
> Firebird 2.1, Mysql 5, Postgre 8.4 up to Informix 5 and even COBOL apps) whe
> are evaluating Virtualization or just sharing a server among PostgreSQL and
> fireb
Hi,
Even though I've enabled statistics collector in our server, it is not
collecting statistics, and because of this autovacuum is also not running as
expected.
PostgreSQL version 8.2
Parameters enabled related to this are:
# - Query/Index Statistics Collector -
#stats_command_str
We recently added a text field to a table, and ended up dropping it and
moving it to a separate related table for performance reasons.
Previously, the toast table size was negligible, but now it is over
250MB.
I have tried performing a vacuum full against the table (this is an
inherited table), b
Hi Everybody,
I'm not a dba. I'm a sysadmin by training. Is there some way to mirror
the disks at the OS level? And then move it to the new machine. Just a though,
I don't know the exact steps. But if you are interested, I can see what I can
find.
-Tino
_
2010/3/30 John Lister
Hi, I have a table which is constantly updated through out the day with no
problems, I'm running Postgresql 8.3.8 in ubuntu karmic. However, within the
last week for some reason overnight it is being emptied and I can't work out
why. I've set log_min_duration_state
On Tue, March 30, 2010 06:09, Greg Smith wrote:
> Michael Gould wrote:
>>
>> I don't know why virtualization is considered a no-no...Since these
>> are all quad core with 32 gig running Windows 2003 64 bit, we can run
>> about 100 users concurrently on each application server before we
>> start to
On Tue, Mar 30, 2010 at 04:16, Mike Williams wrote:
> Thanks Alex, good to know I've not screwed up the kernel somehow.
>
> I've been using 2.6.32 with grsecurity-2.1.14-2.6.32.9-201002231820 applied.
Looks like the first instance I had of this problem was with
2.6.31.1-rc1-grsec. I know I tried
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> What would be the easiest and fastest way to
> migrate Postgres 8.2.24 32 BIT to a new server 64 Bit.
...
> If we cannot use PITR what would be the best approach,
> we can't have down time I am afraid.
>
> Any ideas or suggestions would be v
Renato Oliveira wrote:
Are there any commercial solutions out there for migrating large DBs?
I'm not aware of any. The main way to address this problem by throwing
money at it is to hire someone extremely familiar with PostgreSQL
replication technology and figure out how to customize one
Nilesh Govindarajan skrev 2010-03-29 04.04:
Hi, it seems to be working now. Can somebody explain to me how ? See
this pg_hba.conf -
Did you reload the config, i.e pg_ctl reload, after making changes the
first time?
Regards,
roppert
# "local" is for Unix domain socket connections only
lo
Please don't cc two of the lists here. It makes things difficult for
users who only subscribe to one list or the other who reply--their post
to the other list will be held for moderation. And that's a pain for
the moderators too. In this case, either the pgsql-admin or
pgsql-performance list
On Tue, 2010-03-30 at 16:38 +0200, Tino Schwarze wrote:
> Hi Renato,
>
> dump/restore is the way to go. I suppose, you don't want to compile
> Postgres for 32 bit on the new machine which might work and might allow
> you to do the PITR migration.
>
> And "downtime is not an option" is always a sig
> -Original Message-
> From: Renato Oliveira
> To: pgsql-admin@postgresql.org
> Subject: [ADMIN] Migrate postgres to newer hardware
> Date: Tue, 30 Mar 2010 12:18:36 +0100
>
> Dear All,
>
>
>
> What would be the easiest and fastest way to migrate Postgres 8.2.24 32 BIT
> to a new server 6
Yes, you only have that two possibilities, I think.
PITR is not an option. I tested the same, from 7.4 32bit to 7.4 64bit
and didn't work. Later, when I asked here, I was told why not.
The problem with slony is that you have to manually create tables in
destination database and all database model
On Tue, Mar 30, 2010 at 8:51 AM, Renato Oliveira
wrote:
> If I use postgres 32 bit will it benefit from the extra memory on the system?
Indirectly, yes. No individual PG process will be able to address
more than 4 gbytes of memory. Assuming you have a 64-bit OS living
underneath, however, that
Renato Oliveira writes:
> If I use postgres 32 bit will it benefit from the extra memory on the system?
Yes, although perhaps not as much as you'd get with a 64-bit build.
You still get the ability to have more than 4GB worth of kernel-managed
disk cache, and in many situations that's all the val
2010/3/30 Renato Oliveira :
> If I use postgres 32 bit will it benefit from the extra memory on the system?
>
> I don't think it will.
>
> Thank you very much
>
> Renato
>
Depending on the system, with a 32Bit OS you can only address 2 or 3
GB of continuous memory. 64Bit OS's have not this limitat
We had a similar situation last week, 32-bit to 64-bit OS. We decided to keep
our PostgreSQL 32-bit (our backup/replication servers are still running
32-bit). We are running it on a 64-bit xen image. We used the package manager
to install the 32-bit binaries. Building cross-platform is tricky, s
Are there any commercial solutions out there for migrating large DBs?
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.olive...@grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/
Grant Instruments (Cambridge) Ltd
Company registered in England, regi
If I use postgres 32 bit will it benefit from the extra memory on the system?
I don't think it will.
Thank you very much
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.olive...@grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/
Grant Instruments
Hi Renato,
dump/restore is the way to go. I suppose, you don't want to compile
Postgres for 32 bit on the new machine which might work and might allow
you to do the PITR migration.
And "downtime is not an option" is always a sign of insufficient
planning beforehand. There is no system which doesn
That is very true and well pointed out.
Renato Oliveira
Systems Administrator
e-mail: renato.olive...@grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/
Grant Instruments (Cambridge) Ltd
Company registered in England, registration number 658133
Registered o
On Tue, 2010-03-30 at 16:29 +0200, Iñigo Martinez Lasala wrote:
> Hi Renato.
>
> I would follow the ancient method: perform a pg_dump / pg_restore
This is the easiest approach. The problem is that a lot of people have
contractual SLA's that do not allow them to take their systems down long
enoug
Hi Renato.
I would follow the ancient method: perform a pg_dump / pg_restore
Yes, you will have to take offline database for a long period.
And yes, it would be a great moment to perform a 8.4 upgrade.
Performance is far superior, restore is far faster...
... and yes, it could give you many pro
Hi Brad,
Thank you for your reply, really appreciated.
Do you know how much load slony gives to your servers?
Thank you again
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.olive...@grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/
Grant Ins
On Tue, 2010-03-30 at 12:36 +0100, Renato Oliveira wrote:
>
> Szymon,
>
>
>
> We had Slony running previously, but it lagged behind so badly that
> never managed to catch up.
>
>
>
> Hardware
>
> AMD 1.8GHz 32 Bits
>
> 8GB RAM DDR1
>
> 300GB Disk single volume
>
>
>
> Database:
>
Szymon,
We had Slony running previously, but it lagged behind so badly that never
managed to catch up.
Hardware
AMD 1.8GHz 32 Bits
8GB RAM DDR1
300GB Disk single volume
Database:
Postgres 8.2.24
160GB in size
There are thousands of tables, apparently for each new device a new table is
created.
2010/3/30 Renato Oliveira
>Dear All,
>
> What would be the easiest and fastest way to migrate Postgres 8.2.24 32 BIT
> to a new server 64 Bit.
>
> The existing server runs on 32 bit architecture and has a database as big
> as 160GB.
>
> We initially thought of using PITR, but as one of the PI
Dear All,
What would be the easiest and fastest way to migrate Postgres 8.2.24 32 BIT to
a new server 64 Bit.
The existing server runs on 32 bit architecture and has a database as big as
160GB.
We initially thought of using PITR, but as one of the PITR requirements is both
machines need to be
On Monday 29 March 2010 20:26:08 Alex Hunsaker wrote:
> > Test are para-virt VMs with "regular" kernels, production are real
> > machines with hardened kernels (grsec+pax).
>
> Ive seen this error on a few boxes around here, using a non grsec
> kernel fixes it. I never bothered to report it becaus
hello, John
2010.03.30 10:57, John Lister rašė:
- Is there any other statements that could be causing the rows to be
removed that I've missed
Please see |TRUNCATE.|
- Is there anything that could be deleting them without generating a
log entry for the statement?
Don't think so...
- Is it poss
2010/3/30 John Lister
> Hi, I have a table which is constantly updated through out the day with
> no problems, I'm running Postgresql 8.3.8 in ubuntu karmic. However, within
> the last week for some reason overnight it is being emptied and I can't work
> out why. I've set log_min_duration_statem
Hi, I have a table which is constantly updated through out the day with no
problems, I'm running Postgresql 8.3.8 in ubuntu karmic. However, within the
last week for some reason overnight it is being emptied and I can't work out
why. I've set log_min_duration_statement to 0 so that postgresql du
33 matches
Mail list logo
