On Wed, Mar 11, 2015 at 9:49 PM, Peter Eisentraut wrote:
> On 3/3/15 9:32 AM, Marko Kreen wrote:
>> PL/Python uses str(v) to convert float data, but is lossy
>> by design. Only repr(v) is guaranteed to have enough
>> precision to make floats roundtrip properly:
>
> c
PL/Python uses str(v) to convert float data, but is lossy
by design. Only repr(v) is guaranteed to have enough
precision to make floats roundtrip properly:
https://docs.python.org/2/library/functions.html#func-repr
https://docs.python.org/2/library/functions.html#str
Example:
$ python
>
On Mon, Jun 09, 2014 at 02:45:08PM +0300, Heikki Linnakangas wrote:
> Thoughts? While we're at it, we'll probably want to refactor things
> so that it's easy to support other SSL implementations too, like
> gnutls.
One project that is proud to support several SSL implementations
is curl: http://cu
ed over DHE-RSA if both sides support it.
+
+
+
+The new configuration parameter
+ssl_ecdh_curve
+controls which curve is used for ECDH.
Improve the default ssl_ciphers ciphers
+linkend="guc-ssl-cip
On Sun, Apr 13, 2014 at 05:46:20PM -0400, Jan Wieck wrote:
> On 04/13/14 14:22, Jan Wieck wrote:
> >On 04/13/14 08:27, Marko Kreen wrote:
> >>I think you need to do SET_VARSIZE also here. Alternative is to
> >>move SET_VARSIZE after sort_snapshot().
> >>
&
On Sat, Apr 12, 2014 at 02:10:13PM -0400, Jan Wieck wrote:
> Since it doesn't seem to produce any side effects, I'd think that
> making the snapshot unique within txid_current_snapshot() and
> filtering duplicates on input should be sufficient and eligible for
> backpatching.
Agreed.
> The attach
On Sat, Feb 22, 2014 at 08:31:14PM -0500, Peter Eisentraut wrote:
> On 2/2/14, 7:16 AM, Marko Kreen wrote:
> > On Thu, Dec 12, 2013 at 04:32:07PM +0200, Marko Kreen wrote:
> >> Attached patch changes default ciphersuite to HIGH:MEDIUM:+3DES:!aNULL
> >> and also adds do
On Thu, Dec 12, 2013 at 04:32:07PM +0200, Marko Kreen wrote:
> Attached patch changes default ciphersuite to HIGH:MEDIUM:+3DES:!aNULL
> and also adds documentation about reasoning for it.
This is the last pending SSL cleanup related patch:
https://commitfest.postgresql.org/action/patch_v
On Sat, Jan 25, 2014 at 12:25:30PM -0500, Tom Lane wrote:
> Alternatively, given that TLS has been around for a dozen years and
> openssl versions that old have not gotten security updates for a long
> time, why don't we just reject SSLv3 on the backend side too?
> I guess it's barely possible that
On Mon, Jan 20, 2014 at 06:49:21PM -0300, Alvaro Herrera wrote:
> Marko Kreen escribió:
> > http://www.viva64.com/en/b/0227/ reported that on-stack memset()s
> > might be optimized away by compilers. Fix it.
>
> Just to clarify, this needs to be applied to all branches, righ
On Sat, Dec 28, 2013 at 10:36:19PM -0500, Peter Eisentraut wrote:
> While playing around with the pginclude tools, I noticed that pgcrypto
> header files are failing to include some header files whose symbols they
> use. This change would fix it:
>
> diff --git a/contrib/pgcrypto/pgp.h b/contrib/
http://www.viva64.com/en/b/0227/ reported that on-stack memset()s
might be optimized away by compilers. Fix it.
* Replace memset() with px_memset()
* Add px_memset to copy_crlf()
* ADd px_memset to pgp-s2k.c
--
marko
diff --git a/contrib/pgcrypto/crypt-blowfish.c b/contrib/pgcrypto/crypt-blowf
On Sun, Dec 15, 2013 at 05:10:38PM -0500, James Cloos wrote:
> >>>>> "MK" == Marko Kreen writes:
> >>>>> "PE" == Peter Eisentraut writes:
> PE> Any other opinions on this out there?
>
> For reference, see:
>
>
On Tue, Dec 17, 2013 at 11:26:13AM -0500, Bruce Momjian wrote:
> On Tue, Dec 17, 2013 at 09:51:30AM -0500, Robert Haas wrote:
> > I'm starting to think we should just leave this well enough alone. We
> > can't seem to find two people with the same idea of what would be
> > better than what we have
On Thu, Dec 12, 2013 at 09:18:03PM -0500, Peter Eisentraut wrote:
> On Thu, 2013-12-12 at 12:30 +0200, Marko Kreen wrote:
> > First, if there is explicit wish to keep RC4/SEED in play, I'm fine
> > with "HIGH:MEDIUM:!aNULL" as new default. Clarity-wise, it's
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
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 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 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 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
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 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"
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
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 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
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 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 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 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 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 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, 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 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 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 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 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 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 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
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 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
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
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 Wed, Nov 06, 2013 at 09:57:32PM -0300, Alvaro Herrera wrote:
> Marko Kreen escribió:
>
> > By default OpenSSL (and SSL/TLS in general) lets client cipher
> > order take priority. This is OK for browsers where the ciphers
> > were tuned, but few Postgres client lib
This sets up ECDH key exchange, when compiling against OpenSSL
that supports EC. Then ECDHE-RSA and ECDHE-ECDSA ciphersuites
can be used for SSL connections. Latter one means that EC keys
are now usable.
The reason for EC key exchange is that it's faster than DHE
and it allows to go to higher s
By default OpenSSL (and SSL/TLS in general) lets client cipher
order take priority. This is OK for browsers where the ciphers
were tuned, but few Postgres client libraries make cipher order
configurable. So it makes sense to make cipher order in
postgresql.conf take priority over client defaults
On Wed, Jul 3, 2013 at 8:07 PM, Andres Freund wrote:
> On 2013-07-02 16:29:56 -0400, Robert Haas wrote:
>> There's no possibility of getting confused here; if X is still around
>> at all, it's xmax is of the same generation as Y's xmin. Otherwise,
>> we've had an undetected XID wraparound.
>
> An
On Thu, Jun 27, 2013 at 11:28 AM, Dean Rasheed wrote:
> On 26 June 2013 21:46, Peter Eisentraut wrote:
>> On 6/26/13 4:04 PM, Dean Rasheed wrote:
>>> A quick google search reveals several people asking for something like
>>> this, and people recommending md5(string_agg(...)) or
>>> md5(string_agg
On Mon, May 13, 2013 at 2:58 AM, Robins Tharakan wrote:
> Please find attached a patch that adds basic regression tests for DISCARD
> command.
>
> Any and all feedback is obviously welcome.
Perhaps existing tests in guc.sql should be merged into it?
--
marko
--
Sent via pgsql-hackers mailing
On Mon, Jun 17, 2013 at 11:34:52AM +0100, Dean Rasheed wrote:
> On 15 June 2013 10:22, Dean Rasheed wrote:
> > There seem to be 2 separate directions that this could go, which
> > really meet different requirements:
> >
> > 1). Produce an unordered sum for SQL to compare 2 tables regardless of
> >
On Mon, May 27, 2013 at 5:59 AM, Christopher Browne wrote:
> This situation falls from a problem that we noticed a mighty long time ago
> in Slony, where the set of XIDs outstanding gets very large, and, attendant
> to that, the set of "action id" values by which tuples are being filtered,
> gets
On Thu, Jun 13, 2013 at 12:35 PM, Dean Rasheed wrote:
> Attached is a patch implementing a new aggregate function md5_agg() to
> compute the aggregate MD5 sum across a number of rows. This is
> something I've wished for a number of times. I think the primary use
> case is to do a quick check that
On Tue, May 14, 2013 at 09:29:38AM +0200, Dimitri Fontaine wrote:
> Stephen Frost writes:
> > * Marko Kreen (mark...@gmail.com) wrote:
> >> On Sat, May 04, 2013 at 10:57:44PM +0200, Dimitri Fontaine wrote:
> >> > Other than adminpack, I know of PGQ installing thei
On Sat, May 04, 2013 at 10:57:44PM +0200, Dimitri Fontaine wrote:
> Other than adminpack, I know of PGQ installing their objects in
> pg_catalog. They only began doing that when switching to the CREATE
> EXTENSION facility. And they set relocatable to false.
FYI - PgQ and related modules install n
On Fri, May 10, 2013 at 12:52:55PM -0400, Tom Lane wrote:
> Marko Kreen writes:
> > RSA secret key extraction code uses wrong variable so
> > that decryption is skipped and only secret keys without
> > password work for pgp_pub_decrypt().
>
> > Attached patch
RSA secret key extraction code uses wrong variable so
that decryption is skipped and only secret keys without
password work for pgp_pub_decrypt().
Attached patch fixes it and also adds regtest.
Please apply to all branches.
Reported-by: Keith Fiske
--
marko
diff --git a/contrib/pgcrypto/pgp
On Tue, Apr 16, 2013 at 05:09:19PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I think his point is why don't we clear currval() on DISCARD ALL? I
> > can't think of a good reason we don't.
>
> Because we'd have to invent a new suboperation DISCARD SEQUENCES,
> for one thing, in order to
On Mon, Jan 14, 2013 at 3:00 PM, Noah Misch wrote:
> On Mon, Jan 14, 2013 at 02:21:00PM +0200, Marko Kreen wrote:
>> Note: reading from /dev/urandom does not affect /dev/random.
>
> Reading from /dev/urandom drains the pool that serves /dev/random:
>
> $ cat /proc/sys/kernel
On Mon, Jan 14, 2013 at 12:46 AM, Tom Lane wrote:
> Marko Kreen writes:
>> On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote:
>>> How about instead calling RAND_cleanup() after each backend fork?
>
>> Attached is a patch that adds RAND_cleanup() to fork_process().
&g
On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote:
> How about instead calling RAND_cleanup() after each backend fork?
Attached is a patch that adds RAND_cleanup() to fork_process().
That way all forked processes start with fresh state. This should
make sure the problem does not happen in any p
On Wed, Jan 2, 2013 at 5:11 PM, Boszormenyi Zoltan wrote:
> 2012-12-11 16:09 keltezéssel, Simon Riggs írta:
>
>> On 11 December 2012 12:18, Boszormenyi Zoltan wrote:
>>
> Such mechanism already exist - you just need to set
> your PGresult pointer to NULL after each PQclear().
So
On Sun, Dec 23, 2012 at 9:45 PM, Tom Lane wrote:
> Marko Kreen writes:
>> On Sat, Dec 22, 2012 at 9:20 PM, Tom Lane wrote:
> >> I'm not thrilled with the suggestion to do RAND_cleanup() after forking
> >> though, as that seems like it'll guarantee that eac
On Sat, Dec 22, 2012 at 9:20 PM, Tom Lane wrote:
> I'm not thrilled with the suggestion to do RAND_cleanup() after forking
> though, as that seems like it'll guarantee that each session starts out
> with only a minimal amount of entropy.
No, that's actually the right fix - that forces OpenSSL to
On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote:
> This should have gone to secur...@postgresql.org, instead.
It went and this could have been patched in 9.2.2 but they did not care.
> On Fri, Dec 21, 2012 at 06:05:10PM +0200, Marko Kreen wrote:
>> When there is 'ssl=on
When there is 'ssl=on' then postmaster calls SSL_CTX_new(),
which asks for random number, thus requiring initialization
of randomness pool (RAND_poll). After that all forked backends
think pool is already initialized. Thus they proceed with same
fixed state they got from postmaster.
Output is no
On Tue, Dec 11, 2012 at 6:59 AM, Josh Kupershmidt wrote:
> Would it be crazy to add an "already_freed" flag to the pg_result
> struct which PQclear() would set, or some equivalent safety mechanism,
> to avoid this hassle for users?
Such mechanism already exist - you just need to set
your PGresult
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 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 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 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, 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, 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, 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 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 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 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 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, Jul 25, 2012 at 12:35 AM, Merlin Moncure wrote:
> On Tue, Jul 24, 2012 at 3:52 PM, Marko Kreen wrote:
>> * Is there better API than PQsetSingleRowMode()? New PQsend*
>> functions is my alternative.
>
> I would prefer to have PQsetSingleRowMode() over new fla
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 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
> 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 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
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: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 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 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
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().
-
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.
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
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
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 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 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, 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 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 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 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 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 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
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: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
1 - 100 of 668 matches
Mail list logo
