At 2013-07-12 16:25:14 -0700, jeff.ja...@gmail.com wrote:
I think the reviewer of a performance patch should do some independent
testing of the performance, to replicate the author's numbers; and
hopefully with a few different scenarios.
You're quite right. I apologise for being lazy; doubly
At 2013-07-13 14:19:23 +0530, a...@2ndquadrant.com wrote:
The timings above are with both xid_in_snapshot_cache.v1.patch and
cache_TransactionIdInProgress.v2.patch applied
For anyone who wants to try to reproduce the results, here's the patch I
used, which is both patches above plus some typo
Hi,
Please find attached a new version (v10) of the patch that fixes the
reported dependencies problems and add some new regression tests to
cover them.
The patch implements the solution we discuted privately with Markus
while at the CHAR(13) conference:
- create template for extension is now
At 2013-06-12 14:29:59 -0300, fabriziome...@gmail.com wrote:
The attached patch add support to IF NOT EXISTS to CREATE
statements listed below: […]
I noticed that this patch was listed as Needs Review with no
reviewers, so I had a quick look.
It applies with a couple of trailing whitespace
Generally speaking, I agree with Robert's objection. The patch in
itself adds only one unnecessary keyword, which probably wouldn't be
noticeable, but the argument for it implies that we should be willing
to add a lot more equally-unnecessary keywords, which I'm not. gram.o
is already
Hello
2013/7/12 Peter Eisentraut pete...@gmx.net:
There is a small inconsistency:
select time '12:30:57.123456789';
gives
12:30:57.123457
but
select make_time(12, 30, 57.123456789);
gives
12:30:57.123456
fixed - see attached patch
Regards
Pavel
make_date-v3.patch
ECPG's pgtypeslib contains two slightly different prototypes for
PGTYPEStimestamp_defmt_scan(), neither of which is in a header file. I
propose something like the attached patch, although I'm not sure which
header file is the most appropriate one.
diff --git a/src/interfaces/ecpg/pgtypeslib/dt.h
On 6/30/13 2:04 AM, Fabien COELHO wrote:
My guess is the OS. PQfinish or select do/are systems calls that
present opportunities to switch context. I think that the OS is passing
time with other processes on the same host, expecially postgres
backends, when it is not with the client.
I went
Hello Greg,
There's a refactoring possible here that seems to make this whole class of
problem go away. If I change pgbench so that PQfinish isn't called for any
client until *all* of the clients are actually finished with transactions,
the whole issue goes away.
Sure. If the explanation
I wrote:
Jeevan Chalke jeevan.cha...@enterprisedb.com writes:
Following example does not work as expected:
-- Should return TRUE but returning FALSE
SELECT 'Programmer' ~ '(\w).*?\1' as t;
This is clearly broken, but I'm uncomfortable with the proposed patch.
As written, it changes
On Sat, Jul 13, 2013 at 12:49:45AM +0200, Karol Trzcionka wrote:
Next version:
- cleanup
- regression test
- fix issue reported by johto (invalid values in parallel transactions)
I would like more feedback and comments about the patch, as some parts
may be too hacky.
In particular, is it a
On 06/29/2013 03:29 PM, Pavel Stehule wrote:
5. This patch has user visibility, i.e. now we are throwing an error
when
user only says VARIADIC NULL like:
select concat(variadic NULL) is NULL;
Previously it was working but now we are throwing an error. Well we are
now
more stricter
Hello
2013/7/14 Andrew Dunstan and...@dunslane.net:
On 06/29/2013 03:29 PM, Pavel Stehule wrote:
5. This patch has user visibility, i.e. now we are throwing an error
when
user only says VARIADIC NULL like:
select concat(variadic NULL) is NULL;
Previously it was working but now we
13 matches
Mail list logo
