Re: [HACKERS] Performance Enhancement/Fix for Array Utility Functions

> > > > 1. As-is, it's a significant *pessimization* for small arrays, because > > the heap_tuple_untoast_attr_slice code does a palloc/copy even when one > > is not needed because the data is already not toasted. I think there > > needs to be a code path that avoids that. > > This seems like it s

Re: [HACKERS] Improper usage of MemoryContext in nodeSubplan.c for buildSubPlanHash() function. This maybe causes allocate memory failed.

I wrote: > "Tao Ma" writes: >> This is a potential memory error in nodeSubplan.c or execGrouping.c >> Using select '1'::TEXT IN ((SELECT '1'::NAME) UNION ALL SELECT '1'::NAME); >> to reproduce this bug. >> ... >> To fix this problem, we can use another memory context to passin >> BuildTupleHashTa

Re: [HACKERS] PostGIS vs. PGXS in 9.0beta3

Tom Lane wrote: Josh Berkus writes: A 9.0b3 tester reported this issue with our single most popular PostgreSQL extension, PostGIS: == Postgis makes use of 'PGXS' in postgresql > 8.2. Within postgresql-9, datadir and many other variables are defined as multiple v

Re: [HACKERS] page corruption on 8.3+ that makes it to standby

On Tue, 2010-07-27 at 15:23 -0700, Jeff Davis wrote: > On Tue, 2010-07-27 at 17:18 -0400, Robert Haas wrote: > > > My first concern with that idea was that it may create an inconsistency > > > between the primary and the standby. The primary could have a bunch of > > > zero pages that never make it

Re: [HACKERS] Performance Enhancement/Fix for Array Utility Functions

On Fri, Jul 16, 2010 at 4:43 PM, Tom Lane wrote: > Daniel Farina writes: >> Generally I think the delimited untoasting of metadata from arrays >> separately from the payload is Not A Bad Idea. > > I looked at this patch a bit.  I agree that it could be a big win for > large external arrays, but .

Re: [HACKERS] Improper usage of MemoryContext in nodeSubplan.c for buildSubPlanHash() function. This maybe causes allocate memory failed.

"Tao Ma" writes: > This is a potential memory error in nodeSubplan.c or execGrouping.c > Using select '1'::TEXT IN ((SELECT '1'::NAME) UNION ALL SELECT '1'::NAME); > to reproduce this bug. > ... > To fix this problem, we can use another memory context to passin > BuildTupleHashTable() as the hash

Re: [HACKERS] Toward a column reorder solution

On Jul 27, 2010, at 3:01 PM, Joshua D. Drake wrote: > Correct. We are also hoping to get some sponsorship for it. > > https://www.fossexperts.com/ Frigging copycat. Any sponsorship for PGXN in there? ;-P Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To m

Re: [RRR] Review: Re: [PATCH] Re: [HACKERS] Adding xpath_exists function

