On Tue, 2010-05-04 at 14:04 -0600, Scott Marlowe wrote:
On Tue, May 4, 2010 at 1:41 PM, Peter Sabaini peter.saba...@ait.ac.at wrote:
On Tue, 2010-05-04 at 11:39 -0400, Tom Lane wrote:
Peter Sabaini peter.saba...@ait.ac.at writes:
it seems Postgres tries to send a UDP packet to a random
Dear all,
I am sorry to have another post.
I have been following a problem which has been growing fast on our system.
At the beginning I thought it was related to load on PG server, then I thought
it was load on the switch/network, now I don't know.
We seem to get loads of Exception errors and
The most likely cause is surely application error: your application is
attempting to insert rows into a table and those new rows have the
primary key set to a value that is already present for that table.
Could be the app isn't checking properly before doing an insert (or
update), could be you are
Ian,
Thank you very much for your reply.
Really appreciated it.
Thank you
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
Hi all
Please assist on this scenario, I am a junior DBA, perhaps the question I have
is too simple please bear with me.
I have a server with one PostgreSQL database and the data reside in
/usr/local/pgsql/data/ running on Redhat 9 O/S.
File system looks as follows:
Filesystem
Khangelani Gama wrote:
/usr/local/pgsql/data/base directory shows the following where
95186722/ takes a lot of space :
51G ./95186722
Now the dump file of the very same database created by using
command : pg_dump -U user -O dbname /tmp/filename is 2.8G big.
The main question I have
On Wed, 2010-05-05 at 13:36 +0200, Khangelani Gama wrote:
The main question I have is: What makes
the /usr/local/pgsql/data/base/95186722/ grow so big while the actual
data with its schema is only 2.8G and that is there a way to reduce
the table space sizes or anything related to that?
Which
Στις Wednesday 05 May 2010 14:45:26 ο/η Kevin Grittner έγραψε:
Khangelani Gama wrote:
/usr/local/pgsql/data/base directory shows the following where
95186722/ takes a lot of space :
51G ./95186722
Now the dump file of the very same database created by using
command : pg_dump -U
On 05 May 13:36, Khangelani Gama wrote:
Hi all
Please assist on this scenario, I am a junior DBA, perhaps the
question I have is too simple please bear with me.
I have a server with one PostgreSQL database and the data reside in
/usr/local/pgsql/data/ running on Redhat 9 O/S.
snippage
Daniel J. Summers daniel.li...@djs-consulting.com writes:
I did an strace -o strace.txt /etc/init.d/postgresql-8.4 start *, but
the only socket that was in it was in the error message. I modified
/usr/share/postgresql-common/init.d-functions to add strace to the
pg_ctlcluster call **, and
Many Thanks for all the replies.
The conversion project to version 8 is still in progress, hence we are still
experiencing problems on a version that's not supported. That's an honest
answer I can give. The thing is it's frustrating to not to have a source of
support as we still have to give
What about vacuumdb -azf -U postgres? (or for each database, VACUUM
FULL)
With that script you only vacuum specific tables, but not entire
databases.
vacuum analyze should also be launched more frequently. Perhaps once a
day, if possible, or sooner.
vacuumdb -az -U postgres (or for each
In your original email I think you showed a directory that held
something like 50Gb of files with a listing of that directory that
added up to something much smaller. If that is right - what else is
in that directory?
Does your monthly vacuum script work?
--
Ian.
On Wed, May 5, 2010 at 2:42
Hi Postgres Guru's,
Is it possible to use the Hot Backup (PITR Backup) of PostgreSQL on an
Operating system to restore the database on other Operating system.
Thanks Regards
Raghu
On 05/05/10 8:57 PM, raghu ram wrote:
Hi Postgres Guru's,
Is
it possible to use the Hot Backup (PITR Backup) of PostgreSQL on an
Operating system to restore the database on other Operating system.
Thanks
Regards
Raghu
Nope, Hot Backup (Online Backup) of
Jason Tan Boon Teck wrote:
I need to move some databases written in Psql v8.4 to the stable
production server running v8.3. I tried pg_dump and pg_restore as well
as PgAdmin3. I am unable to do so due to the backward
incompatibility. Is there anyway to do this?
You can try connecting a 8.3
Why don't you use postgres 8.4 from lenny-backports?
Lenny comes with postgres 8.3, but you can add postgresql 8.4 from
backports without problem. We have our production servers with lenny and
postgresql 8.4. No issues.
Detailed instructions here:
Greg Smith g...@2ndquadrant.com writes:
Jason Tan Boon Teck wrote:
I need to move some databases written in Psql v8.4 to the stable
production server running v8.3. I tried pg_dump and pg_restore as well
as PgAdmin3. I am unable to do so due to the backward
incompatibility. Is there anyway to
I have done that for one server today. But it would be a real pain to
do that for other servers that I do not have convenient access to.
And I sometimes need to install from DVD only without access to the
internet to pull from backports.
Jason
On Thu, May 6, 2010 at 12:09 AM, Iñigo Martinez
I don't think I have used any new v8.4 feature, since I finally had my
first encounter with v8.4 this week.
What should i be looking for in the dump script?
Jason
On Thu, May 6, 2010 at 12:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Smith g...@2ndquadrant.com writes:
Jason Tan Boon Teck
Jason Tan Boon Teck tanboont...@gmail.com writes:
I don't think I have used any new v8.4 feature, since I finally had my
first encounter with v8.4 this week.
What should i be looking for in the dump script?
[ shrug... ] You never explained what failed about your previous
attempt, so it's
Dbname = perak
psql file was pg_dumped from v8.4
Trying to restore in v8.3:
postg...@gem:/mnt/d/0/psql$ pg_restore --disable-triggers -d perak
perak-100403_2330.psql
pg_restore: [archiver] unsupported version (1.11) in file header
Second attempt with -i:
postg...@gem:/mnt/d/0/psql$ pg_restore
I wrote:
Huh. Well, there seems to be no other possible conclusion except that
getaddrinfo() is returning something valid for 127.0.0.1 but not
for localhost. And it's not failing outright for localhost, but
returning a sockaddr that bind() won't actually accept.
For the archives: some
Hi,
I use Debian GNU/Linux on various servers. Debian Stable a.k.a. Lenny
comes with PostgreSQL v8.3 while Debian Testing a.k.a Squeeze provides
PostgreSQL v8.4.
I need to move some databases written in Psql v8.4 to the stable
production server running v8.3. I tried pg_dump and pg_restore as
Hello,
I've got a few questions in regards to the way I'd like to design my
database area. Currently I have 2 projects. These projects contain two
dedicated databases, but their data would be stored in the same NFS server.
What I have as a plan is to run two different instances of pgsql server
25 matches
Mail list logo
