Hello list,
Is the following known behaviour, or should I put some time in writing a
self contained test case?
We have a function that takes a value and returns a ROW type. With the
function implemented in language SQL, when executing this function in a
large transaction, memory usage of
(reviving an old thread)
On 23.10.2012 19:53, Peter Eisentraut wrote:
On 10/22/12 1:25 PM, Stephen Frost wrote:
* Peter Eisentraut (pete...@gmx.net) wrote:
On 10/12/12 3:44 PM, Stephen Frost wrote:
In general, I think it's good to build on existing implementations where
possible. Perhaps we
Andrew Dunstan and...@dunslane.net writes:
On 09/11/2013 02:30 PM, Robert Haas wrote:
On Tue, Sep 10, 2013 at 9:53 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Note that I was proposing removing libpq's support for V2 connections.
Not the backend's.
I vote against this. If we remove V2 support
On 12.09.2013 17:30, Andrew Dunstan wrote:
On 09/12/2013 09:10 AM, Heikki Linnakangas wrote:
I just found out that OpenSSL has added support for SRP in version
1.0.1. We're already using OpenSSL, so all we need to do is to provide
a couple of callbacks to OpenSSL, and store SRP verifiers in
On 09/12/2013 09:10 AM, Heikki Linnakangas wrote:
Now, to a completely different approach:
I just found out that OpenSSL has added support for SRP in version
1.0.1. We're already using OpenSSL, so all we need to do is to provide
a couple of callbacks to OpenSSL, and store SRP verifiers in
* Andrew Dunstan (and...@dunslane.net) wrote:
You forgot to mention that we'd actually like to get away from being
tied closely to OpenSSL because it has caused license grief in the
past (not to mention that it's fairly dirty to manage).
While I agree with this sentiment (and have complained
Hello Pavel,
Thanks for your review.
* patched with minor warning
* compilable cleanly
* zero impact on PostgreSQL server functionality
* it does what was in proposal
** change 5sec progress as default (instead no progress)
** finalise a rate limit support - fixes a latency calculation
Just
On Thu, Sep 12, 2013 at 4:41 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 12.09.2013 17:30, Andrew Dunstan wrote:
On 09/12/2013 09:10 AM, Heikki Linnakangas wrote:
I just found out that OpenSSL has added support for SRP in version
1.0.1. We're already using OpenSSL, so all we
* patched with minor warning
some minor issue:
patch warning
make[1]: Leaving directory `/home/pavel/src/postgresql/config'
[pavel@localhost postgresql]$ patch -p1 pgbench-measurements-v2.patch
(Stripping trailing CRs from patch; use --binary to disable.)
patching file
On 9/12/13 3:00 AM, Samrat Revagade wrote:
We are improving the patch for Commit Fest 2 now.
We will fix above compiler warnings as soon as possible and submit
the patch
Attached *synchronous_transfer_v5.patch* implements review comments from
commit fest-1 and reduces the
On 9/11/13 10:14 AM, Ronan Dunklau wrote:
On Wednesday 11 September 2013 06:27:24 Michael Paquier wrote:
As your patch is targeting the implementation of a new feature, please
consider adding this patch to the next commit fest that is going to
begin in a couple of days:
Andres Freund and...@2ndquadrant.com wrote:
Robert Haas wrote:
Andres Freund and...@2ndquadrant.com wrote:
0007 wal_decoding: Add information about a tables primary key to
struct RelationData
* Could be used in the matview refresh code
I think you and Kevin should discuss whether this is
On 9/11/13 1:09 AM, wangs...@highgo.com.cn wrote:
Peter Eisentraut wrote:
Note that other schema objects can depend on the existence of
constraints. For example, the validity of a view might depend on the
existence of a primary key constraint. What would you do with the view
if the primary
Attached is a patch for a bit of infrastructure I believe to be
necessary for correct behavior of REFRESH MATERIALIZED VIEW
CONCURRENTLY as well as incremental maintenance of matviews.
The idea is that after RMVC or incremental maintenance, the matview
should not be visibly different that it
On Wednesday, September 11, 2013, Alvaro Herrera wrote:
Noah Misch escribió:
On Tue, Sep 10, 2013 at 05:18:21PM -0700, Jeff Janes wrote:
I think the problem is here, where there should be a Max rather than a
Min:
commit 82233ce7ea42d6ba519aaec63008aff49da6c7af
Author: Alvaro
On 3/18/13 10:52 AM, Bruce Momjian wrote:
With a potential 10-20% overhead, I am unclear who would enable this at
initdb time.
If you survey people who are running PostgreSQL on cloud hardware, be
it Amazon's EC2 or similar options from other vendors, you will find a
high percentage of them
On 3/18/13 10:52 AM, Bruce Momjian wrote:
With a potential 10-20% overhead, I am unclear who would enable this at
initdb time.
If you survey people who are running PostgreSQL on cloud hardware, be
it Amazon's EC2 or similar options from other vendors, you will find a
high percentage of them
On Fri, Sep 13, 2013 at 1:11 AM, Peter Eisentraut pete...@gmx.net wrote:
On 9/12/13 3:00 AM, Samrat Revagade wrote:
We are improving the patch for Commit Fest 2 now.
We will fix above compiler warnings as soon as possible and submit
the patch
Attached
Last week, I attempted to write some code to perform a trivial
operation in parallel by launching background workers. Despite my
earlier convictions that I'd built enough infrastructure to make this
possible, the experiment turned out badly - so, patches!
It's been pretty obvious to me from the
On 09/13/2013 05:23, Peter Eisentraut wrote:
= create table test1 (a int constraint pk primary key, b text);
= create view test2 as select a, b from test1 group by a;
= alter table test1 drop constraint pk;
ERROR: 2BP01: cannot drop constraint pk on table test1 because other
objects depend on
The experiences with elog() and ereport() have shown that having one
function that can return or not depending on some log level parameter
isn't a good idea when you want to communicate well with the compiler.
In pg_upgrade, there is a similar case with the pg_log() function.
Since that isn't a
On Tue, 2013-09-03 at 22:41 -0400, Peter Eisentraut wrote:
The maintainer-check target never really caught on, I think. Most
people don't run it, and that in turn annoys those who do. Also, it
doesn't provide much functionality.
I propose that we get rid of it and roll the functionality
Dne 12. 9. 2013 17:34 Fabien COELHO coe...@cri.ensmp.fr napsal(a):
* patched with minor warning
some minor issue:
patch warning
make[1]: Leaving directory `/home/pavel/src/postgresql/config'
[pavel@localhost postgresql]$ patch -p1 pgbench-measurements-v2.patch
(Stripping trailing CRs
23 matches
Mail list logo
