[GENERAL] pgfoundry new?

[Tatsuo Ishii]

Sorry for posting to inappropriate list, but I don't know where to
post about pgfoundry...

Does anybody know why following news does not appear on the pgfoundry
new page?

The latest new was:

PGCluster-1.9.0rc6 released
Atsushi Mitani - 2009-10-28 21:05

and next to above was:

SkyTools 2.1.10
Marko Kreen - 2009-09-01 20:19

So the news below dated 2009-10-04 seems gone.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

投稿者: Tatsuo Ishii
日付: 2009-10-04 10:14
サマリー: pgpool-II 2.2.5 released
Project: pgpool

pgpool Gobal Development Group is pleased to announce the availability of 
pgpool-II 2.2.5, the latest stable version of pgpool-II 2.2 series.

This version fixes various bugs in 2.2.4 or before.

- Fix connection_count_down(). It decrements the connectioncounter too much in 
some corner cases and causes onlinerecover never completes(Tatsuo)

- Detect frontend exiting while waiting for commands complete in other cases 
such as internal locks are issued and Parse(Tatsuo)

- Fix inifinit loop in reset_backend(Xavier Noguer, Tatsuo)

- Fix Parse() to print actual query when it detects kind mismatch error(Tatsuo)

- Document enhancements(Tatsuo)

See NEWS and ChangeLog for more details.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] DB Restart

[Sam Jas]

Hi,

We are facing issue with the RES memory. Below is the o/p of
top command. It shows that writer process reserved 3.8g. We have observed that
if it increased to 3.9g we need to restart the db. Otherwise it hangs.  Kindly 
suggest us the good way to figure it out this issue.   shared_buffer
is 3 GB.   

 

PID   USER  PR 
NI  VIRT   RES 
SHR S %CPU %MEM    TIME+  COMMAND

 4822 postgres  15   0
4045m 3.8g 3.8g S  0.7 12.1  
2:09.63 postgres: writer process

18860 postgres 
15   0 12868 1276  816 R 
0.7  0.0   0:00.43 top

 4825 postgres  15   0
86904 2648  660 S  0.3 
0.0   0:25.32 postgres: stats
collector process

 3992 postgres  15   0
88220 1848 1104 S  0.0  0.0  
0:00.09 sshd: postg...@pts/11

 3993 postgres  15   0
66060 1628 1200 S  0.0  0.0  
0:00.02 -bash
--Thanks 
Sam Jas






  Connect more, do more and share more with Yahoo! India Mail. Learn more. 
http://in.overview.mail.yahoo.com/

Re: [GENERAL] Postgres Clustering Options

[Mikko Partio]

On Wed, Nov 11, 2009 at 7:28 PM, David Kerr  wrote:

> What I plan on doing is:
>
> Postgres installed on a Cluster configured in active/passive (both pointing
> to the same SAN
> (If PG or the OS fails we trigger a failover to the passive node)
>
> Is this a common/reccomended method of handling clusterin with Postgres?
> google searches
> basically point to using a replication based solution, which i don't think
> would meet my
> performance demands.
>
> Does anyone have expereince with this or a similar setup that they could
> share with me?
>


We have done a setup like this with Red Hat Cluster Suite.

We are quite happy with the setup in general, and it has been working well
even in 'unexpected circumstances' (power outages etc). The only thing I'd
change in this setup if I could is the cluster software: RHCS is not mature
enough and it seems every release contains new critical bugs, and sometimes
even mission-critical components such as quorum disk do not work after an
upgrade.

Regards

Mikko

Re: [GENERAL] [pgeu-general] pgday.eu

[Peter Geoghegan]

Yes. The conference could not be faulted. I had a great time. The
venue was perfect. I really love Paris. I want to go back very soon.

Pictures here:

http://mha.smugmug.com/Conferences/PostgreSQL/PGDayEU-2009/10262763_bg6oF#708207723_hjhTg

Regards,
Peter Geoghegan

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] [pgeu-general] pgday.eu

[Raymond O'Donnell]

On 12/11/2009 00:18, Thom Brown wrote:

> I second that.  I wasn't sure quite what to expect, but it was very
> well organised and executed.  And thanks to our French hosts whose
> hard work really paid off too!  The talks were excellent, especially
> Gavin M. Roy's lightning talk ;)  : http://vimeo.com/7561950

Heh heh I was gone by then - glad it's been preserved on video! :-)

Ray.

-- 
Raymond O'Donnell :: Galway :: Ireland
r...@iol.ie

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] [pgeu-general] pgday.eu

[Thom Brown]

2009/11/12 Raymond O'Donnell :
> Hi all,
>
> Congratulations and many thanks indeed to all the organisers of and
> speakers at the conference in Paris. A great couple of days, with really
> interesting talks...and a really enjoyable session in the pub on Friday
> night!
>
> Ray.
>
> --
> Raymond O'Donnell :: Galway :: Ireland
> r...@iol.ie
>

