Tom Lane wrote:
Hannu Krosing <[EMAIL PROTECTED]> writes:
On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote:
Also, PL/Perl shouldn't be the only language to have this capability.
How might we add similar capabilities to PL/PythonU
I'll look at adding this to pl/pythonu.
I would argue
2008/10/30 Robert Haas <[EMAIL PROTECTED]>:
>> All of this is pie-in-the-sky for PL functions, and I think properly so:
>> the whole reason for supporting PLs is to enable doing things that SQL
>> does poorly or not at all. So expecting SQL to interoperate very
>> closely with them seems impossibl
On Wed, Oct 29, 2008 at 10:23:36PM -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote:
> >> Also, PL/Perl shouldn't be the only language to have this
> >> capability. How might we add similar capabilities to PL/PythonU
>
>
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Regarding the LOG message, it is confusing to have a recovery.conf
> file which contains this:
> recovery_target_time = '2008-10-16 17:00:00.0'
> and see this in the log:
> [2008-10-16 23:04:26.006 CDT] 19951 LOG: last completed transaction
> was at l
On Wednesday 29 October 2008 20:12, Tom Lane wrote:
> Earlier today I had a different thought about how to sort things early
> in the fest. I think that there is a strong temptation to finish off
> the "simple" patches quickly so as to reduce the size of the list ---
> I know I've done that and I
"David Blewett" <[EMAIL PROTECTED]> writes:
> Here's a vote for allowing this in plain SQL.
> I use the tablefunc contrib module as a way to build a view of a
> specific questionnaire's responses (using Elein's nice model here
> [1]). Currently, if I then write queries against these views that
> i
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I think I like this best of all the suggestions -
> suppress_redundant_updates_trigger() is what I have now.
> If there's no further discussion, I'll go ahead and commit this in a day
> or two.
The documentation seems a bit lacking: it gives neither
Josh Berkus <[EMAIL PROTECTED]> writes:
>> (2) sorting the pending patches by complexity or subject matter
> Sorting them by complexity would be great, if I thought I could do it. I'm
> not sure I can.
We organized them by subject matter (or code area, really) in a couple
of the earlier fests.
Simon Riggs wrote:
On Wed, 2008-10-29 at 17:42 +0900, KaiGai Kohei wrote:
I've updated my patches, these are ready for CommitFest:Nov.
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1155.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel
Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Not sure that's appropriate, but I can't see anything else that is
>> very appropriate either.
> The plpgsql code uses errcode(ERRCODE_FEATURE_NOT_SUPPORTED) for this
> situation, so I guess we should be consistent with that.
TRIGGERED_DATA_CHANGE_V
Robert,
> (1) moving all of the patches committed prior to 11/1 to a separate
> section or page
Why?
> (2) sorting the pending patches by complexity or subject matter
Sorting them by complexity would be great, if I thought I could do it. I'm
not sure I can.
--
Josh Berkus
PostgreSQL
San Fra
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote:
>> Also, PL/Perl shouldn't be the only language to have this capability.
>> How might we add similar capabilities to PL/PythonU
> I'll look at adding this to pl/pythonu.
I would argue that it's alr
On Wed, 2008-10-29 at 21:58 -0400, Robert Haas wrote:
> > If you say its a loss you should publish timings to support that. Using
> > a BAS for VACUUM was a performance gain, not a loss.
>
> Well, I can dig up and publish the timings from my laptop, but I'm not
> sure where that will get us. Tru
I wonder if we should consider:
(1) moving all of the patches committed prior to 11/1 to a separate
section or page
(2) sorting the pending patches by complexity or subject matter
...Robert
On Wed, Oct 29, 2008 at 5:26 PM, Josh Berkus <[EMAIL PROTECTED]> wrote:
> Patch submitters,
>
> Please mak
> If you say its a loss you should publish timings to support that. Using
> a BAS for VACUUM was a performance gain, not a loss.
Well, I can dig up and publish the timings from my laptop, but I'm not
sure where that will get us. Trust me, the numbers were higher with
BAS, otherwise I wouldn't be
On Thu, 2008-10-30 at 09:46 +0900, Koichi Suzuki wrote:
> I'm not sure if blocks reffered from all WAL records in single WAL
> segment can fit kernel cache. This is why current pg_readahead
> returns the last LSN and require starting LSN. So far, with FPW, it
> seems that we can prefetch all
Hi,
2008/10/29 Simon Riggs <[EMAIL PROTECTED]>:
>
> On Tue, 2008-10-28 at 14:21 +0200, Heikki Linnakangas wrote:
>
>> 1. You should avoid useless posix_fadvise() calls. In the naive
>> implementation, where you simply call posix_fadvise() for every page
>> referenced in every WAL record, you'll d
I'm not sure if blocks reffered from all WAL records in single WAL
segment can fit kernel cache. This is why current pg_readahead
returns the last LSN and require starting LSN. So far, with FPW, it
seems that we can prefetch all the pages in a WAL segment. So it
will be okay for archive log c
> All of this is pie-in-the-sky for PL functions, and I think properly so:
> the whole reason for supporting PLs is to enable doing things that SQL
> does poorly or not at all. So expecting SQL to interoperate very
> closely with them seems impossible, or at least unreasonably limiting.
> The real
Patch submitters,
Please make sure your patches are on the November CommitFest wiki page, with
correct and updated links.
http://wiki.postgresql.org/wiki/CommitFest_2008-11
--
Josh Berkus
PostgreSQL
San Francisco
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On Wed, 2008-10-29 at 10:33 -0700, Joshua D. Drake wrote:
> On Wed, 2008-10-29 at 19:17 +0200, Hannu Krosing wrote:
> > On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote:
> > > Folks,
> > >
> > > Please find enclosed a WIP patch to add the ability for functions to
> > > see the qualifiers of t
On Tue, 2008-10-28 at 23:45 -0400, Robert Haas wrote:
> One concern that I have about this approach is that the situation in
> which people are probably most concerned about COPY performance is
> restoring a dump. In that case, the COPY will be the only thing
> running, and using a BufferAccessS
Alvaro Herrera wrote:
> 3. the bgwriter is seen writing WAL entries at checkpoint. At shutdown,
> this might cause an error to be reported on how there was not supposed
> to be activity on the log. I didn't save the exact error report and I
> can't find it in the source :-(
LOG: received fast
"Gevik Babakhani" <[EMAIL PROTECTED]> writes:
> I asked this question because I have a situation where a service like this
> would be very useful. If such a functionality would be accepted by the core
> team, I am willing to work on it.
The existing code uses APIs that Apple has deprecated, so it'
Andrew Dunstan wrote:
David Fetter wrote:
Maybe we should fix our C sample trigger, from which this was taken.
Yes :)
Does the attached have the right error code?
-elog(ERROR, "trigf: not called by trigger manager");
+ereport(ERROR,
+(error(TRIGGERED
On Wed, 2008-10-29 at 17:42 +0900, KaiGai Kohei wrote:
> I've updated my patches, these are ready for CommitFest:Nov.
>
> [1/6]
> http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1155.patch
> [2/6]
> http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1155.
David Fetter wrote:
Maybe we should fix our C sample trigger, from which this was taken.
Yes :)
Does the attached have the right error code?
-elog(ERROR, "trigf: not called by trigger manager");
+ereport(ERROR,
+(error(TRIGGERED_DATA_CHANGE_VIOLATION),
On Wed, Oct 29, 2008 at 03:48:09PM -0400, Andrew Dunstan wrote:
>
>>> + /* make sure it's called as a trigger */
>>> + if (!CALLED_AS_TRIGGER(fcinfo))
>>> + elog(ERROR, "suppress_redundant_updates_trigger: must be called
>>> as trigger");
>>
>> Shouldn't these all be ereport()?
>
>
I asked this question because I have a situation where a service like this
would be very useful. If such a functionality would be accepted by the core
team, I am willing to work on it.
> -Original Message-
> From: Alvaro Herrera [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 29, 200
If I am not mistaken, it only works fine on OSX environments. (I might be
very wrong here)
> -Original Message-
> From: Magnus Hagander [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 29, 2008 8:47 PM
> To: Gevik Babakhani
> Cc: 'PGSQL Hackers'
> Subject: Re: [HACKERS] PostgreSQL ne
Alvaro Herrera wrote:
> There are some gotchas in this patch:
>
> 1. it does not consider hint bits other than the ones defined in htup.h.
> Some index AMs use hint bits to "kill" tuples (LP_DEAD mostly, I think).
> This means that CRCs will be broken for such pages when pages are torn.
The "oth
Gevik Babakhani wrote:
> Hi,
>
> There is a nice little feature within MSSQL where it is possible to
> enumerate all MSSQL servers on the local network.
> I wonder how this can be made possible with PG. Pinging every IP:PGPORT
> within the current subnet is one of the options but I guess that wou
Alvaro Herrera wrote:
Andrew Dunstan escribió:
+ /* make sure it's called as a trigger */
+ if (!CALLED_AS_TRIGGER(fcinfo))
+ elog(ERROR, "suppress_redundant_updates_trigger: must be called as
trigger");
Shouldn't these all be ereport()?
Good point.
I'll fix
Gevik Babakhani wrote:
> Hi,
>
> There is a nice little feature within MSSQL where it is possible to
> enumerate all MSSQL servers on the local network.
> I wonder how this can be made possible with PG. Pinging every IP:PGPORT
> within the current subnet is one of the options but I guess that wou
Hi,
There is a nice little feature within MSSQL where it is possible to
enumerate all MSSQL servers on the local network.
I wonder how this can be made possible with PG. Pinging every IP:PGPORT
within the current subnet is one of the options but I guess that would be
just a bad solution. Any tho
Andrew Dunstan escribió:
> + /* make sure it's called as a trigger */
> + if (!CALLED_AS_TRIGGER(fcinfo))
> + elog(ERROR, "suppress_redundant_updates_trigger: must be called as
> trigger");
Shouldn't these all be ereport()?
--
Alvaro Herrerahttp:
Hi Alvaro,
On Wed, Oct 29, 2008 at 3:46 PM, Alvaro Herrera
<[EMAIL PROTECTED]>wrote:
> Noah Freire escribió:
>
> > please check the first log message: the vacuum threshold is 6,000,050
> rows
> > and the number of dead tuples is 16,697,969. Even though the number of
> > dead_tuples is greater than
Andrew Dunstan wrote:
>
>
> Kenneth Marshall wrote:
>> On Wed, Oct 22, 2008 at 06:05:26PM -0400, Tom Lane wrote:
>>
>>> Simon Riggs <[EMAIL PROTECTED]> writes:
>>>
> On Wed, Oct 22, 2008 at 3:24 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
>> "Minimal" really fails to conve
Noah Freire escribió:
> datid | datname | procpid | usesysid | usename | current_query | waiting |
> xact_start | query_start | backend_start | client_addr | client_port
> ---+-+-+--+--+-+-
Kenneth Marshall wrote:
On Wed, Oct 22, 2008 at 06:05:26PM -0400, Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
On Wed, Oct 22, 2008 at 3:24 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
"Minimal" really fails to convey the point here IMHO. How about
something like "sup
Alvaro Herrera wrote:
> So this is what I ended up doing; attached.
Oh, another thing. The contents for the WAL log message here is very
simplistic; just store all the t_infomask and t_infomask2 relevant bits,
for all the tuples in the table. A possible optimization to reduce the
WAL traffic is
Noah Freire escribió:
> please check the first log message: the vacuum threshold is 6,000,050 rows
> and the number of dead tuples is 16,697,969. Even though the number of
> dead_tuples is greater than the threshold the autovacuum is not being
> triggered for this table. So, besides this condition
On Wed, Oct 29, 2008 at 12:40 PM, David Fetter <[EMAIL PROTECTED]> wrote:
> Also, PL/Perl shouldn't be the only language to have this capability.
> How might we add similar capabilities to PL/PythonU and PL/Tcl? To
> the rest of the PLs? Would it make any sense to have it in SQL
> language functi
I'm posting on hackers because I think that there is a problem in one
of three places, and I'm not sure which:
(1) The documentation needs clarification.
(2) A LOG message needs clarification.
(3) There is a bug in recovery. (unlikely)
This issue was previously posted here with no response:
Hello,
I have a table (accounts) with 600,000,000 rows. A heavy high-concurrent
workload that makes mostly updates on this table generates a lot of dead
tuples in its run, which is expected due to MVCC.
The problem is that even though autovacuum is enabled, the autovacuum worker
does not vacuum th
Simon Riggs wrote:
> But perhaps writing a single WAL record if you scan whole page and set
> all bits at once. Then it makes sense in some cases.
So this is what I ended up doing; attached.
There are some gotchas in this patch:
1. it does not consider hint bits other than the ones defined in h
>Hi Simon,
>
>He is going to do some investigation in the methods and
>write down the possibilities and then he is going to implement
>something from that for PostgreSQL.
>
>When will this work be complete? We are days away from completing main
>work on 8.4, so you won't get much discussion on this
Hi Simon,
He is going to do some investigation in the methods and
write down the possibilities and then he is going to implement
something from that for PostgreSQL.
When will this work be complete? We are days away from completing main
work on 8.4, so you won't get much discussion on this
On Wed, 2008-10-29 at 19:15 +0200, Hannu Krosing wrote:
>
> > SLAVE 0 is defined by a GUC on the slave, replication_slave_no I think.
> > ( I would have to check the docs)
>
> And the only other GUC slave needs for replication is MCP/Slave connect
> info ?
https://projects.commandprompt.com/pub
On Wed, 2008-10-29 at 19:17 +0200, Hannu Krosing wrote:
> On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote:
> > Folks,
> >
> > Please find enclosed a WIP patch to add the ability for functions to
> > see the qualifiers of the query in which they're called. It's not
> > working just yet, and
On Wed, 2008-10-29 at 11:58 -0400, Tom Lane wrote:
> Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> > And I fail to see how the user would control which behavior will get
> > chosen,
>
> Oh, I'm sorry, I didn't realize you misunderstood my syntax example.
> I was suggesting that the SQL function
On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote:
> Folks,
>
> Please find enclosed a WIP patch to add the ability for functions to
> see the qualifiers of the query in which they're called. It's not
> working just yet, and I'm not sure how best to get it working, but I'd
> like to see this
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> Le mercredi 29 octobre 2008, Tom Lane a écrit :
>> However, I see no
>> solution to that problem except function inlining; and if the function
>> gets inlined then all this discussion is moot anyhow.
> How to inline PLs functions?
All of this is p
On Wed, 2008-10-29 at 09:01 -0700, Joshua D. Drake wrote:
> On Wed, 2008-10-29 at 12:02 +0200, Hannu Krosing wrote:
> > On Tue, 2008-10-28 at 22:16 -0700, Joshua D. Drake wrote:
> > > Alvaro Herrera wrote:
> > > Case in point. To replicate a table currently you do this:
> > >
> > > ALTER TABLE fo
On Wed, Oct 29, 2008 at 12:40 PM, David Fetter <[EMAIL PROTECTED]> wrote:
> Please find enclosed a WIP patch to add the ability for functions to
> see the qualifiers of the query in which they're called. It's not
> working just yet, and I'm not sure how best to get it working, but I'd
> like to se
Le mercredi 29 octobre 2008, Tom Lane a écrit :
> Now of course the bigger problem with either this syntax or yours is
> that attaching such a property to a function is arguably the Wrong Thing
> in the first place. Which one is the best way is likely to depend on
> the calling query more than it
Folks,
Please find enclosed a WIP patch to add the ability for functions to
see the qualifiers of the query in which they're called. It's not
working just yet, and I'm not sure how best to get it working, but I'd
like to see this as part of 8.4, as SQL/MED is just way too ambitious
given the time
On Wed, 2008-10-29 at 09:54 +0200, Hannu Krosing wrote:
> On Tue, 2008-10-28 at 22:37 -0300, Alvaro Herrera wrote:
> > Hannu Krosing wrote:
> > > On Tue, 2008-10-28 at 15:18 -0700, Joshua Drake wrote:
> it was in subsection "mcp_server mysteriously dies"
> http://www.commandprompt.com/products/mam
On Wed, 2008-10-29 at 12:02 +0200, Hannu Krosing wrote:
> On Tue, 2008-10-28 at 22:16 -0700, Joshua D. Drake wrote:
> > Alvaro Herrera wrote:
> > Case in point. To replicate a table currently you do this:
> >
> > ALTER TABLE foo ENABLE REPLICATION;
> > ALTER TABLE foo ENABLE REPLICATION ON SLAVE
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> And I fail to see how the user would control which behavior will get chosen,
Oh, I'm sorry, I didn't realize you misunderstood my syntax example.
I was suggesting that the SQL function manager recognize some optional
non-SQL keywords at the start of
Le mercredi 29 octobre 2008, Tom Lane a écrit :
> Well, call-per-value is *necessary* for lazy evaluation, but it's not
> *sufficient*. You need a function implementation that can suspend and
> resume execution, and that's difficult in general.
Ok, I think I begin to understand how things are tie
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> Le mercredi 29 octobre 2008, Tom Lane a écrit :
>> So the fact that it's possible for SQL-language functions is an
>> idiosyncrasy of that language, not something we should cram into the
>> general CREATE FUNCTION syntax in the vain hope that having
Attached is my latest parallel restore patch. I think it's functionally
complete for Unix.
Many bugs have been fixed since the last patch, and the hardcoded
limitation to two table dependencies is removed. It seems fairly robust
in my recent testing.
Remaining to be done:
. code cleanup
.
Le mercredi 29 octobre 2008, Tom Lane a écrit :
> So the fact that it's possible for SQL-language functions is an
> idiosyncrasy of that language, not something we should cram into the
> general CREATE FUNCTION syntax in the vain hope that having syntax
> might cause an implementation to appear som
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> Done this way, the user could also choose for the function to be lazy or to
> use a tuplestore whatever the language in which it's written.
The odds of this ever happening for any of the PLs are not
distinguishable from zero. It might be nice to hav
On Wed, Oct 29, 2008 at 12:02:20PM +0200, Hannu Krosing wrote:
> A good goal. But why would anybody _need_ 50 slaves ?
They might have a contractual responsibility for extremely wide
geographic distribution. Or they might be building an application
that needs extremely wide network-topological
> Buffer ReadBuffer(Relation reln, BlockNumber blockNum);
> Buffer ReadBufferExt(Relation reln, ForkNumber forkNum, BlockNumber
> blockNum, BufferAccessStrategy strategy, ReadBufferMode mode);
> Buffer ReadBufferWithoutRelcache(RelFileNode rnode, bool isTemp, ForkNumber
> forkNum, BlockNumber block
> So my idea would be to have the SQL function behavior choose to return values
> either via tuplestore or via value-per-call, depending on the user
> setting "generator" or "lazy".
> Done this way, the user could also choose for the function to be lazy or to
> use a tuplestore whatever the languag
2008/10/29 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> I understand. So every smallint should be call with casting?
>
> A long time ago we tried to make small integer literals be interpreted
> as int2 initially, instead of int4, and the attempt failed rather
> spe
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I understand. So every smallint should be call with casting?
A long time ago we tried to make small integer literals be interpreted
as int2 initially, instead of int4, and the attempt failed rather
spectacularly. (It broke most of the regression tests
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> The FSM would be perfectly happy to just initialize torn or otherwise
> damaged pages, so I think we should add yet another mode to ReadBuffer()
> to allow that. We could also treat read() errors as merely warnings in
> that mode, effectively the
2008/10/29 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> I am not sure, it's probably bug.
>
>> postgres=# create function t1(smallint) returns smallint as $$select
>> $1$$ language sql;
>> CREATE FUNCTION
>> postgres=# select t1(10);
>> ERROR: function t1(integer)
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I am not sure, it's probably bug.
> postgres=# create function t1(smallint) returns smallint as $$select
> $1$$ language sql;
> CREATE FUNCTION
> postgres=# select t1(10);
> ERROR: function t1(integer) does not exist
That's not "unknown to smallint",
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
As far as the ugliness in XLogRecordPageWithFreeSpace goes: couldn't you
just call XLogReadBufferWithFork with init = true, and then initialize
the page if PageIsNew?
With init=true, we don't even try to read the p
Le mardi 28 octobre 2008, Pavel Stehule a écrit :
> 2008/10/28 Dimitri Fontaine <[EMAIL PROTECTED]>:
> > Hi,
> >
> > In the python language, functions that lazily return collections are
> > called generators and use the yield keyword instead of return.
> > http://www.python.org/doc/2.5.2/tut/node11
On Tue, 2008-10-28 at 22:16 -0700, Joshua D. Drake wrote:
> Alvaro Herrera wrote:
> > Hannu Krosing wrote:
> >> On Tue, 2008-10-28 at 15:18 -0700, Joshua Drake wrote:
>
> >> Will there be an helper application for setting up and configuring
> >> changes in replication. or will it all be done usin
On Wed, 2008-10-29 at 09:55 +0900, Koichi Suzuki wrote:
> I'd like to hear some more about these. I'm more than happy to write
> all the code inside PG core to avoid overhead to create another
> process.
Having an external program can help earlier releases also, so I think
this is the right ap
I've updated my patches, these are ready for CommitFest:Nov.
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1155.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1155.patch
[3/6]
http://sepgsql.googlecode.com/files/sepostgresql-policy
On Tue, 2008-10-28 at 14:21 +0200, Heikki Linnakangas wrote:
> 1. You should avoid useless posix_fadvise() calls. In the naive
> implementation, where you simply call posix_fadvise() for every page
> referenced in every WAL record, you'll do 1-2 posix_fadvise() syscalls
> per WAL record, and t
It could be useful to have a command that returns the table definition
(like pg_dump -st) from within the query interface. This could be
particularly useful if one doesn't have access to or prefers not to
manipulate results coming from a shell. If I have an API from which to
query the databas
Hello
I am not sure, it's probably bug.
postgres=# create function t1(smallint) returns smallint as $$select
$1$$ language sql;
CREATE FUNCTION
postgres=# create function t2(bigint) returns bigint as $$select $1$$
language sql;
CREATE FUNCTION
postgres=# select t1(10);
ERROR: function t1(integer
On Tue, 2008-10-28 at 22:37 -0300, Alvaro Herrera wrote:
> Hannu Krosing wrote:
> > On Tue, 2008-10-28 at 15:18 -0700, Joshua Drake wrote:
>
> > > The two obvious problems with the existing MCP architecture is:
> > >
> > > 1. Single point of failure
> >
> > For async replication there is always
82 matches
Mail list logo
