Michael Glaesemann writes:
> We came across a regexp that takes very much longer than expected.
I poked into this a little bit. What seems to be happening is that the
use of non-greedy quantifiers plus backreferences turns off most of the
optimization that the regexp engine usually does, leaving
On 01/29/2010 09:01 PM, Tom Lane wrote:
Maybe. We concluded in the April 2009 thread that
standard_conforming_strings = ON had gotten little or no field testing,
and I don't see any strong reason to hope that it's gotten much more
since then. It would be rather surprising if there *aren't* any
Hi there,
I made available test data I used on
http://www.sai.msu.su/~megera/wiki/2009-07-27,
so anyone can reproduce my results. You can download data
http://www.sai.msu.su/~megera/postgres/files/links2.sql.gz, it's big (580Mb)
Regards,
Oleg
__
On Sat, Jan 30, 2010 at 9:01 AM, Josh Berkus wrote:
> I don't think it's clear, or intuitive for users. In SR, recovery is
> *never* done, so smart shutdown never completes (even if the master is
> shut down, when I tested it).
If you specify the trigger_file parameter in the recovery.conf, the
On Mon, Jan 25, 2010 at 12:53, Tim Bunce wrote:
> - Added the 'warnings' pragma to the list of modules to load into Safe.
> So plperl functions can now "use warnings;" - added test for that.
*yay*
> - Added 'use 5.008001;' to plc_perlboot.pl as a run-time check to
> complement the configure-ti
Tim Bunce wrote:
This is an updated version of the third of the patches to be
split out from the former 'plperl feature patch 1'.
It includes changes following discussions with Tom Lane and others.
Changes in this patch:
- Added plperl.on_perl_init GUC for DBA use (PGC_SIGHUP)
SPI functio
> An actual plan here might look like "let's flip it before 9.1alpha1
> so we can get some alpha testing cycles on it" ...
"Hey, let's flip it in 9.1 CF 1, so that we can have some alpha testing
cycles on it."
;-)
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
=?ISO-8859-1?Q?C=E9dric_Villemain?= writes:
> 2010/1/29 Tom Lane :
>> We would have more than no-time-at-all to test it and fix any breakage.
>> Just to start close to home, do you really trust either psql or pg_dump
>> to be completely free of standard_conforming_strings issues? How about
>> JDB
2010/1/29 Tom Lane :
> Josh Berkus writes:
>>> I stand by the position that it's way too late in the cycle for
>>> insufficiently-thought-out proposals for major behavioral changes.
>
>> I don't see how announcing this earlier in the dev cycle would help, at
>> all.
>
> We would have more than no-
On Friday 29 January 2010 23:47:22 Bruce Momjian wrote:
> Andres Freund wrote:
> > On Friday 29 January 2010 23:34:09 Tom Lane wrote:
> > > Josh Berkus writes:
> > > >> I stand by the position that it's way too late in the cycle for
> > > >> insufficiently-thought-out proposals for major behaviora
On Fri, Jan 29, 2010 at 7:01 PM, Josh Berkus wrote:
>>> It's a good question if that still makes sense with Hot Standby.
>>> Perhaps we should redefine smart shutdown in standby mode to shut down
>>> as soon as all read-only connections have died.
>> It's clear that "smart" shutdown doesn't work w
>> It's a good question if that still makes sense with Hot Standby.
>> Perhaps we should redefine smart shutdown in standby mode to shut down
>> as soon as all read-only connections have died.
>
> It's clear that "smart" shutdown doesn't work while something is active.
> Recovery is "active" and
On Fri, Jan 29, 2010 at 5:44 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Well, since I asked in April of 2009, at the beginning of the cycle, 6
>> years after the introduction of the variable, and we still are not doing
>> it, then let's stop pretending we will ever do it.
>
> We have made for
> We would have more than no-time-at-all to test it and fix any breakage.
> Just to start close to home, do you really trust either psql or pg_dump
> to be completely free of standard_conforming_strings issues? How about
> JDBC or ODBC? Python drivers? PLs?
Oh, yeah. I was just thinking about
On Friday 29 January 2010 23:54:15 Tom Lane wrote:
> Andres Freund writes:
> > What about anouncing in the 9.0 releasenotes that it will be removed in
> > 9.1?
>
> That seems quite useless.
>
> I note that we've made such statements before and not followed through
> on them; one that just came u
Comments:
* In standard_ProcessUtility(), case NotifyStmt, you add a comment:
/* XXX the new listen/notify version can be enabled
* for Hot Standby */
but I don't think that's correct. We may be able to support LISTEN
on the standby, but not NOTIFY (right?). I don't think we should
On Thu, 2010-01-21 at 09:27 +0200, Heikki Linnakangas wrote:
> Right, that's the way a standby server (= one still in recovery) has
> always behaved. It has made sense in the past: it's not in the spirit
> of smart shutdown to kill the WAL replay immediately. "smart" means
> wait for recovery to f
Andres Freund writes:
> What about anouncing in the 9.0 releasenotes that it will be removed in 9.1?
That seems quite useless.
I note that we've made such statements before and not followed through
on them; one that just came up again is that contrib/xml2 is a couple
releases past when it was sa
Andres Freund wrote:
> On Friday 29 January 2010 23:34:09 Tom Lane wrote:
> > Josh Berkus writes:
> > >> I stand by the position that it's way too late in the cycle for
> > >> insufficiently-thought-out proposals for major behavioral changes.
> > >
> > > I don't see how announcing this earlier in
On Friday 29 January 2010 23:34:09 Tom Lane wrote:
> Josh Berkus writes:
> >> I stand by the position that it's way too late in the cycle for
> >> insufficiently-thought-out proposals for major behavioral changes.
> >
> > I don't see how announcing this earlier in the dev cycle would help, at
> >
Bruce Momjian writes:
> Well, since I asked in April of 2009, at the beginning of the cycle, 6
> years after the introduction of the variable, and we still are not doing
> it, then let's stop pretending we will ever do it.
We have made forward progress since that thread (we fixed the plpgsql
pars
Josh Berkus writes:
>> I stand by the position that it's way too late in the cycle for
>> insufficiently-thought-out proposals for major behavioral changes.
> I don't see how announcing this earlier in the dev cycle would help, at
> all.
We would have more than no-time-at-all to test it and fix
Andrew Dunstan wrote:
initializing dependencies ... WARNING: pgstat wait timeout
WARNING: pgstat wait timeout
ok
vacuuming database template1 ... WARNING: pgstat wait timeout
WARNING: pgstat wait timeout
ok
copying template1 to template0 ... WARNING: pgstat wait
Alex Hunsaker wrote:
> After skimming the thread Bruce linked:
> http://archives.postgresql.org/pgsql-hackers/2009-04/msg00512.php
>
> It certainly seems "insufficiently-thought-out". :(
Just as a clarification, while the GUC was *added* in 8.1, it was
read-only with a value of 'off'. I su
Alex Hunsaker wrote:
> On Fri, Jan 29, 2010 at 14:03, Tom Lane wrote:
> > Alex Hunsaker writes:
> >> On Fri, Jan 29, 2010 at 13:42, Tom Lane wrote:
> > I stand by the position that it's way too late in the cycle for
> > insufficiently-thought-out proposals for major behavioral changes.
>
> Afte
> I stand by the position that it's way too late in the cycle for
> insufficiently-thought-out proposals for major behavioral changes.
I don't see how announcing this earlier in the dev cycle would help, at
all. The people who read -hackers have been using
standards-conforming-strings for years.
On Fri, Jan 29, 2010 at 14:03, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Fri, Jan 29, 2010 at 13:42, Tom Lane wrote:
> I stand by the position that it's way too late in the cycle for
> insufficiently-thought-out proposals for major behavioral changes.
After skimming the thread Bruce linked:
Tom Lane wrote:
> Alex Hunsaker writes:
> > On Fri, Jan 29, 2010 at 13:42, Tom Lane wrote:
> >> [ still bearing scars from the 8.3 implicit-cast business, which we
> >> didn't think would generate nearly the backlash it did... ]
>
> > Yeah that was my first reaction. But then again we also have
Josh Berkus wrote:
>> I guess that the startup process and the walreceiver should wait
>> for all read only backends to exit in smart shutdown case. It's
>> because those backends might be waiting for the record that conflicts
>> with their queries to be replayed. Is this OK? Or we should kill the
Alex Hunsaker writes:
> On Fri, Jan 29, 2010 at 13:42, Tom Lane wrote:
>> [ still bearing scars from the 8.3 implicit-cast business, which we
>> didn't think would generate nearly the backlash it did... ]
> Yeah that was my first reaction. But then again we also have a guc
> they can change bac
Joshua D. Drake wrote:
> (4) The 8.3 issue wasn't nearly as bad as Tom is making it out to be.
> Yes, there was a lot of WTF going on, but only by people that aren't
> paying attention anyway and the work to fix it was pretty nominal.
The big mistake we made in 8.3 is not having those compatibilit
Tom Lane wrote:
> I wrote:
> > Bruce Momjian writes:
> >> With the release of Postgres 9.0, should we consider changing the
> >> default for 'standard_conforming_strings'?
>
> > I'm inclined to think we're going to have enough problems without that.
>
> BTW, core already had that discussion, but
On Fri, 2010-01-29 at 15:45 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > With the release of Postgres 9.0, should we consider changing the
> > > default for 'standard_conforming_strings'?
> >
> > I'm inclined to think we're going to have enough problems without th
In response to Bruce Momjian :
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > With the release of Postgres 9.0, should we consider changing the
> > > default for 'standard_conforming_strings'?
> >
> > I'm inclined to think we're going to have enough problems without that.
> > Changing that de
On Fri, Jan 29, 2010 at 3:28 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> With the release of Postgres 9.0, should we consider changing the
>> default for 'standard_conforming_strings'?
>
> I'm inclined to think we're going to have enough problems without that.
> Changing that default will brea
On Fri, Jan 29, 2010 at 13:42, Tom Lane wrote:
> I wrote:
>> Bruce Momjian writes:
>>> With the release of Postgres 9.0, should we consider changing the
>>> default for 'standard_conforming_strings'?
>
>> I'm inclined to think we're going to have enough problems without that.
> [ still bearing s
Tom Lane wrote:
> Bruce Momjian writes:
> > With the release of Postgres 9.0, should we consider changing the
> > default for 'standard_conforming_strings'?
>
> I'm inclined to think we're going to have enough problems without that.
> Changing that default will break, approximately speaking, ever
I wrote:
> Bruce Momjian writes:
>> With the release of Postgres 9.0, should we consider changing the
>> default for 'standard_conforming_strings'?
> I'm inclined to think we're going to have enough problems without that.
BTW, core already had that discussion, but maybe I should repeat it
to try
On Fri, 2010-01-29 at 14:04 -0500, Tom Lane wrote:
> sri...@postgresql.org (Simon Riggs) writes:
> > Log Message:
> > ---
> > Augment WAL records for btree delete with GetOldestXmin() to reduce
> > false positives during Hot Standby conflict processing. Simple
> > patch to enhance conflict
Bruce Momjian writes:
> With the release of Postgres 9.0, should we consider changing the
> default for 'standard_conforming_strings'?
I'm inclined to think we're going to have enough problems without that.
Changing that default will break, approximately speaking, every single
Postgres client app
I saw some odd pgstat output during an initdb on Windows today:
The files belonging to this database system will be owned by user
"pgrunner".
This user must also own the server process.
The database cluster will be initialized with locale C.
The default database encoding has acco
On Jan 29, 2010, at 11:51 AM, Bruce Momjian wrote:
> With the release of Postgres 9.0, should we consider changing the
> default for 'standard_conforming_strings'?
+1
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
Bruce Momjian wrote:
> With the release of Postgres 9.0, should we consider changing the
> default for 'standard_conforming_strings'?
If not now, when?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
With the release of Postgres 9.0, should we consider changing the
default for 'standard_conforming_strings'?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent v
On Fri, 2010-01-29 at 11:41 -0800, Josh Berkus wrote:
> All,
>
> Is there a working list of HS must-fix items somewhere which people
> agree on? Or are we still lacking consensus?
VACUUM FULL, I believe is one.
Joshua D. Drake
>
> --Josh Berkus
>
--
PostgreSQL.org Major Contributor
Comman
Fujii,
> I guess that the startup process and the walreceiver should wait
> for all read only backends to exit in smart shutdown case. It's
> because those backends might be waiting for the record that conflicts
> with their queries to be replayed. Is this OK? Or we should kill the
> startup proce
All,
Is there a working list of HS must-fix items somewhere which people
agree on? Or are we still lacking consensus?
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
In the past we've rejected proposed patches for pgbench on the grounds
that they would make results non-comparable to previous results. So the
key question here is how much this affects the speed. Please be sure to
test that on a 32-bit machine, not a 64-bit one.
Sheesh, wh
Tom Lane wrote:
sri...@postgresql.org (Simon Riggs) writes:
Log Message:
---
Augment WAL records for btree delete with GetOldestXmin() to reduce
false positives during Hot Standby conflict processing. Simple
patch to enhance conflict processing, following previous discussions.
Controlle
Robert Haas writes:
> On Fri, Jan 29, 2010 at 9:00 AM, Mark Cave-Ayland
> wrote:
>> ... In terms of location, I think utils/misc is a reasonable
>> place for it to live since I see it as analogous to the hash table
>> implementation, i.e. it's a template RB-Tree implementation designed to
>> be u
sri...@postgresql.org (Simon Riggs) writes:
> Log Message:
> ---
> Augment WAL records for btree delete with GetOldestXmin() to reduce
> false positives during Hot Standby conflict processing. Simple
> patch to enhance conflict processing, following previous discussions.
> Controlled by pa
On Fri, Jan 29, 2010 at 9:00 AM, Mark Cave-Ayland
wrote:
> I'm happy that the code is a reasonable implementation of an RB-Tree, at
> least with respect to the link to the related public domain source that
> was posted. In terms of location, I think utils/misc is a reasonable
> place for it to liv
On Tue, Jan 19, 2010 at 3:25 PM, Tom Lane wrote:
> That function *seriously* needs documentation, in particular the fact
> that it's a no-op on machines without the right kernel call. The name
> you've chosen is very bad for those semantics. I'd pick something
> else myself. Maybe "pg_start_dat
Mark, do you need my data to reproduce results from
http://www.sai.msu.su/~megera/wiki/2009-07-27 ?
Oleg
On Fri, 29 Jan 2010, Mark Cave-Ayland wrote:
Hi Robert,
I've also spent some time reviewing this patch since it is a
pre-requisite to the KNNGiST patch. I did have a much more comprehensive
On Jan 29, 2010, at 10:46 AM, Robert Haas wrote:
>> I did and revised them slightly. There isn't much, just a brief comment in
>> the table of aggregate functions. The documentation for all the functions on
>> that page could use a little love, frankly.
>
> Want to take a short at it?
ENOTUITS
On Fri, Jan 29, 2010 at 1:45 PM, David E. Wheeler wrote:
> On Jan 29, 2010, at 10:43 AM, Robert Haas wrote:
>
>> I haven't even looked at this code - I sort of assumed Itagaki was
>> handling this one. But it might be good to make sure that the docs
>> have been read through by a native English s
On Jan 29, 2010, at 10:43 AM, Robert Haas wrote:
> I haven't even looked at this code - I sort of assumed Itagaki was
> handling this one. But it might be good to make sure that the docs
> have been read through by a native English speaker prior to commit...
I did and revised them slightly. Ther
On Fri, Jan 29, 2010 at 2:43 AM, Pavel Stehule wrote:
> 2010/1/28 Tom Lane :
>> Pavel Stehule writes:
>>> with get_fn_expr_arg_stable() we are able to fix second parameter
>>> without some performance issues.
>>
>> No, that will create its own performance issues ---
>> get_fn_expr_arg_stable isn'
2010/1/28 KaiGai Kohei :
> (2010/01/29 9:58), KaiGai Kohei wrote:
>> (2010/01/29 9:29), Robert Haas wrote:
>>> 2010/1/28 KaiGai Kohei:
(2010/01/29 0:46), Robert Haas wrote:
> 2010/1/27 KaiGai Kohei:
>> Hmm, indeed, this logic (V3/V5) is busted.
>>
>> The idea of V4 patch can al
On Fri, 2010-01-29 at 18:08 +, Simon Riggs wrote:
> On Fri, 2010-01-29 at 12:23 -0500, Robert Haas wrote:
> > Two months on, there is
> > zero sign of any activity on that front
>
> I'm surprised that you call 14 commits in 28 days following a publicly
> available priority list: "zero sign of
On Fri, Jan 29, 2010 at 1:08 PM, Simon Riggs wrote:
> On Fri, 2010-01-29 at 12:23 -0500, Robert Haas wrote:
>> Two months on, there is
>> zero sign of any activity on that front
>
> I'm surprised that you call 14 commits in 28 days following a publicly
> available priority list: "zero sign of acti
On Fri, 2010-01-29 at 12:23 -0500, Robert Haas wrote:
> Two months on, there is
> zero sign of any activity on that front
I'm surprised that you call 14 commits in 28 days following a publicly
available priority list: "zero sign of activity".
Further discussion seems pointless.
--
Simon Riggs
"Jonah H. Harris" writes:
>> http://download.oracle.com/docs/cd/E11882_01/server.112/e10592/functions087.htm
>>
>> Defines:
>>
>> *LISTAGG* (measure_expr [, 'delimiter_expr'])
>> *WITHIN GROUP* (order_by_clause) [*OVER* query_partition_clause]
Hmph. I don't know what would possess them to mode
On Fri, 2010-01-29 at 12:23 -0500, Robert Haas wrote:
> Exactly. It would be nice to see 9.0 come out in 2010, and we're not
> going to get there unless we start fixing the issues that are actually
> release-blockers, rather than adding new features. Hot Standby was
> committed with at least one
On Fri, Jan 29, 2010 at 11:32 AM, Joshua D. Drake
wrote:
> On Fri, 2010-01-29 at 12:56 +, Simon Riggs wrote:
>
>> I think we should extend the time available to make sure we have a
>> sensible set of features for 9.0. The heat of this discussion tells me
>> that we are going to be lacking fea
On Fri, Jan 29, 2010 at 12:09 PM, Jonah H. Harris wrote:
> On Fri, Jan 29, 2010 at 11:57 AM, Tom Lane wrote:
>
>> I find it doubtful that it's actually necessary in Oracle's version
>> of listagg ...
>>
>
> Eh?
>
>
> http://download.oracle.com/docs/cd/E11882_01/server.112/e10592/functions087.htm
On Fri, Jan 29, 2010 at 11:57 AM, Tom Lane wrote:
> I find it doubtful that it's actually necessary in Oracle's version
> of listagg ...
>
Eh?
http://download.oracle.com/docs/cd/E11882_01/server.112/e10592/functions087.htm
Defines:
*LISTAGG* (measure_expr [, 'delimiter_expr'])
*WITHIN GROUP
Simon Riggs wrote:
On Fri, 2010-01-29 at 11:20 +0100, Stefan Kaltenbrunner wrote:
Simon Riggs wrote:
On Fri, 2010-01-29 at 11:10 +0100, Stefan Kaltenbrunner wrote:
yeah and we keep finding major bugs nearly daily
Facts, please?
5 seconds of time spent on archives.postgresql.org show at leas
Alvaro Herrera writes:
> So that's how Oracle supports ordered aggregates? Interesting -- we
> just got that capability but using a different syntax. Hmm, the
> SQL:200x draft also has which seems the
> standard way to do the ORDER BY stuff for aggregates ... Should we
> change the syntax?
No
Michael Meskes írta:
> On Fri, Jan 29, 2010 at 06:32:20AM +0100, Boszormenyi Zoltan wrote:
>
>> I know. Patches were already posted for that,
>> waiting for Michael to review and apply it.
>>
>
> Just came back from another trip. Patch works on my system, so I committed
> it.
>
> Michael
On Fri, 2010-01-29 at 14:52 +, Greg Stark wrote:
> You said "I think we should extend the time available to make sure we
> have a sensible set of features for 9.0." Perhaps part of the problem
> is that I couldn't understand what your patch did from the description
> you posted and can't eval
So I never realized the consequences of this little heuristic in
analyze.c in the handling of very low cardinality columns where we
want to just capture the complete list of values in the mcv and throw
away the histogram:
else if (toowide_cnt == 0 && nmultiple == ndistinct)
On Fri, 2010-01-29 at 12:56 +, Simon Riggs wrote:
> I think we should extend the time available to make sure we have a
> sensible set of features for 9.0. The heat of this discussion tells me
> that we are going to be lacking features that are must-have to someone,
> whether or not they are in
On Fri, Jan 29, 2010 at 06:32:20AM +0100, Boszormenyi Zoltan wrote:
> I know. Patches were already posted for that,
> waiting for Michael to review and apply it.
Just came back from another trip. Patch works on my system, so I committed it.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
On Fri, Jan 29, 2010 at 11:09 AM, Tom Lane wrote:
> Greg Smith writes:
>> Was looking for general feedback on whether the way I've converted this
>> to use 64 bit integers for the account numbers seems appropriate, and to
>> see if there's any objection to fixing this in general given the
>> pote
On Fri, Jan 29, 2010 at 2:08 AM, Pavel Stehule wrote:
>>
>> First, you can't just remove support for the escape syntax from \d
>> commands without some discussion of whether or not that's the right
>> thing to do, and I don't think it is. The cases where this will
>> potentially cause a problem a
Greg Smith writes:
> Was looking for general feedback on whether the way I've converted this
> to use 64 bit integers for the account numbers seems appropriate, and to
> see if there's any objection to fixing this in general given the
> potential downsides.
In the past we've rejected proposed
2010/1/29 Alvaro Herrera :
> Jonah H. Harris escribió:
>
>> The syntax is listagg(expression [, delimiter]) WITHIN GROUP (order by
>> clause) [OVER partition clause]
>> If a delimiter is defined, it must be a constant.
>>
>> Query: SELECT listagg(a, ',') WITHIN GROUP (ORDER BY a) FROM foo;
>> Resul
Jonah H. Harris escribió:
> The syntax is listagg(expression [, delimiter]) WITHIN GROUP (order by
> clause) [OVER partition clause]
> If a delimiter is defined, it must be a constant.
>
> Query: SELECT listagg(a, ',') WITHIN GROUP (ORDER BY a) FROM foo;
> Result: aaa,bbb,ccc
So that's how Oracl
Magnus Hagander wrote:
> 2010/1/29 Alvaro Herrera :
> > (There's a badly needed CHECK_FOR_INTERRUPTS in this code BTW)
>
> Incidentally, I ran across the exact same issue with a non-greedy
> regexp with a client earlier this week, and put on my TODO to figure
> out a good place to stick a check fo
On Fri, 2010-01-29 at 16:44 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > I removed code that you mentioned was
> > buggy because I don't have time to fix it and it is not high enough up
> > the priority list. We have discussed all of these things before yet you
> > raise them again as
The fundamental disagreement here is over what qualifies as a
"wishlist" item, aka a feature or added functionality. And what
qualifies as a must-fix bug.
Priorities are context sensitive. If this were early in the cycle then
working on bigger impact features like conflict resolution code might
be
Simon Riggs wrote:
> I removed code that you mentioned was
> buggy because I don't have time to fix it and it is not high enough up
> the priority list. We have discussed all of these things before yet you
> raise them again as if those things have never been said.
*sigh*. Yeah, we've been through
On Fri, Jan 29, 2010 at 7:34 AM, Ivan Sergio Borgonovo
wrote:
> I'm still trying to collect all the bits to be able to read and
> return several types of data in C functions.
>
> I'm looking for quick ways to deal with ArrayType.
>
> I'd expect some helper because these kind of operation should be
On Fri, 2010-01-29 at 11:33 +0200, Heikki Linnakangas wrote:
> I even *fixed* that already, but you decided to take it out before
> committing. I then added it to the list of must-fix items in the TODO
> list, but you took that out too. I have no objection to doing things
> in smaller steps, but t
Hi Robert,
I've also spent some time reviewing this patch since it is a
pre-requisite to the KNNGiST patch. I did have a much more comprehensive
list of suggestions, but it seems you've managed to resolve most of
these with your latest re-write. Please find some more comments inline:
Here's an
This is an updated version of the third of the patches to be
split out from the former 'plperl feature patch 1'.
It includes changes following discussions with Tom Lane and others.
Changes in this patch:
- Added plperl.on_perl_init GUC for DBA use (PGC_SIGHUP)
SPI functions are not available
On Thu, Jan 21, 2010 at 4:27 PM, Heikki Linnakangas
wrote:
> It's a good question if that still makes sense with Hot Standby. Perhaps
> we should redefine smart shutdown in standby mode to shut down as soon
> as all read-only connections have died.
Okay. Let's work out the details.
I guess that
2010/1/29 Greg Smith :
> I just found a few of these errors in a log file during some pgbench testing
> tonight. Linux, recent CVS HEAD; given the range of systems and versions
> this has been reported against now, this bug doesn't look like a platform or
> version/build specific issue.
>
> Unf
2010/1/29 Alvaro Herrera :
> Hi Michael,
>
> Michael Glaesemann wrote:
>> We came across a regexp that takes very much longer than expected.
>>
>> PostgreSQL 8.4.1 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC)
>> 4.1.2 20080704 (Red Hat 4.1.2-44), 64-bit
>>
>> SELECT 'ooo...' ~ $r$Z(Q)[^Q
On Fri, 2010-01-29 at 07:01 -0500, Robert Haas wrote:
> On Fri, Jan 29, 2010 at 5:08 AM, Simon Riggs wrote:
> > On Fri, 2010-01-29 at 11:33 +0200, Heikki Linnakangas wrote:
> >
> >> So what was the clear result?
> >
> > I have spoken clearly enough. You were welcome to attend the Hot Standby
> > U
I'm still trying to collect all the bits to be able to read and
return several types of data in C functions.
I'm looking for quick ways to deal with ArrayType.
I'd expect some helper because these kind of operation should be
frequent and without any helper (function/macro) they really make
the co
On Fri, Jan 29, 2010 at 5:08 AM, Simon Riggs wrote:
> On Fri, 2010-01-29 at 11:33 +0200, Heikki Linnakangas wrote:
>
>> So what was the clear result?
>
> I have spoken clearly enough. You were welcome to attend the Hot Standby
> User Group. The fact that you did not expresses your own priorities
>
On Thu, Jan 28, 2010 at 07:49:37PM +, Tim Bunce wrote:
>
> I think I missed this because the Xcode compiler on Snow Leopard is
> fairly old (gcc 4.2.1).
For the record, gcc 4.2.1 does report the error. I'd missed it because
I'd done most of my builds with perl 5.8.x and the notnull attributes
On Thu, Jan 28, 2010 at 11:02:23PM -0500, Andrew Dunstan wrote:
>
>
> Tim Bunce wrote:
> >This is an updated version of the third of the patches to be split out
> >from the former 'plperl feature patch 1'.
> >
> >It includes changes following discussions with Tom Lane and others.
> >
> >Changes i
On Fri, Jan 29, 2010 at 5:41 PM, Simon Riggs wrote:
>> To improve the situation, I think that we need to use
>> checkpoint_segment/timeout as a trigger of restartpoint, regardless
>> of the checkpoint record. Though I'm not sure that is possible and
>> should be included in v9.0.
>
> Yes, that is
On Thu, Jan 28, 2010 at 5:28 PM, Heikki Linnakangas
wrote:
> How about extending the format of the string returned by
> pg_last_xlog_receive/replay_location() to include the timeline ID? When
> it currently returns e.g '6/200016C', it could return '1/6/200016C',
> where 1 is the timeline ID. Then
On Fri, 2010-01-29 at 11:20 +0100, Stefan Kaltenbrunner wrote:
> Simon Riggs wrote:
> > On Fri, 2010-01-29 at 11:10 +0100, Stefan Kaltenbrunner wrote:
> >
> >> yeah and we keep finding major bugs nearly daily
> >
> > Facts, please?
> >
>
> 5 seconds of time spent on archives.postgresql.org show
Simon Riggs wrote:
On Fri, 2010-01-29 at 11:12 +0100, Stefan Kaltenbrunner wrote:
There are many features we should add. I will add them in priority order
until forced to stop.
we are past the point of adding new features for 9.0 imho
So presumably we cannot add the new feature to start hot
Simon Riggs wrote:
On Fri, 2010-01-29 at 11:10 +0100, Stefan Kaltenbrunner wrote:
yeah and we keep finding major bugs nearly daily
Facts, please?
5 seconds of time spent on archives.postgresql.org show at least the
following SR/HS related bugs in the last 7 days or so:
http://archives.p
1 - 100 of 114 matches
Mail list logo
