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 relat
2010/1/28 Takahiro Itagaki :
>
> Pavel Stehule 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 string_agg(elem, delim)
> FROM (VALUES('A', ','), ('
2010/1/28 David E. Wheeler :
> 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 return 'A+B*C'
2010/1/28 Pavel Stehule :
> 2010/1/28 David E. Wheeler :
>> 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,
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
Pavel Stehule wrote:
> 2010/1/28 Pavel Stehule :
> > 2010/1/28 David E. Wheeler :
> >> 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
On Wed, Jan 27, 2010 at 06:33:19PM -0500, Tom Lane wrote:
> Tim Bunce 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
> >> a coup
KaiGai Kohei 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 LARGEOBJECT
(withou
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 transact
On Wed, Jan 27, 2010 at 06:27:50PM -0500, Tom Lane wrote:
> Tim Bunce 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
> > on_proc_exit() in
2010/1/27 Robert Haas :
> On Mon, Jan 25, 2010 at 7:36 AM, Pavel Stehule
> 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
> working up the attached patch. Let me
On Thu, Jan 28, 2010 at 4:47 PM, Heikki Linnakangas
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
> disk? But it won't find it in
Fujii Masao wrote:
> On Thu, Jan 28, 2010 at 4:47 PM, Heikki Linnakangas
> 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
>> dis
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 h
On Thu, Jan 28, 2010 at 7:43 PM, Heikki Linnakangas
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 more
> clean, you could easily tell
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: I
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/
Postg
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
wrote:
> Pavel Stehule wrote:
>
>> 2010/1/28 Pavel Stehule :
>> > 2010/1/28 David E. Wheeler :
>> >> On Jan 27, 2010, at 6:47 PM, Takahiro Itagaki wrote:
>> >>
>> >>> * I think we cannot cache the delimiter at the first call.
>> >>> For example,
2010/1/28 Robert Haas :
> On Thu, Jan 28, 2010 at 3:59 AM, Takahiro Itagaki
> wrote:
>> Pavel Stehule wrote:
>>
>>> 2010/1/28 Pavel Stehule :
>>> > 2010/1/28 David E. Wheeler :
>>> >> On Jan 27, 2010, at 6:47 PM, Takahiro Itagaki wrote:
>>> >>
>>> >>> * I think we cannot cache the delimiter at th
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 pgsql-hackers
On Wed, Jan 27, 2010 at 11:13 PM, Greg Smith 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 that there isn'
On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule 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 would want to have a
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 sugg
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 eve
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 wrote:
> 2010/1/27 Robert Haas :
>> On Mon, Jan 25, 2010 at 7:36 AM, Pavel Stehule
>> 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 sp
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]: LOG:
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 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 messages, right?
The comm
2010/1/28 Robert Haas :
> On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule
> 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 likel
Heikki Linnakangas 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 concept of a lock on a type.
For sc
Tim Bunce 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
>> gets called.
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
2010/1/27 KaiGai Kohei :
> 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 RENAME/TYPE is not
Fujii Masao 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 was to limit disk
Robert Haas writes:
> On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule
> 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 th
On Thu, Jan 28, 2010 at 10:56 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule
>> 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 arbi
On Wed, Jan 27, 2010 at 9:47 PM, Takahiro Itagaki
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 final functions should matc
On Thu, Jan 28, 2010 at 10:39:33AM -0500, Tom Lane wrote:
> Tim Bunce 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 wou
On Thu, 2010-01-28 at 10:48 -0500, Tom Lane wrote:
> Fujii Masao 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
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 branc
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 t
Simon Riggs 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, and hardly anyone
woul
Tim Bunce 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, ...)
> + plperl.on_
2010/1/28 Robert Haas :
> On Thu, Jan 28, 2010 at 4:53 AM, Pavel Stehule
> wrote:
>> 2010/1/27 Robert Haas :
>>> On Mon, Jan 25, 2010 at 7:36 AM, Pavel Stehule
>>> wrote:
I hope, so this version is more readable and more clean. I removed
some not necessary checks.
>>>
>>> This still s
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 :
> 2010/1/28 Robert Haas :
>> On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule
>> 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 11:41 AM, Tom Lane wrote:
> Simon Riggs 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
2010/1/28 Robert Haas :
> On Thu, Jan 28, 2010 at 10:56 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule
>>> 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.
>>
>>
2010/1/28 Robert Haas :
> On Wed, Jan 27, 2010 at 9:47 PM, Takahiro Itagaki
> 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 transiti
Pavel Stehule 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
variable in any sane
2010/1/28 Hitoshi Harada :
> 2010/1/29 Pavel Stehule :
>> 2010/1/28 Robert Haas :
>>> On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule
>>> 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 a
Andrew Dunstan 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.
regards,
2010/1/28 Tom Lane :
> Pavel Stehule 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 ev
Hitoshi Harada 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
--
Sent via pgsql-hacke
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't especially cheap.
If there were a really strong reason why we had to do it,
then I'd agree,
On 2010-01-28 19:17, Pavel Stehule wrote:
> 2010/1/28 Hitoshi Harada :
>> 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 parameter is stable
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 (pgsql-hackers@postgresq
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
On Thu, 2010-01-28 at 11:41 -0500, Tom Lane wrote:
> Simon Riggs 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
Joe Conway 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 same on Fe
Simon Riggs 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 a word about cas
On Thu, Jan 28, 2010 at 11:59 AM, Pavel Stehule wrote:
> 2010/1/28 Robert Haas :
>> On Thu, Jan 28, 2010 at 4:53 AM, Pavel Stehule
>> wrote:
>>> 2010/1/27 Robert Haas :
On Mon, Jan 25, 2010 at 7:36 AM, Pavel Stehule
wrote:
> I hope, so this version is more readable and more clean
On Thu, 2010-01-28 at 13:05 -0500, Tom Lane wrote:
> Simon Riggs 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
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 slaves.
Tom Lane wrote:
> Fujii Masao 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
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 appro
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 streami
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 sublis
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 pol
Simon Riggs wrote:
> On Thu, 2010-01-28 at 10:48 -0500, Tom Lane wrote:
>> Fujii Masao 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 leav
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
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:
http://www
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 witho
On Thu, Jan 28, 2010 at 2:23 PM, Heikki Linnakangas
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 on Windows).
Seems like it doesn'
Tom Lane wrote:
Joe Conway 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 Fedo
On Thu, Jan 28, 2010 at 12:49:20PM -0500, Tom Lane wrote:
> Joe Conway 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 compile
On tor, 2010-01-28 at 10:34 -0500, Tom Lane wrote:
> Heikki Linnakangas 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?
>
On Thu, Jan 28, 2010 at 12:12:58PM -0500, Tom Lane wrote:
> Andrew Dunstan 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_i
Peter Eisentraut 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 appropriate locking ca
On Thu, Jan 28, 2010 at 11:54:08AM -0500, Tom Lane wrote:
> Tim Bunce 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.
> >> Er
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
> checkpoi
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
documentat
On Sun, Jan 24, 2010 at 12:30 PM, Tom Lane wrote:
> Robert Haas 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 think I want to add that muc
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 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
>> http://archives.postgresql.org/pgsql-bugs/2010-01/msg00198.p
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 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 far and away one of
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.
Andrew Dunstan 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 good idea.
Y
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: 90
> 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 (pg
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 Sn
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 (pgsql-hackers@p
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 w
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 p
(2010/01/28 18:21), Takahiro Itagaki wrote:
>
> KaiGai Kohei 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? A
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, &typa
1 - 100 of 127 matches
Mail list logo