On Tue, 2010-07-27 at 19:41 -0400, Robert Haas wrote: > On Tue, Jul 27, 2010 at 7:33 PM, David Fetter wrote: > >Minor quibble with the regression tests: should we be using > >dollar quotes in things like this? Doubled-up quote marks: > > > >SELECT xpath_exists('//town[text

Re: [HACKERS] Parsing of aggregate ORDER BY clauses

Robert Haas writes: > Am I misreading this, or did you just answer an "either-or" question with > "yes"? I meant "Yes, that's an issue." regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http:/

Re: [HACKERS] SSL cipher and version

On Tue, Jul 27, 2010 at 12:06 AM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jul 26, 2010 at 9:57 AM, Dave Page wrote: >>> On Mon, Jul 26, 2010 at 2:49 PM, Robert Haas wrote: Any objections to me committing this? >>> >>> Might wanna fix this first: >>> >>> +PG_FUNCTION_INFO_V1(ssl_ve

Re: Review: Re: [PATCH] Re: [HACKERS] Adding xpath_exists function

On Tue, Jul 27, 2010 at 7:33 PM, David Fetter wrote: >        Minor quibble with the regression tests: should we be using >        dollar quotes in things like this?  Doubled-up quote marks: > >        SELECT xpath_exists('//town[text() = > ''Cwmbran'']','Bidford-on-AvonCwmbranBristol'::xml); > >

Re: [HACKERS] Parsing of aggregate ORDER BY clauses

On Tue, Jul 27, 2010 at 7:16 PM, Tom Lane wrote: > Daniel Grace writes: >>  But if we SELECT >> SOME_INTEGER_AGGREGATE(DISTINCT floatcol ORDER BY floatcol), should >> the DISTINCT operate on floatcol (i.e. 1.1 and 1.2 are distinct, even >> if it means the function is called with '1' twice) or >>

Review: Re: [PATCH] Re: [HACKERS] Adding xpath_exists function

== Submission review == * Is the patch in context diff format? Yes. * Does it apply cleanly to the current CVS HEAD? Yes. patch -p1 < ../xpath_exists-3.patch patching file doc/src/sgml/func.sgml Hunk #1 succeeded at 8642 (offset 16 lines). patching file src/backend/uti

Re: [HACKERS] Parsing of aggregate ORDER BY clauses

Daniel Grace writes: > One possible concern might be typecasts that aren't a 1:1 > representation. While no two VARCHARs are going to produce the same > TEXT, this is not true in other cases (1.1::float::integer and > 1.2::float::integer both produce 1, for instance). > Off the top of my head, I

Re: [HACKERS] Toward a column reorder solution

Nilson Damasceno wrote: The Tom's message was in Dec/2006. We are in 2010. So what? The problem hasn't changed. Sincerelly, I'm not afraid to seem naive, but I believe that a column that inherits the persistent semantics of attnum solves the 99.9% problem with column reordering of legac

Re: [HACKERS] do we need to postpone beta4?

On Tue, Jul 27, 2010 at 6:42 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jul 27, 2010 at 4:48 PM, Robert Haas wrote: >>> On Tue, Jul 27, 2010 at 4:09 PM, Tom Lane wrote: Yup, that's what I think.  In fact I think September might be optimistic.  This is what happens when you f

Re: [HACKERS] do we need to postpone beta4?

Robert Haas writes: > On Tue, Jul 27, 2010 at 4:48 PM, Robert Haas wrote: >> On Tue, Jul 27, 2010 at 4:09 PM, Tom Lane wrote: >>> Yup, that's what I think.  In fact I think September might be >>> optimistic.  This is what happens when you fork early and allow >>> developers to start focusing on

Re: [HACKERS] page corruption on 8.3+ that makes it to standby

On Tue, 2010-07-27 at 17:18 -0400, Robert Haas wrote: > > My first concern with that idea was that it may create an inconsistency > > between the primary and the standby. The primary could have a bunch of > > zero pages that never make it to the standby. > > Maybe I'm slow on the uptake here, but

Re: [HACKERS] PostGIS vs. PGXS in 9.0beta3

Josh Berkus writes: > A 9.0b3 tester reported this issue with our single most popular > PostgreSQL extension, PostGIS: > == > Postgis makes use of 'PGXS' in postgresql > 8.2. Within postgresql-9, > datadir and many other variables are defined as multiple values with an > append

Re: [HACKERS] Toward a column reorder solution

Andrew, The Tom's message was in Dec/2006. We are in 2010. Sincerelly, I'm not afraid to seem naive, but I believe that a column that inherits the persistent semantics of attnum solves the 99.9% problem with column reordering of legacy software. The exceptions seems to be: 1) software that addr

Re: [HACKERS] Toward a column reorder solution

On Tue, 2010-07-27 at 17:56 -0400, Andrew Dunstan wrote: > > Robert Haas wrote: > >> Please review the previous discussions on this. In particular, see this > >> proposal from Tom Lane that I believe represents the consensus way we want > >> to go on this: > >>

Re: [HACKERS] Toward a column reorder solution

Robert Haas wrote: Please review the previous discussions on this. In particular, see this proposal from Tom Lane that I believe represents the consensus way we want to go on this: Alvaro is planning to work on this for

Re: [HACKERS] Toward a column reorder solution

On Tue, Jul 27, 2010 at 5:45 PM, Andrew Dunstan wrote: > > > Nilson wrote: >> >> Quoting  "wiki.postgresql.org/wiki/Alter_column_position >> " : >> >> "The idea of allowing re-ordering of column position is not one the >> postgresql developers

Re: [HACKERS] do we need to postpone beta4?

On Tue, Jul 27, 2010 at 4:48 PM, Robert Haas wrote: > On Tue, Jul 27, 2010 at 4:09 PM, Tom Lane wrote: >> Robert Haas writes: >>> Well, that's pretty much saying we won't release before September. >> >> Yup, that's what I think.  In fact I think September might be >> optimistic.  This is what ha

Re: [HACKERS] Toward a column reorder solution

Nilson wrote: Quoting "wiki.postgresql.org/wiki/Alter_column_position " : "The idea of allowing re-ordering of column position is not one the postgresql developers are against, it is more a case where no one has stepped forward to do t

[HACKERS] Toward a column reorder solution

Quoting "wiki.postgresql.org/wiki/Alter_column_position" : "The idea of allowing re-ordering of column position is not one the postgresql developers are against, it is more a case where no one has stepped forward to do the work." Well, a ha

Re: [HACKERS] page corruption on 8.3+ that makes it to standby

On Tue, Jul 27, 2010 at 5:08 PM, Jeff Davis wrote: > On Tue, 2010-07-27 at 15:50 -0400, Robert Haas wrote: >> > 1. Have log_newpage() and heap_xlog_newpage() only call PageSetLSN() and >> > PageSetTLI() if the page is not new. This seems slightly awkward because >> > most WAL replay stuff doesn't

Re: [HACKERS] page corruption on 8.3+ that makes it to standby

On Tue, 2010-07-27 at 15:50 -0400, Robert Haas wrote: > > 1. Have log_newpage() and heap_xlog_newpage() only call PageSetLSN() and > > PageSetTLI() if the page is not new. This seems slightly awkward because > > most WAL replay stuff doesn't have to worry about zero pages, but in > > this case I th

Re: [HACKERS] do we need to postpone beta4?

On Tue, Jul 27, 2010 at 4:09 PM, Tom Lane wrote: > Robert Haas writes: >> Well, that's pretty much saying we won't release before September. > > Yup, that's what I think.  In fact I think September might be > optimistic.  This is what happens when you fork early and allow > developers to start fo

Re: [HACKERS] Copy path in Dynamic programming

Robert Haas writes: > On Thu, Jul 22, 2010 at 12:38 PM, vamsi krishna > wrote: >> if lev=5 , and let's say there are two combinations setA = {1,2,3,4,5} and >> set B={6,7,8,9,10}. >> >> I want to reuse the plan of {1.2,3,4,5} for {6,7,8,9,10}. > I don't think that makes any sense. Yeah. The t

Re: [HACKERS] do we need to postpone beta4?

Robert Haas writes: > Well, that's pretty much saying we won't release before September. Yup, that's what I think. In fact I think September might be optimistic. This is what happens when you fork early and allow developers to start focusing on new development instead of testing the release bra

Re: [HACKERS] do we need to postpone beta4?

On Tue, Jul 27, 2010 at 3:53 PM, Bruce Momjian wrote: >> Well, that's pretty much saying we won't release before September. >> Which is kind of a bummer, but I guess that's what happens when we get >> into vacation season. > > Yeah, if we are lucky we can do RC1 in mid-August and still release > f

Re: [HACKERS] patch (for 9.1) string functions

2010/7/26 Robert Haas : > On Mon, Jul 26, 2010 at 2:09 PM, Pavel Stehule > wrote: >> I understand, but with only text accepting, then CONCAT will has much >> less benefit - you can't do a numeric list, for example >> >> see concat(c1::text, ',', c2::text, ',' ...) >> >> with this is much simpler

Re: [HACKERS] patch (for 9.1) string functions

On Mon, Jul 26, 2010 at 3:49 PM, Merlin Moncure wrote: > concat() is not a variadic text function. it is variadic "any" that > happens to do text coercion (not casting) inside the function. The > the assumption that concat is casting internally is probably wrong. > Suppose I had hacked the int->te

Re: [HACKERS] patch (for 9.1) string functions

On Mon, Jul 26, 2010 at 2:09 PM, Pavel Stehule wrote: > I understand, but with only text accepting, then CONCAT will has much > less benefit - you can't do a numeric list, for example > > see concat(c1::text, ',', c2::text, ',' ...) > > with this is much simpler use a pipes '' || c1 || ',' || c2 .

Re: [HACKERS] patch (for 9.1) string functions

On Mon, Jul 26, 2010 at 3:07 PM, Robert Haas wrote: > On Mon, Jul 26, 2010 at 2:09 PM, Pavel Stehule > wrote: >> I understand, but with only text accepting, then CONCAT will has much >> less benefit - you can't do a numeric list, for example >> >> see concat(c1::text, ',', c2::text, ',' ...) >>

Re: [HACKERS] patch (for 9.1) string functions

2010/7/26 Robert Haas : > On Mon, Jul 26, 2010 at 11:39 AM, Merlin Moncure wrote: >>> I'm just very skeptical that we should give our functions argument >>> types that are essentially fantasy.  CONCAT() doesn't concatenate >>> integers or intervals or boxes: it concatenates strings, and only >>> s

Re: [HACKERS] patch (for 9.1) string functions

On Mon, Jul 26, 2010 at 11:39 AM, Merlin Moncure wrote: >> I'm just very skeptical that we should give our functions argument >> types that are essentially fantasy.  CONCAT() doesn't concatenate >> integers or intervals or boxes: it concatenates strings, and only >> strings.  Surely the right fix,

Re: [HACKERS] patch (for 9.1) string functions

> > so "any" datatype is last possibility - is workaroud for custom functions. Probably the most correct implementation of CONCAT have to contains a parser changes - and then you can use a some internal concat function with text only parameters. VARIADIC with "any" is just workaround that is enouh

Re: [HACKERS] patch (for 9.1) string functions

2010/7/26 Robert Haas : > On Mon, Jul 26, 2010 at 10:39 AM, Merlin Moncure wrote: >> On Mon, Jul 26, 2010 at 9:26 AM, Robert Haas wrote: >>> On Mon, Jul 26, 2010 at 9:10 AM, Merlin Moncure wrote: > CONCAT('foo', NULL) => 'foo' really the behavior that everyone else > implements here?  An

[HACKERS] Improper usage of MemoryContext in nodeSubplan.c for buildSubPlanHash() function. This maybe causes allocate memory failed.

Hi all, This is a potential memory error in nodeSubplan.c or execGrouping.c Using select '1'::TEXT IN ((SELECT '1'::NAME) UNION ALL SELECT '1'::NAME); to reproduce this bug. You may see the memory content that slot1's tts_values[0] point to before and after the statement : MemoryContextReset(ev

Re: [HACKERS] multibyte charater set in levenshtein function

Here is new version of my patch. There are following changes: 1) I've merged singlebyte and multibyte versions of levenshtein_internal and levenshtein_less_equal_internal using macros and includes. 2) I found that levenshtein takes reasonable time even for long strings. There is an example with st

