Fujii Masao wrote:
In relation to the functions added recently, I found an annoying problem;
pg_xlogfile_name(pg_last_xlog_receive/replay_location()) might report the
wrong name because pg_xlogfile_name() always uses the current timeline,
and a backend doesn't know the actual timeline related
2010/1/28 Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp:
Pavel Stehule pavel.steh...@gmail.com wrote:
with actualised oids
I'm checking the patch for commit, and have a couple of comments.
* I think we cannot cache the delimiter at the first call.
For example,
SELECT
2010/1/28 David E. Wheeler da...@kineticode.com:
On Jan 27, 2010, at 6:47 PM, Takahiro Itagaki wrote:
* I think we cannot cache the delimiter at the first call.
For example,
SELECT string_agg(elem, delim)
FROM (VALUES('A', ','), ('B', '+'), ('C', '*')) t(elem, delim);
should
2010/1/28 Pavel Stehule pavel.steh...@gmail.com:
2010/1/28 David E. Wheeler da...@kineticode.com:
On Jan 27, 2010, at 6:47 PM, Takahiro Itagaki wrote:
* I think we cannot cache the delimiter at the first call.
For example,
SELECT string_agg(elem, delim)
FROM (VALUES('A', ','),
Le 28/01/2010 07:32, Joe Conway a écrit :
On 01/26/2010 02:55 PM, Guillaume Lelarge wrote:
Le 26/01/2010 19:43, Joe Conway a écrit :
On 01/25/2010 03:21 PM, Guillaume Lelarge wrote:
I didn't put any documentation before knowing which one will be choosen.
So we still need to work on the
Pavel Stehule pavel.steh...@gmail.com wrote:
2010/1/28 Pavel Stehule pavel.steh...@gmail.com:
2010/1/28 David E. Wheeler da...@kineticode.com:
On Jan 27, 2010, at 6:47 PM, Takahiro Itagaki wrote:
* I think we cannot cache the delimiter at the first call.
For example,
SELECT
On Wed, Jan 27, 2010 at 06:33:19PM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
On Wed, Jan 27, 2010 at 11:28:02AM -0500, Tom Lane wrote:
Really? We've found that gprof, for instance, doesn't exactly have
zero interaction with the rest of the backend --- there's actually
KaiGai Kohei kai...@ak.jp.nec.com wrote:
The attached patch uses one TOC entry for each blob objects.
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? As I remember, we had decided not to use
Peter Eisentraut wrote:
Everyone,
We could use some help. Anyone's got an idea what could be causing the
behavior described below?
On mån, 2010-01-25 at 21:45 +0200, Peter Eisentraut wrote:
On tis, 2010-01-19 at 01:01 +0900, Hitoshi Harada wrote:
* Conflict between transactions
I'm
On Wed, Jan 27, 2010 at 06:27:50PM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
Okay. I could change the callback code to ignore calls if
proc_exit_inprogress is false. So an abnormal shutdown via exit()
wouldn't involve plperl at all. (Alternatively I could use use
2010/1/27 Robert Haas robertmh...@gmail.com:
On Mon, Jan 25, 2010 at 7:36 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I hope, so this version is more readable and more clean. I removed
some not necessary checks.
This still seems overly complicated to me. I spent a few hours today
On Thu, Jan 28, 2010 at 4:47 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I think there's a race condition at the end of recovery. When the
shutdown checkpoint is written, with new TLI, doesn't a cascading
walsender try to send that to the standby as soon as it's flushed to
Fujii Masao wrote:
On Thu, Jan 28, 2010 at 4:47 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I think there's a race condition at the end of recovery. When the
shutdown checkpoint is written, with new TLI, doesn't a cascading
walsender try to send that to the standby as
Hi,
Greg Smith írta:
Provide rowcount for utility SELECTs
I think I can write a review for this one right now based on the
discussion that's already happened:
-Multiple people think the feature is valuable and it seems worth
exploring
-The right way to handle the protocol change here is
On Thu, Jan 28, 2010 at 7:43 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
How about restoring/streaming files to a new directory, say
pg_xlog/restored/, with the real filenames? At least in standby_mode,
probably best to keep the current behavior in PITR. That would feel
Hi all,
attached a patch to do seq scan + sorting instead of index scan
on CLUSTER (when that's supposed to be faster).
As I've already said, the patch is based on:
http://archives.postgresql.org/pgsql-hackers/2008-08/msg01371.php
Of course, the code isn't supposed to be ready to be merged:
Andrew Dunstan wrote:
Alvaro Herrera wrote:
make world sounds reasonable and I've remember seeing it elsewhere.
Here's a simple patch. Comments?
Should the new targets be added to Makefile too?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Alvaro Herrera wrote:
make world sounds reasonable and I've remember seeing it elsewhere.
Here's a simple patch. Comments?
Should the new targets be added to Makefile too?
Sure, good idea.
cheers
andrew
--
Sent via
On Thu, Jan 28, 2010 at 3:59 AM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Pavel Stehule pavel.steh...@gmail.com wrote:
2010/1/28 Pavel Stehule pavel.steh...@gmail.com:
2010/1/28 David E. Wheeler da...@kineticode.com:
On Jan 27, 2010, at 6:47 PM, Takahiro Itagaki wrote:
* I
2010/1/28 Robert Haas robertmh...@gmail.com:
On Thu, Jan 28, 2010 at 3:59 AM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Pavel Stehule pavel.steh...@gmail.com wrote:
2010/1/28 Pavel Stehule pavel.steh...@gmail.com:
2010/1/28 David E. Wheeler da...@kineticode.com:
On Jan 27,
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','+');
SELECT listagg(a,b) FROM foo;
Thank you
Pavel Stehule
--
Sent via
On Wed, Jan 27, 2010 at 11:13 PM, Greg Smith g...@2ndquadrant.com wrote:
Robert Haas wrote:
plpython3 - no reviewer yet
This whole feature seems quite interesting, and I'm really impressed at how
much work James has put into rethinking what a Python PL should look like.
But isn't the fact
On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
simplest could not be a best. There have to be only a const
expression. But we have not possibility to check it in pg.
Well... that's an entirely arbitrary limitation. I admit that it
doesn't seem likely that someone
Tim Bunce wrote:
I've no use-case for that so I'm happy to leave it disabled. If someone
does have a sane use-case, please let me know. It can always be enabled later.
As I noted upthread, there have been requests for user level session end
handlers before. With SPI enabled as Tom
Robert Haas escribió:
Furthermore, if we are going to ever change this in an incompatible
way that may break clients, isn't 9.0 exactly the right time to do
that? If that doesn't scream big changes coming, proceed with
caution, I don't know what would.
I agree with this -- if we're ever
Last night I noted the following warning:
plperl.c: In function ‘plperl_create_sub’:
plperl.c:1117: warning: null argument where non-null required (argument 2)
I'm not familiar enough with this code to propose a fix...
Joe
signature.asc
Description: OpenPGP digital signature
On Thu, Jan 28, 2010 at 4:53 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/1/27 Robert Haas robertmh...@gmail.com:
On Mon, Jan 25, 2010 at 7:36 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I hope, so this version is more readable and more clean. I removed
some not necessary
Hi,
When I created the trigger file to activate the standby server,
I got the segmentation fault:
sby [11342]: LOG: trigger file found: ../trigger
sby [11343]: FATAL: terminating walreceiver process due to
administrator command
sby [11342]: LOG: redo done at 0/1E0
sby [11342]:
On Thu, Jan 28, 2010 at 06:31:19AM -0800, Joe Conway wrote:
Last night I noted the following warning:
plperl.c: In function ‘plperl_create_sub’:
plperl.c:1117: warning: null argument where non-null required (argument 2)
The master branch of my git clone says line 1117 is:
subref =
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
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? As I remember, we had decided not to use LARGEOBJECT
(without a space) in user-visible
2010/1/28 Robert Haas robertmh...@gmail.com:
On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
simplest could not be a best. There have to be only a const
expression. But we have not possibility to check it in pg.
Well... that's an entirely arbitrary limitation.
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
ISTM you should explicitly grab a lock on the of-type at some point, to
make sure it doesn't get dropped while you're busy creating the table.
How do we protect against that for the types used in columns?
We don't. There is no
Tim Bunce tim.bu...@pobox.com writes:
On Wed, Jan 27, 2010 at 06:27:50PM -0500, Tom Lane wrote:
An advantage of on_proc_exit from your end is that it should allow
you to not have to try to prevent the END blocks from using SPI,
as that would still be perfectly functional when your callback
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
2010/1/27 KaiGai Kohei kai...@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.
Basically, I assume ALTER TABLE
Fujii Masao masao.fu...@gmail.com writes:
How about just making a restore_command copy the WAL files as the
normal one (e.g., ...) instead of a pg_xlog/RECOVERYXLOG?
Though we need to worry about deleting them, we can easily leave
the task to the bgwriter.
The reason for doing it that way
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
simplest could not be a best. There have to be only a const
expression. But we have not possibility to check it in pg.
Well... that's an entirely arbitrary limitation. I
On Thu, Jan 28, 2010 at 10:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
simplest could not be a best. There have to be only a const
expression. But we have not possibility to
On Wed, Jan 27, 2010 at 9:47 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
* Do we need better names for string_agg1_transfn and string_agg2_transfn?
They are almost internal names, but we could have more
like string_agg_with_sep_transfn.
Surely the names of the transition and
On Thu, Jan 28, 2010 at 10:39:33AM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
On Wed, Jan 27, 2010 at 06:27:50PM -0500, Tom Lane wrote:
An advantage of on_proc_exit from your end is that it should allow
you to not have to try to prevent the END blocks from using SPI,
as
On Thu, 2010-01-28 at 10:48 -0500, Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com writes:
How about just making a restore_command copy the WAL files as the
normal one (e.g., ...) instead of a pg_xlog/RECOVERYXLOG?
Though we need to worry about deleting them, we can easily leave
the
On 01/28/2010 07:30 AM, Tim Bunce wrote:
On Thu, Jan 28, 2010 at 06:31:19AM -0800, Joe Conway wrote:
Last night I noted the following warning:
plperl.c: In function ‘plperl_create_sub’:
plperl.c:1117: warning: null argument where non-null required (argument 2)
The master branch of my git
Now the dust is settling on the on_perl_init patch I'd like to ask for
clarification on this next patch.
On Fri, Jan 15, 2010 at 12:35:06AM +, Tim Bunce wrote:
This is the fourth of the patches to be split out from the former
'plperl feature patch 1'.
Changes in this patch:
I think the
Simon Riggs si...@2ndquadrant.com writes:
I'm keen to allow cascading in 9.0. If you pull both synch rep and
cascading you're not offering much that isn't already there.
FWIW, I don't agree with that prioritization in the least. Cascading
is something we could leave till 9.1, or even later,
Tim Bunce tim.bu...@pobox.com writes:
I think the only controversial change is this one:
- Adds plperl.on_trusted_init and plperl.on_untrusted_init GUCs
Both are PGC_USERSET.
SPI functions are not available when the code is run.
Errors are detected and reported as ereport(ERROR, ...)
+
2010/1/28 Robert Haas robertmh...@gmail.com:
On Thu, Jan 28, 2010 at 4:53 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2010/1/27 Robert Haas robertmh...@gmail.com:
On Mon, Jan 25, 2010 at 7:36 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I hope, so this version is more readable and
Tom Lane wrote:
Isn't it a security hole if on_trusted_init is USERSET? That means
an unprivileged user can determine what will happen in plperlu.
SUSET would be saner.
ITYM on_untrusted_init.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
2010/1/29 Pavel Stehule pavel.steh...@gmail.com:
2010/1/28 Robert Haas robertmh...@gmail.com:
On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
simplest could not be a best. There have to be only a const
expression. But we have not possibility to check it in pg.
On Thu, Jan 28, 2010 at 11:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
I'm keen to allow cascading in 9.0. If you pull both synch rep and
cascading you're not offering much that isn't already there.
FWIW, I don't agree with that prioritization in the
2010/1/28 Robert Haas robertmh...@gmail.com:
On Thu, Jan 28, 2010 at 10:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
simplest could not be a best. There have to be only a
2010/1/28 Robert Haas robertmh...@gmail.com:
On Wed, Jan 27, 2010 at 9:47 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
* Do we need better names for string_agg1_transfn and string_agg2_transfn?
They are almost internal names, but we could have more
like
Pavel Stehule pavel.steh...@gmail.com writes:
in 99.99% the second argument will be a constant. Can we use this
information and optimize function for this case?
The detoast on every row can take some percent from a performance.
What detoast? There won't be one for a constant, nor even for a
2010/1/28 Hitoshi Harada umi.tan...@gmail.com:
2010/1/29 Pavel Stehule pavel.steh...@gmail.com:
2010/1/28 Robert Haas robertmh...@gmail.com:
On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
simplest could not be a best. There have to be only a const
expression.
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
Isn't it a security hole if on_trusted_init is USERSET? That means
an unprivileged user can determine what will happen in plperlu.
SUSET would be saner.
ITYM on_untrusted_init.
Right, sorry, got 'em backwards.
2010/1/28 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
in 99.99% the second argument will be a constant. Can we use this
information and optimize function for this case?
The detoast on every row can take some percent from a performance.
What detoast? There
Hitoshi Harada umi.tan...@gmail.com writes:
What about get_fn_expr_arg_stable() to check if the argument is stable
during aggregate?
Seems quite expensive (possible catalog lookups) and there still isn't
any strong argument why we should bother.
regards, tom lane
--
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 were a really strong reason why we had to
On 2010-01-28 19:17, Pavel Stehule wrote:
2010/1/28 Hitoshi Harada umi.tan...@gmail.com:
What about get_fn_expr_arg_stable() to check if the argument is stable
during aggregate?
I newer know so this function exists. Now we can
a) check and allow only stable params
b) when second
On Jan 28, 2010, at 9:29 AM, Marko Tiikkaja wrote:
Someone might have a perfectly good use case for using different
delimiters. I don't think it's a good idea to be artificially limiting
what you can and can't do.
+1
David
--
Sent via pgsql-hackers mailing list
On Thu, 2010-01-28 at 12:09 -0500, Robert Haas wrote:
I agree. According to
http://wiki.postgresql.org/wiki/Hot_Standby_TODO , the only must-fix
issues that remain prior to beta are (1) implementing the new VACUUM
FULL for system relations, and (2) some documentation improvements.
It's a
On Thu, 2010-01-28 at 11:41 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
I'm keen to allow cascading in 9.0. If you pull both synch rep and
cascading you're not offering much that isn't already there.
FWIW, I don't agree with that prioritization in the least. Cascading
Joe Conway m...@joeconway.com writes:
I pull directly from CVS, not git, but in any case my line 1117 is
subref = newRV_inc((SV*)GvCVu((GV*)sub_glob));
so it appears to be the same
What perl version are you using?
What compiler version are you using?
I'm on stock Fedora 12:
I see the
Simon Riggs si...@2ndquadrant.com writes:
On Thu, 2010-01-28 at 11:41 -0500, Tom Lane wrote:
FWIW, I don't agree with that prioritization in the least. Cascading
is something we could leave till 9.1, or even later, and
Not what you said just a few days ago.
Me? I don't recall having said
On Thu, Jan 28, 2010 at 11:59 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/1/28 Robert Haas robertmh...@gmail.com:
On Thu, Jan 28, 2010 at 4:53 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2010/1/27 Robert Haas robertmh...@gmail.com:
On Mon, Jan 25, 2010 at 7:36 AM, Pavel
On Thu, 2010-01-28 at 13:05 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Thu, 2010-01-28 at 11:41 -0500, Tom Lane wrote:
FWIW, I don't agree with that prioritization in the least. Cascading
is something we could leave till 9.1, or even later, and
Not what you
Tom Lane wrote:
(Anyway, the argument that it's important for performance is pure
speculation AFAIK, untainted by any actual measurements. Given the lack
of optimization of WAL replay, it seems entirely possible that the last
thing you want to burden a slave with is sourcing data to more
Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com writes:
How about just making a restore_command copy the WAL files as the
normal one (e.g., ...) instead of a pg_xlog/RECOVERYXLOG?
Though we need to worry about deleting them, we can easily leave
the task to the bgwriter.
The reason
On Thu, 2010-01-28 at 13:05 -0500, Tom Lane wrote:
I'm a little worried the feature set of streaming rep isn't any better
than what we have already.
Nonsense. Getting rid of the WAL-segment-based shipping delays is a
quantum improvement --- it means we actually have something approaching
Simon Riggs wrote:
I'm a little worried the feature set of streaming rep isn't any better
than what we have already.
Huh? Are you thinking of the Record-based Log Shipping described in
the manual, using a program to poll pg_xlogfile_name_offset() in a tight
loop, as a replacement for streaming
One situation where this could actually matter in the long term is if we
want to have an optimization for aggregate functions whose state variables
can be combined. this could be important if we ever want to do parallel
processing someday.
So we could have, for example two subjobs build two
On Thu, 2010-01-28 at 20:49 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
I'm a little worried the feature set of streaming rep isn't any better
than what we have already.
Huh? Are you thinking of the Record-based Log Shipping described in
the manual, using a program to poll
Simon Riggs wrote:
On Thu, 2010-01-28 at 10:48 -0500, Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com writes:
How about just making a restore_command copy the WAL files as the
normal one (e.g., ...) instead of a pg_xlog/RECOVERYXLOG?
Though we need to worry about deleting them, we can
On Thu, 2010-01-28 at 21:00 +0200, Heikki Linnakangas wrote:
However, since not every checkpoint is a restartpoint we might easily
end up with significantly more WAL files on the standby than would
normally be there when it would be a primary. Not sure if that is an
issue in this case, but
Joshua D. Drake wrote:
...if with SR the entire log must be written before it streams to the slaves.
No.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Fujii Masao wrote:
When I created the trigger file to activate the standby server,
I got the segmentation fault:
...
The attached patch would fix the bug.
Thanks, committed. (I kept the old comment, though, I liked it better)
Now, whether we should even allow setting up a standby without
On Thu, Jan 28, 2010 at 2:23 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Perhaps we should require a restore_command. If you know what you're
doing, you can always use '/bin/false' as restore_command to hack around it.
That seems kind of needlessly hacky (and it won't work
Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
I pull directly from CVS, not git, but in any case my line 1117 is
subref = newRV_inc((SV*)GvCVu((GV*)sub_glob));
so it appears to be the same
What perl version are you using?
What compiler version are you using?
On Thu, Jan 28, 2010 at 12:49:20PM -0500, Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
I pull directly from CVS, not git, but in any case my line 1117 is
subref = newRV_inc((SV*)GvCVu((GV*)sub_glob));
so it appears to be the same
What perl version are you using?
What
On tor, 2010-01-28 at 10:34 -0500, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
ISTM you should explicitly grab a lock on the of-type at some point, to
make sure it doesn't get dropped while you're busy creating the table.
How do we protect against that for
On Thu, Jan 28, 2010 at 12:12:58PM -0500, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
Isn't it a security hole if on_trusted_init is USERSET? That means
an unprivileged user can determine what will happen in plperlu.
SUSET would be saner.
ITYM
Peter Eisentraut pete...@gmx.net writes:
The right thing would probably be SELECT FOR SHARE on the pg_type row,
but I don't see that sort of thing used anywhere else in system catalog
changes.
If we were to do it the right thing would just be to define a locktag
for type OIDs and add
On Thu, Jan 28, 2010 at 11:54:08AM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
I think the only controversial change is this one:
- Adds plperl.on_trusted_init and plperl.on_untrusted_init GUCs
Both are PGC_USERSET.
SPI functions are not available when the code is run.
Guys,
Hmm, I'm sorry but that's bogus. Retaining so much WAL that we are
strongly in danger of blowing disk space is not what I would call a
safety feature. Since there is no way to control or restrain the number
of files for certain, that approach seems fatally flawed. Reducing
On Jan 28, 2010, at 12:01 PM, Tim Bunce wrote:
Once the previous patch lands I'll post an update to this patch with
those changes applied.
Ds the Add on_perl_init and proper destruction to plperl patch the one you're
waiting on, then?
Best,
David, who loses track of these things
--
Sent
Robert Haas wrote:
There has been some more discussion lately of problems caused by contrib/xml2.
http://archives.postgresql.org/pgsql-bugs/2010-01/msg00251.php
http://archives.postgresql.org/pgsql-bugs/2010-01/msg00198.php
I think we need to either (1) fix the bugs and update the
On Sun, Jan 24, 2010 at 12:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jan 24, 2010 at 12:06 AM, Jaime Casanova
why not let it go in ANALYZE, just as the sort info
It's kinda long-winded - it adds like 4 extra lines for each hash
join. I don't
I wrote:
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Alvaro Herrera wrote:
make world sounds reasonable and I've remember seeing it elsewhere.
Here's a simple patch. Comments?
Should the new targets be added to Makefile too?
Sure, good idea.
One more thing:
On Thu, Jan 28, 2010 at 4:18 PM, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
There has been some more discussion lately of problems caused by
contrib/xml2.
http://archives.postgresql.org/pgsql-bugs/2010-01/msg00251.php
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 implementation of that design.
On Wed, Jan 27, 2010 at 4:05 PM, Robert Haas robertmh...@gmail.com wrote:
Waiting for Re-Review (5)
=
Writeable CTEs
Set this ready for commit. For such a small patch, it's a wonderful
feature. I think it deserves a fair shot on this 'fest.
insert/returning/subquery is
Hi,
Boszormenyi Zoltan írta:
I think the best would be to delete the NAN test from outofscope.pgc
and fix the double/numeric NaN/Inf/-Inf problem separately and have
their own test case.
the attached patch attempts to fix NaN/Infinity problems in ECPG
for float/double/numeric/decimal.
I
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
I think we need to either (1) fix the bugs and update the
documentation to remove the statement that this will be removed or (2)
actually remove it.
I agree it's a mess but I don't think just abandoning the functionality
is a
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 brevity
?column?
--
t
(1 row)
Time:
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 /contrib.
--Josh Berkus
--
Sent via pgsql-hackers mailing list
Tim Bunce wrote:
It looks to me like this is probably a live bug not just compiler
hypersensitivity.
Yes. (ISTR there have been cases where the notnull attribute was
misapplied to some perl functions, but that's not the case here.)
I think I missed this because the Xcode compiler on
On tor, 2010-01-28 at 16:21 -0500, Andrew Dunstan wrote:
One more thing: do we want the new targets world and
install-world
documented, or just left for developers?
Document them. How else would new developers learn about them?
--
Sent via pgsql-hackers mailing list
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 that. This month I've run into two
systems
On tor, 2010-01-28 at 00:43 +0900, Hitoshi Harada wrote:
OK, I confirmed all the issues relevant to the patch were fixed. I'm
not so familiar with transaction detail, so I leave it as a known
issue.
I have applied this now, because it appeared that the locking issue is a
known more general
(2010/01/28 18:21), Takahiro Itagaki wrote:
KaiGai Koheikai...@ak.jp.nec.com wrote:
The attached patch uses one TOC entry for each blob objects.
When I'm testing the new patch, I found ALTER LARGE OBJECT command
returns ALTER LARGEOBJECT tag. Should it be ALTER LARGE(space)OBJECT
I'm trying to return a set of record as:
(text, int[]),
(text, int[]),
...
row from C
and I really would like to avoid to use BuildTupleFromCString
So this is how I think my function should end...
char *curout; /* cstring */
int4 *pos;
...
get_typlenbyvalalign(INT4OID, typlen, typbyval,
1 - 100 of 127 matches
Mail list logo