I second that.  I wasn't sure quite what to expect, but it was very
well organised and executed.  And thanks to our French hosts whose
hard work really paid off too!  The talks were excellent, especially
Gavin M. Roy's lightning talk ;)  : http://vimeo.com/7561950

Thom

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] pgday.eu

[Raymond O'Donnell]

Hi all,

Congratulations and many thanks indeed to all the organisers of and
speakers at the conference in Paris. A great couple of days, with really
interesting talks...and a really enjoyable session in the pub on Friday
night!

Ray.

-- 
Raymond O'Donnell :: Galway :: Ireland
r...@iol.ie

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Incremental Backups in postgres

[Greg Smith]

akp geek wrote:

Got it almost. Thanks a lot. One final question, please bear with me.

1.  select pg_start_backup('label')  ==> 10 AM
2.  PGDATA folder backup ==> 10:05 AM
3. select pg_stop_backup => 10.10AM
4. The archiving will start writing files
  
You've got step (4) in the wrong place.  The archiver will generate 
files you are compelled to save as soon as you issue pg_start_backup in 
(1).  That's how you're able to recover from a failure at any time after 
that.  When you issue pg_stop_backup, it will tell you what files it 
expects to be copied over to the slave system in order to recovery from 
a failure, and that list will go back to when you started the backup.  
Saving those is actually part of the base backup process, as documented 
in the manual if you read that section more carefully.


--
Greg Smith2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
g...@2ndquadrant.com  www.2ndQuadrant.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Incremental Backups in postgres

[akp geek]

Got it almost. Thanks a lot. One final question, please bear with me.

1.  select pg_start_backup('label')  ==> 10 AM
2.  PGDATA folder backup ==> 10:05 AM
3. select pg_stop_backup => 10.10AM
4. The archiving will start writing files
5. If the disc crashes at 11AM,  what will happen to the data between
10:10AM and 11:00AM, since we issued a pg_stop_backup at 10:10AM

Appreciate your help

Regards


On Wed, Nov 11, 2009 at 2:58 PM, Scott Mead
 wrote:
>
> On Wed, Nov 11, 2009 at 12:51 PM, akp geek  wrote:
>>
>> Hi All -
>>                   I have read the document got a reasonable
>> understanding of the WAL process. I have some confusion regarding the
>> process.
>>
>> 1. I have set up the archiving process. Now the archive file are going
>> to a different mount point.
>> 2. I set up job to create a back up of the PGDATA directory
>
> Before you backup PGDATA, you either need to stop the database or use
> pg_start_backup('label');
> After your backup, you would need to run: pg_stop_backup();
>
>
>>
>> Are the 2 above steps enough for recovery. My confusion is why we need
>> to have  Making a Base Backup. When you have time can you please
>> clarify?
>
>   Remember, an 'incremental' backup is an increment to an original full
> backup.  That's why you need to make a backup of the PGDATA.
> --Scott
>

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] upgrade to 8.4 with new character set

[Martijn van Oosterhout]

On Wed, Nov 11, 2009 at 10:45:55AM -0500, Kevin Duffy wrote:
> We originally built our database with a character set of SQL_ASCII.  We
> now know the error of our foolish ways.  We are trying to upgrade to 8.4
> and the windows binaries would like us to use UTF8.  I would like to use
> a backup to restore onto the new installation, however I am getting
> warnings and errors about how I am trying to restore a SQL_ASCII
> character set to a UTF8 Database.  I need to have confidence that my
> data is intact before I can continue with the upgrade.  I was wondering
> what would be the best course of action.  I currently have the 8.4
> database installed on a separate machine for testing.  

Do you know what character you were using before. If, for example, you
know that all the data is actually in latin1 or win1252, then you can
just change the client_encoding in the dump file and reload it into
your utf-8 database.

Hope this helps,
-- 
Martijn van Oosterhout  http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while 
> boarding. Thank you for flying nlogn airlines.


signature.asc
Description: Digital signature

Re: [GENERAL] Editor for sgml files

[Peter Eisentraut]

On ons, 2009-11-11 at 08:32 -0500, Bill Moran wrote:
> In response to Peter Eisentraut :
> 
> > * The Elements of Style
> 
> Hope this doesn't start a flame war, but:
> http://chronicle.com/article/50-Years-of-Stupid-Grammar/25497

Yeah, you need to be prepared to reject about 30% of the advice and
guidelines in each of the sources I mentioned.

However, some of the prescriptionism in these various style guides that
a writer or journalist might ordinarily complain about is actually a
good idea for open-source documentation writing, because it enforces
consistency.  For similar reasons we have commenting and indentation and
portability conventions, even though purists might complain about "35
years of stupid C code". ;-)


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Incremental Backups in postgres

[Scott Mead]

