d not wait for another year for it.
Given this is a one-liner, which doesn't introduce any new code, but
one flag to the function call, would it be
possible to review it as a part of the current commitfest?
Kind regards,
--
Alexey Klyukin
--
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, Sep 15, 2014 at 10:23 AM, Alexey Klyukin wrote:
> On Fri, Sep 12, 2014 at 4:20 PM, Heikki Linnakangas
> wrote:
>
>>> Hmm. If that's what the browsers do, I think we should also err on the
>>> side of caution here. Ignoring the CN is highly unlikely to
g, I don't have particularly strong arguments for either
of the possible behaviors, so sticking to RFC makes sense here
Sincerely,
--
Alexey Klyukin
--
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, Sep 8, 2014 at 8:04 PM, Heikki Linnakangas
wrote:
> On 09/05/2014 07:30 PM, Alexey Klyukin wrote:
>> The error does not state whether the names comes from the CN or from
>> the SAN section.
>
>
> I'd reword that slightly, to:
>
> psql: server certifi
ooks to me the least ugly of anything else I
could come up (i.e. extracting those names at the time the error
message is shown).
Regards,
--
Alexey Klyukin
diff --git a/src/interfaces/libpq/fe-secure-openssl.c
b/src/interfaces/libpq/fe-secure-openssl.c
new file mode 100644
index f950fc3..a4ad3
names, but I do not like collecting
them just for the sake of displaying in the error message.
And last one is to just show the error without mentioning names,
that's what I've chosen to be the most consistent.
Regards,
--
Alexey Klyukin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
flag to off.
I do not know much about the WAL-related code, but one thing that I
found strange
in the patch is a separate file xlogarchive.h instead of putting
stuff into xlog.h?
Does not make much sense for a single enum, are you planning to put
more things there?
There was a single hunk when ap
On Mon, Sep 1, 2014 at 10:39 AM, Alexey Klyukin wrote:
> On Fri, Aug 29, 2014 at 11:22 AM, Heikki Linnakangas
> wrote:
>> Yeah, I think a certificate without CN should be supported. See also RFC
>> 6125, section 4.1. "Rules" [for issuers of certificates]:
>>
&g
On Fri, Aug 29, 2014 at 11:22 AM, Heikki Linnakangas
wrote:
>
> On 08/28/2014 07:28 PM, Alexey Klyukin wrote:
>>
>> On Mon, Aug 25, 2014 at 12:02 PM, Heikki Linnakangas <
>> hlinnakan...@vmware.com> wrote:
>>
>>> On 08/24/2014 03:11 PM, Alexey Klyukin
d CVEs.
>
Sounds reasonable.
>
> I guess we'll go ahead with this patch for now, but keep this in mind if
> someone wants to complicate the rules further in the future.
+1
--
Regards,
Alexey Klyukin
On Mon, Aug 25, 2014 at 12:02 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 08/24/2014 03:11 PM, Alexey Klyukin wrote:
>
>> On Wed, Aug 20, 2014 at 11:53 AM, Heikki Linnakangas <
>> hlinnakan...@vmware.com> wrote:
>>
>>>
>&g
ver will be unable to
restart, but this are the sort of problems that also happen with reload of
pg_hba.conf as well, so these alone does not sound like a significant
showstopper.
--
Regards,
Alexey Klyukin
On Wed, Aug 20, 2014 at 11:53 AM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 07/25/2014 07:10 PM, Alexey Klyukin wrote:
>
>> Greetings,
>>
>> I'd like to propose a patch for checking subject alternative names entry
>> in
>&g
ch happens if the
pg_strcasecmp
finds a match between the given dNSName and the name supplied by the client.
>
> Please add it to the next CF - this was just a very quick review, and
> it needs a proper one along with openssl version testing :)
>
Done.
Sincerely,
--
Alexey Klyukin
ers,
Linux and Mac clients). I don't have either Windows or old versions of
OpenSSL, it's not tested against those systems.
I'd appreciate your feedback.
Sincerely,
--
Alexey Klyukin
diff --git a/src/interfaces/libpq/fe-secure.c b/src/interfaces/libpq/fe-secure.c
new file mode 1006
't be there in the first place.
Cheers,
--
Alexey Klyukin
(we originally
discovered it in the server logs, likely because the autovacuum was also
failing). Any hints on what's going on (and whether the data corruption is
a possibility)?
Cheers,
--
Alexey Klyukin
Hi Martijn,
On Sun, Nov 17, 2013 at 7:56 PM, Martijn van Oosterhout
wrote:
> On Sat, Nov 16, 2013 at 09:26:33PM +0100, Alexey Klyukin wrote:
> > Hi,
> >
> > Attached is the patch that improves usage of '*' wildcard in .pgpass,
> > particularly in the host p
an interest in making this patch a part of the core.
Your feedback is greatly appreciated.
--
Regards,
Alexey Klyukin
diff --git a/src/interfaces/libpq/fe-connect.c
b/src/interfaces/libpq/fe-connect.c
new file mode 100644
index 18fcb0c..003739f
*** a/src/interfaces/libpq/fe-connec
URL syntax, to
> connect to a non-default UNIX socket, you need to create the URL object
> directly.
>
> How about the "service" option, that's a nice way of handling
> non-default socket options.
Another idea is to use local:/dir/name for UNIX domain socket instead
to-non-rowtype-result-type cases
> throw errors, rather than returning the rather useless ARRAY(...) and
> HASH(...) strings as pre-9.1 did?
No objections here.
--
Alexey Klyukinhttp://www.commandprompt.com
The PostgreSQL Company – Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
effect is you can now return a composite literal where you
> could not before. ( We already let you return array literals )
>
> The comments might still be a bit sparse-- Im hoping the added errors
> make things a bit more self explanatory.
>
> A large portion of the diff is
nly
> one gets applied. I think ACID(-like) changes is a feature, also on
> this level.
>
I think exactly this argument has already been discussed earlier in this thread:
http://archives.postgresql.org/message-id/21310d95-eb8d-4b15-a8bc-0f05505c6...@phlo.org
--
Alexey Klyukinhttp://
6456 is the oid of the child table.
It seems that the pg_constraint scan at ATExecDropConstraint (tablecmds.c:6751)
is re-reading those tuples that were updated in the previous iterations of this
scan, at least that's what I've observed in gdb. I'm not sure how to fix this
ye
If others
will be opposed to changing the set_config_option, I'll fix this by removing
the first, verification call and final 'errors were detected' warning to avoid
'false positives' on that (i.e. the WARNING you saw with the previous version
for the valid .conf).
I
call of this function
per var. What do you think about changing the code above to return true if the
variable is actually unchanged?
This explains the WARNINGs emitted during reload even for a pristine
configuration file right after the installation. I'm looking into why the
server gets
On Aug 4, 2011, at 5:25 PM, Alvaro Herrera wrote:
> Excerpts from Hannu Krosing's message of jue ago 04 09:53:40 -0400 2011:
>> On Thu, 2011-08-04 at 09:42 -0400, Andrew Dunstan wrote:
>>>
>>> On 08/04/2011 09:07 AM, Hannu Krosing wrote:
>
I have been helping some people to debug a SIGALAR
On Jul 16, 2011, at 9:55 PM, Tom Lane wrote:
> I wrote:
>> I think that it might be sensible to have the following behavior:
>
>> 1. Parse the file, where "parse" means collect all the name = value
>> pairs. Bail out if we find any syntax errors at that level of detail.
>> (With this patch, we
On Jul 14, 2011, at 4:38 AM, Alvaro Herrera wrote:
> Excerpts from Florian Pflug's message of mié jul 13 20:12:28 -0400 2011:
>> On Jul14, 2011, at 01:38 , Alvaro Herrera wrote:
>>> One strange thing here is that you could get two such messages; say if a
>>> file has 100 parse errors and there ar
Hi,
On May 27, 2011, at 11:43 PM, Alvaro Herrera wrote:
>
> One of our customers is interested in being able to store original
> timezone along with a certain timestamp.
>
> It is currently possible to store a TZ in a separate column, but this is
> a bit wasteful and not very convenient anyway.
On Jun 21, 2011, at 9:58 PM, Noah Misch wrote:
>
> A pg_regress test needs stable output, so we would do it roughly like this:
>
> CREATE TEMP TABLE relstorage AS SELECT 0::regclass AS oldnode;
> ...
> UPDATE relstorage SET oldnode =
> (SELECT relfilenode FROM pg
Hi,
On Jun 19, 2011, at 2:10 PM, Noah Misch wrote:
> On Sat, Jun 18, 2011 at 11:32:20PM -0400, Robert Haas wrote:
>> On Sat, Jun 18, 2011 at 11:12 PM, Robert Haas wrote:
>>> On Sat, Jun 18, 2011 at 11:06 PM, Noah Misch wrote:
On Sat, Jun 18, 2011 at 10:57:13PM -0400, Robert Haas wrote:
>>>
On Jun 20, 2011, at 6:22 PM, Florian Pflug wrote:
> On Jun20, 2011, at 17:02 , Alexey Klyukin wrote:
>>
>> I don't think it has changed at all. Previously, we did goto cleanup_list (or
>> cleanup_exit in ParseConfigFp) right after the first error, no matter whether
&
Florian,
On Jun 18, 2011, at 5:40 PM, Florian Pflug wrote:
> On Jun16, 2011, at 22:34 , Alexey Klyukin wrote:
>> Attached is the v2 of the patch to show all parse errors at postgresql.conf.
>> Changes (per review and suggestions from Florian):
>>
>> - do not sto
Hi,
On Jun 16, 2011, at 9:18 PM, Florian Pflug wrote:
> On Jun16, 2011, at 20:14 , Alexey Klyukin wrote:
>>
>> Well, while thinking about this I decided to leave the counter for the
>> ParseConfigFp, but
>> drop it in ProcessConfigFile. The case we are protecting a
On Jun 16, 2011, at 8:01 PM, Florian Pflug wrote:
> On Jun16, 2011, at 18:46 , Alexey Klyukin wrote:
>> On Jun 16, 2011, at 6:49 PM, Florian Pflug wrote:
>>> Hm, wouldn't a test for "context == PGC_POSTMASTER" be more appropriate?
>>
>> In such a cas
On Jun 16, 2011, at 6:49 PM, Florian Pflug wrote:
> On Jun16, 2011, at 17:23 , Alexey Klyukin wrote:
>> On Jun 16, 2011, at 2:34 PM, Florian Pflug wrote:
>>> The first problem I ran into when I tried to test this is that it *only*
>>> reports multiple errors during
Florian,
On Jun 16, 2011, at 2:34 PM, Florian Pflug wrote:
> Hi
>
> On May14, 2011, at 00:49 , Alexey Klyukin wrote:
>> The patch forces the parser to report all errors (max 100) from the
>> ProcessConfigFile/ParseConfigFp. Currently, only the first parse error or an
&g
Noah,
Providing my thoughts on the 'mundane' question first.
On Tue, May 24, 2011 at 1:40 PM, Noah Misch wrote:
>
> I also had a more mundane design question in the second paragraph of [2]. It
> can probably wait for the review of the next version of the patch. However,
> given that it affects
On Jun 2, 2011, at 10:49 PM, Tom Lane wrote:
> Alexey Klyukin writes:
>> We've recently come across the task of estimating the size of shared memory
>> required for PostgreSQL to start.
>
>> ...
>
>> - Try to actually allocate the shared memory in a way
Hi,
On Jun 2, 2011, at 10:22 PM, Noah Misch wrote:
> Hi Alexey,
>
...
> Is your interest in cheap varchar(N)->varchar(N+M) conversions specifically,
> or
> in some broader application of this facility?
Exactly varchar conversions.
>
> Thanks for volunteering to review; that will be a big hel
Hello,
We've recently come across the task of estimating the size of shared memory
required for PostgreSQL to start. This comes from the problem of validating
postgresql.conf files
(http://archives.postgresql.org/pgsql-hackers/2011-03/msg01831.php), i.e.
checking that the server will be able to st
along the lines of "PLAN TRANSFORM FUNCTION
> helperfunctionname". Then again, that wrongly sounds somewhat like it's
> transforming planner nodes. Perhaps plain TRANSFORM or TRANSFORM FUNCTION
> would
> be the way to go.
Looks like this thread has silently died
On May 13, 2011, at 2:07 AM, Alexey Klyukin wrote:
> On May 13, 2011, at 1:28 AM, Tom Lane wrote:
>
>>
>> We're not likely to do that, first because it's randomly different from
>> the handling of every other system catalog update, and second because it
>
Hi,
On Apr 14, 2011, at 9:50 PM, Robert Haas wrote:
> On Mon, Apr 4, 2011 at 2:03 PM, Alexey Klyukin
> wrote:
>> Here's the update of Selena's patch, which also shows all errors in
>> configuration parameters (as well as parser errors) during reload.
>
> Yo
On May 13, 2011, at 1:28 AM, Tom Lane wrote:
> Alexey Klyukin writes:
>> After digging in the code I've found that a RowExclusiveLock is acquired on
>> a pg_db_role_setting table in AlterSetting(). While the name of the locks
>> suggests that it should conflict with
itself, it doesn't. After I've replaced
the lock in question with ShareUpdateExclusiveLock, the problem disappeared.
Attached is the simple patch with these changes.
Regards,
--
Alexey Klyukin
The PostgreSQL Company - Command Prompt, Inc.
db_role_setting.diff
Description: Binary da
On Apr 1, 2011, at 12:08 AM, Alexey Klyukin wrote:
> Hi Selena,
>
> On Mar 30, 2011, at 11:42 PM, Selena Deckelmann wrote:
>
>> Hi!
>>
>> On Wed, Mar 30, 2011 at 8:40 AM, Alexey Klyukin
>> wrote:
>>
>>
>> I did a little bit
Hi Selena,
On Mar 30, 2011, at 11:42 PM, Selena Deckelmann wrote:
> Hi!
>
> On Wed, Mar 30, 2011 at 8:40 AM, Alexey Klyukin
> wrote:
>
>
> I did a little bit of work on this, and we discussed it here:
>
> http://archives.postgresql.org/pgsql-hackers/
would be available in the server's log. It's possible to address these
shortcomings in the future.
Ideas, suggestions are welcome.
--
Alexey Klyukin
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
On Feb 15, 2011, at 7:45 PM, David E. Wheeler wrote:
> On Feb 15, 2011, at 6:39 AM, Alexey Klyukin wrote:
>
>> After I re-added the closing in plperl.sgml:235 these errors
>> disappeared, and the
>> resulting html looks fine too. v10 with just this single change is a
On Feb 12, 2011, at 9:53 AM, Alex Hunsaker wrote:
> On Fri, Feb 11, 2011 at 17:17, Alexey Klyukin wrote:
>
> Anyway in playing with this patch a bit more I found another bug
> return [[]]; would segfault.
>
> So find attached a v9 that:
> - fixes above
On Feb 10, 2011, at 11:26 PM, Alexey Klyukin wrote:
> On Feb 10, 2011, at 9:44 PM, Andrew Dunstan wrote:
>
>> On 02/10/2011 08:15 AM, Alexey Klyukin wrote:
>>>
>>> Let me try implementing that as an XS interface to plperl_array_to_datum.
>>
>>
>&g
On Feb 10, 2011, at 9:44 PM, Andrew Dunstan wrote:
>
>
> On 02/10/2011 08:15 AM, Alexey Klyukin wrote:
>> On Feb 9, 2011, at 9:28 PM, Alex Hunsaker wrote:
>>
>>> On Wed, Feb 9, 2011 at 08:24, Alexey Klyukin
>>> wrote:
>>>> What was
On Feb 9, 2011, at 9:28 PM, Alex Hunsaker wrote:
> On Wed, Feb 9, 2011 at 08:24, Alexey Klyukin wrote:
>>
>> What was actually broken in encode_array_literal support of composite types
>> (it converted perl hashes to the literal composite-type constants, expanding
>&
it would be a useful extension of the
existing encode_array_literal.
/A
--
Alexey Klyukin
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Feb 6, 2011, at 9:43 AM, Alex Hunsaker wrote:
> On Thu, Feb 3, 2011 at 18:29, Alex Hunsaker wrote:
>> On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin
>> wrote:
>>> I've looked at the patch and added a test for arrays exceeding or equal
>>> maximum dime
muti-dimensional arrays to a perl function one would need to
convert it to the array references anyway.
>
> - Making the conversion lazy would be a big help.
Converting it to string is already lazy, and, per the argumens above, I don't
see a real benefit of lazy conversion to the p
On Jan 29, 2011, at 12:27 AM, Alex Hunsaker wrote:
> On Thu, Jan 27, 2011 at 03:38, Alexey Klyukin wrote:
>> Hi,
>>
>> On Jan 27, 2011, at 9:31 AM, Alex Hunsaker wrote:
>>
>>> Find attached v3 of the patch. changes include:
>>> - fix deep rec
hed is the simple fix for that.
/A
--
Alexey Klyukin
The PostgreSQL Company - Command Prompt, Inc.
array_error_msg_fix.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
only a minor suggestion, I think is_array is worth mentioning in the utility
functions chapter of the pl/perl documentation, it would be also more clear to
use it in regression tests as opposed to manually checking whether the ref is
equal to 'PostgreSQL::InServer::ARRAY'.
/A
--
On Jan 26, 2011, at 10:08 PM, Alex Hunsaker wrote:
> On Wed, Jan 26, 2011 at 12:44, Alexey Klyukin wrote:
>> Hi,
>>
>> On Jan 26, 2011, at 8:45 PM, Alex Hunsaker wrote:
>>
>>> On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker wrote:
>>>> On Wed, Ja
Hi,
On Jan 26, 2011, at 8:45 PM, Alex Hunsaker wrote:
> On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker wrote:
>> On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin
>> wrote:
>>>
>>> On Jan 12, 2011, at 8:52 PM, David E. Wheeler wrote:
>>>
>>>
wing out the
compatibility option. There are many other reasons except for PL/Perl for
people to upgrade to 9.1, let's not force them to rewrite their Perl code
if they were not planning to do that.
/A
--
Alexey Klyukin
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-
On Jan 12, 2011, at 8:52 PM, David E. Wheeler wrote:
> On Jan 12, 2011, at 5:14 AM, Alexey Klyukin wrote:
>
>> You mean packing both a string representation and a reference to a single SV
>> * value?
>
> Dunno, I'm not a guts guy.
Well, neither me (I haven'
ward-compatibility GUC at all, ISTM that you ought to get the good
> stuff unless you ask for the old way.
I think the number of people failing to notice the changes would be the same
whenever we set the new or the old behavior by default. I decided to default to
the the old behavior since it
On Jan 12, 2011, at 1:07 AM, David E. Wheeler wrote:
> On Jan 11, 2011, at 2:25 PM, Alexey Klyukin wrote:
>
>> Hello,
>>
>> Here's the patch that improves handling of arrays as pl/perl function input
>> arguments, converting postgres arrays of arbitrary dimen
uct was
added. Arrays as members of composite types are also handled in
plperl_hash_from_tuple.
/A
--
Alexey Klyukin
The PostgreSQL Company - Command Prompt, Inc.
pg_to_perl_arrays.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
to one-dimensional resulting
arrays. If there's an interest in that approach I can update it for the
current code base, add support multi-dimensional arrays (I used to implement
that, but lost the changes accidentally) and post it for review.
/A
--
Alexey Klyukin
ake sense.
The original proposal didn't mention them, but limited the list of initially
supported objects to those to tables, views and sequences, implicitly
excluding synonyms referring to another synonyms.
--
Alexey Klyukin http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
from? We can consider adding
column synonyms if we won't hardwire synonyms to pg_class objects.
--
Alexey Klyukin http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Nov 30, 2010, at 6:28 PM, Tom Lane wrote:
> Alexey Klyukin writes:
>> To support addition of new database objects types that can be referenced by
>> synonyms a new system catalog, pg_synonym, is to be added, with an oid to
>> support comments on synonym, and the follow
ing a referenced object without removing the
synonym first (without using CASCADE). On DROP SYNONYM the related dependency
will be removed.
--
Alexey Klyukin http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc
--
Sent via pgsql-hackers mailing
erent OS X versions in
postgres sources (any suggestions?).
Regards,
--
Alexey Klyukin http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
guage can do is to
> define a *whitelist* of what it can do, not a blacklist of what it
> can't do. That's the only way to get a complete definition. It's then
> up to the implementation step to figure out how to represent that in
> the form of tests.
Yes, PL/Perl is
t. However,
there is one in CVS:
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/port/sprompt.c?only_with_tag=REL7_4
This looks like the initial synchronization issue, since this file is there for
really long time and appears not to be touched by any commit since 2003.
--
Alex
Hi,
Is there a reason why only a table free SQL functions are allowed to be inlined
? I wonder why a simple SQL function containing only a SELECT * FROM table
can't be expanded inline ? Is there an interest in expanding the class of SQL
functions that can be inlined ?
Thanks,
--
A
On Feb 11, 2010, at 7:07 PM, Andrew Dunstan wrote:
>
>
> Alexey Klyukin wrote:
>> On Feb 11, 2010, at 6:24 PM, Andrew Dunstan wrote:
>>
>>
>>> Alexey Klyukin wrote:
>>>
>>>> Hello,
>>>>
>>>> When devel
On Feb 11, 2010, at 6:24 PM, Andrew Dunstan wrote:
>
>
> Alexey Klyukin wrote:
>> Hello,
>>
>> When developing pl/perlu functions common definitions and methods are often
>> stored in external .pm modules. During deployment the modules should be
>
a user to specify such
location by adding a new custom GUC variable.
--
Alexey Klyukin http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
8.2.
plperl_db.diff
Description: Binary data
--
Alexey Klyukin http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Jan 22, 2010, at 4:38 PM, Robert Haas wrote:
> On Fri, Jan 22, 2010 at 9:13 AM, Alexey Klyukin wrote:
>> I think elog(WARNING) is less surprising for the end-user, unless there's an
>> objection strong enough to include it into the documentation :)
>
> I think t
annoyingly verbose, which
> is probably why the original patch didn't make them have a higher level in
> Postgres. If this were a big issue we'd have surely heard about it before now
> - there are plenty of plperl users out there.
I think elog(WARNING) is less surprising fo
On Nov 29, 2009, at 4:40 AM, Tom Lane wrote:
> Alexey Klyukin writes:
>
>> Isn't it also the case with the existing plperl code ? I've noticed that
>> free(prodesc) is called when it's no longer used (i.e. in
>> plperl_compile_callback:1636), b
The patch is attached.
Anybody interested in this feature ? Ideas, improvements, suggestions ?
Regards,
--
Alexey Klyukin http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc
plperl_array.diff
Description: Binary data
--
Sent via pgsql-hacke
when it's no longer used (i.e. in
plperl_compile_callback:1636), but refcount of desc->reference is never
decremented.
--
Alexey Klyukin http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc
--
Sent via pgsql-hackers mailing list (pgsql
On Nov 20, 2009, at 2:04 AM, Joshua Tolley wrote:
> On Wed, Nov 18, 2009 at 12:38:00PM +0200, Alexey Klyukin wrote:
>> Yes, current_call_data can't be allocate in the SPI memory context, since
>> it's used to extract the result after SPI_finish is called, althou
rent_call_data initialization.
I also noticed that no error context is set in the inline handler, not sure
whether it really useful except for the sake of consistency, but in case it is
- here is the patch:
inline_callback.diff
Description: Binary data
--
Alexey Klyukin
cutable.
1895spi_rv = SPI_execute(query,
current_call_data->prodesc->fn_readonly,
(gdb) bt
#0 0x0001006f0336 in plperl_spi_exec (query=0x1007ecb60 "select 1",
limit=0) at plperl.c:1895
Also, a call to to plperl_call_perl_func should be cast to void to avoid a
pos
On Oct 31, 2009, at 7:30 PM, Tom Lane wrote:
Alexey Klyukin writes:
One of our customers is running 8.2.14 and use a couple of pl/perl
and
pl/perlu functions written by CMD. Everything worked normally until
they tried to call one particular pl/perl function from pl/perl via
spi. It appears
1650c9 in PostmasterMain (argc=3, argv=0x100500470) at
postmaster.c:966
#21 0x000100119f89 in main (argc=3, argv=0x100500470) at main.c:188
(gdb) s
Program exited with code 0377.
--
Alexey Klyukin http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.cgi/pgsql/src/pl/plperl/plperl.c.diff?r1=1.136;r2=1.136.2.2
>> >
>
>
> We haven't put out an 8.3 release that includes that patch yet.
>
Thanks, Andrew, this patch solved the problem.
--
Alexey Klyukin .commandprompt.com
The PostgreSQL Company - Command Prompt, Inc
pltemplate = (PLTemplate *) 0x847990
handlerOid = 0
valOid =
funcrettype =
funcargtypes =
__func__ = "CreateProceduralLanguage"
#23 0x001acca8 in MemoryContextSwitchTo [inlined] () at palloc.h:1173
__func__ = "PortalRunUtility"
#
On Jul 21, 2009, at 7:47 PM, Alexey Klyukin wrote:
On Jul 21, 2009, at 7:20 PM, Alvaro Herrera wrote:
Alexey Klyukin wrote:
NOTICE: Test from function one
CONTEXT: PL/Perl function "perl_log1"
SQL statement "SELECT * FROM perl_log1()"
PL/Perl function "perl_log
On Jul 21, 2009, at 7:20 PM, Alvaro Herrera wrote:
Alexey Klyukin wrote:
NOTICE: Test from function one
CONTEXT: PL/Perl function "perl_log1"
SQL statement "SELECT * FROM perl_log1()"
PL/Perl function "perl_log1"
Shouldn't the second "PL/Perl fu
On Jul 21, 2009, at 6:39 PM, Alvaro Herrera wrote:
Alexey Klyukin wrote:
Attached is a patch (HEAD) that sets errcontext with PL/Perl function
name, making a distinction between compilation and execution stages,
fixes error messages where function name was already included in the
message
tself and updates regression tests. I'll appreciate any
suggestions on how to improve it.
plperl_error_callback.diff
Description: Binary data
--
Alexey Klyukin http://www.CommandPrompt.com
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list (pgs
eue manager gets a
message from the process it may signal that process to copy the next
message from the process local memory into the shmem. To keep a
correct ordering of queue messages an additional shared memory queue of
pid_t can be maintained, containing one pid per each message.
--
Alexey Kl
> 6) Do we want to distinguish between "restart only" settings, and
>reloadable settings, and if so, how?
I think now, since we don't digstinguish between them when writing the
config file manually.
--
Alexey Klyukin http://www.commandprompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 6: explain analyze is your friend
ex
> to file index.c for example?
> Thank,
>
> --
> Pedro Belmino.
>
> # Ciência da Computação - UNIFOR
> # [EMAIL PROTECTED]
> ---------
1 - 100 of 111 matches
Mail list logo
