when did use varchar_transform function?
src/backend/uitls/adt/varchar.c.
All,
Here's a draft cleanup on the JSON section of the Datatype docs. Since
there's been a bunch of incremental patches on this, I just did a diff
against HEAD.
I looked over json-functions a bit, but am not clear on what needs to
change there; the docs are pretty similar to other sections of
Fu
On 22 February 2014 06:16, MauMau Wrote:
Thanks for reviewing again.
> Please make small cosmetic changes so that make_absolute_path() follows
> the
> style of other parts. Then I'll make this ready for committer.
>
> (1)
> Add the function name in the comment as in:
>
> /*
> * make_absolute_
On Fri, Feb 21, 2014 at 2:19 AM, Kohei KaiGai wrote:
> Hello,
>
> The attached patch is a revised one for cache-only scan module
> on top of custom-scan interface. Please check it.
>
Thanks for the revised patch. Please find some minor comments.
1. memcpy(dest, tuple, HEAPTUPLESIZE);
+ memcpy(
Teodor, Oleg:
Some bitrot on the nested-hstore patch on current HEAD, possibly due to
the recent update release?
josh@radegast:~/git/pg94$ patch -p1 -i nested-hstore-10.patch
patching file contrib/hstore/.gitignore
patching file contrib/hstore/Makefile
patching file contrib/hstore/crc32.c
patchin
On 02/06/2014 06:14 PM, Emre Hasegeli wrote:
Third versions of the patches attached. They are rebased to the HEAD. In
this versions, the bitncommon function is changed. included
to network_gist.c to be able to compile it on FreeBSD. Geometric mean
calculation for partial bucket match on the func
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 documentation about reasoning fo
Hi,
On 2014-02-23 20:04:39 +0100, Pavel Stehule wrote:
> There is relative few very long ProcArrayLocks lwlocks
>
> This issue is very pathologic on fast computers with more than 8 CPU. This
> issue was detected after migration from 8.4 to 9.2. (but tested with same
> result on 9.0) I see it on
On 2014-02-23 14:48:12 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Currently the error handling of normal backends only does a
> > LWLockReleaseAll() once CurrentTransactionState->state != TRANS_DEFAULT
> > because it's called in AbortTransaction(). There's pretty damn few
> > places that f
Noah Misch writes:
> On Fri, Feb 21, 2014 at 05:20:06PM -0500, Tom Lane wrote:
>> ... However, I think there's a case to be
>> made for adding the additional pg_verify_mbstr() calls in the back
>> branches. We've been promising since around 8.3 that invalidly encoded
>> data can't get into a dat
2014-02-23 20:35 GMT+01:00 Jeff Janes :
> On Sun, Feb 23, 2014 at 11:04 AM, Pavel Stehule
> wrote:
>
>> Hello
>>
>> I got a example of code, that generate relatively high load with minimal
>> connections.
>>
>> This code is +/- bad - it repeatedly generate prepare statement, but
>> somewhere uses
2014-02-23 20:35 GMT+01:00 Jeff Janes :
> On Sun, Feb 23, 2014 at 11:04 AM, Pavel Stehule
> wrote:
>
>> Hello
>>
>> I got a example of code, that generate relatively high load with minimal
>> connections.
>>
>> This code is +/- bad - it repeatedly generate prepare statement, but
>> somewhere uses
Andres Freund writes:
> Currently the error handling of normal backends only does a
> LWLockReleaseAll() once CurrentTransactionState->state != TRANS_DEFAULT
> because it's called in AbortTransaction(). There's pretty damn few
> places that fiddle with lwlocks outside of a transaction command, but
On Sun, Feb 23, 2014 at 11:04 AM, Pavel Stehule wrote:
> Hello
>
> I got a example of code, that generate relatively high load with minimal
> connections.
>
> This code is +/- bad - it repeatedly generate prepare statement, but
> somewhere uses prepared statements as protections against SQL inject
Hello
I got a example of code, that generate relatively high load with minimal
connections.
This code is +/- bad - it repeatedly generate prepare statement, but
somewhere uses prepared statements as protections against SQL injections
and they can use same use case.
Pseudocode (I can send a test
Hi,
Currently the error handling of normal backends only does a
LWLockReleaseAll() once CurrentTransactionState->state != TRANS_DEFAULT
because it's called in AbortTransaction(). There's pretty damn few
places that fiddle with lwlocks outside of a transaction command, but I
still do wonder whether
Gaussian Pgbench v8 patch by Mitsumasa KONDO review & patch v9.
* The purpose of the patch is to allow a pgbench script to draw from normally
distributed or exponentially distributed integer values instead of uniformly
distributed.
This is a valuable contribution to enable pgbench to gene
17 matches
Mail list logo