On Wed, Nov 11, 2009 at 12:51 PM, akp geek  wrote:

> Hi All -
>   I have read the document got a reasonable
> understanding of the WAL process. I have some confusion regarding the
> process.
>
> 1. I have set up the archiving process. Now the archive file are going
> to a different mount point.
> 2. I set up job to create a back up of the PGDATA directory
>

Before you backup PGDATA, you either need to stop the database or use
pg_start_backup('label');

After your backup, you would need to run: pg_stop_backup();




>
> Are the 2 above steps enough for recovery. My confusion is why we need
> to have  Making a Base Backup. When you have time can you please
> clarify?
>

  Remember, an 'incremental' backup is an increment to an original full
backup.  That's why you need to make a backup of the PGDATA.

--Scott

Re: [GENERAL] Postgres Clustering Options

[John R Pierce]

Greg Smith wrote:
It sounds like you've got the basics nailed down here and are on a 
well trod path, just one not one documented publicly very well.  Since 
you said that even DRBD was too much overhead for you, I think a dive 
into evaluating the commercial clustering approaches (or the free 
LinuxHA that RedHat's is based on, which I haven't been real impressed 
by) would be appropriate.  The hard part is generally getting a 
heartbeat between the two servers sharing the SAN that is both 
sensitive enough to catch failures while not being so paranoid that it 
fails over needlessly (say, when load spikes on the primary and it 
slows down).  Make sure you test that part out very carefully with any 
vendor you evaluate.


hence the 'multiple dedicated heartbeat networks' previously suggested.

a typical cluster server has a quad ethernet, 2 ports (802.3ad link 
aggregation w/ failover) for the LAN, and 2 dedicated for the heartbeat, 
then a dual HBA for the SAN.the heartbeats can run over crossover 
cables, even 10baseT is plenty as the traffic volume is quite low, it 
just needs low latency and no possibility of congestion.


I setup the RHCS aka CentOS Cluster in a test lab environment...  it 
seemed to work well enough.   I was using FC storage via a QLogic SANbox 
5600 switch, which was supported by RHCS as a fencing device...  

Note that ALL of the storage used by the cluster servers on the SAN 
should be under cluster management as the 'standby' server won't see any 
of it when its fenced (I implemented fencing via FC port disable).   
This is can be an issue when you want to do rolling upgrades (update the 
standby server, force a failover, update the previous master).   I 
built each cluster node with its own direct attached mirrored storage 
for the OS and software.



As far as the PostgreSQL specifics go, you need a solid way to ensure 
you've disconnected the now defunct master from the SAN (the classic 
"shoot the other node in the head" problem).  All you *should* have to 
do is start the database again on the backup after doing that.  That 
will come up as a standard crash, run through WAL replay crash 
recovery, and the result should be no different than had you restarted 
after a crash on the original node.  The thing you cannot let happen 
is allowing the original master to continue writing to the shared SAN 
volume once that transition has happened.




which is what 'storage fencing' prevents.



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres Clustering Options

[David Kerr]

On Wed, Nov 11, 2009 at 01:35:58PM -0500, Greg Smith wrote:
- David Kerr wrote:
- >The apps actually aren't as robust as the DB in this case, so i'll have 
- >time to
- >replay all of the logs that made it before "the big one" while those are 
- >being
- >configured to come up. and if it does take longer that's not a huge issue
- >i'll have a few hours to get 100% caught up.
- >  
- It sounds like you've got the basics nailed down here and are on a well 
- trod path, just one not one documented publicly very well.  Since you 
- said that even DRBD was too much overhead for you, I think a dive into 
- evaluating the commercial clustering approaches (or the free LinuxHA 
- that RedHat's is based on, which I haven't been real impressed by) would 
- be appropriate.  The hard part is generally getting a heartbeat between 
- the two servers sharing the SAN that is both sensitive enough to catch 
- failures while not being so paranoid that it fails over needlessly (say, 
- when load spikes on the primary and it slows down).  Make sure you test 
- that part out very carefully with any vendor you evaluate. 
- 
- As far as the PostgreSQL specifics go, you need a solid way to ensure 
- you've disconnected the now defunct master from the SAN (the classic 
- "shoot the other node in the head" problem).  All you *should* have to 
- do is start the database again on the backup after doing that.  That 
- will come up as a standard crash, run through WAL replay crash recovery, 
- and the result should be no different than had you restarted after a 
- crash on the original node.  The thing you cannot let happen is allowing 
- the original master to continue writing to the shared SAN volume once 
- that transition has happened.

