Alvaro Herrera writes:
> ... However, when you create an index, you can
> indicate which operator class to use, and it may not be the default one.
> If a different one is chosen at index creation time, then a query using
> COUNT(distinct) will do the wrong thing, because DISTINCT will select
> an
I wrote:
> So the question is, does anyone care? I wouldn't except that our
> documentation appears to claim that we work with Perl "5.8 or later".
> And the lack of field complaints suggests strongly that nobody else
> cares. So I'm inclined to think we just need to be more specific
> about the
Hi Ashutosh,
0003 patch
> +parentRel = heap_open(parentOid, AccessExclusiveLock);
> In [2], Amit Langote has given a reason as to why heap_drop_with_catalog()
> should not heap_open() the parent relation. But this patch still calls
> heap_open() without giving any counter argument. Also I
Mark Rofail wrote:
> These are limitations of the patch ordered by importance:
>
> ✗ presupposes that count(distinct y) has exactly the same notion of
> equality that the PK unique index has. In reality, count(distinct) will
> fall back to the default btree opclass for the array element type.
Ope
Claudio Freire wrote:
README.HOT says that that cost is not worth the benefit of
preventing a new index write, but I think that it ought to take into
account that not all index writes are equal. There is an appreciable
difference between inserting a new tuple, and updating one in-place. We
can r
These are limitations of the patch ordered by importance:
✗ presupposes that count(distinct y) has exactly the same notion of
equality that the PK unique index has. In reality, count(distinct) will
fall back to the default btree opclass for the array element type.
- Supported actions:
✔ NO ACTIO
Andres Freund writes:
> [ 0002-Move-ExecProcNode-from-dispatch-to-function-pointer-.patch ]
Here's a reviewed version of this patch.
I added dummy ExecProcNodeMtd functions to the various node types that
lacked them because they expect to be called through MultiExecProcNode
instead. In the old
> On 12 July 2017 at 23:45, Thomas Munro
wrote:
> I renamed it to "synchronous replay", because "causal reads" seemed a bit
too
> arcane.
Hi
I looked through the code of `synchronous-replay-v1.patch` a bit and ran a
few
tests. I didn't manage to break anything, except one mysterious error that
I
On 2017-07-29 14:20:32 -0400, Tom Lane wrote:
> Here's a reviewed version of this patch.
Thanks!
> * I think you put ExecScan's CFI in the wrong place; AFAICT yours
> only covers its fast path.
Sure - but the old path already has a CFI? And it has to be inside the
loop, because well, the loop ;)
Andres Freund writes:
> On 2017-07-26 16:28:38 -0400, Tom Lane wrote:
>> It's certainly possible that there are long-running loops not involving
>> any ExecProcNode recursion at all, but that would be a bug independent
>> of this issue. The CFI in ExecProcNode itself can be replaced exactly
>> ei
You are right. When I add those code， it really give me a strong bad smell.
It not worth these effort.
Thanks for your reply and suggestion.
--
Sincerely
Fan Yang
fan yang writes:
> - src/port/quotes.c
> At line 38, at function "escape_single_quotes_ascii",
> here used "malloc" to get some memory and return the
> pointer returned by the "malloc".
> So, any caller used this function shoule free this memory.
> - /src/bin/initdb/initdb.c
>
Hi all，
While reading the code, I find some code that make memory leak:
- src/port/quotes.c
At line 38, at function "escape_single_quotes_ascii",
here used "malloc" to get some memory and return the
pointer returned by the "malloc".
So, any caller used this function shoule free th
13 matches
Mail list logo
