On Tue, Jul 20, 2010 at 9:47 AM, Robert Haas rh...@postgresql.org 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_crash.
Sorry, I had overlooked that
Fujii Masao wrote:
On Mon, Jul 26, 2010 at 8:25 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 26, 2010 at 6:48 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 7/26/10 1:44 PM +0300, Fujii Masao wrote:
On Mon, Jul 26, 2010 at 6:36 PM, Yeb
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
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
On Tue, Jul 27, 2010 at 7:39 PM, Yeb Havinga yebhavi...@gmail.com 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,
On Tue, Jul 27, 2010 at 5:42 PM, Yeb Havinga yebhavi...@gmail.com 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,
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
On Tue, Jul 27, 2010 at 01:41:10PM +0900, Fujii Masao wrote:
On Tue, Jul 27, 2010 at 12:36 PM, Joshua Tolley eggyk...@gmail.com 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
On Tue, Jul 27, 2010 at 8:48 PM, Yeb Havinga yebhavi...@gmail.com wrote:
Is there a reason not to send the signal in XlogFlush itself, so it would be
called at
CreateCheckPoint(), EndPrepare(), FlushBuffer(),
RecordTransactionAbortPrepared(), RecordTransactionCommit(),
On Tue, Jul 27, 2010 at 10:12 PM, Joshua Tolley eggyk...@gmail.com 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,
On Tue, Jul 27, 2010 at 10:53:45PM +0900, Fujii Masao wrote:
On Tue, Jul 27, 2010 at 10:12 PM, Joshua Tolley eggyk...@gmail.com 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
On Tue, Jul 27, 2010 at 2:33 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Jul 20, 2010 at 9:47 AM, Robert Haas rh...@postgresql.org 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
Le 27 juil. 2010 à 15:12, Joshua Tolley eggyk...@gmail.com 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
On Tue, Jul 27, 2010 at 1:04 AM, Boxuan Zhai bxzhai2...@gmail.com 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
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:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 20, 2010 at 11:23 AM, Dimitri Fontaine
dfonta...@hi-media.com 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)
On Tue, Jul 27, 2010 at 1:13 PM, Josh Berkus j...@agliodbs.com 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?
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
Robert Haas robertmh...@gmail.com 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
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
On Tue, 2010-07-27 at 14:11 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas wrote:
On Tue, Jul 27, 2010 at 1:13 PM, Josh Berkus j...@agliodbs.com 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
Robert Haas robertmh...@gmail.com writes:
On Thu, Jul 22, 2010 at 5:41 AM, Magnus Hagander mag...@hagander.net 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
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
On Tue, Jul 27, 2010 at 2:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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,
On Tue, Jul 27, 2010 at 3:07 PM, James Robinson
jlrob...@socialserve.com 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
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
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
On Tue, Jul 27, 2010 at 2:06 PM, Jeff Davis pg...@j-davis.com 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
Robert Haas wrote:
On Tue, Jul 27, 2010 at 2:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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
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 :
2010/7/26 Robert Haas robertmh...@gmail.com:
On Mon, Jul 26, 2010 at 10:39 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Mon, Jul 26, 2010 at 9:26 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 26, 2010 at 9:10 AM, Merlin Moncure mmonc...@gmail.com wrote:
CONCAT('foo', NULL) =
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 enouhg
On Mon, Jul 26, 2010 at 11:39 AM, Merlin Moncure mmonc...@gmail.com 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
2010/7/26 Robert Haas robertmh...@gmail.com:
On Mon, Jul 26, 2010 at 11:39 AM, Merlin Moncure mmonc...@gmail.com 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
On Mon, Jul 26, 2010 at 3:07 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 26, 2010 at 2:09 PM, Pavel Stehule pavel.steh...@gmail.com
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
On Mon, Jul 26, 2010 at 2:09 PM, Pavel Stehule pavel.steh...@gmail.com 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 '' ||
On Mon, Jul 26, 2010 at 3:49 PM, Merlin Moncure mmonc...@gmail.com 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
2010/7/26 Robert Haas robertmh...@gmail.com:
On Mon, Jul 26, 2010 at 2:09 PM, Pavel Stehule pavel.steh...@gmail.com
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, ','
On Tue, Jul 27, 2010 at 3:53 PM, Bruce Momjian br...@momjian.us 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
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Thu, Jul 22, 2010 at 12:38 PM, vamsi krishna
vamsikrishna1...@gmail.com 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
On Tue, Jul 27, 2010 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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 think it
On Tue, Jul 27, 2010 at 5:08 PM, Jeff Davis pg...@j-davis.com 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
Quoting
wiki.postgresql.org/wiki/Alter_column_positionhttp://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 hard
Nilson wrote:
Quoting wiki.postgresql.org/wiki/Alter_column_position
http://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
On Tue, Jul 27, 2010 at 4:48 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 27, 2010 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Well, that's pretty much saying we won't release before September.
Yup, that's what I think. In fact I think
On Tue, Jul 27, 2010 at 5:45 PM, Andrew Dunstan and...@dunslane.net wrote:
Nilson wrote:
Quoting wiki.postgresql.org/wiki/Alter_column_position
http://wiki.postgresql.org/wiki/Alter_column_position :
The idea of allowing re-ordering of column position is not one the
postgresql developers
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:
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00983.php
Alvaro is planning to work on this for
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:
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
Josh Berkus j...@agliodbs.com 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
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 don't
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 27, 2010 at 4:48 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 27, 2010 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yup, that's what I think. In fact I think September might be
optimistic. This is what happens when you fork
On Tue, Jul 27, 2010 at 6:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 27, 2010 at 4:48 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 27, 2010 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yup, that's what I think. In fact I think
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
Daniel Grace dgr...@wingsnw.com 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
== 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
On Tue, Jul 27, 2010 at 7:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Grace dgr...@wingsnw.com 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
On Tue, Jul 27, 2010 at 7:33 PM, David Fetter da...@fetter.org 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() =
On Tue, Jul 27, 2010 at 12:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jul 26, 2010 at 9:57 AM, Dave Page dp...@pgadmin.org wrote:
On Mon, Jul 26, 2010 at 2:49 PM, Robert Haas robertmh...@gmail.com wrote:
Any objections to me committing this?
Robert Haas robertmh...@gmail.com 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
On Tue, 2010-07-27 at 19:41 -0400, Robert Haas wrote:
On Tue, Jul 27, 2010 at 7:33 PM, David Fetter da...@fetter.org wrote:
Minor quibble with the regression tests: should we be using
dollar quotes in things like this? Doubled-up quote marks:
SELECT
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
Tao Ma feng_e...@163.com 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()
On Fri, Jul 16, 2010 at 4:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina drfar...@acm.org 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
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 to the
Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
I wrote:
Tao Ma feng_e...@163.com 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
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 shouldn't be
72 matches
Mail list logo