Thanks Greg that sounds good! and puts my (and my management's) concerns at 
ease!

Dave

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres Clustering Options

[Greg Smith]

David Kerr wrote:

The apps actually aren't as robust as the DB in this case, so i'll have time to
replay all of the logs that made it before "the big one" while those are being
configured to come up. and if it does take longer that's not a huge issue
i'll have a few hours to get 100% caught up.
  
It sounds like you've got the basics nailed down here and are on a well 
trod path, just one not one documented publicly very well.  Since you 
said that even DRBD was too much overhead for you, I think a dive into 
evaluating the commercial clustering approaches (or the free LinuxHA 
that RedHat's is based on, which I haven't been real impressed by) would 
be appropriate.  The hard part is generally getting a heartbeat between 
the two servers sharing the SAN that is both sensitive enough to catch 
failures while not being so paranoid that it fails over needlessly (say, 
when load spikes on the primary and it slows down).  Make sure you test 
that part out very carefully with any vendor you evaluate. 

As far as the PostgreSQL specifics go, you need a solid way to ensure 
you've disconnected the now defunct master from the SAN (the classic 
"shoot the other node in the head" problem).  All you *should* have to 
do is start the database again on the backup after doing that.  That 
will come up as a standard crash, run through WAL replay crash recovery, 
and the result should be no different than had you restarted after a 
crash on the original node.  The thing you cannot let happen is allowing 
the original master to continue writing to the shared SAN volume once 
that transition has happened.


--
Greg Smith2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
g...@2ndquadrant.com  www.2ndQuadrant.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres Clustering Options

[David Kerr]

On Wed, Nov 11, 2009 at 09:35:35AM -0800, Ben Chobot wrote:
- What are you trying to protect against? Software failure? Hardware 
- failure? Both?
- 
- Depending on your budget, you could theoretically point any number of 
- failover nodes at a san, so long as you make sure only one of them is 
- running postgres at a time. Of course, you still have the single point 
- of failure in the SAN. If you aren't made of money and are running 
- linux, we've found DRBD is a great way to cluster two machines and it 
- avoids a few single points of failure. But you limit yourself to two or 
- three cluster nodes.

Protecting against both hardware and software failure.