Re: [HACKERS] do we need to postpone beta4?

Robert Haas wrote: > On Tue, Jul 27, 2010 at 2:11 PM, Tom Lane wrote: > > Robert Haas writes: > >> I think we should consider postponing beta4. ?I count eleven > >> non-documentation, 9.0-specific bug fix on REL9_0_STABLE, but there > >> are currently five items on the open 9.0 issues list, at le

Re: [HACKERS] page corruption on 8.3+ that makes it to standby

On Tue, Jul 27, 2010 at 2:06 PM, Jeff Davis wrote: > I reported a problem here: > > http://archives.postgresql.org/pgsql-bugs/2010-07/msg00173.php > > Perhaps I used a poor subject line, but I believe it's a serious issue. > That reproducible sequence seems like an obvious bug to me on 8.3+, and >

Re: [HACKERS] Preliminary review of Synchronous Replication patches

Kevin Grittner wrote: Unless there are objections, I will mark the patch by Zoltán Böszörményi as Returned with Feedback in a couple days, and ask that everyone interested in this feature focus on advancing the patch by Fujii Masao. Given the scope and importance of this area, I think we could b

Re: [HACKERS] Preliminary review of Synchronous Replication patches

Kevin Grittner wrote: Unless there are objections, I will mark the patch by Zoltán Böszörményi as Returned with Feedback in a couple days, and ask that everyone interested in this feature focus on advancing the patch by Fujii Masao. Given the scope and importance of this area, I think we could b

