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
>> checkpoin
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
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't especially cheap.
> If there were a really strong reason why
2010/1/29 Jonah H. Harris :
> On Thu, Jan 28, 2010 at 9:10 AM, Pavel Stehule
> 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 VALUES('bbb',';');
>> INSER
Greg Smith 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 that. This month
KaiGai Kohei 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.
Committed
>
> 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,
On Fri, Jan 29, 2010 at 4:23 AM, Heikki Linnakangas
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 you *can* take a base
> backup with
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 i
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, developin
On Thu, Jan 28, 2010 at 9:10 AM, Pavel Stehule 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 VALUES('bbb',';');
> INSERT INTO foo VALUES('ccc','+');
>
> SELECT lis
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 th
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 associat
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 regexp
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:
http://www.postgresql.org/ma
On Thu, Jan 28, 2010 at 11:03 PM, Scott Bailey wrote:
> Robert Haas wrote:
>> On Sun, Jan 17, 2010 at 11:33 AM, Jan Urbański
>> wrote:
>>> [ detailed review ]
>>
>> Arie,
>>
>> Are you planning to submit an updated patch? If so, please do so soon.
>>
> What is the time limit on this? I've been te
Robert Haas wrote:
On Sun, Jan 17, 2010 at 11:33 AM, Jan Urbański 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 see it get in. I can m
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 functi
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 20080
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...' ~ $
(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 also handle this case correctly, alt
Robert Haas escribió:
> On Thu, Jan 28, 2010 at 5:54 PM, Josh Berkus 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 ship
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
(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 also handle this case correctly, although it
is lesser in performance.
I
On Thu, Jan 28, 2010 at 5:54 PM, Josh Berkus 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 /contrib.
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 also handle this case correctly, although it
>>> is lesser in performance.
>>> I wonder whether it is really unacceptable cost
(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 also handle this case correctly, although it
>> is lesser in performance.
>> I wonder whether it is really unacceptable cost in performance, or not.
>> Basica
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
(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
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
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 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
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
> 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
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
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
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.
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
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 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
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 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
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 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
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 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
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 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
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: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
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 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'
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
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
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
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 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
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
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
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
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
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.
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
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
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
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
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
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 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 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
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,
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
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
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 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
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 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
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.
>>
>>
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/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
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/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
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_
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
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
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
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 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 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: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
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
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
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
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
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.
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
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
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
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 =
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:
1 - 100 of 127 matches
Mail list logo