SAN failure would be handled by the offsite node, but we've got a pretty robust
SAN, (I don't have all of the details) so it may even not have a single point
of failure.

We tried out DRBD and the performance impact was pretty sigificant. our 
app is very sensitive to any performance hitch so I just can't see any
form of replication working for us.

Dave

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres Clustering Options

[David Kerr]

On Wed, Nov 11, 2009 at 01:11:52PM -0500, Greg Smith wrote:
- David Kerr wrote:
- >Postgres installed on a Cluster configured in active/passive (both 
- >pointing to the same SAN
- >(If PG or the OS fails we trigger a failover to the passive node)
- >Log shipping between that cluster and a single PG Instance off site.
- >Is this a common/reccomended method of handling clusterin with Postgres? 
- >google searches
- >basically point to using a replication based solution, which i don't think 
- >would meet my performance demands.
- >  
- The part I'm having trouble with here is how it is you expect to keep a 
- remote node up to date with log-shipping, but then reject log-shipping 
- based replication as not high enough performance for you?  The classic 
- problem with log-shipping in PostgreSQL is that you've got a single 
- recovery process trying to replay the work of what many workers did on 
- the master, and that can turn into a potential lag problem as volume 
- spikes upwards.  If you don't expect a standby is going to be able to 
- keep up with your volume due to that issue, the remote one is going to 
- be even worse though.

We'd fail over to the standby db (recipient of the log shipping) in the case 
that our hosting center was nuked. those are considered "extreme" circumstances
and we have a higher RTO/RPO in those cases.

The apps actually aren't as robust as the DB in this case, so i'll have time to
replay all of the logs that made it before "the big one" while those are being
configured to come up. and if it does take longer that's not a huge issue
i'll have a few hours to get 100% caught up.

Dave

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres Clustering Options

[David Kerr]

On Wed, Nov 11, 2009 at 09:40:21AM -0800, John R Pierce wrote:
- David Kerr wrote:
- >Does anyone have expereince with this or a similar setup that they could 
- >share with me?
- >  
- 
- thats your classic database cluster.the reason you don't see 
- much of that in online writeups is that the high availability SAN 
- hardware is expensive
- 
- presumably you'd manage this with classic cluster managemetn software 
- (veritas cluster, sun cluster, redhat cluster, heartbeat, or whatever is 
- appropriate to your environment. commercial cluster vendors 
- generally recommend doing the cluster 'heartbeat' over at least two 
- seperate network links so that a network failure doesn't trigger a false 
- failover. implementing 'fencing' in your storage switch is also a 
- very good idea, most fencing systems can send commands to common 
- fiberchannel switches to disable the access port or soft zone of the 
- current standby server so ti can't accidentally mount the storage.
- 
- your applications should be tolerant of database server disconnects, and 
- know how to reconnect and restart the transaction that was in progress.

I'll look into Fencing this is the first i've heard of that. But everything
else you mentioned is exactly how I planned on doing it. so that's good
news =)

Thanks!

Dave

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres Clustering Options

[Greg Smith]

David Kerr wrote:

Postgres installed on a Cluster configured in active/passive (both pointing to 
the same SAN
(If PG or the OS fails we trigger a failover to the passive node)
Log shipping between that cluster and a single PG Instance off site.
Is this a common/reccomended method of handling clusterin with Postgres? google 
searches
basically point to using a replication based solution, which i don't think would meet my 
performance demands.
  
The part I'm having trouble with here is how it is you expect to keep a 
remote node up to date with log-shipping, but then reject log-shipping 
based replication as not high enough performance for you?  The classic 
problem with log-shipping in PostgreSQL is that you've got a single 
recovery process trying to replay the work of what many workers did on 
the master, and that can turn into a potential lag problem as volume 
spikes upwards.  If you don't expect a standby is going to be able to 
keep up with your volume due to that issue, the remote one is going to 
be even worse though.


--
Greg Smithg...@2ndquadrant.comBaltimore, MD


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres Clustering Options

[Greg Smith]

John R Pierce wrote:
presumably you'd manage this with classic cluster managemetn software 
(veritas cluster, sun cluster, redhat cluster, heartbeat, or whatever 
is appropriate to your environment.
I've seen or heard of successful implementations like this done with 
Veritas, Sun, RedHat, and Linux HA.  This topic is actually addressed 
briefly at both http://www.postgresql.org/about/press/faq and 
http://www.enterprisedb.com/products/allfaq.do ; Sun even mentions 
PostgreSQL support as a specific strength of their product at 
http://blogs.sun.com/SC/entry/migrating_from_veritas_cluster_server


I think you don't hear about this much here because the sort of 
companies who have the cash for this style of deployment are hiring 
commercial vendors and private consultants under NDA rather than relying 
on the PostgreSQL community.  That's why I can't say more about the one 
project like this I did, that featured a shared SAN and commercial 
cluster software.


--
Greg Smithg...@2ndquadrant.comBaltimore, MD


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Incremental Backups in postgres

[akp geek]

Hi All -
                  I have read the document got a reasonable
understanding of the WAL process. I have some confusion regarding the
process.

1. I have set up the archiving process. Now the archive file are going
to a different mount point.
2. I set up job to create a back up of the PGDATA directory

Are the 2 above steps enough for recovery. My confusion is why we need
to have  Making a Base Backup. When you have time can you please
clarify?


Regards

On Tue, Nov 10, 2009 at 4:56 PM, Alan Hodgson  wrote:
>
> On Tuesday 10 November 2009, akp geek  wrote:
> > So Is it always good to have the backup using PG_dump instead of PITR or
> > a combination of both
> >
>
> I like to do both. Ongoing PITR, daily base backups (by updating an rsync
> copy), and weekly pg_dumps that in turn go to tape.
>
> PITR gives a very recent restore point in the event of server loss. As
> previously mentioned, the full (custom) backups let you restore individual
> tables. They're also a lot smaller than base backups + WAL logs.
>
> --
> "No animals were harmed in the recording of this episode. We tried but that
> damn monkey was just too fast."
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres Clustering Options

[John R Pierce]

Ben Chobot wrote:

Of course, you still have the single point of failure in the SAN.


a proper SAN has two switches, each host connected to it has two HBA 
interfaces, there are two redundant storage controllers with mirrored 
cache, dual paths from each controller to all the storage, and redundant 
power supplies throughout.   there is no single point of failure 
there.of course, none of this is cheap.




--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres Clustering Options

[John R Pierce]

David Kerr wrote:

I'm trying to meet a very high uptime requirement in a high performance 
environment.

to do this we will need to have some form of cluster for our databases

What I plan on doing is:

Postgres installed on a Cluster configured in active/passive (both pointing to 
the same SAN
(If PG or the OS fails we trigger a failover to the passive node)

Log shipping between that cluster and a single PG Instance off site.


Is this a common/reccomended method of handling clusterin with Postgres? google 
searches
basically point to using a replication based solution, which i don't think would meet my 
performance demands.


Does anyone have expereince with this or a similar setup that they could share 
with me?
  


thats your classic database cluster.the reason you don't see 
much of that in online writeups is that the high availability SAN 
hardware is expensive


presumably you'd manage this with classic cluster managemetn software 
(veritas cluster, sun cluster, redhat cluster, heartbeat, or whatever is 
appropriate to your environment. commercial cluster vendors 
generally recommend doing the cluster 'heartbeat' over at least two 
seperate network links so that a network failure doesn't trigger a false 
failover. implementing 'fencing' in your storage switch is also a 
very good idea, most fencing systems can send commands to common 
fiberchannel switches to disable the access port or soft zone of the 
current standby server so ti can't accidentally mount the storage.


your applications should be tolerant of database server disconnects, and 
know how to reconnect and restart the transaction that was in progress.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres Clustering Options

[Ben Chobot]

What are you trying to protect against? Software failure? Hardware 
failure? Both?


Depending on your budget, you could theoretically point any number of 
failover nodes at a san, so long as you make sure only one of them is 
running postgres at a time. Of course, you still have the single point 
of failure in the SAN. If you aren't made of money and are running 
linux, we've found DRBD is a great way to cluster two machines and it 
avoids a few single points of failure. But you limit yourself to two or 
three cluster nodes.


What are you trying to achieve with your offsite node? Is it supposed to 
pick up the load if the cluster dies?


David Kerr wrote:

I'm trying to meet a very high uptime requirement in a high performance 
environment.

to do this we will need to have some form of cluster for our databases

What I plan on doing is:

Postgres installed on a Cluster configured in active/passive (both pointing to 
the same SAN
(If PG or the OS fails we trigger a failover to the passive node)

Log shipping between that cluster and a single PG Instance off site.


Is this a common/reccomended method of handling clusterin with Postgres? google 
searches
basically point to using a replication based solution, which i don't think would meet my 
performance demands.


Does anyone have expereince with this or a similar setup that they could share 
with me?

Thanks

Dave

  


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Postgres Clustering Options

[David Kerr]

I'm trying to meet a very high uptime requirement in a high performance 
environment.

to do this we will need to have some form of cluster for our databases

What I plan on doing is:

Postgres installed on a Cluster configured in active/passive (both pointing to 
the same SAN
(If PG or the OS fails we trigger a failover to the passive node)

Log shipping between that cluster and a single PG Instance off site.


Is this a common/reccomended method of handling clusterin with Postgres? google 
searches
basically point to using a replication based solution, which i don't think 
would meet my 
performance demands.

Does anyone have expereince with this or a similar setup that they could share 
with me?

Thanks

Dave

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Will PostgreSQL 8.4 allow having different encoding databases on a same PostgreSQL server ?

[informatica]

Bruno Baguette-3 wrote:
> 
> Hello !
> 
> Currently, I have several PostgreSQL databases, some of them are using 
> LATIN1 encoding, some of them are using UTF-8 encoding.
> 
> In order to have theses two encoding, we had to install two PostgreSQL 
> server on two different ports. One is for LATIN1 databases and one is 
> for UTF-8 databases. (I known there is a workaround which allows to mix 
> several databases encoding them on a same PostgreSQL server, by 
> specifying "C" locale to initdb).
> 
> I've heard some rumors on freenode stating that PostgreSQL 8.4. will 
> allow to have several databases encoding. Did I understand right ?
> 
> Thanks in advance for any informations about that feature !
> 
> Regards,
> 
> -- 
> Bruno Baguette - bruno.bague...@gmail.com
> 
> -- 
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
> 
> 

1 ACTUALIZAR LOS PAQUETES DEL SISTEMA OPERATIVO
apt-get  update
apt-get  upgrade
apt-get  dist-upgrade
CONFIGURACIÓN DEL IDIOMA EN EL SERVER
1.INSTALAR  EL SIGUIENTE PAQUETE

aptitude install utillinux-locale
locale-gen es_CO
aptitude search language | grep sp
aptitude install language-pack-eo-base
locale-gen es
dpkg-reconfigure locales
2.Ediatar la línea /etc/default/locale  la cual debe decir lo
siguiente en la primera linea

LANG="es_CO.ISO-8859-1"


Editar la línea /etc/enviroment la cual debe decir lo siguiente despues de
la segunda linea

LANGUAGE="es_CO:es_ES:es:en_US:en"
LANG="es_CO.ISO-8859-1"
LC_CTYPE="es_CO.ISO-8859-1"
LC_MESSAGES="es_CO.ISO-8859-1"
LC_COLLATE="es_CO.ISO-8859-1"
LC_ALL="es_CO.ISO-8859-1"


ejecutar el comando “dpkg-reconfigure locales”

3. reinice el servidor

4. instale nuevamente postgres para que coja el idioma y la codificación
configurada, si no desintala  y vuelve a instalar postgres los cambios de
codificación no surgen efecto


+ PARA DESINSTALAR POSTGRES

1. miramos que paquete estan instalados con el comando:

aptitude search postgres | grep 8.4

2 desinatalamos con el comando 
 aptitude purge postgresql-8.4
 aptitude purge postgresql-contrib-8.4

++INSTALACION DE POSTGRES++

1. miarqmos que paquete estan disponibles para esta versión de postgres con
el sig comando.

aptitude search postgres | grep 8.4

debe mostrar  algo asi como esto:

p   postgresql-8.4  - object-relational SQL database,
version 8.
p   postgresql-client-8.4   - front-end programs for PostgreSQL 8.4
p   postgresql-contrib-8.4  - additional facilities for PostgreSQL
p   postgresql-doc-8.4  - documentation for the PostgreSQL
database
p   postgresql-plperl-8.4   - PL/Perl procedural language for
PostgreSQL
p   postgresql-plpython-8.4 - PL/Python procedural language for
PostgreS
p   postgresql-pltcl-8.4- PL/Tcl procedural language for
PostgreSQL
p   postgresql-server-dev-8.4   - development files for PostgreSQL 8.4
serve


2 instalamos los siguientes paquetes con el comando:

aptitude install postgresql-8.4
aptitude install postgresql-contrib-8.4
aptitude install postgresql-server-dev-8.4
aptitude install postgresql-doc-8.4


cuando cree la base de datos esta se crea automáticamente con codificación
LATIN1 la cual es compatible con la bd de capigono.

Siga este manual paso a  paso el cual está comprobado que funciona.

COPYRIGHT @ ING. WILLDIMAN MIRA HERNANDEZ



-- 
View this message in context: 
http://old.nabble.com/Will-PostgreSQL-8.4-allow-having-different-encoding-databases-on-a-same-PostgreSQL-server---tp22969538p26304056.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] upgrade to 8.4 with new character set

[Kevin Duffy]

 

 



From: Jonathan Schindler 
Sent: Wednesday, November 11, 2009 9:58 AM
To: Kevin Duffy
Subject: upgrade to 8.4 with new character set

 

To those that know,

 

We originally built our database with a character set of SQL_ASCII.  We
now know the error of our foolish ways.  We are trying to upgrade to 8.4
and the windows binaries would like us to use UTF8.  I would like to use
a backup to restore onto the new installation, however I am getting
warnings and errors about how I am trying to restore a SQL_ASCII
character set to a UTF8 Database.  I need to have confidence that my
data is intact before I can continue with the upgrade.  I was wondering
what would be the best course of action.  I currently have the 8.4
database installed on a separate machine for testing.  

 

Thank you for all your help

 

Jonathan Schindler

 

 

Re: [GENERAL] PostgreSQL 8.3.8 on AIX5.3 : compilation failed

[Tom Lane]

"Albe Laurenz"  writes:
> Alexandra Roy wrote:
>> Why the "-disable-largefile" option is necessary to do a 
>> PostgreSQL 8.3.8 32-build ? 

> The problem will be fixed in the upcoming 8.5 release.

... and the next minor releases, eg 8.3.9.

regards, tom lane

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] PostgreSQL 8.3.8 on AIX5.3 : compilation failed

[Alvaro Herrera]

Albe Laurenz wrote:
> Alexandra Roy wrote:
> > Without the "-disable-largefile" option, the compilation is 
> > still failing with this error:
> > 
> > 
> > In file included from psqlscan.c:2385: 
> >/usr/include/unistd.h:171: error: conflicting types for 'lseek64' 
> >/usr/include/unistd.h:169: error: previous declaration of 'lseek64' 
> >was here 
> >In file included from /usr/include/unistd.h:744, 
> > from psqlscan.c:2385: 
> [...]
> > 
> > 
> > Does someone have an idea about this ? 
> > Why the "-disable-largefile" option is necessary to do a 
> > PostgreSQL 8.3.8 32-build ? 
> > Why the "OBJECT_MODE" exported to 32 is not sufficient ? 
> 
> The problem will be fixed in the upcoming 8.5 release.
> 
> If you need a 32-bit build of 8.3.8 on AIX, you can (after
> you got the error message) edit src/bin/psql/psqlscan.c and add
> #include "postgres.h"
> as first line.

Actually it's in the 8.3 CVS branch too.  A 8.3 snapshot should work
fine.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Editor for sgml files

[Bill Moran]

In response to Peter Eisentraut :

> * The Elements of Style

Hope this doesn't start a flame war, but:
http://chronicle.com/article/50-Years-of-Stupid-Grammar/25497

-- 
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Editor for sgml files

[Peter Eisentraut]

On tis, 2009-11-10 at 14:10 -0800, Richard Broersma wrote:
> On Tue, Nov 10, 2009 at 2:04 PM, Peter Eisentraut  wrote:
> 
> > Well, a lot of hard work. ;-)  Just like there are coding standards and
> > best practices, there are standards and customs in writing and
> > publishing.
> 
> Are these published anywhere?

Um, well, that's like asking, how can I write good programs. ;-)

Off the top of my head, some sources I have found useful over the years:

* FreeBSD Documentation Project 

* GNU Coding Standards, section Documentation


* man-pages(7), which I adapted into our own style guide:
http://developer.postgresql.org/pgdocs/postgres/docguide-style.html

* The Elements of Style

* The Chicago Manual of Style

* Various publishers I have worked with over the years have the own
style guidelines.

Also, just like open-source projects adopt certain practices that make
the code more suitable for collaborative development, similar practices
can be found for collaborative documentation writing, e.g., version
control, frequent rebuilds and tests, consistent interfaces, robust
tools, etc.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] PostgreSQL 8.3.8 on AIX5.3 : compilation failed

[Albe Laurenz]

Alexandra Roy wrote:
> Without the "-disable-largefile" option, the compilation is 
> still failing with this error:
> 
> 
>   In file included from psqlscan.c:2385: 
>  /usr/include/unistd.h:171: error: conflicting types for 'lseek64' 
>  /usr/include/unistd.h:169: error: previous declaration of 'lseek64' 
>  was here 
>  In file included from /usr/include/unistd.h:744, 
>   from psqlscan.c:2385: 
[...]
>   
> 
> Does someone have an idea about this ? 
> Why the "-disable-largefile" option is necessary to do a 
> PostgreSQL 8.3.8 32-build ? 
> Why the "OBJECT_MODE" exported to 32 is not sufficient ? 

The problem will be fixed in the upcoming 8.5 release.

If you need a 32-bit build of 8.3.8 on AIX, you can (after
you got the error message) edit src/bin/psql/psqlscan.c and add
#include "postgres.h"
as first line.

Then try again, and it should work.

Yours,
Laurenz Albe

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] [GENERAL] PostgreSQL 8.3.8 on AIX5.3 : compilation failed

[Albe Laurenz]

Tom Lane wrote:
>> The problem is that both _LARGE_FILES and _LARGE_FILE_API are #defined
>> in this case, which makes #include  fail.
>> Does anyone have an idea how to best fix this problem in the
>> source tree? I'm willing to implement and test.
> 
> I've committed changes for this in CVS, please verify it fixes your
> problem.

Problem fixed.
Thanks for the quick work!

Yours,
Laurenz Albe

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] -c argument not recognized

[Antonio Ruggiero]

On Nov 10, 4:56 pm, thombr...@gmail.com (Thom Brown) wrote:
> 2009/11/10 Antonio Ruggiero :
>
>
>
>
>
> > I am running PostgresSQL 8.3.8 on windows XP-64Bit.  I am using psql
> > client from the PostgreSQL installation and not the Cygwin client.
>
> > My issue is that the command line argument "-c command" is not
> > recognized. For example, if I run (from Cygwin)
>
> > psql -h localhost -p 5432 -d $database postgres -c "select count(*)
> > from  $table_name"
>
> > I receive the following output:
>
> > psql: warning: extra command-line argument "-c" ignored
> > psql: warning: extra command-line argument "select count(*) from
> > $table_name" ignored
> > Welcome to psql 8.3.8, the PostgreSQL interactive terminal.
>
> > Type:  \copyright for distribution terms
> >       \h for help with SQL commands
> >       \? for help with psql commands
> >       \g or terminate with semicolon to execute query
> >       \q to quit
>
> > Warning: Console code page (437) differs from Windows code page (1252)
> >         8-bit characters might not work correctly. See psql reference
> >         page "Notes for Windows users" for details.
>
> > End output.
>
> > If I put the query in a file and run the file from the command line,
> > then it works fine.  Furthermore, it appears I have all the necessary
> > priviledges since I can create/delete/modify tables in the database -
> > as long as the sql code is in a script file.
>
> > I will add that this code runs on an XP-32Bit 8.2 install and I
> > recently installed PostgreSQL on the XP-64Bit machine.
>
> > Thanks for any insight you can provide.
>
> It might be because you're specifying it after the database name which
> should be the last parameter, and which you've already specified with
> -d anyway.  Try: psql -h localhost -p 5432 -d $database -c "select
> count(*)
>
> Regards
>
> Thom
>
> --
> Sent via pgsql-general mailing list (pgsql-gene...@postgresql.org)
> To make changes to your 
> subscription:http://www.postgresql.org/mailpref/pgsql-general- Hide quoted 
> text -
>
> - Show quoted text -

You suggestion did work when I run this

$ psql -h localhost -p 5432 -d $database -c "select count(*) from
client_claim_file" postgres

However, if I now force the username command line argument then I can
recover the original form that worked with 8.2, that is:

>psql -h localhost -p 5432 -d $database -U postgres -c "select count(*) from 
>$tablename"

Thanks for your help - never would have thought about the order of
command line arguments.  FYI, the reason I was trying to recover the
original form was that I have an alias for "psql -h localhost -p 5432 -
d $database -U postgres".


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Dynamically-sized WAL files

[Thom Brown]

2009/11/10 Simon Riggs :
> On Tue, 2009-11-10 at 09:39 +, Thom Brown wrote:
>
>> Is there a reason we require fixed-size WAL files?
>
> Currently we reuse the files, which is much easier with fixed size
> files.
>
> It might have been interesting once to pass the size at log switch
> through to the archiver as a parameter, though we didn't do that at the
> time. Streaming is the way forwards, not file-by-file.
>

I see!  Yes, streaming is far more preferrable. :)

Thanks Simon.

Thom Brown

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general