Re: [HACKERS] ALTER TABLE ... DISABLE TRIGGER vs. AccessExclusiveLock

On Tue, Jul 27, 2010 at 3:07 PM, James Robinson wrote: > Experience and a read through backend/commands/tablecmds.c's AlterTable() > indicate that ALTER TABLE ... DISABLE TRIGGER obtains an exclusive lock on > the table (as does any ALTER TABLE). > > Blocking other readers from a table when we've,

Re: [HACKERS] do we need to postpone beta4?

On Tue, Jul 27, 2010 at 2:11 PM, Tom Lane wrote: > Robert Haas writes: >> I think we should consider postponing beta4.  I count eleven >> non-documentation, 9.0-specific bug fix on REL9_0_STABLE, but there >> are currently five items on the open 9.0 issues list, at least one of >> which appears t

[HACKERS] ALTER TABLE ... DISABLE TRIGGER vs. AccessExclusiveLock

Hackers, Experience and a read through backend/commands/tablecmds.c's AlterTable() indicate that ALTER TABLE ... DISABLE TRIGGER obtains an exclusive lock on the table (as does any ALTER TABLE). Blocking other readers from a table when we've, within the body of a transaction performing a

Re: [HACKERS] git config user.email

Robert Haas writes: > On Thu, Jul 22, 2010 at 5:41 AM, Magnus Hagander wrote: >> *Personally*, I'd prefer to keep using my main email address for >> commits. > As for me, I'd much prefer to be rh...@postgresql.org than > robertmh...@gmail.com. "Prefer" is exactly the key word here. I see no re

