Hello,
About patch eols:
postgresql> patch -p1 < ../pgbench-measurements-v2.patch
patching file contrib/pgbench/pgbench.c
patching file doc/src/sgml/pgbench.sgml
it can depends on o.s. I did tests on Fedora 14. and for patching without
warning I had to use dos2unix tool.
Hmmm. I
Dne 12. 9. 2013 17:34 "Fabien COELHO" 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 C
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 functionalit
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 pub
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
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 b
On Fri, Sep 13, 2013 at 1:11 AM, Peter Eisentraut 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 *synchronous_transfer_v5.pa
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 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
> > > Aut
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 would
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
Andres Freund wrote:
> Robert Haas wrote:
>> Andres Freund 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 actually the
>> right way to do
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:
>> https://commit
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
* 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 contrib/pgbench/pgb
On Thu, Sep 12, 2013 at 4:41 PM, Heikki Linnakangas
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 need t
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
* 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
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 p
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 pg
Andrew Dunstan writes:
> On 09/11/2013 02:30 PM, Robert Haas wrote:
>> On Tue, Sep 10, 2013 at 9:53 AM, Tom Lane 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 from libpq, then we'll
>> hav
(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
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 the
24 matches
Mail list logo
