On 14 Dec 2002 at 18:02, Justin Clift wrote:
> For PITR-log-based-replication, how much data would be required to be pushed out to
>each slave system in order to bring
> it up to date?
>
> I'm having visions of a 16MB WAL file being pushed out to slave systems in order to
>update them with a fe
Bruce Momjian wrote:
Joe Conway wrote:
Point-In-Time Recovery (PITR)
J. R. Nield did a PITR patch late in 7.3 development, and Patrick
MacDonald from Red Hat is working on merging it into CVS and
adding any missing pieces. Patrick, do you have an ETA on that?
As Hannu asked (and related
[EMAIL PROTECTED] wrote:
It is asynchronous without the need of 2 phase commit. It is group
communication based and requires the group communication system to
guarantee total order. The tricky part is, that the local transaction
must be on hold until the own commit message comes back without a pri
On Friday 13 December 2002 11:01 pm, you wrote:
> Good. This is the discussion we need. Let me quote the TODO list
> replication section first:
>
> * Add replication of distributed databases [replication]
> o automatic failover
Very good. We need that for HA.
> o load balanc
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Jeroen T. Vermeulen wrote:
>> Perhaps 7.3.1 could include a true, 7.2-style libpq.so.2.2 to overwrite
>> any 7.3-style version that the original 7.3 may have installed under that
>> name?
> That's an interesting idea, but then 7.3 binaries would link to
On Fri, 2002-12-13 at 20:20, Christopher Kings-Lynne wrote:
> > This is a good point. I don't want to push Postgres-R as our solution.
> > Rather, I have looked at both and like Postgres-R, but others need to
> > look at both and decide so we are all in agreement when we move forward.
>
> I think
Bruce Momjian wrote:
>
> Joe Conway wrote:
> > Bruce Momjian wrote:
> > > Win32 Port:
> > >
> > > Katie Ward and Jan are working on contributing their Win32
> > > port for 7.4. They plan to have a patch available by the end of
> > > December.
> >
> > I have .Net Studio available to me
Jeroen T. Vermeulen wrote:
> On Fri, Dec 13, 2002 at 09:06:47PM +, Oliver Elphick wrote:
> >
> > Yes. You will have libpq.so.3.0 in 7.3.1; and you have libpq.so.2.2
> > from 7.3 (and also from 7.2.x, though in fact they are different). If
> > you have installed 7.3.1 on top of 7.3, you will
On Fri, Dec 13, 2002 at 09:06:47PM +, Oliver Elphick wrote:
>
> Yes. You will have libpq.so.3.0 in 7.3.1; and you have libpq.so.2.2
> from 7.3 (and also from 7.2.x, though in fact they are different). If
> you have installed 7.3.1 on top of 7.3, you will have libpq.so.3
> (symlinked to libpq
Lets say we have systems A, B and C. Each one has some
changes and sends a writeset to the group communication
system (GSC). The total order dictates WS(A), WS(B), and
WS(C) and the writes sets are recieved in that order at
each system. Now C gets WS(A) no conflict, gets WS(B) no
conflict, a
> This is a good point. I don't want to push Postgres-R as our solution.
> Rather, I have looked at both and like Postgres-R, but others need to
> look at both and decide so we are all in agreement when we move forward.
I think in either way, it's clear that they need to be in the main CVS, in
or
Bruce Momjian wrote:
Iavor Raytchev wrote:
I actually do not understand why is the whole cry - why not somebody who
has REALLY the marketing in his/her heart - does not make an open source
amazingly beautiful and powerful web site. You do not have to ask Bruce
for that. You get BRICOLAGE -
Iavor Raytchev wrote:
> I actually do not understand why is the whole cry - why not somebody who
> has REALLY the marketing in his/her heart - does not make an open source
> amazingly beautiful and powerful web site. You do not have to ask Bruce
> for that. You get BRICOLAGE - it is free, and it
Neil Conway wrote:
> On Fri, 2002-12-13 at 13:36, Jan Wieck wrote:
> > But you cannot use the result of such a SELECT to update anything. So
> > you can only phase out complete read only transaction to the slaves.
> > Requires support from the application since the load balancing system
> > cannot
Peter Eisentraut wrote:
Marc G. Fournier writes:
It isn't, but those working on -advocacy were asked to help come up with a
stronger release *announcement* then we've had in the past ...
Consider that a failed experiment. PostgreSQL is driven by the
development group
At 08:55 PM 13/12/2002 +0100, Peter Eisentraut wrote:
The frequency of vacuum and analyze would seem to belong..
...max_fsm_relations belongs...
...Setting max_fsm_pages also belongs in that list...
...parts that refer to the VACUUM output should be put... near the Routine
Vacuuming
Not sure I l
Murthy Kambhampaty <[EMAIL PROTECTED]> writes:
> "/home/postgres/postgresql-7.3/src/test/regress/./tmp_check/install//usr/loc
> al/pgsql/bin/pg_encoding: relocation error:
> /home/postgres/postgresql-7.3/src/test/regress/./tmp_check/install//usr/loca
> l/pgsql/bin/pg_encoding: undefined symbol: pg_
A basic version of the SQL information schema is now available in newly
initdb'ed database installations. There's still a bunch of work to do to
create all the views that the spec defines.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)
Tom Lane writes:
> Should we remove this error check, thereby effectively making
> zero-column tables first-class citizens?
Yes.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please se
Thank you for a good workaround.
Even BETTER would be to fix the aggregates so workarounds wouldn't have to
be found.
Thanks again,
L.
On Fri, 13 Dec 2002, Josh Berkus wrote:
>
>
> -- Forwarded Message --
>
> Subject: Re: [PERFORM] Odd Sort/Limit/Max Problem
> Date: Fri, 13
On Fri, 2002-12-13 at 13:36, Jan Wieck wrote:
> But you cannot use the result of such a SELECT to update anything. So
> you can only phase out complete read only transaction to the slaves.
> Requires support from the application since the load balancing system
> cannot know automatically what will
[EMAIL PROTECTED] wrote:
>
> > It is asynchronous without the need of 2 phase commit. It is group
> > communication based and requires the group communication system to
> > guarantee total order. The tricky part is, that the local transaction
> > must be on hold until the own commit message comes
[EMAIL PROTECTED] wrote:
> >
> >
> > Darren, can you clarify this? Why does it send that message? How does
> > it allow commits not to wait for ordered writesets?
> >
>
> There are two channels. One for total order writesets
> (changes to the DB). The other is simple order for
> aborts, c
[EMAIL PROTECTED] wrote:
>
> >
> >
> > Darren, can you clarify this? Why does it send that message? How does
> > it allow commits not to wait for ordered writesets?
> >
>
> There are two channels. One for total order writesets
> (changes to the DB). The other is simple order for
> aborts, com
>
>
> Darren, can you clarify this? Why does it send that message? How does
> it allow commits not to wait for ordered writesets?
>
There are two channels. One for total order writesets
(changes to the DB). The other is simple order for
aborts, commits, joins (systems joining the replica)
[EMAIL PROTECTED] wrote:
> > It is asynchronous without the need of 2 phase commit. It is group
> > communication based and requires the group communication system to
> > guarantee total order. The tricky part is, that the local transaction
> > must be on hold until the own commit message comes bac
> > It is asynchronous without the need of 2 phase commit. It is group
>
> Well, Darren's PDF at:
>
>
>ftp://gborg.postgresql.org/pub/pgreplication/stable/PostgreSQLReplication.pdf.gz
>
> calls Postgres-R "Type: Embedded, Peer-to-Peer, Sync". I don't know
> enough about replication so I
> It is asynchronous without the need of 2 phase commit. It is group
> communication based and requires the group communication system to
> guarantee total order. The tricky part is, that the local transaction
> must be on hold until the own commit message comes back without a prior
No, It holds u
Jan Wieck wrote:
> Bruce Momjian wrote:
>
> > OK, the first thing is that there isn't any one replication solution
> > that will behave optimally in all situations.
>
> Right
>
> > Now, let me describe Postgres-R and then the other replication
> > solutions. Postgres-R is multi-master, meaning
On Fri, 2002-12-13 at 19:13, Bruce Momjian wrote:
> OK, let me see if I understand the ramifications.
>
> If you install 7.3.1 _on_top_of 7.3, both major versions will exist, and
> you your old binaries will continue to work. However, if you delete the
> old libraries, then install, anything comp
[EMAIL PROTECTED] wrote:
> > > Note that while Spread is open source in the sense that "the source is
> > > available", it's license is significantly more restrictive than
> > > PostgreSQL's:
> > >
> > > http://www.spread.org/license/
> > >
> >
> > Interesting. It looks like a modified vers
Tom Lane wrote:
> CVSROOT: /cvsroot
> Module name: pgsql-server
> Changes by: [EMAIL PROTECTED] 02/12/13 15:35:57
>
> Modified files:
> src/test/regress: resultmap
> Added files:
> src/test/regress/expected: geometry_1.out
> Removed files:
> src/test/regress/expect
> > Note that while Spread is open source in the sense that "the source is
> > available", it's license is significantly more restrictive than
> > PostgreSQL's:
> >
> > http://www.spread.org/license/
> >
>
> Interesting. It looks like a modified version of the old BSD license
> where you ar
Bruce Momjian wrote:
> OK, the first thing is that there isn't any one replication solution
> that will behave optimally in all situations.
Right
> Now, let me describe Postgres-R and then the other replication
> solutions. Postgres-R is multi-master, meaning you can send SELECT and
> UPDATE/DE
Philip Warner writes:
> Just wondering where I should put my modified tuning notes. I was planning
> on making them section 3.7 in the Admin guide. Does that sound reasonable?
The frequency of vacuum and analyze would seem to belong under Routine
Vacuuming in the Maintenance chapter. Setting ma
Bruce Momjian writes:
> > No, the run-time linker only looks at the major version.
>
> Then what value is there to incrementing the minor number?
For those platforms that have an ldconfig program, the ldconfig will
update the symlinks to the shared library based on the minor version
number. So i
I wrote:
>
> I guess I'm basically asking:
>
> 1) Is it necessary to *choose* between support for 2PC and Spread (Postgres-R) or
>can't we have both? Spread for Replication, 2PC for non-replicating distributed TX?
>
> 2) Do major SQL DBMS vendors which support distributed options expose a calla
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The point is that we are changing it for 7.3.1, so though 7.3 libpq is
> > almost identical to 7.3.1 libpq, we are going to bump the major and
> > force recompile. The binary API change was from 7.2 to 7.3, not 7.3 to
> > 7.3.1. Do p
Neil Conway wrote:
> On Fri, 2002-12-13 at 13:20, Bruce Momjian wrote:
> > Let me address the Spread issue and two-phase commit. (Spread is an
> > open source piece of software used by Postgres-R.)
>
> Note that while Spread is open source in the sense that "the source is
> available", it's licen
On Fri, 2002-12-13 at 13:20, Bruce Momjian wrote:
> Let me address the Spread issue and two-phase commit. (Spread is an
> open source piece of software used by Postgres-R.)
Note that while Spread is open source in the sense that "the source is
available", it's license is significantly more restri
- Original Message -
From: "Bruce Momjian" <[EMAIL PROTECTED]>
> Mike Mascari wrote:
> > Okay. But please keep in mind that a 2-phase commit implementation
> > is used for more than just replication.
>
> This is a good point. I don't want to push Postgres-R as our solution.
> Rather,
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The point is that we are changing it for 7.3.1, so though 7.3 libpq is
> almost identical to 7.3.1 libpq, we are going to bump the major and
> force recompile. The binary API change was from 7.2 to 7.3, not 7.3 to
> 7.3.1. Do people still want a major b
Oliver Elphick wrote:
> On Fri, 2002-12-13 at 05:34, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > OK, so what do we do with 7.3.1. Increment major or minor?
> > >
> > > Major. I thought you did it already?
> >
> > I did only minor, which I kne
Lee Kindness wrote:
> Making something binary incompatible IS an API change! In the case in
> question an externally visible structure definition was changed -
> clearly a change of API...
My point was that I thought it was a source-level API change that
required a major bump. I now see it can be
Mike Mascari wrote:
> Okay. But please keep in mind that a 2-phase commit implementation
> is used for more than just replication. Any distributed TX will
> require a 2PC protocol. As an example, for the DBLINK implementation
> to ultimately be transaction safe (at least amongst multiple
> PostgreS
Joe Conway wrote:
> Bruce Momjian wrote:
> > Win32 Port:
> >
> > Katie Ward and Jan are working on contributing their Win32
> > port for 7.4. They plan to have a patch available by the end of
> > December.
>
> I have .Net Studio available to me, so if you need help in merging or test
On Friday 13 December 2002 17:51, Bruce Momjian wrote:
> Shridhar Daithankar wrote:
> > And where are nested transactions?
>
> I didn't mention nested transactions because it didn't seem to be a
> _big_ item like the others.
This is big item
regards
Haris Peco
---(end of
Okay. But please keep in mind that a 2-phase commit implementation is used for more
than just replication. Any distributed TX will require a 2PC protocol. As an example,
for the DBLINK implementation to ultimately be transaction safe (at least amongst
multiple PostgreSQL installations), the play
[EMAIL PROTECTED] wrote:
> >
> > How hard would it be to extend PITR for master-slave (hot backup)
> > repliaction, which should then amount to continuously shipping logs to
> > slave and doing nonstop PITR there :)
>
> I have not looked at the PITR patch yet, but it might be possible
> to use the
Mike Mascari wrote:
> What about distributed TX support:
>
>
>http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=20021106111554.69ae1dcd.pgsql%40snaga.org&rnum=2&prev=/groups%3Fq%3DNAGAYASU%2BSatoshi%26ie%3DUTF-8%26oe%3DUTF-8%26hl%3Den
OK, yes, that is Satoshi's 2-phase commit i
Hannu Krosing wrote:
> On Fri, 2002-12-13 at 06:22, Bruce Momjian wrote:
> > I wanted to outline some of the big items we are looking at for 7.4:
> > Point-In-Time Recovery (PITR)
> >
> > J. R. Nield did a PITR patch late in 7.3 development, and Patrick
> > MacDonald from Red Hat is workin
Shridhar Daithankar wrote:
> 1) What kind of replication are we looking at? log file
> replay/synchronous etc. If it is real time, like usogres( I
> hope I am in line with things here), that would be real good.
> Choice is always good.
Good. This is the discussion we need. Let me quote the TODO
Shridhar Daithankar wrote:
> And where are nested transactions?
I didn't mention nested transactions because it didn't seem to be a
_big_ item like the others.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your li
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Fri, Dec 13, 2002 at 09:43:19AM -0500, Tom Lane wrote:
>> Actually, if you don't mind grabbing a copy of pg_filedump --- see
>> http://sources.redhat.com/rhdb/tools.html
> Has this been updated for 7.3? Last time I looked it only did 7.2, and
> the
On Fri, Dec 13, 2002 at 09:43:19AM -0500, Tom Lane wrote:
> Actually, if you don't mind grabbing a copy of pg_filedump --- see
> http://sources.redhat.com/rhdb/tools.html
Has this been updated for 7.3? Last time I looked it only did 7.2, and
the site shows an old date. If it hasn't, are there p
Bruce Momjian wrote:
Win32 Port:
Katie Ward and Jan are working on contributing their Win32
port for 7.4. They plan to have a patch available by the end of
December.
I have .Net Studio available to me, so if you need help in merging or testing
or whatever, let me know.
Point-In-Time Recov
Robert Treat <[EMAIL PROTECTED]> writes:
> Just out of curiosity, do any of the SQL specs deal with 0 column
> tables? I can't recall any dbms supporting a create table command that
> didn't require at least 1 column.
Actually, in SQL92 11.17 I find
3) C shall be a column of T and C sha
On Fri, 2002-12-13 at 03:43, Philip Warner wrote:
> At 02:56 AM 13/12/2002 -0500, Tom Lane wrote:
> >if it's not the only column in Amy's table, Beth can drop her type
> >and Amy's column along with it.
>
> I keep forgetting PG's inheritance features. In a non-inheritance system, I
> would vote f
Steve King <[EMAIL PROTECTED]> writes:
> The ctids are different however vaccum is run on this table and the record
> is updated.
It would be useful to look at xmin,xmax,cmin,cmax of these tuples too.
Actually, if you don't mind grabbing a copy of pg_filedump --- see
http://sources.redhat.com/rhd
>
> How hard would it be to extend PITR for master-slave (hot backup)
> repliaction, which should then amount to continuously shipping logs to
> slave and doing nonstop PITR there :)
I have not looked at the PITR patch yet, but it might be
possible to use the same PITR format to queue/log writese
Bruce Momjian wrote:
I wanted to outline some of the big items we are looking at for 7.4:
Win32 Port:
Katie Ward and Jan are working on contributing their Win32
port for 7.4. They plan to have a patch available by the end of
December.
Point-In-Time Recovery (PITR)
J. R. Nield did a PITR p
The ctids are different however vaccum is run on this table and the record
is updated.
The machineid is a SERIAL and so should also never be duplicated.
ctid | oid | machineid
+-+---
(7,18) | 9646238 |12
(7,10) | 9646238 |12
Any help as usual is g
On Fri, 2002-12-13 at 05:34, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > OK, so what do we do with 7.3.1. Increment major or minor?
> >
> > Major. I thought you did it already?
>
> I did only minor, which I knew was safe. Do folks realize this wil
On Fri, Dec 13, 2002 at 12:34:58AM -0500, Bruce Momjian wrote:
>
> I did only minor, which I knew was safe. Do folks realize this will
> require recompile of applications by 7.3 users moving to 7.3.1? That
> seems very drastic, and there have been very few problem reports about
> the NOTIFY chan
Guys,
Some further comments on bumbing the major version number which aren't
so cut-n-dry...
Lee Kindness writes:
> The major version number should be updated whenever the source of the
> library changes to make it binary incompatible. Such changes include,
> but limited to:
>
> 1. Removing
Guys, can I take this chance to summarise the thread and when the
major and minor versions should be updated, perhaps could be added to
the developers FAQ if everyone is in agreement?
Major Version
=
The major version number should be updated whenever the source of the
library changes
On Fri, 2002-12-13 at 09:27, Steve King wrote:
> > -Original Message-
> > From: Steve King
> > Sent: 12 December 2002 11:45
> > To: [EMAIL PROTECTED]
> > Subject:Duplicate oids!
> >
> > Forgive me if this is a previous question but I cannot find any
> > information on it
> -Original Message-
> From: Steve King
> Sent: 12 December 2002 11:45
> To: [EMAIL PROTECTED]
> Subject: Duplicate oids!
>
> Forgive me if this is a previous question but I cannot find any
> information on it in any of the mailing lists.
>
> I have a postgres database
Making something binary incompatible IS an API change! In the case in
question an externally visible structure definition was changed -
clearly a change of API...
Bruce Momjian writes:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > So if a recompile fixes it, increment mi
On Fri, 2002-12-13 at 06:22, Bruce Momjian wrote:
> I wanted to outline some of the big items we are looking at for 7.4:
> Point-In-Time Recovery (PITR)
>
> J. R. Nield did a PITR patch late in 7.3 development, and Patrick
> MacDonald from Red Hat is working on merging it into CVS and
At 02:56 AM 13/12/2002 -0500, Tom Lane wrote:
if it's not the only column in Amy's table, Beth can drop her type
and Amy's column along with it.
I keep forgetting PG's inheritance features. In a non-inheritance system, I
would vote for forcing a one column table to be dropped. For PG, I think
71 matches
Mail list logo