Re: [HACKERS] PostGIS vs. PGXS in 9.0beta3

Robert Haas wrote: On Tue, Jul 27, 2010 at 1:13 PM, Josh Berkus wrote: http://postgis.refractions.net/pipermail/postgis-users/2010-May/026654.html It's not obvious that there's an unresolved issue here; downthread there's some indication this might be an environment problem? http:/

Re: [HACKERS] do we need to postpone beta4?

On Tue, 2010-07-27 at 14:11 -0400, Tom Lane wrote: > Robert Haas writes: > > I think we should consider postponing beta4. I count eleven > > non-documentation, 9.0-specific bug fix on REL9_0_STABLE, but there > > are currently five items on the open 9.0 issues list, at least one of > > which appe

[HACKERS] page corruption on 8.3+ that makes it to standby

I reported a problem here: http://archives.postgresql.org/pgsql-bugs/2010-07/msg00173.php Perhaps I used a poor subject line, but I believe it's a serious issue. That reproducible sequence seems like an obvious bug to me on 8.3+, and what's worse, the corruption propagates to the standby as I fou

Re: [HACKERS] do we need to postpone beta4?

Robert Haas writes: > I think we should consider postponing beta4. I count eleven > non-documentation, 9.0-specific bug fix on REL9_0_STABLE, but there > are currently five items on the open 9.0 issues list, at least one of > which appears to be a new bug in 9.0, and we just got a bug report on >

[HACKERS] do we need to postpone beta4?

I think we should consider postponing beta4. I count eleven non-documentation, 9.0-specific bug fix on REL9_0_STABLE, but there are currently five items on the open 9.0 issues list, at least one of which appears to be a new bug in 9.0, and we just got a bug report on pgsql-bugs from Valentine Gogi

Re: [HACKERS] PostGIS vs. PGXS in 9.0beta3

On Tue, Jul 27, 2010 at 1:13 PM, Josh Berkus wrote: > http://postgis.refractions.net/pipermail/postgis-users/2010-May/026654.html It's not obvious that there's an unresolved issue here; downthread there's some indication this might be an environment problem? http://postgis.refractions.net/piperm

Re: [HACKERS] Query optimization problem

Robert Haas writes: > On Tue, Jul 20, 2010 at 11:23 AM, Dimitri Fontaine > wrote: >> The specific diff between the two queries is : >> >> JOIN DocPrimary d2 ON d2.BasedOn=d1.ID >> - WHERE (d1.ID=234409763) or (d2.ID=234409763) >> + WHERE (d2.BasedOn=234409763) or (d2.ID=234409763) >> >> So th

[HACKERS] PostGIS vs. PGXS in 9.0beta3

Hackers, A 9.0b3 tester reported this issue with our single most popular PostgreSQL extension, PostGIS: == Postgis makes use of 'PGXS' in postgresql > 8.2. Within postgresql-9, datadir and many other variables are defined as multiple values with an append operator, like this:

Re: [HACKERS] merge command - GSoC progress

On Tue, Jul 27, 2010 at 1:04 AM, Boxuan Zhai wrote: > I have get a edition that the merge command can run. It accept the standard > merge command and can do UPDATE, INSERT and DELETE actions now. But we > cannot put additional qualification for actions. There are some bugs when we > try to evaluat

Re: [HACKERS] Synchronous replication

