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
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
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, plea
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: previ
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 pub
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
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/incl
"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
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 f
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 LAT
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 fail
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
(
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
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 redunda
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 d
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 Lin
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 clu
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 tha
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 P
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
- r
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.
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
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
Li
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
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
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
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 bet
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
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
--
Sen
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'
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://vime
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 mai
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 c
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
i
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.1
35 matches
Mail list logo
