On Wed, Jul 25, 2012 at 1:29 AM, Merlin Moncure wrote:
> On Tue, Jul 24, 2012 at 4:59 PM, Marko Kreen wrote:
>> So if we give only PQgetResult() in 9.2, I do not see that we
>> are locked out from any interesting optimizations.
>
> Well, you are locked out of having PQgetRe
On Wed, Aug 1, 2012 at 6:18 PM, Tom Lane wrote:
> Marko Kreen writes:
>> * Is there better API than PQsetSingleRowMode()? New PQsend*
>> functions is my alternative.
>
> After thinking it over, I'm really unexcited about adding new versions
> of all the PQs
On Thu, Aug 2, 2012 at 8:19 AM, Tom Lane wrote:
> Marko Kreen writes:
>> On Wed, Aug 1, 2012 at 6:18 PM, Tom Lane wrote:
>>> So I'm working from the first set of patches in your message
>>> <20120721194907.ga28...@gmail.com>.
>
>> Great!
>
&g
On Fri, Aug 3, 2012 at 12:01 AM, Tom Lane wrote:
> Marko Kreen writes:
>> On Thu, Aug 2, 2012 at 8:19 AM, Tom Lane wrote:
>>> In principle I suppose we could hack PQconsumeInput enough that it
>>> didn't damage the row buffer while still meeting its API contrac
On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian wrote:
> Is there a TODO here?
There is still open ToDecide here:
1) Status quo - md5() in core, everything else in pgcrypto
2) Start moving other hashes as separate functions into core: eg. sha1()
Problems:
- sha1 will be obsolete soon, like md5
-
On Wed, Aug 15, 2012 at 4:48 PM, Tom Lane wrote:
> Marko Kreen writes:
>> On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian wrote:
>>> Is there a TODO here?
>
>> There is still open ToDecide here: [snip]
>
> The argument against moving crypto code into core remain
On Wed, Sep 26, 2012 at 5:36 PM, Dimitri Fontaine
wrote:
> After much distractions I've at least been able to do something about
> that bug report.
Thanks.
>> 2) If there is schema with functions, but nothing else,
>> create extension pgq_coop from 'unpackaged';
>> drop extension pgq_coop;
>> cr
On Wed, Sep 26, 2012 at 7:15 PM, Dimitri Fontaine
wrote:
> Marko Kreen writes:
>>> Can we work out a minimal example to reproduce the bug?
>>
>> Yes, the above text or sql/pgq_coop/sql/pgq_coop_init_ext.sql
>>
>> I guess you could replace pgq_coop with any
On Wed, Oct 10, 2012 at 3:36 PM, Simon Riggs wrote:
> On 10 October 2012 11:41, Heikki Linnakangas wrote:
>> Thoughts on that?
>
> I think there has been enough discussion of md5 problems elsewhere
> that we should provide an alternative.
>
> If we can agree on that bit first, we can move onto ex
On Fri, Oct 12, 2012 at 10:47 PM, Stephen Frost wrote:
> * Marko Kreen (mark...@gmail.com) wrote:
>> As it works only on connect
>> time, it can actually be secure, unlike user switching
>> with SET ROLE.
>
> I'm guessing your issue with SET ROLE is that a RESET R
On Wed, Oct 10, 2012 at 4:24 PM, Marko Kreen wrote:
> The SCRAM looks good from the quick glance.
SCRAM does have weakness - the info necessary to log in
as client (ClientKey) is exposed during authentication
process.
IOW, the stored auth info can be used to log in as client,
if the attac
On 2/5/10, Josh Berkus wrote:
> > I think another difference is that the Perl DBI interface is very rich,
> > whereas the Python DB-API is quite minimal and almost forces people to
> > write (incompatible) extensions. The DB-SIG at Python that ought to
> > drive all this is also quite dead, p
On 2/5/10, Greg Smith wrote:
> The issues here have already been identified: the Perl DBI is an excellent
> spec, while the Python one is so weak everybody ends up needing their own
> extensions to it. And then portability *even among Python PostgreSQL
> drivers* goes out the window.
Well, no.
On 2/7/10, Greg Smith wrote:
> Marko Kreen wrote:
> > Psycopg was the leader, especially in web-environments,
> > but it has non-obvious license and with dead website it does not
> > seem that attractive. Although it is well-maintained still.
> > Best path forward wo
On 2/7/10, Robert Haas wrote:
> On Sat, Feb 6, 2010 at 7:48 PM, Marko Kreen wrote:
> > This is long-term todo item for psycopg, seems offtopic
> > to the "driver situation".
>
> [...]
>
> > This is routine bug in either app or psycopg, we have no reason
On 2/11/10, Tollef Fog Heen wrote:
> | I disagree. I have clients who have problems with leftover client
> connections
> | due to server host failures. They do not write apps in C. For a non-default
> | change to be effective we would need to have all the client drivers, eg
> JDBC,
> | psyco
On 2/24/10, Rémi Zara wrote:
> Pika, which has been upgraded to NetBSD/mips 5.0.2, failed twice in a row
> pgcrypto/test sha2 because of the following warning (identical each time) :
>
> Anything I should try ?
Please try --without-openssl.
--
marko
--
Sent via pgsql-hackers mailing list
On 2/24/10, Rémi Zara wrote:
> Le 24 févr. 2010 à 01:04, Marko Kreen a écrit :
> > On 2/24/10, Rémi Zara wrote:
> >> Pika, which has been upgraded to NetBSD/mips 5.0.2, failed twice in a row
> pgcrypto/test sha2 because of the following warning
On 4/18/10, Simon Riggs wrote:
> On Sat, 2010-04-17 at 16:48 -0400, Tom Lane wrote:
> > There are some places where we suppose that a *single* write into shared
> > memory can safely be done without a lock, if we're not too concerned
> > about how soon other transactions will see the effects.
On 4/23/10, Tom Lane wrote:
> Marko Kreen writes:
> > Um, you have been burned by exactly this on x86 also:
> > http://archives.postgresql.org/pgsql-hackers/2009-03/msg01265.php
>
>
> Yeah, we never did figure out exactly how come you were observing that
> failur
On Fri, May 4, 2012 at 8:45 PM, Peter Eisentraut wrote:
> On tor, 2012-05-03 at 17:39 +0100, Peter Geoghegan wrote:
>> On 3 May 2012 17:21, Bruce Momjian wrote:
>> > I think I was the only user left; I have never heard from a BSD/OS user
>> > in the past 5-7 years.
>>
>> I'm inclined to agree wi
Following query crashes backend on 9.2:
select substring('asd TO foo' from ' TO (([a-z0-9._]+|"([^"]+|"")+")+)');
It is supposed to load potentially quoted table name from
CREATE RULE definition. Works fine on 8.3 .. 9.1
Backtrace:
Program terminated with signal 11, Segmentation fault.
#0 Ex
duplicate code here that can be refactored (callback exec),
but I did not do it yet to avoid affecting existing code too much.
--
marko
PS. If a squint it seems like fix of exising API instead of new feature,
so perhaps it can still fit into 9.2?
commit 4114613 (HEAD, single-row)
Author: Marko Kr
On Sat, Jun 16, 2012 at 6:39 AM, Magnus Hagander wrote:
> On Sat, Jun 16, 2012 at 4:04 AM, Euler Taveira wrote:
>> On 15-06-2012 11:39, Magnus Hagander wrote:
>>> As long as a free implementation exists, it can be ported to
>>> Java/.Net. Sure, it takes more work, but it *can be done*.
>>>
>> Goo
Demos:
https://github.com/markokr/libpq-rowproc-demos/blob/master/demo-onerow-sync.c
https://github.com/markokr/libpq-rowproc-demos/blob/master/demo-onerow-async.c
Few clarifications below.
On Fri, Jun 15, 2012 at 9:21 PM, Marko Kreen wrote:
> Now, looking at the problem with some perspect
On Sat, Jun 16, 2012 at 6:09 PM, Tom Lane wrote:
> I guess this raises the question of whether we ought to revert the
> row-callback patch entirely and support only this approach. IMO
> it is (barely) not too late to do that for 9.2, if we want to.
> If we don't want to, then this is just another
On Sat, Jun 16, 2012 at 7:58 PM, Marko Kreen wrote:
> So my preference would be to simply remove the callback API
> but keep the processing and provide PQgetRowData() instead.
This is implemented in attached patch. It also
converts dblink to use single-row API.
The patch should be appl
On Sun, Jun 17, 2012 at 2:07 PM, Simon Riggs wrote:
> I prefer the description of Marko's API than the one we have now.
>
> Adopting one API in 9.2 and another in 9.3 would be fairly bad.
> Perhaps we can have both?
I see no reason the keep the (public) callback API around,
except if we don't bot
On Wed, Jun 13, 2012 at 2:28 PM, Andres Freund wrote:
> +/*
> + * removes a node from a list
> + * Attention: O(n)
> + */
> +static inline void ilist_s_remove(ilist_s_head *head,
> + ilist_s_node *node)
> +{
> + ilist_s_node *last = &head->head;
> + ili
On Tue, Jun 19, 2012 at 11:02 PM, Andres Freund wrote:
> On Tuesday, June 19, 2012 09:59:48 PM Marko Kreen wrote:
>> On Wed, Jun 13, 2012 at 2:28 PM, Andres Freund
> wrote:
>> > +/*
>> > + * removes a node from a list
>> > + * Attention: O(n)
>> &
On Mon, Jun 18, 2012 at 6:35 PM, Simon Riggs wrote:
> On 13 June 2012 19:28, Andres Freund wrote:
>> This adds a new configuration parameter multimaster_node_id which determines
>> the id used for wal originating in one cluster.
>
> Looks good and it seems this aspect at least is commitable in th
On Wed, Jun 20, 2012 at 10:05 PM, Florian Pflug wrote:
> I'm starting to think that relying on SSL/TLS for compression of
> unencrypted connections might not be such a good idea after all. We'd
> be using the protocol in a way it quite clearly never was intended to
> be used...
Maybe, but what is
On Mon, Jul 16, 2012 at 4:11 AM, Tom Lane wrote:
> Marko Kreen writes:
>> Now, looking at the problem with some perspective, the solution
>> is obvious: when in single-row mode, the PQgetResult() must return
>> proper PGresult for that single row. And everything else follow
On Mon, Jul 16, 2012 at 4:33 PM, Tom Lane wrote:
> Marko Kreen writes:
>> On Mon, Jul 16, 2012 at 4:11 AM, Tom Lane wrote:
>>> I'm starting to look at this patch now. I think we could drop the
>>> PQgetRowData() API: it complicates matters for little gain that
On Mon, Jul 16, 2012 at 6:47 PM, Tom Lane wrote:
> Marko Kreen writes:
>> On Mon, Jul 16, 2012 at 4:33 PM, Tom Lane wrote:
>>> Mm. I still think we should drop it, because it's still a dangerous API
>>> that's not necessary for the principal benefit of this
I converted Skytools modules to extensions and found 2 problems:
1) Dumpable sequences are not supported - if sequence is tagged
with pg_catalog.pg_extension_config_dump(), the pg_dump tries
to run COPY on it.
2) If there is schema with functions, but nothing else,
then when later conver
Here is 2 approaches how to get to state where only PQsetSingleRowMode()
is available. Both on top of REL9_2_STABLE branch.
a) Remove callback hooks, keep rowBuf, implement single-row-mode on
top of that. This was posted before, I just additionally removed
the PQgetRowData() function.
Here is a simple test program that takes a SELECT
query, reads it and outputs a COPY-formatted stream
to standard output, to simulate some activity.
It operates on 3 modes, specified by commant-line switches:
-f Load full resultset at once - old way.
-s Single-Row mode using PQgetResult().
-
On Tue, Jul 24, 2012 at 12:27 AM, Merlin Moncure wrote:
> On Mon, Jul 23, 2012 at 2:05 PM, Marko Kreen wrote:
> It seems odd (but maybe ok) that you have to set the single row mode
> on the connection only to have the server reset it whenever you call a
> send function: may
On Tue, Jul 24, 2012 at 6:18 PM, Merlin Moncure wrote:
> On Mon, Jul 23, 2012 at 5:07 PM, Marko Kreen wrote:
>>> Does PQgetRowData() break the ability to call PQgetvalue() against the
>>> result as well as other functions like PQgetisnull()? If so, I
>>> object.
On Tue, Jul 24, 2012 at 7:08 PM, Marko Kreen wrote:
> The PQgetRowData() is unimportant as it just exposes
> the rowBuf to user and thats all.
So to get back to the more interesting PQgetRowData() discussion...
Did you notice that it's up to app to decide whether it calls
PQget
On Tue, Jul 24, 2012 at 7:25 PM, Merlin Moncure wrote:
> On Tue, Jul 24, 2012 at 11:08 AM, Marko Kreen wrote:
>>> I'm arguing that *all* data getting must continue to do so through the
>>> result object, and bypassing the result to get at data is breaking the
>>&
On Tue, Jul 24, 2012 at 7:52 PM, Merlin Moncure wrote:
> But, the faster rowbuf method is a generally incompatible way of
> dealing with data vs current libpq -- this is bad. If it's truly
> impossible to get those benefits without bypassing result API that
> then I remove my objection on the gro
> Hm, I think it's possible to rig the test to do dummy
> copy of pgresult, thus it's possible to see what kind
> of speed is possible.. Will try.
I added a new method (-x) to rowdump where it asks for row
with PQgetRowData() and then tries to emulate super-efficient
PGresult copy, then loads dat
On Tue, Jul 24, 2012 at 11:34 PM, Merlin Moncure wrote:
> On Tue, Jul 24, 2012 at 2:37 PM, Tom Lane wrote:
>> In particular I agree that PQsetSingleRowMode is a bit ugly, so I'm
>> wondering about your thoughts on providing PQgetSingleRowResult instead.
>> I don't see how to make that work in asy
On Tue, Jul 24, 2012 at 10:37 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> Either way, it looks like there's plausible paths to optimizing
>> repeated result fetch without having expose an alternate data-fetching
>> API and that the proposed implementation doesn't appear to be a wall
>> in ter
On 9/7/10, Peter Eisentraut wrote:
> On sön, 2010-08-22 at 15:15 -0400, Tom Lane wrote:
> > > We combine the surrogate pair components to a single code point and
> > > encode that in UTF-8. We don't encode the components separately;
> > that
> > > would be wrong.
> >
> > Oh, OK. Should the
On 9/8/10, Peter Eisentraut wrote:
> On ons, 2010-09-08 at 10:18 +0300, Marko Kreen wrote:
> > On 9/7/10, Peter Eisentraut wrote:
> > > On sön, 2010-08-22 at 15:15 -0400, Tom Lane wrote:
> > > > > We combine the surrogate pair components to a single code poi
On 9/8/10, Tom Lane wrote:
> Marko Kreen writes:
> > Although it does seem unnecessary.
>
>
> The reason I asked for this to be spelled out is that ordinarily,
> a backslash escape \nnn is a very low-level thing that will insert
> exactly what you say. To me it
On Fri, Oct 8, 2010 at 3:13 PM, Andrew Dunstan wrote:
> On 10/08/2010 02:09 AM, Magnus Hagander wrote:
>> On Fri, Oct 8, 2010 at 03:52, Andrew Dunstan wrote:
>>> There's a simpler solution which I have just tested. Instead of patching,
>>> use the Pg driver instead of SQLite. Set the dbname to %m
On Thu, Nov 11, 2010 at 6:08 PM, Tom Lane wrote:
> Marti Raudsepp writes:
>> On Thu, Nov 11, 2010 at 17:24, Tom Lane wrote:
>>> Given that we have, in fact, never renamed any files in the history of
>>> the project, I'm wondering exactly why it thinks that the number of
>>> potential rename/copy
On Sat, Apr 16, 2011 at 8:48 AM, Greg Smith wrote:
> Joshua Berkus wrote:
>>
>> Guys, can we *please* focus on the patch for now, rather than the
>> formatting, which is fixable with sed?
>>
>
> Never, and that's not true. Heikki was being nice; I wouldn't have even
> slogged through it long enou
On Fri, Apr 15, 2011 at 3:12 PM, Radosław Smogura
wrote:
> On Fri, 15 Apr 2011 14:33:37 +0300, Heikki Linnakangas wrote:
>> The patch is quite hard to read because of random whitespace changes
>> and other stylistic issues, but I have a couple of high-level
>> questions on the design:
>
> Yes, but
On Thu, Apr 28, 2011 at 4:07 PM, Daniele Varrazzo
wrote:
> On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine
> wrote:
>> Tom Lane writes:
>>> If you didn't change the install script then it's not necessary to
>>> execute ALTER EXTENSION ... UPGRADE. You seem to be assuming that the
>>> pg_exten
On Thu, Apr 28, 2011 at 4:40 PM, Daniele Varrazzo
wrote:
> On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen wrote:
>> On Thu, Apr 28, 2011 at 4:07 PM, Daniele Varrazzo
>> wrote:
>>> On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine
>>> wrote:
>>>> Tom
On Wed, May 18, 2011 at 2:57 PM, Magnus Hagander wrote:
> On Wed, May 18, 2011 at 10:25, Greg Smith wrote:
>> Some of my personal discussions of this topic have suggested that some other
>> popular extensions like pgcrypto and hstore get converted too. I think
>> those all fail test (3), and I'm
On Wed, May 18, 2011 at 3:37 PM, Magnus Hagander wrote:
> On Wed, May 18, 2011 at 15:29, Marko Kreen wrote:
>> On Wed, May 18, 2011 at 2:57 PM, Magnus Hagander wrote:
>>> On Wed, May 18, 2011 at 10:25, Greg Smith wrote:
>>>> Some of my personal discussions of
On Wed, Jun 1, 2011 at 12:22 AM, Tom Lane wrote:
> Greg Stark writes:
>> On Tue, May 31, 2011 at 12:38 PM, Peter Eisentraut wrote:
>>> Oh yes, no point in having complicated code that doesn't get exercised.
>
>> This does amount to desupporting old versions of those OSes in newer
>> versions of
On Wed, Jun 1, 2011 at 1:03 AM, Tom Lane wrote:
> Marko Kreen writes:
>> My suggestion would be to use getpeereid() everywhere.
>> And just have compat getpeereid() implementation on non-BSD
>> platforms. This would minimize ifdeffery in core core.
>
> Hm, maybe. I&#
On Wed, Jun 1, 2011 at 1:03 AM, Tom Lane wrote:
> Marko Kreen writes:
>> My suggestion would be to use getpeereid() everywhere.
>> And just have compat getpeereid() implementation on non-BSD
>> platforms. This would minimize ifdeffery in core core.
>
> Hm, maybe. I&#
On Thu, Jun 2, 2011 at 5:49 PM, Tom Lane wrote:
> Marko Kreen writes:
>> Here's my attempt for it. As conditional port module seems trouble,
>> I set up an unconditional pgGetpeereid() that is always defined.
>
> -1 ... why would you think that a conditional substitu
On Thu, Jun 2, 2011 at 7:20 PM, Andrew Dunstan wrote:
> On 06/02/2011 12:04 PM, Marko Kreen wrote:
>> On Thu, Jun 2, 2011 at 6:59 PM, Andrew Dunstan
>> wrote:
>>> On 06/02/2011 11:29 AM, Marko Kreen wrote:
>>>> As there was no going back now, I even touched m
On Thu, Jun 2, 2011 at 6:59 PM, Andrew Dunstan wrote:
> On 06/02/2011 11:29 AM, Marko Kreen wrote:
>> As there was no going back now, I even touched msvc.pm.
>
> Why? Windows doesn't have Unix domain sockets at all.
Because the function is still referenced in the code.
--
On Thu, Jun 2, 2011 at 7:44 PM, Tom Lane wrote:
> Marko Kreen writes:
>> On Thu, Jun 2, 2011 at 7:20 PM, Andrew Dunstan wrote:
>>> Then maybe we need to use "#ifndef WIN32" in those places. That's what we do
>>> for similar cases.
>
>> No, t
On Thu, Jun 2, 2011 at 7:31 PM, Alvaro Herrera
wrote:
> Excerpts from Andrew Dunstan's message of jue jun 02 11:59:02 -0400 2011:
>> On 06/02/2011 11:29 AM, Marko Kreen wrote:
>> > As there was no going back now, I even touched msvc.pm.
>>
>> Why? Windows does
On Mon, Feb 14, 2011 at 3:08 PM, Martin Pitt wrote:
> thanks Markus for CC'ing me, I'm not on -hackers@.
>
> Markus Wanner [2011-02-14 13:37 +0100]:
>> On 02/10/2011 11:34 PM, Joshua D. Drake wrote:
>> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109
>
> Note that the recent discussions h
On Fri, Feb 11, 2011 at 1:04 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I'll be happy if you do, but why haven't I haven't noticed, say, RedHat
>> taking this line?
>
> Less narrow-minded interpretation of GPL requirements, perhaps.
> (And yes, we have real lawyers on staff considering these
On Mon, Feb 14, 2011 at 6:49 PM, Peter Eisentraut wrote:
> On mån, 2011-02-14 at 10:13 -0500, Tom Lane wrote:
>> Peter Eisentraut writes:
>> > Why do the extension load files need two dashes, like xml2--1.0.sql?
>> > Why isn't one enough?
>>
>> Because we'd have to forbid dashes in extension name
On Thu, Feb 17, 2011 at 2:39 AM, Tom Lane wrote:
> Greg Smith writes:
>> I find it hard to get excited about working to replace the software that
>> has a reasonable license here (readline) rather than trying to eliminate
>> dependence on the one with an unreasonable license (OpenSSL).
>
> Hm?
>
On Thu, Mar 17, 2011 at 4:40 AM, Robert Haas wrote:
> On Fri, Mar 11, 2011 at 6:02 AM, Bruce Momjian wrote:
>> What has been done with this report/fix?
>
> AFAIK, nothing. Added to 9.1 open items list.
The patch seems to do the right thing.
--
marko
--
Sent via pgsql-hackers mailing list (p
On Sat, Mar 19, 2011 at 6:10 AM, Tom Lane wrote:
> Or we could bite the bullet and start using str_tolower(), but the
> performance implications of that are unpleasant; not to mention that
> we really don't want to re-introduce the "Turkish problem" with
> unexpected handling of i/I in identifiers
On Sat, Mar 19, 2011 at 5:05 PM, Tom Lane wrote:
> Marko Kreen writes:
>> On Sat, Mar 19, 2011 at 6:10 AM, Tom Lane wrote:
>>> Or we could bite the bullet and start using str_tolower(), but the
>>> performance implications of that are unpleasant; not to mention that
On Wed, Apr 6, 2011 at 9:55 AM, Joshua D. Drake wrote:
> I want to achieve two things:
>
> 1. More understandable .pgpass format. Yes, I understand our standard
> format, most people won't. Like JoshB said, hard to debug.
How about allowing '#'-comments there and putting field
list into all templ
Attached patch changes the default ciphersuite to
HIGH:!aNULL
instead of old
DEFAULT:!LOW:!EXP:!MD5:@STRENGTH
where DEFAULT is a shortcut for "ALL:!aNULL:!eNULL".
Main goal is to leave low-level ciphersuite details to OpenSSL guys
and give clear impression to Postgres admins what it i
On Fri, Nov 15, 2013 at 11:16:25AM -0800, Adrian Klaver wrote:
> The description of the GUCs show up in the documentation but I am
> not seeing the GUCs themselves in postgresql.conf, so I could test
> no further. It is entirely possible I am missing a step and would
> appreciate enlightenment.
So
On Fri, Nov 15, 2013 at 02:16:52PM -0800, Adrian Klaver wrote:
> On 11/15/2013 11:49 AM, Marko Kreen wrote:
> >On Fri, Nov 15, 2013 at 11:16:25AM -0800, Adrian Klaver wrote:
> >>The description of the GUCs show up in the documentation but I am
> >>not seeing the GUCs th
Thanks for testing!
On Sat, Nov 16, 2013 at 12:17:40PM -0800, Adrian Klaver wrote:
> On 11/16/2013 06:24 AM, Marko Kreen wrote:
> >ssl-better-default:
> > SSL should stay working, openssl ciphers -v 'value' should not contain
> > any weak suites (RC4, SEED,
On Sat, Nov 16, 2013 at 01:03:05PM -0800, Adrian Klaver wrote:
> On 11/16/2013 12:37 PM, Marko Kreen wrote:
> >Thanks for testing!
> >
> >On Sat, Nov 16, 2013 at 12:17:40PM -0800, Adrian Klaver wrote:
> >>On 11/16/2013 06:24 AM, Marko Kreen wrote:
> >>>s
On Sat, Nov 16, 2013 at 02:07:57PM -0800, Adrian Klaver wrote:
> On 11/16/2013 01:13 PM, Marko Kreen wrote:
> >https://commitfest.postgresql.org/action/patch_view?id=1310
>
> Got it, applied it.
>
> Results:
>
> openssl ciphers -v 'HIGH:!aNULL'|eg
On Sat, Nov 16, 2013 at 02:54:22PM -0800, Adrian Klaver wrote:
> On 11/16/2013 02:41 PM, Marko Kreen wrote:
> >If you don't see any other issues perhaps they are ready for committer?
>
> I do not have any other questions/issues at this point. I am new to
> the review pro
On Sat, Nov 16, 2013 at 03:21:19PM -0800, Adrian Klaver wrote:
> On 11/16/2013 03:09 PM, Marko Kreen wrote:
> >On Sat, Nov 16, 2013 at 02:54:22PM -0800, Adrian Klaver wrote:
> >>On 11/16/2013 02:41 PM, Marko Kreen wrote:
> >>>If you don't see any other issues p
On Thu, Nov 14, 2013 at 09:33:59PM +1300, David Rowley wrote:
> On Sun, Nov 3, 2013 at 3:18 AM, David Rowley wrote:
> > I'm low on ideas on how to improve things much around here for now, but
> > for what it's worth, I did create a patch which changes unnecessary calls
> > to appendPQExpBuffer() i
On Mon, Nov 18, 2013 at 06:18:01PM +1300, David Rowley wrote:
> On Mon, Nov 18, 2013 at 1:01 AM, Marko Kreen wrote:
> > I am bit suspicious of performance impact of this patch, but think
> > that it's still worthwhile as it decreases code style where single
> > string a
On Sat, Oct 26, 2013 at 11:17:19AM -0200, Rodolfo Campero wrote:
> The attached patch add support of domains over arrays to PL/Python (eg:
> CREATE DOMAIN my_domain AS integer[]).
>
> Basically it just uses get_base_element_type instead of get_element_type
> in plpy_typeio.c, and uses domain_check
On Fri, Nov 22, 2013 at 08:45:56AM -0200, Rodolfo Campero wrote:
> There are other cosmetic changes in this patch, wrt previous version (not
> preexistent code):
> * adjusted alignment of variable name "rv" in line 12
> * reworded comment in line 850, resulting in more than 80 characters, so I
>
On Sat, Nov 23, 2013 at 11:09:53AM -0200, Rodolfo Campero wrote:
> 2013/11/22 Marko Kreen
> > One more thing - please update Python 3 regtests too.
> >
> The attached patch (version 3) includes the expected results for Python 3
> (file plpython_types_3.out).
Thanks. Looks
On Tue, Nov 26, 2013 at 12:23:48AM +0200, Heikki Linnakangas wrote:
> The new behavior is clearly better, but it is an incompatibility
> nonetheless. I don't do anything with PL/python myself, so I don't
> have a good feel of how much that'll break people's applications.
> Probably not much I guess
On Tue, Nov 26, 2013 at 07:12:00PM -0200, Rodolfo Campero wrote:
> 2013/11/26 Heikki Linnakangas
> > Oops, sorry about that. Fixed.
>
> Maybe be you forgot to modify
> plpython_types_3.out
Yes. Heikki, please fix plpython_types_3.out too.
See attached patch.
--
marko
diff --git a/src/pl/plp
On Fri, Nov 29, 2013 at 09:25:02AM -0500, Peter Eisentraut wrote:
> On Thu, 2013-11-14 at 11:45 +0100, Magnus Hagander wrote:
> > I think the default behaviour should be the one we recommend (which
> > would be to have the server one be preferred). But I do agree with the
> > requirement to have a
On Fri, Nov 29, 2013 at 09:18:49AM -0500, Peter Eisentraut wrote:
> On Fri, 2013-11-15 at 01:11 +0200, Marko Kreen wrote:
> > Attached patch changes the default ciphersuite to
> >
> > HIGH:!aNULL
> >
> > instead of old
> >
> > DEFAULT:!LOW:!E
On Fri, Nov 29, 2013 at 05:51:28PM +0200, Heikki Linnakangas wrote:
> On 11/29/2013 05:43 PM, Marko Kreen wrote:
> >On Fri, Nov 29, 2013 at 09:25:02AM -0500, Peter Eisentraut wrote:
> >>On Thu, 2013-11-14 at 11:45 +0100, Magnus Hagander wrote:
> >>>I think the defau
Reply to mails in pgsql-bugs:
http://www.postgresql.org/message-id/CAH8yC8mc_2J2UY0Q42WQdWFyaoqT3onG+83Fr=vn46j5+ml...@mail.gmail.com
and
http://www.postgresql.org/message-id/CAH8yC8nZVUyCQznkQd8=ELMM4k_=uxjrjt8yf9v22cy2x_d...@mail.gmail.com
* Default ciphersuite
> I would argue nothing
On Fri, Nov 29, 2013 at 06:01:01PM -0500, Jeffrey Walton wrote:
> I know of no other ways to check the result of OpenSSL's chain
> validation. The open question (for me) is where are
> SSL_get_verify_result/X509_V_OK checked? Neither show up in the
> Postgres sources.
According to SSL_set_verify m
On Sat, Nov 30, 2013 at 03:46:06AM -0500, Jeffrey Walton wrote:
> >> I believe the "standard" way of achieving TLS1.0 and above is to use
> >> the SSLv23_client_method() and then remove the SSL protocols with
> >> SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3. I have to use handwaiving around
> >> "standard"
As pointed out by Jeffrey Walton, only SSLv23_method() will negotiate
higher TLS versions than immediately requested. All other _method()
functions will negotiate only one specific version.
Attached are two patches:
* libpq.tls11plus.diff
Use SSLv23_method() instead TLSv1_method in fe-secure.c.
On Thu, Dec 05, 2013 at 09:43:31AM -0500, Peter Eisentraut wrote:
> On 12/5/13, 8:53 AM, Dr. Andreas Kunert wrote:
> > we were really missing the information in our log files if (and which
> > of) our users are using SSL during their connections.
> >
> > The attached patch is a very simple solutio
On Fri, Dec 06, 2013 at 11:43:55AM +0100, Dr. Andreas Kunert wrote:
> >>That seems useful. Do we need more information, like whether a client
> >>certificate was presented, or what ciphers were used?
> >
> >Yes, please show ciphersuite and TLS version too. Andreas, you can use my
> >recent \conni
On Fri, Dec 06, 2013 at 02:53:27PM +0100, Dr. Andreas Kunert wrote:
> >>Anything else missing?
> >
> >Functionally it's fine now, but I see few style problems:
> >
> >- "if (port->ssl > 0)" is wrong, ->ssl is pointer. So use just
> > "if (port->ssl)".
> >- Deeper indentation would look nicer wit
On Wed, Dec 11, 2013 at 10:08:44PM -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > Any other opinions on this out there? All instances of other
> > SSL-enabled servers out there, except nginx, default to some variant of
> > DEFAULT:!LOW:... or HIGH:MEDIUM: The proposal here is essentia
On Thu, Dec 12, 2013 at 01:33:57PM +0100, Magnus Hagander wrote:
> On Thu, Dec 12, 2013 at 11:30 AM, Marko Kreen wrote:
> > On Wed, Dec 11, 2013 at 10:08:44PM -0500, Tom Lane wrote:
> > I know that SChannel SSL library in Windows XP (and earlier) is such
> > RC4+3DES only
101 - 200 of 668 matches
Mail list logo
