Someone is working on extending the current system to allow read-only
queries on a standby server [1], thus making it a hot standby, but
this feature apparently won't be included until 8.4 [2].
My 2 cents...
I would rather see someone working on true synchronous replication,
rather than a
Jeff Larsen escribió:
Someone is working on extending the current system to allow read-only
queries on a standby server [1], thus making it a hot standby, but
this feature apparently won't be included until 8.4 [2].
My 2 cents...
I would rather see someone working on true synchronous
Glyn Astill wrote:
Thanks everyone for your replies. EnterpriseDB looks like the way to
go if we want good replication.
Sorry, this makes no sense to me -- EnterpriseDB has no replication
solution that I know of.
Postgres-r sounds very nice but moving our organisations data onto a
system
On Mon, 2007-11-26 at 07:25 -0600, Jeff Larsen wrote:
Someone is working on extending the current system to allow read-only
queries on a standby server [1], thus making it a hot standby, but
this feature apparently won't be included until 8.4 [2].
My 2 cents...
I would rather see
Alvaro Herrera, 26.11.2007 15:07:
EnterpriseDB has no replication solution that I know of.
Quote from
http://www.enterprisedb.com/products/enterprisedb_replication.do
EnterpriseDB Replication Server replicates data across the enterprise
in near real time to meet a wide array of business
Alvaro Herrera wrote:
Glyn Astill wrote:
Thanks everyone for your replies. EnterpriseDB looks like the way to
go if we want good replication.
Sorry, this makes no sense to me -- EnterpriseDB has no replication
solution that I know of.
Yeah, there is:
Alvaro Herrera wrote:
Glyn Astill wrote:
Thanks everyone for your replies. EnterpriseDB looks like the way to
go if we want good replication.
Sorry, this makes no sense to me -- EnterpriseDB has no replication
solution that I know of.
Yeah, there is:
On Nov 24, 2007, at 6:18 PM, Laurent CARON wrote:
Question:
I'd like to know if it is possible (and wise) to just keep the
/var/lib/postgres.. directories from the old 32Bit server to use
on
the 64Bit version.
This is just as a personal interest since I can also just dump and
restore
On Nov 26, 2007, at 10:14 AM, Jeff Larsen wrote:
Yes, but I'd like something better than near real time as the above
page describes. Or maybe someone could clarify that Besides,
EnterpriseDB does not save me enough money. In my current commercial
DB, if a transaction is committed on the
Yes, but I'd like something better than near real time as the above
page describes. Or maybe someone could clarify that Besides,
EnterpriseDB does not save me enough money. In my current commercial
DB, if a transaction is committed on the master, it is guaranteed to
be committed to
Jeff Larsen wrote:
Alvaro Herrera wrote:
Glyn Astill wrote:
Yes, but I'd like something better than near real time as the above
page describes. Or maybe someone could clarify that Besides,
EnterpriseDB does not save me enough money.
Well do what EnterpriseDB does :) use Slony. Which is
Martijn van Oosterhout wrote:
On Fri, Nov 23, 2007 at 09:33:13AM +, Peter Childs wrote:
I tend to agree that primary keys should be single fields if they need to be
referenced but should also be natural if at all possible. ie use car number
plates rather than some serial int.
Car
[EMAIL PROTECTED] (Jeff Larsen) writes:
Alvaro Herrera wrote:
Glyn Astill wrote:
Thanks everyone for your replies. EnterpriseDB looks like the way to
go if we want good replication.
Sorry, this makes no sense to me -- EnterpriseDB has no replication
solution that I know of.
Yeah,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 26 Nov 2007 10:11:37 -0800
Steve Crawford [EMAIL PROTECTED] wrote:
Although I haven't seen it much, recently, semi-trucks used to
regularly have with numerous plates - one for each state in which
they operated. And some states such as
--- On Mon, 11/26/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
In theory the item that would be a natural key
in this instance is the VIN. You would of course have
to make some kind of allowance for cars that don't
have a VIN (nothing in the last what...
50 years?).
So this is why the
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Richard Broersma Jr
Sent: Monday, November 26, 2007 10:28 AM
To: Joshua D. Drake
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Primary Key
--- On Mon, 11/26/07, Joshua D. Drake [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 26 Nov 2007 10:28:03 -0800 (PST)
Richard Broersma Jr [EMAIL PROTECTED] wrote:
--- On Mon, 11/26/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
In theory the item that would be a natural key
in this instance is the VIN. You would of
--- Alvaro Herrera [EMAIL PROTECTED] wrote:
Glyn Astill wrote:
Thanks everyone for your replies. EnterpriseDB looks like the way
to
go if we want good replication.
Sorry, this makes no sense to me -- EnterpriseDB has no replication
solution that I know of.
This is bullsh*t, it does
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 26 Nov 2007 18:57:19 + (GMT)
Glyn Astill [EMAIL PROTECTED] wrote:
--- Alvaro Herrera [EMAIL PROTECTED] wrote:
Glyn Astill wrote:
Thanks everyone for your replies. EnterpriseDB looks like the way
to
go if we want good
It it possible to get a system that does syncronous replication and
also allows slaves to catch up if they're down for a period of time
like you can with asyncronous?
I'm just interested.
Of course a grid or a clustwer is better to makesure all servers are
in sync, but there's performance issues
Glyn Astill escribió:
It it possible to get a system that does syncronous replication and
also allows slaves to catch up if they're down for a period of time
like you can with asyncronous?
Guess what, Postgres-R is designed to do that.
Just for the record I'm a programmer, not a database
--- Original Message ---
From: Chris Browne [EMAIL PROTECTED]
To: pgsql-general@postgresql.org
Sent: 26/11/07, 17:39:42
Subject: Re: [GENERAL] replication in Postgres
I believe that what they are using is a version of Slony-I, which
certainly falls into the near real time
Okay I'm relaxed ;-) honest.
It does irritate me sometimes (my fault) when people post back
comments as if they have knowledge on a subject when they don't
though, if you don't know then keep quiet.
All it does is confuse prople like me, who really don't know, and are
reaching out for a little
It's worse than that.
It's even worse than that. Decades ago, Florida used to issue multiple
plates with the same number, differentiated by color.
There are other cases of states having multiple types of license plates,
with overlapping numbers.
--
Scott Ribe
[EMAIL PROTECTED]
On Nov 26, 2007 1:02 PM, Glyn Astill [EMAIL PROTECTED] wrote:
It it possible to get a system that does syncronous replication and
also allows slaves to catch up if they're down for a period of time
like you can with asyncronous?
Ummm, if one server falls behind, and the other keeps going,
Joshua D. Drake wrote:
In theory the item that would be a natural key in this instance is
the VIN. You would of course have to make some kind of allowance for
cars that don't have a VIN (nothing in the last what... 50 years?).
And some kind of allowance for Title 49, Sec. 565.4, subsection (d):
On Nov 26, 2007 1:30 PM, Steve Crawford [EMAIL PROTECTED] wrote:
I'm sure someone has defined a vehicle, but I don't know what number
applies when you've pieced together a rebuilt engine, salvaged
transmission, junkyard hood and so-on to get a working car. I think
custom builders end up
On Mon, Nov 26, 2007 at 07:02:35PM +, Glyn Astill wrote:
It it possible to get a system that does syncronous replication and
also allows slaves to catch up if they're down for a period of time
like you can with asyncronous?
This is what Postgres-R is intended to do. In order to get that
On Mon, Nov 26, 2007 at 07:25:04AM -0600, Jeff Larsen wrote:
My 2 cents...
I would rather see someone working on true synchronous replication,
It will cost more than US$0.02. But if you're willing to put up real money,
there are people willing to put in the work. Or, if you're willing to
On Mon, Nov 26, 2007 at 03:31:46PM +0100, Thomas Kellerer wrote:
EnterpriseDB Replication Server replicates data across the enterprise
in near real time to meet a wide array of business challenges. Data can
Slony does this, except that it can't talk to Oracle. What's wrong with
Slony? My
Hi all,
What is the proper syntax/escape character when using 'ALTER ...
OWNER TO user-name'? I've tried single quotes, backslashes, backticks
and various others without luck. Is it at all possible?
Thanks!
Madi
---(end of broadcast)---
TIP
Madison Kelly wrote:
Hi all,
What is the proper syntax/escape character when using 'ALTER ... OWNER TO
user-name'? I've tried single quotes, backslashes, backticks and various
others without luck. Is it at all possible?
Double quotes (same as for any identifier)
--
Alvaro Herrera
Joshua D. Drake wrote:
On Mon, 26 Nov 2007 10:28:03 -0800 (PST)
Richard Broersma Jr [EMAIL PROTECTED] wrote:
--- On Mon, 11/26/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
In theory the item that would be a natural key
in this instance is the VIN.
And you then need to deal with cars that
Since no one's mentioned it, and while I don't have any personal
experience with it, I thought I'd mention the recently released
Bucardo (http://bucardo.org/) as another Postgres replication option.
Erik Jones
Software Developer | Emma®
[EMAIL PROTECTED]
800.595.4401 or 615.292.5888
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 26 Nov 2007 12:39:42 -0500
Chris Browne [EMAIL PROTECTED] wrote:
Unfortunately, the only way to make things deterministic (or to get
from near real time to *GUARANTEED* real time) is to jump to
synchronous replication, which is not much
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/26/07 12:11, Steve Crawford wrote:
[snip]
If we presume that the plate is a key to a vehicle, then we immediately
run into problems as a vehicle can, over time, have several plates
(lost, stolen, changed to vanity...) and a plate can
So what is the state-of-the-art in the Postgresql world if I _do_ want
synchronous replication? 2-phase commit from the client application? Any
success/horror stories about doing it in Java?
---(end of broadcast)---
TIP 6: explain analyze is
On Nov 26, 2007 3:41 PM, Garber, Mikhail [EMAIL PROTECTED] wrote:
So what is the state-of-the-art in the Postgresql world if I _do_ want
synchronous replication? 2-phase commit from the client application? Any
success/horror stories about doing it in Java?
Depending on the restrictions
On Nov 26, 2007 1:11 PM, Steve Crawford [EMAIL PROTECTED] wrote:
It's worse than that.
If we presume that the plate is a key to a vehicle, then we immediately
run into problems as a vehicle can, over time, have several plates
(lost, stolen, changed to vanity...) and a plate can belong,
[EMAIL PROTECTED] (Erik Jones) writes:
Since no one's mentioned it, and while I don't have any personal
experience with it, I thought I'd mention the recently released
Bucardo (http://bucardo.org/) as another Postgres replication option.
It's Yet Another Asynchronous Replication System, ergo
[EMAIL PROTECTED] (Glyn Astill) writes:
It it possible to get a system that does syncronous replication and
also allows slaves to catch up if they're down for a period of time
like you can with asyncronous?
Well, a modal approach is possible - that's what Postgres-R tries to
do.
Of course,
On Nov 26, 2007, at 3:21 PM, Chris Browne wrote:
[EMAIL PROTECTED] (Erik Jones) writes:
Since no one's mentioned it, and while I don't have any personal
experience with it, I thought I'd mention the recently released
Bucardo (http://bucardo.org/) as another Postgres replication option.
It's
Hey everybody. I'm trying to speed up a query (not general optimization,
one query in particular), and I'm not sure if there's any way to get it
to go faster.
The query looks like this
INSERT INTO transaction
(
tr_acct_num,
tr_acct_typ,
tr_atm_rec,
tr_audit_seq,
tr_branch_cd,
2 things
tr_tran_time needs to be already in 'time format'
is_ok needs to be indexed (preferably bitmapped index)
HTH/
Martin
- Original Message -
From: Tom Hart [EMAIL PROTECTED]
To: Postgres General List pgsql-general@postgresql.org
Sent: Monday, November 26, 2007 5:30 PM
Subject:
Martin Gainty wrote:
2 things
tr_tran_time needs to be already in 'time format'
is_ok needs to be indexed (preferably bitmapped index)
HTH/
Martin
The data is COPY'ed from csv's that our internal software creates, and
we don't have control over output format. Is coaxing tr_tran_time into
Tom Hart wrote:
Martin Gainty wrote:
2 things
tr_tran_time needs to be already in 'time format'
is_ok needs to be indexed (preferably bitmapped index)
HTH/
Martin
The data is COPY'ed from csv's that our internal software creates, and
we don't have control over output format. Is coaxing
On 11/13/07 10:02 AM, Scott Ribe [EMAIL PROTECTED] wrote:
What you're referring to must be that the kernel was essentially
single-threaded, with a single kernel-funnel lock. (Because the OS
certainly supported threads, and it was certainly possible to write
highly-threaded applications, and I
Hi all,
I've got a data warehouse with pretty high rate of insert into
partitioned tables. What I've noticed, is that rule-based partitioning
seems to be somewhat slower than insertions made directly into
partitions through execution of dynamic SQL.
Is it really true ?
Thanks!
Best
On Mon, 2007-11-26 at 16:01 -0800, Alex Vinogradovs wrote:
I've got a data warehouse with pretty high rate of insert into
partitioned tables. What I've noticed, is that rule-based partitioning
seems to be somewhat slower than insertions made directly into
partitions through execution of
On Mon, 2007-11-26 at 17:37 -0600, Wes wrote:
On 11/13/07 10:02 AM, Scott Ribe [EMAIL PROTECTED] wrote:
What you're referring to must be that the kernel was essentially
single-threaded, with a single kernel-funnel lock. (Because the OS
certainly supported threads, and it was certainly
PostgreSQL users,
Given the importance of India to the world of software, it's critical that
we have an Indian Regional Contact who can be the community press
relations person for India. In the past, we had Vishal and Shridhar who
did a terrific job but are no longer available.
If you are an
So what is the state-of-the-art in the Postgresql world if I _do_ want
synchronous replication? 2-phase commit from the client application? Any
success/horror stories about doing it in Java?
For Java, you could check out Sequoia (http://sequoia.continuent.org/) or
their commercial version
52 matches
Mail list logo