Le 27 juil. 2010 à 15:12, Joshua Tolley a écrit : > My concern is that in a quorum system, if the quorum number is less than the > total number of replicas, there's no way to know *which* replicas composed the > quorum for any given transaction, so we can't know which servers to fail to if > the m

Re: [HACKERS] [COMMITTERS] pgsql: Add restart_after_crash GUC.

On Tue, Jul 27, 2010 at 2:33 AM, Fujii Masao wrote: > On Tue, Jul 20, 2010 at 9:47 AM, Robert Haas wrote: >> Log Message: >> --- >> Add restart_after_crash GUC. > > In postgresql.conf.sample, on/off is used as a boolean value. > But true/false is used for exit_on_error and restart_after_c

Re: [HACKERS] Synchronous replication

On Tue, Jul 27, 2010 at 10:53:45PM +0900, Fujii Masao wrote: > On Tue, Jul 27, 2010 at 10:12 PM, Joshua Tolley wrote: > > My concern is that in a quorum system, if the quorum number is less than the > > total number of replicas, there's no way to know *which* replicas composed > > the > > quorum

Re: [HACKERS] Synchronous replication

On Tue, Jul 27, 2010 at 10:12 PM, Joshua Tolley wrote: > I don't think it can support the case you're interested in, though I'm not > terribly expert on it. I'm definitely not arguing for the syntax Oracle uses, > or something similar; I much prefer the flexibility we're proposing, and agree > wit

Re: [HACKERS] Synchronous replication

On Tue, Jul 27, 2010 at 8:48 PM, Yeb Havinga wrote: > Is there a reason not to send the signal in XlogFlush itself, so it would be > called at > > CreateCheckPoint(), EndPrepare(), FlushBuffer(), > RecordTransactionAbortPrepared(), RecordTransactionCommit(), > RecordTransactionCommitPrepared(), Re

Re: [HACKERS] Synchronous replication

On Tue, Jul 27, 2010 at 01:41:10PM +0900, Fujii Masao wrote: > On Tue, Jul 27, 2010 at 12:36 PM, Joshua Tolley wrote: > > Perhaps I'm hijacking the wrong thread for this, but I wonder if the quorum > > idea is really the best thing for us. I've been thinking about Oracle's way > > of > > doing th

Re: [HACKERS] Synchronous replication

Fujii Masao wrote: I noted the changes in XlogSend where instead of *caughtup = true/false it now returns !MyWalSnd->sndrqst. That value is initialized to false in that procedure and it cannot be changed to true during execution of that procedure, or can it? That value is set to true in Wa

Re: [HACKERS] Synchronous replication

On Tue, Jul 27, 2010 at 5:42 PM, Yeb Havinga wrote: > I'd like to bring forward another suggestion (please tell me when it is > becoming spam). My feeling about replication_mode as is, is that is says in > the same parameter something about async or sync, as well as, if sync, which > method of fee

Re: [HACKERS] Synchronous replication

On Tue, Jul 27, 2010 at 7:39 PM, Yeb Havinga wrote: > Fujii Masao wrote: >> >> The attached patch changes the backend so that it signals walsender to >> wake up from the sleep and send WAL immediately. It doesn't include any >> other synchronous replication stuff. >> > > Hello Fujii, Thanks for t

Re: [HACKERS] Synchronous replication

Fujii Masao wrote: The attached patch changes the backend so that it signals walsender to wake up from the sleep and send WAL immediately. It doesn't include any other synchronous replication stuff. Hello Fujii, I noted the changes in XlogSend where instead of *caughtup = true/false it now

Re: [HACKERS] Synchronous replication

Joshua Tolley wrote: Perhaps I'm hijacking the wrong thread for this, but I wonder if the quorum idea is really the best thing for us. For reference: it appeared in a long thread a while ago http://archives.postgresql.org/pgsql-hackers/2010-05/msg01226.php. In short, there are three different m

Re: [HACKERS] Synchronous replication

Fujii Masao wrote: On Mon, Jul 26, 2010 at 8:25 PM, Robert Haas wrote: On Mon, Jul 26, 2010 at 6:48 AM, Marko Tiikkaja wrote: On 7/26/10 1:44 PM +0300, Fujii Masao wrote: On Mon, Jul 26, 2010 at 6:36 PM, Yeb Havinga wrote: I wasn't entirely clear. My suggestion was