Jeff Davis wrote:
On Sun, 2011-06-26 at 00:57 -0700, Darren Duncan wrote:
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
generic order-sensitive operation, including any ranges defined
On 27 June 2011 03:31, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jun 25, 2011 at 2:15 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
Really? I would expect the reverse, namely that the not-nullness is
part of the PK constraint and dropping the PK *would* then start
allowing NULLs.
On Fri, Jun 24, 2011 at 16:37, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Heikki Linnakangas's message of vie jun 24 07:01:57 -0400 2011:
While reviewing Peter Geoghegan's postmaster death patch, I noticed that
if you turn on silent_mode, the LINUX_OOM_ADJ code in
On Fri, Jun 17, 2011 at 8:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Department of second thoughts: I think I see a problem.
Um, yeah, so that doesn't really work any better than my idea.
On further reflection, there's a problem at a higher level than
On Mon, Jun 27, 2011 at 12:45:02AM +0200, Florian Pflug wrote:
Updated patch attached. Do you think this is Ready for Committer?
Thanks. Yes; I have just marked it that way.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Fri, Jun 17, 2011 at 6:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jun 16, 2011 at 6:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I believe that this is fundamentally unavoidable so long as we use
SnapshotNow to read catalogs --- which is
On 27.06.2011 10:23, Magnus Hagander wrote:
On Fri, Jun 24, 2011 at 16:37, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Heikki Linnakangas's message of vie jun 24 07:01:57 -0400 2011:
While reviewing Peter Geoghegan's postmaster death patch, I noticed that
if you turn on
Hi Heikki,
On Mon, 27 Jun 2011 at 12:10, Heikki Linnakangas wrote:
Max, you're the maintainer of the PostgreSQL SuSE RPMs, right?
my first name is Reinhard, but aside from that, you are right. ;)
Can you comment on the above?
I enabled it many years ago when (IIRC) it was needed in
On Jun27, 2011, at 02:48 , Jeff Davis wrote:
On Mon, 2011-06-27 at 00:56 +0200, Florian Pflug wrote:
Well, there actually *is* some precedence for that kind of top-down
(form a syntactic perspective) type inference. We *enforce* the cast
in
array[]::arraytype
and actually for a very
On Jun27, 2011, at 03:12 , Jeff Davis wrote:
But I think you're right, it shouldn't be the responsibility of range
types. Perhaps I should leave length() as some inlinable SQL functions
like I mentioned, or perhaps I should remove them completely.
Does the current definition of length(range),
I've added information about testing on some real-life dataset to wiki page.
This dataset have a speciality: data is ordered inside it. In this case
tradeoff was inverse in comparison with expectations about fast build
algrorithm. Index built is longer but index quality is significantly better.
I
On 27.06.2011 13:45, Alexander Korotkov wrote:
I've added information about testing on some real-life dataset to wiki page.
This dataset have a speciality: data is ordered inside it. In this case
tradeoff was inverse in comparison with expectations about fast build
algrorithm. Index built is
On Fri, Jun 24, 2011 at 5:14 PM, Steve Singer ssinger...@sympatico.ca wrote:
A few things I noticed (that you might be aware of since you mentioned it
needs cleanup)
-The patch doesn't compile with non-ssl builds, the debug at the bottom of
PQSendSome isn't in an #ifdef
-I don't think your
On Sat, Jun 25, 2011 at 6:24 AM, Jeff Davis pg...@j-davis.com wrote:
On Fri, 2011-06-24 at 15:32 -0400, Robert Haas wrote:
On Sun, Jun 19, 2011 at 2:16 PM, Robert Haas robertmh...@gmail.com wrote:
New patch attached, with that one-line change.
Jeff, are you planning to review this further?
On 27.06.2011 13:45, Alexander Korotkov wrote:
I've added information about testing on some real-life dataset to wiki page.
This dataset have a speciality: data is ordered inside it. In this case
tradeoff was inverse in comparison with expectations about fast build
algrorithm. Index built is
On Mon, Jun 27, 2011 at 3:08 AM, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 27 June 2011 03:31, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jun 25, 2011 at 2:15 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
Really? I would expect the reverse, namely that the not-nullness is
part
On Fri, Jun 24, 2011 at 6:07 PM, Christian Ullrich ch...@chrullrich.net wrote:
When Magnus fixed and applied my SSPI-via-GSS patch in January, we forgot to
fix to the documentation. Suggested patch attached; should I also put that
four-liner into any CFs?
I have committed a slightly different
On Sat, Jun 25, 2011 at 8:26 PM, Greg Stark st...@mit.edu wrote:
On Thu, Jun 23, 2011 at 4:42 PM, Robert Haas robertmh...@gmail.com wrote:
ProcArrayLock looks like a tougher nut to crack - there's simply no
way, with the system we have right now, that you can take a snapshot
without locking
On Mon, Jun 27, 2011 at 11:49 AM, Jonathan Corbet cor...@lwn.net wrote:
On Fri, 24 Jun 2011 13:42:04 -0400
Robert Haas robertmh...@gmail.com wrote:
As for annotating the commit messages, I think something like:
Reporter: Sam Jones
Author: Beverly Smith
Author: Jim Davids
Reviewer: Fred
On Sat, Jun 25, 2011 at 9:01 PM, Greg Stark st...@mit.edu wrote:
I think this commit was ill-advised:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=a03feb9354bda5084f19cc952bc52ba7be89f372
In a concurrent index build, the index is actually entered into the
system
On Sun, Jun 26, 2011 at 10:33 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of vie jun 24 22:22:55 -0400 2011:
On Fri, Jun 24, 2011 at 7:47 PM, Bruce Momjian br...@momjian.us wrote:
You want the environment variable support removed?
I don't. It's
On Fri, 24 Jun 2011 13:42:04 -0400
Robert Haas robertmh...@gmail.com wrote:
As for annotating the commit messages, I think something like:
Reporter: Sam Jones
Author: Beverly Smith
Author: Jim Davids
Reviewer: Fred Block
Reviewer: Pauline Andrews
Can I just toss in one little note from
* Robert Haas wrote:
On Fri, Jun 24, 2011 at 6:07 PM, Christian Ullrichch...@chrullrich.net wrote:
When Magnus fixed and applied my SSPI-via-GSS patch in January, we forgot to
fix to the documentation. Suggested patch attached; should I also put that
four-liner into any CFs?
I have
On Mon, 2011-06-27 at 12:25 +0200, Florian Pflug wrote:
Does the current definition of length(range), i.e.
upper(range) - lower(range)
deal correctly with open vs. closed ranges and unbounded ranges? I'm thinking
that it probably doesn't - what would be the results of
We have a couple of open items outstanding right now, but I'm
wondering if it's about time we should be thinking about a date for
beta3.
We tagged beta1 on April 27th, and beta2 on June 9th, so about six weeks apart.
But perhaps we shouldn't wait quite so long before putting out beta3?
--
On Mon, 2011-06-27 at 12:16 +0200, Florian Pflug wrote:
I wouldn't take it that far. What I had in mind was to *only* support
the case where the cast directly follows the function call, i.e. the case
f(...)::type
OK, so instead of writing:
On Sun, 2011-06-26 at 22:29 -0700, Darren Duncan wrote:
Tom Lane wrote:
Darren Duncan dar...@darrenduncan.net writes:
I believe that the best general solution here is for every ordered base
type to
just have a single total order, which is always used with that type in any
generic
On Wed, Jun 22, 2011 at 1:36 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 22, 2011 at 12:51 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié jun 22 08:56:02 -0400 2011:
Another option might be to leave heap_openrv() and
Robert Haas wrote:
On Sun, Jun 26, 2011 at 10:33 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of vie jun 24 22:22:55 -0400 2011:
On Fri, Jun 24, 2011 at 7:47 PM, Bruce Momjian br...@momjian.us wrote:
You want the environment variable support
On Mon, Jun 27, 2011 at 1:39 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Sun, Jun 26, 2011 at 10:33 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of vie jun 24 22:22:55 -0400 2011:
On Fri, Jun 24, 2011 at 7:47 PM, Bruce Momjian
\Robert Haas wrote:
On Mon, Jun 27, 2011 at 1:39 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Sun, Jun 26, 2011 at 10:33 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of vie jun 24 22:22:55 -0400 2011:
On Fri, Jun 24, 2011
Hackers,
I'm curious about behavior such as this:
bric=# select generate_series('2011-05-31'::timestamp ,
'2012-04-01'::timestamp, '1 month');
generate_series
-
2011-05-31 00:00:00
2011-06-30 00:00:00
2011-07-30 00:00:00
2011-08-30 00:00:00
2011-09-30 00:00:00
On 6/27/11 9:45 AM, Robert Haas wrote:
We have a couple of open items outstanding right now, but I'm
wondering if it's about time we should be thinking about a date for
beta3.
We tagged beta1 on April 27th, and beta2 on June 9th, so about six weeks
apart.
But perhaps we shouldn't wait
On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian br...@momjian.us wrote:
OK, fair enough. Should I apply my ports patch to Postgres 9.2?
I'm not sure which patch you are referring to.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
On Mon, Jun 27, 2011 at 1:51 PM, Josh Berkus j...@agliodbs.com wrote:
On 6/27/11 9:45 AM, Robert Haas wrote:
We have a couple of open items outstanding right now, but I'm
wondering if it's about time we should be thinking about a date for
beta3.
We tagged beta1 on April 27th, and beta2 on
On 06/27/2011 10:49 AM, David E. Wheeler wrote:
Hackers,
I'm curious about behavior such as this:
bric=# select generate_series('2011-05-31'::timestamp ,
'2012-04-01'::timestamp, '1 month');
generate_series
-
2011-05-31 00:00:00
2011-06-30 00:00:00
2011-07-30
On Jun 27, 2011, at 10:54 AM, Steve Crawford wrote:
That's just how intervals that represent varying periods of time work. You
would need to write your own. But a series of end-of-month dates is pretty
easy:
select generate_series('2011-06-01'::timestamp , '2012-04-01'::timestamp, '1
Robert Haas wrote:
On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian br...@momjian.us wrote:
OK, fair enough. ?Should I apply my ports patch to Postgres 9.2?
I'm not sure which patch you are referring to.
This one which makes 50432 the default port.
--
Bruce Momjian br...@momjian.us
On Thu, Jun 23, 2011 at 9:22 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 22, 2011 at 10:23 PM, Robert Haas robertmh...@gmail.com wrote:
Well, it seems I didn't put nearly enough thought into heap_update().
The fix for the immediate problem looks simple enough - all the code
has
David E. Wheeler da...@kineticode.com wrote:
generate_series
-
2011-05-31 00:00:00
2011-06-30 00:00:00
2011-07-31 00:00:00
2011-08-31 00:00:00
2011-09-30 00:00:00
2011-10-31 00:00:00
2011-11-30 00:00:00
2011-12-31 00:00:00
2012-01-31 00:00:00
On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian br...@momjian.us wrote:
OK, fair enough. ?Should I apply my ports patch to Postgres 9.2?
I'm not sure which patch you are referring to.
This one which
2011/6/27 Shigeru Hanada shigeru.han...@gmail.com:
* It might be an option to extend attreloptions, instead of the new
attfdwoptions.
Although I didn't track the discussion when pg_foreign_table catalog
that provides
relation level fdw-options, was it impossible or unreasonable to extend
On Jun 27, 2011, at 11:03 AM, Kevin Grittner wrote:
It is precisely to support such fancy things that some products
support a more abstract date type which allows 31 days in any month,
and then normalizes to real dates as needed. The PostgreSQL
developer community has generally not been
All,
So we're supposedly 1/3 of the way through CF1. Here's the good news:
- Almost all patches have reviewers assigned.
- 9 patches have been committed
- 8 more are ready for a committer
- 9 have been returned
This means that 1/4 of the patches have been dealt with and another 1/8
should be
Jeff Davis wrote:
On Sun, 2011-06-26 at 22:29 -0700, Darren Duncan wrote:
Tom Lane wrote:
Darren Duncan dar...@darrenduncan.net writes:
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
Robert Haas wrote:
On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian br...@momjian.us wrote:
OK, fair enough. ?Should I apply my ports patch to Postgres 9.2?
I'm not sure which patch you are
There are two outstanding patches for SSI which involve questions
about modularity. In particular, they involve calls to predicate
locking and conflict detection from executor source files rather
than AM source files (where most such calls exist).
(1) Dan submitted this patch:
On Mon, Jun 27, 2011 at 2:19 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian br...@momjian.us wrote:
OK, fair enough. ?Should I apply my
Robert Haas wrote:
On Mon, Jun 27, 2011 at 2:19 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian br...@momjian.us wrote:
OK, fair
On Mon, Jun 27, 2011 at 6:34 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The penalty function is called whenever a tuple is routed to the next level
down, and the final tree has the same depth with and without the patch, so I
would expect the number of penalty calls to
On Mon, Jun 27, 2011 at 2:27 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jun 27, 2011 at 2:19 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jun 27,
Bruce Momjian wrote:
Robert Haas wrote:
On Mon, Jun 27, 2011 at 2:19 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian
On Mon, Jun 27, 2011 at 2:34 PM, Bruce Momjian br...@momjian.us wrote:
Bruce Momjian wrote:
Robert Haas wrote:
On Mon, Jun 27, 2011 at 2:19 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas
On 06/27/2011 10:56 AM, David E. Wheeler wrote:
On Jun 27, 2011, at 10:54 AM, Steve Crawford wrote:
That's just how intervals that represent varying periods of time work. You
would need to write your own. But a series of end-of-month dates is pretty easy:
select
On Jun 27, 2011, at 11:36 AM, Steve Crawford wrote:
The query is marginally trickier. But the better calendaring apps give a
variety of options when selecting repeat: A user who selects June 30, 2011
and wants a monthly repeat might want:
30th of every month - skip months without a 30th
On Sat, Jun 25, 2011 at 6:29 PM, Jeff Davis pg...@j-davis.com wrote:
Different ranges over the same subtype make sense when using different
total orders for the subtype. This is most apparent with text collation,
but makes sense (at least mathematically, if not practically) for any
subtype.
On Mon, Jun 27, 2011 at 01:28:30PM -0400, Robert Haas wrote:
On Wed, Jun 22, 2011 at 1:36 PM, Robert Haas robertmh...@gmail.com wrote:
I agree with you. ?If we had a whole pile of options it might be worth
having heap_openrv() and heap_openrv_extended() so as not to
complicate the simple
On Mon, Jun 27, 2011 at 1:38 PM, David E. Wheeler da...@kineticode.comwrote:
Yeah, which is why I said it was subject to interpretation. Of course
there's no way to tell generate_series() which to use, which is what I
figured.
generate_series() is doing exactly what it was designed to do,
Yeah, which is why I said it was subject to interpretation. Of course there's
no way to tell generate_series() which to use, which is what I figured.
Fortunately PostgreSQL uses the same interpretation for '1 month' when
used in generate_series that it does everywhere else - to do otherwise
On Mon, Jun 27, 2011 at 1:49 PM, David E. Wheeler da...@kineticode.com wrote:
Hackers,
I'm curious about behavior such as this:
bric=# select generate_series('2011-05-31'::timestamp ,
'2012-04-01'::timestamp, '1 month');
generate_series
-
2011-05-31 00:00:00
On Mon, Jun 27, 2011 at 2:36 PM, Steve Crawford
scrawf...@pinpointresearch.com wrote:
On 06/27/2011 10:56 AM, David E. Wheeler wrote:
On Jun 27, 2011, at 10:54 AM, Steve Crawford wrote:
That's just how intervals that represent varying periods of time work.
You would need to write your own.
On Wed, Jun 15, 2011 at 1:03 AM, Noah Misch n...@leadboat.com wrote:
[patch to avoid index rebuilds]
With respect to the documentation hunks, it seems to me that the first
hunk might be made clearer by leaving the paragraph of which it is a
part as-is, and adding another paragraph afterwards
On Mon, Jun 27, 2011 at 2:59 PM, Noah Misch n...@leadboat.com wrote:
On Mon, Jun 27, 2011 at 01:28:30PM -0400, Robert Haas wrote:
On Wed, Jun 22, 2011 at 1:36 PM, Robert Haas robertmh...@gmail.com wrote:
I agree with you. ?If we had a whole pile of options it might be worth
having
On Jun 27, 2011, at 12:36 PM, Christopher Browne wrote:
I wrote something on this on pgsql-general about 5 years ago that
still seems pretty relevant.
http://archives.postgresql.org/pgsql-general/2006-02/msg00159.php
iwantsandy.com (now defunct) originally had a solution like this. However
The attached patch is rebased one towards the latest tree, using
relation_openrv_extended().
Although it is not a matter in this patch itself, I found a problem on
the upcoming patch
that consolidate routines associated with DropStmt.
Existing RemoveRelations() acquires a lock on the table owning
Hi guys,
I have added the '-n' option to pg_archivecleanup which performs a
dry-run and outputs the names of the files to be removed to stdout
(making possible to pass the list via pipe to another process). Please
find attached the small patch.
Thanks,
Gabriele
--
Gabriele Bartolini -
On mån, 2011-06-27 at 14:34 -0400, Bruce Momjian wrote:
Bruce Momjian wrote:
Robert Haas wrote:
It's easier to read the patches if you do separate changes in separate
patches. Anyway, I'm a bit nervous about this hunk:
+ if (old_cluster.port == DEF_PGUPORT)
+
Ive been holding off because its marked as Waiting on Author, am now
thinking thats a mistake. =)
It links to this patch:
http://archives.postgresql.org/message-id/20110215135131.gx4...@tamriel.snowman.net
Which is older than the latest patch in that thread posted by Robert:
On Fri, Jun 17, 2011 at 05:59:31AM -0700, David Fetter wrote:
On Fri, Jun 17, 2011 at 07:19:39PM +0900, Shigeru Hanada wrote:
Here's an example of a non-trivial mapping.
Database type:
MySQL
Foreign data type:
datetime
PostgreSQL data type:
timestamptz
On Mon, Jun 27, 2011 at 4:40 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The attached patch is rebased one towards the latest tree, using
relation_openrv_extended().
Committed.
Although it is not a matter in this patch itself, I found a problem on
the upcoming patch
that consolidate
On 18 June 2011 09:49, Brendan Jurd dire...@gmail.com wrote:
Hi Fabien,
I'm taking a look at this patch for the commitfest. On first reading
of the patch, it looked pretty sensible to me, but I had some trouble
applying it to HEAD:
error: patch failed: doc/src/sgml/ref/create_cast.sgml:20
On Mon, Jun 27, 2011 at 03:45:43PM -0400, Robert Haas wrote:
On Wed, Jun 15, 2011 at 1:03 AM, Noah Misch n...@leadboat.com wrote:
[patch to avoid index rebuilds]
With respect to the documentation hunks, it seems to me that the first
hunk might be made clearer by leaving the paragraph of
On Mon, 2011-06-27 at 14:50 -0400, Robert Haas wrote:
Couldn't we also do neither of these things? I mean, presumably
'[1,10]'::int8range had better work.
I think that if we combine this idea with Florian's PAIR suggestion
here:
Hi,
I've been tracing the data structure in the query plan process for a
while. But then I found the data structure manipulation is really so
confusing. Could some guy tell me where could I find any guide on how to
figure out the process and data structure usage? Is there any good resource
HuangQi huangq...@gmail.com writes:
Hi,
I've been tracing the data structure in the query plan process for a
while. But then I found the data structure manipulation is really so
confusing.
Could some guy tell me where could I find any guide on how to figure out the
process and data
Hello!~
Now i encounter a function call problem in PostgreSQL's psql module!
The situation is as follow:
In ./src/bin/psql/common.c, I want to call the function
pqCatenateResultError().
Function pqCatenateResultError() is declared in
Considering everything that has been discussed on this thread so far.
Do you still think your patch is the best way to accomplish base backups
from standby servers?
If not what changes do you think should be made?
I reconsider the way to not use pg_stop_backup().
Process of online base
77 matches
Mail list logo
