Please consider adding this minor patch, or offering improvements.
*Problem*: vacuumlo required PostgreSQL to use more locks per transaction
than possible resulting in an error and a log file full of "ignored until
end of transaction" warnings.
(max_locks_per_transaction is limited by shmmax which
Hi Álvaro, thanks for the response.
Here is the requested "diff with 3 lines of context":
git diff HEAD -- contrib/vacuumlo/vacuumlo.c
diff --git a/contrib/vacuumlo/vacuumlo.c b/contrib/vacuumlo/vacuumlo.c
index f6e2a28..b7c7d64 100644
--- a/contrib/vacuumlo/vacuumlo.c
+++ b/contrib/vacuumlo/vacu
Updated the patch to also apply when the no-action flag is enabled.
git diff HEAD -- contrib/vacuumlo/vacuumlo.c
diff --git a/contrib/vacuumlo/vacuumlo.c b/contrib/vacuumlo/vacuumlo.c
index f6e2a28..8e9c342 100644
--- a/contrib/vacuumlo/vacuumlo.c
+++ b/contrib/vacuumlo/vacuumlo.c
@@ -48,6 +48,7 @
Hi Josh,
Thanks for help. Attached is a patch including changes suggested in your
comments.
Excerpts from Josh's message On Sat, Aug 6, 2011 at 9:57 PM:
>
> 1. It wasn't clear to me whether you're OK with Aron's suggested
> tweak, please include it in your patch if so.
>
I decided to and inclu
Excerpts from Josh's message On Sun, Aug 7, 2011 at 2:36 AM:
> could we figure out what that limit should be based on
> max_locks_per_transaction?
It would be nice to implement via "-l max" instead of making users do it
manually or something like this "-l $(grep "max_locks_per_transaction.*="
po
Excerpts from Peter's message On Sun, Aug 7, 2011 at 3:49 AM:
> Please put the new option 'l' in some sensible order in the code and the
> help output (normally alphabetical). Also, there should probably be
> some update to the documentation.
>
I have alphabetized the help output, and one piece
Thanks Josh,
I like the ability to bail out on PQTRANS_INERROR, and I think it's a small
enough fix to be appropriate to include in this patch.
I did consider it before but did not implement it because I am still new to
pgsql-hackers and did not know how off-the-cuff.
So thanks for the big improvem
example, I am not sure that
`pwd` is the best way to find the configure/build dir.
HTH
--Tim Larson
Index: Makefile
===
RCS file: /projects/cvsroot/pgsql-server/src/interfaces/jdbc/Makefile,v
retrieving revision 1.39
diff -r1.39 Makefile
Just following up here since I haven't gotten a reply -- I'd love to work
with someone from the Postgres community on a plan to make the
tsearch_extras functionality available as part of mainline postgres.
-Tim Abbott
On Wed, Feb 3, 2016 at 9:41 PM, Tim Abbott wrote:
> H
This old thread on "user-based query white list" is now nearly 10 years old!
http://grokbase.com/t/postgresql/pgsql-hackers/08c6zh42fa/user-based-query-white-list
Since then, is it now possible to configure a user to only be able to
execute a limited white-listing of queries? Is this something tha
Just to be pedantic, commit message shows
"support for Tru64 ended in 201."
I think you mean 2012.
On 18/10/2013 13:41, "Robert Haas" wrote:
>On Thu, Oct 17, 2013 at 5:41 PM, Peter Eisentraut wrote:
>> On 10/17/13 12:45 PM, Robert Haas wrote:
>>> The attached patch, which I propose
Hi all,
I haven't given this a lot of thought, but it struck me that when
rebuilding tables (be it for a restore process, or some other operational
activity) - there is more often than not a need to build an index or two,
sometimes many indexes, against the same relation.
It strikes me that in or
Wow.. thanks guys, really appreciate the detailed analysis.
Tim
On Wed, Jul 24, 2013 at 4:08 AM, Noah Misch wrote:
> On Tue, Jul 23, 2013 at 01:06:26PM +0100, Tim Kane wrote:
> > I haven't given this a lot of thought, but it struck me that when
> > rebuilding tables
This just hit us today... Admittedly on an old cluster still running 9.2,
though I can't see any mention of it being addressed since.
Any chance of getting this on to to-do list?
On Sat, 1 Nov 2014 at 07:45, Simon Riggs wrote:
> On 31 October 2014 17:46, Michael Banck wrote:
>
> > I wonder whet
Changes:
Sets the local $_TD via C instead of passing an extra argument.
So functions no longer start with "our $_TD; local $_TD = shift;"
Pre-extend stack for trigger arguments for slight performance gain.
Passes installcheck.
Tim.
diff --git a/src/pl/plperl/plperl.
On Tue, Dec 07, 2010 at 10:00:28AM -0500, Andrew Dunstan wrote:
>
>
> On 12/07/2010 09:24 AM, Tim Bunce wrote:
> >Changes:
> >
> > Sets the local $_TD via C instead of passing an extra argument.
> > So functions no longer start with "our $_TD; local
On Wed, Dec 08, 2010 at 09:21:05AM -0800, David E. Wheeler wrote:
> On Dec 8, 2010, at 9:14 AM, Tim Bunce wrote:
>
> >> Do you have any more improvements in the pipeline?
> >
> > I'd like to add $arrayref = decode_array_literal('{2,3}') and
> > ma
On Mon, Feb 01, 2010 at 07:53:05PM -0700, Alex Hunsaker wrote:
> On Mon, Feb 1, 2010 at 03:58, Tim Bunce wrote:
> > On Sat, Jan 30, 2010 at 06:38:59PM -0700, Alex Hunsaker wrote:
> >
> >> plc_safe_ok.pl seems to loose its CVS $PostgreSQL$ keyword.
> >Probably a sli
On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
>
> > SPI functions are not available when the code is run.
>
> Hrm, we might want to stick why in the docs or as a comment somewhere.
> I think this
On Wed, Feb 03, 2010 at 10:18:51AM -0700, Alex Hunsaker wrote:
> On Wed, Feb 3, 2010 at 09:31, Tim Bunce wrote:
> > On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
> >> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
> >>
> >> > SPI funct
e in plperl in terms of what perl code can be compiled.
It seems there is a plausable vector for trojan-horse code though, so I
think the key issue if this could be exploited in a security definer
scenario.
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
unchanged.
- The utf8fix code has been greatly simplified.
- More code comments re PGC_SUSET and no access to SPI functions.
Tim.
diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml
index 7018624..0999bd0 100644
*** a/doc/src/sgml/plperl.sgml
--- b/doc/src/sgml/p
7;s
only one DBI PostgreSQL driver: http://search.cpan.org/dist/DBD-Pg/
The only non-DBI interfaces I could find (by skimming the 384 results
for postgresql on search.cpan.org) were:
Postgres: http://search.cpan.org/dist/Postgres/last updated in 1998.
Pg: http://search.cpan.org/dist
On Sat, Feb 06, 2010 at 10:38:00PM -0800, Josh Berkus wrote:
>
> Add on_trusted_init and on_untrusted_init to plperl
> Package namespace and Safe init cleanup for plperl
Alex Hunsaker has marked the latest version of both of those
as Ready for Committer.
Tim.
--
Sent via pgsq
On Sun, Feb 07, 2010 at 08:25:33PM -0500, Andrew Dunstan wrote:
> Tim Bunce wrote:
> >This is the third update to the fourth of the patches to be split out
> >from the former 'plperl feature patch 1'.
> >
> >Changes in this patch:
> >
> >- Added
On Mon, Feb 08, 2010 at 01:44:16PM +, Tim Bunce wrote:
>
> > I'll continue reviewing the patch, but these things at least need fixing.
Here's an updated patch. The only changes relative to the previous
version are in the docs, as I outlined in the previous message.
[Sigh. This email, unlike the previous, actually includes the patch.]
On Mon, Feb 08, 2010 at 01:44:16PM +, Tim Bunce wrote:
>
> > I'll continue reviewing the patch, but these things at least need fixing.
Here's an updated patch. The only changes relative to the previous
eflect the needed doc changes in
http://archives.postgresql.org/message-id/20100208204213.gh1...@timac.local
That updated patch is in the commitfest
https://commitfest.postgresql.org/action/patch_view?id=271
>From talking to Andrew via IM I understand he's very busy, and also that
he'll be traveling on Sunday and Monday.
I certainly hope he can commit this patch today (along with the next
patch, which is also marked ready for committer) but if not, is there
someone else who could?
What happens to patches marked 'ready for committer' after the
commitfest ends?
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
i_fetchrow($sth) ) {
push(@mlx_area_ids, $row->{tl_domain_mlx_area_ids});
}
New:
@mlx_area_ids = call('tl_domain_mlx_area_ids(int,int,int)', $mlx_board_id,
$domain_id, $debug);
I've appended the POD documentation and attached the (rough but working)
test scri
On Fri, Feb 12, 2010 at 11:10:15PM +, Tim Bunce wrote:
> I've appended the POD documentation and attached the (rough but working)
> test script.
Oops. Here's the test script.
Tim.
create or replace function test_call() returns text language plperlu as $func$
use lib
e trust, or lack of it, placed in DBAs.
> Anyway reasons I can come up for it are:
> -its general so we can add other modules/pragmas easily in the future
> -helps with the plperl/plperlu all or nothing situation
> -starts to flesh out how an actual exposed (read documented) inte
cumented it's not supported.
> Another objection is that discussion on this facility has been
> pretty scant. I think that's putting it mildly. Maybe it's been
> apparent to a few people what the implications are, but I doubt it's
> been apparent to many
On Mon, Feb 15, 2010 at 07:31:14AM +, Richard Huxton wrote:
> On 12/02/10 23:10, Tim Bunce wrote:
> >There was some discussion a few weeks ago about inter-stored-procedure
> >calling from PL/Perl.
>
> >I'd greatly appreciate any feedback.
>
> Looks gre
On Sat, Feb 13, 2010 at 02:25:48PM -0800, David E. Wheeler wrote:
> On Feb 12, 2010, at 3:10 PM, Tim Bunce wrote:
>
> > I've appended the POD documentation and attached the (rough but working)
> > test script.
> >
> > I plan to release the module to CPAN i
so on_proc_exit will only be called if plperl_*_init() succeeds
(else there's a risk of on_proc_exit consuming all the exit hook slots)
- don't allow use of Safe version 2.21 as that's broken for PL/Perl.
Tim.
commit d8c0d4e63c00606db95f95a9c8f2b7ccf3c819b3
Author: Tim Bunce
On Mon, Feb 15, 2010 at 10:42:15AM +, Richard Huxton wrote:
> On 15/02/10 10:32, Tim Bunce wrote:
> >On Mon, Feb 15, 2010 at 07:31:14AM +, Richard Huxton wrote:
> >>
> >>Is there any value in having a two-stage interface?
> >>
> >>$seq_fn =
On Mon, Feb 15, 2010 at 10:51:14AM +, Tim Bunce wrote:
> On Sat, Feb 13, 2010 at 02:25:48PM -0800, David E. Wheeler wrote:
> > On Feb 12, 2010, at 3:10 PM, Tim Bunce wrote:
> >
> > > I've appended the POD documentation and attached the (rough but working)
>
On Mon, Feb 15, 2010 at 11:52:01AM -0800, David E. Wheeler wrote:
> On Feb 15, 2010, at 2:51 AM, Tim Bunce wrote:
>
> > The signature doesn't just qualify the selection of the function,
> > it also ensures appropriate interpretation of the arguments.
> >
> &
On Mon, Feb 15, 2010 at 02:58:47PM -0800, David E. Wheeler wrote:
> On Feb 15, 2010, at 2:42 PM, Tim Bunce wrote:
>
> > I've not really looked the the DBD::Pg code much so this seemed like a
> > good excuse... It looks like the default is to call PQprepare() with
> &g
On Tue, Feb 16, 2010 at 09:11:24AM -0800, David E. Wheeler wrote:
> On Feb 16, 2010, at 4:08 AM, Tim Bunce wrote:
>
> From the docs:
>
> > Immediately after the function name, in parenthesis, a comma separated list
> > of
> > type names can be given.
On Tue, Feb 16, 2010 at 04:42:29PM -0500, Andrew Dunstan wrote:
> Tim Bunce wrote:
> >On Sun, Feb 14, 2010 at 10:14:28PM -0500, Andrew Dunstan wrote:
> >>Robert Haas wrote:
> >>>We're down to 5 patches remaining, and 1 day remaining, so it's time
> >&g
On Tue, Feb 16, 2010 at 02:25:00PM -0800, David E. Wheeler wrote:
> On Feb 16, 2010, at 2:19 PM, Tim Bunce wrote:
>
> > p.s. One quick heads-up: David Wheeler has reported a possible issue
> > with Safe 2.21. I hope to investigate that tomorrow.
>
> Actually it'
u back for 9.1)!
Thanks Robert. That's nice to hear.
I'd be happy to do more for 9.1 (subject to the ongoing generosity of my
client http://TigerLead.com who are the ones to thank for my work on
PostgreSQL).
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
On Tue, Feb 16, 2010 at 02:13:30PM -0800, David E. Wheeler wrote:
> On Feb 16, 2010, at 2:06 PM, Tim Bunce wrote:
>
> >>> For varadic functions, separate plans are created and cached for each
> >>> distinct
> >>> number of arguments the function is call
Did this ever get turned into a formal bug report with a number?
Tim.
On Thu, Jan 14, 2010 at 07:39:09PM -0500, Andrew Dunstan wrote:
>
> Tim Bunce just showed me the following oddity:
>
>andrew=# SET SESSION plperl.use_strict = on;
>SET
>andrew=# SHOW
On Wed, Feb 17, 2010 at 10:30:03AM -0800, David E. Wheeler wrote:
> On Feb 17, 2010, at 4:28 AM, Tim Bunce wrote:
>
> >> Yes, but if it's a variadic function, I suspect that it won't often be
> >> called with the same number of args. So you'd potentially e
statement than can be justified.
The docs for Safe http://search.cpan.org/~rgarcia/Safe-2.23/Safe.pm#WARNING
say "The authors make no warranty, implied or otherwise, about the
suitability of this software for safety or security purposes".
Tim.
--
Sent via pgsql-hackers maili
directly checking "does this sv contains a reference".
The attached patch fixes the problem by changing the SvTYPE check to use
SvROK instead. Although I only tripped over one case, the patch changes
all four uses of SvTYPE(sv) == SVt_RV. The remaining uses of SvTYPE are ok.
Tim.
diff --gi
On Sun, Mar 07, 2010 at 12:11:26PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > I encountered a core dump running PL/Perl installcheck with a very
> > recent git HEAD of PostgreSQL and a not quite so recent git HEAD of perl.
>
> > The cause is a subtle difference betw
ntainer package name (a simple and sound security measure).
3. requires Safe 2.25 (which has assorted fixes, including security).
4. removed a harmless but suprious exclamation mark from the source.
Tim.
diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml
index c000463..0cc59c5 100644
*
On Mon, Mar 08, 2010 at 11:03:27AM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > Here's a patch that:
> > 1. adds wording like that to the docs.
> > 2. randomises the container package name (a simple and sound security
> > measure).
> > 3. requires Safe 2.2
On Mon, May 17, 2010 at 11:34:37AM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > Why do the release notes say this, under plperl:
> > * PL/Perl subroutines are now given names (Tim Bunce)
> > This is for the use of profiling and code coverage tools. DIDN&
> I thought the problem was that they upgraded the OS and now the encoding
> names changed, though they behaved the same. Is that now what is
> happening? Can they supply the values with different cases?
>
In my case I never touched the locale. It was set by the OS. I presume
this is true for m
On Mon, Jan 31, 2011 at 02:22:37PM -0500, Andrew Dunstan wrote:
>
>
> On 01/15/2011 12:31 AM, Alex Hunsaker wrote:
> >On Tue, Dec 7, 2010 at 07:24, Tim Bunce wrote:
> >>Changes:
> >>
> >>Sets the local $_TD via C instead of passing an extra argu
o the overhead of parsing the string and allocating the
array and all its elements.
- Some of those functions may not use the array at all and some may
simply pass it on as an argument to another function.
- Making the conversion lazy would be a big help.
Tim.
--
Sent via pgsql-hackers mailin
On Wed, Feb 02, 2011 at 12:10:59PM -0500, Andrew Dunstan wrote:
>
> On 02/02/2011 11:45 AM, Tim Bunce wrote:
> >>But why are we bothering to keep $prolog at
> >>all any more, if all we're going to pass it is&PL_sv_no all the
> >>time? Maybe we'll ha
On Thu, Feb 03, 2011 at 02:23:32PM +0200, Alexey Klyukin wrote:
> Hi,
>
> On Feb 2, 2011, at 7:16 PM, Tim Bunce wrote:
>
> > I'm sorry I'm late to this party. I haven't been keeping up with
> > pgsql-hackers.
>
> Better late than never :)
>
&g
nions, but...]
I can't see any major issues so I'm happy for you to move ahead.
Thanks!
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
al,
I'd assume encode_type_literal() encodes a _type_ as a literal.
I'd suggest encode_typed_literal() as a better name.
Tim [just passing though]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
would have
expected foreign keying from a materialised view to behave independently of
the FDW, as if from a regular local table.
FYI, I'm running postgresql 9.3.4
Cheers,
Tim
*.devices (device_id) );
ERROR: referenced relation "devices" is not a table
On Tue, Feb 17, 2015 at 1:08 PM, Tim Kane wrote:
> Hi all,
>
> Not sure if this has been reported already, it seems to be a variation on
> this thread:
>
> http://www.postgresql.org/m
[Sorry for the delay. I'd stopped checking the pgsql mailing lists.
Thanks to David Wheeler and Josh Berkus for the heads-up.]
On Sun, May 30, 2010 at 06:58:32PM -0400, Andrew Dunstan wrote:
>
> Tim Bunce wrote:
> >On Mon, May 17, 2010 at 11:34:37AM -0400, Tom Lane wrote:
&
herwise be challenging to automatically not
only delete the "$PostgreSQL$" line, but also leading and/or
trailing empty (comment) lines, and not mess up.
Tim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
in this thread is that
there doesn't seem to be a "usually" with regard to "\d"
equivalents either.
Tim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
; would seem odd for a database to tout its ability to deal with such
> data types as geometric shapes and global positioning, etc., which
> then didn't have such a common type as money. In my experience,
> many business applications deal with money.
One major flaw I see is that the f
Hi Aron,
Thanks for the input. The "small change" you suggest would change the
behavior of the patch which I would prefer not to do as I have reasons for
the previous behavior.
Because you gave no reasons and "stop after removing LIMIT LOs" was not
changed to "stop after attempting to remove LIMIT
-wE '$SIG{INT} = sub { say "Foo"}; { local %SIG; kill "INT", $$; };'
Foo
And, even worse, they're not reset at scope exit:
$ perl -wE '$SIG{INT} = sub { say "Foo"}; { local %SIG; $SIG{INT} = sub {say
"Bar" }} kill "INT", $$;'
Bar
That sure seems like a bug (I'll check with the perl5-porters list).
Localizing an individual element of %SIG works fine.
In C that's something like this (untested):
hv = gv_fetchpv("SIG", 0, SVt_PVHV);
keysv = ...SV containing "ALRM"...
he = hv_fetch_ent(hv, keysv, 0, 0);
if (he) { /* arrange to restore existing elem */
save_helem_flags(hv, keysv, &HeVAL(he), SAVEf_SETMAGIC);
}
else { /* arrange to delete a new elem */
SAVEHDELETE(hv, keysv);
}
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Aug 08, 2011 at 01:23:08AM -0600, Alex Hunsaker wrote:
> On Sun, Aug 7, 2011 at 17:06, Tim Bunce wrote:
>
> > Localizing an individual element of %SIG works fine.
> > In C that's something like this (untested):
> >
> > hv = gv_fetchpv("
log_line_prefix = '%m [%p] %d %u %h ' # Special values:
We're seeing this in postgresql 8.1.8 on AIX 5.3. Also, even though we're
using the same binaries for a bunch of clusters, we've only seen this issue
on one of them.
Any ideas of what could cause this?
--
Tim
ng that pipe, remember.
>
> BTW, although I'm blaming stdio here, it's conceivable that it is
> issuing messages in a single write() and the kernel is failing to keep
> the writes atomic, as I think is required by spec if the write is for
> less than PIPEBUF bytes. So Tim m
Hackers;
I've noticed a strangeness on our cross-compiled uclibc linked
postgresql package that I was hoping to elicit some help with.
This is probably best described by showing some queries with
commentary, so on with that.
postgres=# select count(*) from pg_timezone_names where utc_offset != '
On Sat, Nov 28, 2009 at 09:35:10AM -0500, Andrew Dunstan wrote:
>
> Tim Bunce wrote:
>> - Changed MULTIPLICITY check from runtime to compiletime.
>> No loads the large Config module.
>
> ISTM the trouble with this is that it assumes that the library that we
> comp
On Mon, Nov 30, 2009 at 12:50:41PM -0500, Andrew Dunstan wrote:
>
> Tim Bunce wrote:
>> In summary, changing between multiplicity and non-multiplicity libperls
>> after building postgresql isn't safe or supported.
>
> OK, good. Are you adding a check at load time that
n a perlchunks.h file which is #included
Additions since previous verion:
- Replaced calls to SvPV(val, PL_na) with SvPV_nolen(val)
- Simplifed plperl_safe_init() slightly
- Removed trailing whitespace from new plc_*.pl files.
I'd appreciate any feedback on the patch.
Tim.
diff --git a/doc/src/sgml
optimizations like pre-growing data structures.
I'm working on adding tests and documentation now, meanwhile I'd very
much appreciate any feedback on the patch.
Tim.
p.s. Once this patch is complete I plan to work on patches that:
- add quote_literal and quote_identifier functions in
On Thu, Dec 03, 2009 at 04:53:47PM -0800, David E. Wheeler wrote:
> On Dec 3, 2009, at 3:30 PM, Tim Bunce wrote:
>
> > - New GUC plperl.on_perl_init='...perl...' for admin use.
> > - New GUC plperl.on_trusted_init='...perl...' for plperl user use.
> >
es priority over that and forbids compiling
code that does a use/require.
I may end up re-enabling the require opcode but redirecting it to run
some C code in plperl.c (the same 'opcode redirection' technique used by
my NYTProf profiler). That C code would only need to throw an exceptio
On Thu, Dec 03, 2009 at 03:47:21PM -0800, Josh Berkus wrote:
> Tim,
>
> Since there's a commitfest on right now, meaningful feedback on your
> patch could be delayed. Just so you know.
Understood. Thanks Josh.
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
with mod_perl is very apt. Preloading code gives
dramatic performance gains in production situations where there's a
significant codebase and connections are frequent.
The docs for plperl.on_perl_init could include a section relating to
it's use with shared_preload_libraries. That could documen
hing that it
> does creates another opportunity to have a nonrecoverable failure.
> The postmaster can recover if a child crashes, but the other way
> round, not so much.
I hope the combination of disabling the SPI functions during
initialization, and documenting the risks of combining on_p
On Sat, Dec 05, 2009 at 11:41:36AM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > I'll modify the patch to disable the SPI functions during
> > initialization (both on_perl_init and on_(un)trusted_init).
>
> Yeah, in the shower this morning I was thinking that not lo
ike to point out that
the "JSON is a subset of YAML" meme is not without controversy:
http://search.cpan.org/~mlehmann/JSON-XS-2.26/XS.pm#JSON_and_YAML
It may not be relevant in your use-case, but I thought it worth a mention.
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.2) as a minimum for threads/multiplicity.
Perl 5.5 had complelely different, and unsafe, code for threads
and no concept of multiplicity.
I'd recommend Perl 5.8(.1) as a minimum for UTF-8 databases.
Perl 5.7 had a complelely different, and flawed, concept of
Unicode operation.
Tim.
p.
I've submitted this patch to the open CommitFest
https://commitfest.postgresql.org/action/patch_view?id=245
Tim.
On Wed, Nov 25, 2009 at 03:36:25PM +0000, Tim Bunce wrote:
> Following on from my earlier draft plperl.c refactoring patch, here's a
> new version that's complete
On Mon, Dec 21, 2009 at 10:09:58AM -0500, Tom Lane wrote:
> Magnus Hagander writes:
> > 2009/12/21 Robert Haas :
> >> On Mon, Dec 21, 2009 at 5:45 AM, Tim Bunce wrote:
> >>> plperl requires Safe v2.09, released in Oct 2003 and included in 5.8.1.
> >>> T
On Mon, Dec 21, 2009 at 08:22:54AM -0800, David E. Wheeler wrote:
> On Dec 21, 2009, at 7:18 AM, Tim Bunce wrote:
>
> >> Given the above three things it seems like we could define 5.8.1 as the
> >> minimum required version.
> >
> > I'd be delighted
uld be cast to text, I think.
>
> It's not doing that for me.
You're using 5.8.8. In 5.10.0 $^V was changed to be an object.
I'm working in that area. I'll look into it.
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Dec 25, 2009 at 12:54:13PM -0500, Andrew Dunstan wrote:
> Tim Bunce wrote:
>> I've attached an update of my previous refactoring of plperl.c.
>> It's been rebased over the current (git) HEAD and has a few
>> very minor additions.
>>
> [snip]
&
On Thu, Dec 24, 2009 at 11:08:49AM -0500, Andrew Dunstan wrote:
> Tim Bunce wrote:
>> I'm about ready to post the next draft of my plperl feature patch.
>>
>> When I looked at the diff I saw ~7800 lines of it were just due to
>> updating ppport.h. So I'v
directly to the client. That can be construed as a feature.
* Cache invalidation. How can I hook into an SP being dropped so I can
pro-actively invalidate the cache?
* Probably many other things I've not thought of.
This is all a little rough and exploratory at the moment.
I'm ver
On Thu, Dec 31, 2009 at 09:47:24AM -0800, David E. Wheeler wrote:
> On Dec 30, 2009, at 2:54 PM, Tim Bunce wrote:
>
> > That much works currently. Behind the scenes, when a stored procedure is
> > loaded into plperl the code ref for the perl sub is stored in a cache.
&g
On Tue, Jan 05, 2010 at 01:05:40PM -0800, David E. Wheeler wrote:
> On Jan 5, 2010, at 12:59 PM, Tim Bunce wrote:
>
> > So you're suggesting SP::foo(...) _always_ executes foo(...) via bunch
> > of spi_* calls. Umm. I thought performance was a major driving factor.
>
s dropped and recreated?
Assuming it does, or there's some other need to free/recreate plans,
then I can add a function call to do that (by recording a reference
to the $h's in the example above and using that to undef them).
Does the above sound workable? Anything I've missed?
Tim
On Tue, Jan 05, 2010 at 06:54:36PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Thu, Dec 31, 2009 at 09:47:24AM -0800, David E. Wheeler wrote:
> >> Definite benefit, there. How does it handle the difference between
> >> IMMUTABLE | STABLE | VOLATILE, as well as
On Tue, Jan 05, 2010 at 07:06:35PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > The only question I have at the moment, before I try implementing this,
> > is the the need for freeing the plan. When would that be needed?
>
> There's probably no strong need to
that 5.8 was the lowest safe version because of utf8 and other
> > considerations.
>
> +1, and 5.8.3 at a minimum for utf8 stuff, 5.8.8 much much better.
I think we said 5.8.1 at the time, but 5.8.3 sounds good to me.
There would be _very_ few places using < 5.8.6.
Tim.
--
Sen
ere to stash the the results at all.
>
> Whatever do you mean by "take effect in the caller's context"? I surely
> hope it's not "return the row to the caller's caller, who likely isn't
> expecting anything of the kind".
>
> I suspect
SELECT * FROM bar(); -- throws exception normally
SELECT * FROM foo(); -- causes the server to exit abnormaly
before then rereading the 8.4.2 release notes and seeing that the bug
was already fixed. D'oh!
I see the test suite doesn't have any plperlu tests at all.
Is there any re
multi.sql
file and add logic to the GNUmakefile to add that file to REGRESS
if "perl -V:usemultiplicity" returns "usemultiplicity='define';"
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 06, 2010 at 08:46:11PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Wed, Jan 06, 2010 at 01:45:45PM -0800, David E. Wheeler wrote:
> >> On Jan 6, 2010, at 12:20 PM, Tom Lane wrote:
> >>> One of the things on my to-do list for today is to make config
1 - 100 of 206 matches
Mail list logo
