Hello
2013/7/14 Andrew Dunstan :
>
> 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;
>>
>> Previou
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 th
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
I wrote:
> Jeevan Chalke 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 behavior for both the shor
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
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
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 b
Hello
2013/7/12 Peter Eisentraut :
> 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
Description
> >> 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
>
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 whit
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-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 typ
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; doub
13 matches
Mail list logo
