(2010/01/29 0:46), Robert Haas wrote:
2010/1/27 KaiGai Koheikai...@ak.jp.nec.com:
Hmm, indeed, this logic (V3/V5) is busted.
The idea of V4 patch can also handle this case correctly, although it
is lesser in performance.
I wonder whether it is really unacceptable cost in performance, or not.
2010/1/28 KaiGai Kohei kai...@ak.jp.nec.com:
(2010/01/29 0:46), Robert Haas wrote:
2010/1/27 KaiGai Koheikai...@ak.jp.nec.com:
Hmm, indeed, this logic (V3/V5) is busted.
The idea of V4 patch can also handle this case correctly, although it
is lesser in performance.
I wonder whether it is
On Thu, Jan 28, 2010 at 5:54 PM, Josh Berkus j...@agliodbs.com wrote:
Yeah, we can't really remove it until we have a plausible substitute for
the xpath_table functionality. This is in the TODO list ...
What about moving it to pgfoundry?
I'm really not keen on shipping known-broken stuff in
(2010/01/29 9:29), Robert Haas wrote:
2010/1/28 KaiGai Koheikai...@ak.jp.nec.com:
(2010/01/29 0:46), Robert Haas wrote:
2010/1/27 KaiGai Koheikai...@ak.jp.nec.com:
Hmm, indeed, this logic (V3/V5) is busted.
The idea of V4 patch can also handle this case correctly, although it
is lesser in
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]*A.*?(\1)$r$; -- omitted for email
Robert Haas escribió:
On Thu, Jan 28, 2010 at 5:54 PM, Josh Berkus j...@agliodbs.com wrote:
Yeah, we can't really remove it until we have a plausible substitute for
the xpath_table functionality. This is in the TODO list ...
What about moving it to pgfoundry?
I'm really not keen on
(2010/01/29 9:58), KaiGai Kohei wrote:
(2010/01/29 9:29), Robert Haas wrote:
2010/1/28 KaiGai Koheikai...@ak.jp.nec.com:
(2010/01/29 0:46), Robert Haas wrote:
2010/1/27 KaiGai Koheikai...@ak.jp.nec.com:
Hmm, indeed, this logic (V3/V5) is busted.
The idea of V4 patch can also handle this
On Jan 28, 2010, at 21:59 , Alvaro Herrera wrote:
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...' ~
Michael Glaesemann wrote:
On Jan 28, 2010, at 21:59 , Alvaro Herrera wrote:
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
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
Robert Haas wrote:
On Sun, Jan 17, 2010 at 11:33 AM, Jan Urbański wulc...@wulczer.org wrote:
[ detailed review ]
Arie,
Are you planning to submit an updated patch? If so, please do so soon.
Thanks,
...Robert
What is the time limit on this? I've been testing Arie's patch and I
want to
On Thu, Jan 28, 2010 at 11:03 PM, Scott Bailey arta...@comcast.net wrote:
Robert Haas wrote:
On Sun, Jan 17, 2010 at 11:33 AM, Jan Urbański wulc...@wulczer.org
wrote:
[ detailed review ]
Arie,
Are you planning to submit an updated patch? If so, please do so soon.
What is the time limit
We seem to have a large portion of the buildfarm red from the ECPG
tests, presumably due to the recently applied out-of-scope cursor patches.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Michael Glaesemann wrote:
However, as you point out, Postgres doesn't appear to take this into
account:
postgres=# select regexp_replace('oooZQoooAoooQooQooQooo', $r$(Z(Q)
[^Q]*A.*(\2))$r$, $s$X$s$);
regexp_replace
oooXooo
(1 row)
postgres=# select
On Jan 28, 2010, at 23:21 , Alvaro Herrera wrote:
I think the reason for this is that the first * is greedy and thus the
entire expression is considered greedy. The fact that you've made the
second * non-greedy does not ungreedify the RE ... Note the docs say:
The above rules
Andrew Dunstan írta:
We seem to have a large portion of the buildfarm red from the ECPG
tests, presumably due to the recently applied out-of-scope cursor
patches.
cheers
andrew
Hi.
I know. Patches were already posted for that,
waiting for Michael to review and apply it.
Look at the
On Thu, Jan 28, 2010 at 9:10 AM, Pavel Stehule pavel.steh...@gmail.comwrote:
Hello,
I can't to install Oracle, and need to know result.
CREATE TABLE foo(a varchar(10), b varchar(10));
INSERT INTO foo VALUES('aaa',',');
INSERT INTO foo VALUES('bbb',';');
INSERT INTO foo VALUES('ccc','+');
Tatsuo Ishii wrote:
Hi,
I know this has been discussed several times and it seems the
conclusin was it's impossible if we would like to use existing XQuery
external modules (some are by license reasons and some are by
techinical reasons).
So it seems the only way to support XQuery is,
Simon Riggs wrote:
Conflict resolution improvements are important to include in this
release, as discussed many times. Proposal given here
http://archives.postgresql.org/pgsql-hackers/2009-12/msg01175.php
presents a viable design to improve this.
Following patch is a complete working
On Fri, Jan 29, 2010 at 4:23 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Thanks, committed. (I kept the old comment, though, I liked it better)
Thanks!
Then again, if the database is small, maybe you don't mind taking a new
base backup if the standby falls behind. And
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 are limited to those where the input is
invalidly encoded, and I
KaiGai Kohei kai...@ak.jp.nec.com wrote:
When I'm testing the new patch, I found ALTER LARGE OBJECT command
returns ALTER LARGEOBJECT tag. Should it be ALTER LARGE(space)OBJECT
instead?
Sorry, I left for fix this tag when I was pointed out LARGEOBJECT should
be LARGE(space)OBJECT.
Greg Smith g...@2ndquadrant.com wrote:
Attached is a patch that fixes a long standing bug in pgbench: it won't
handle scale factors above ~4000 (around 60GB) because it uses 32-bit
integers for its computations related to the number of accounts, and it
just crashes badly when you exceed
2010/1/29 Jonah H. Harris jonah.har...@gmail.com:
On Thu, Jan 28, 2010 at 9:10 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello,
I can't to install Oracle, and need to know result.
CREATE TABLE foo(a varchar(10), b varchar(10));
INSERT INTO foo VALUES('aaa',',');
INSERT INTO foo
2010/1/28 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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't especially cheap.
If there
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.
Unfortunately the instance I had up
Simon Riggs wrote:
On Thu, 2010-01-28 at 21:00 +0200, Heikki Linnakangas wrote:
I think it is a pretty important safety feature that we keep all the
WAL around that's needed to recover the standby. To avoid
out-of-disk-space situation, it's probably enough in practice to set
101 - 127 of 127 matches
Mail list logo
