Hi.
We're now at the "nearly done" stage of the first 9.5 CF.
Twenty-four patches have been committed so far, and five more are ready
for committer (and of those, four are small). Thirty patches are still
marked "needs review", and twenty-one are waiting on author.
I'll go through the patches an
## Andres Freund (and...@2ndquadrant.com):
> Care to submit a patch for it Christoph?
There it is.
Regards,
Christoph
--
Spare Space
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index 41b63b4..6c3707c 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/do
On Fri, Jun 13, 2014 at 1:11 PM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
>
> Hello, This is the continuation from the last CF.
>
> This patch intends to make PG to use index for longer pathkeys
> than index columns when,
>
> - The index is a unique index.
> - All index columns
Tomas,
* Tomas Vondra (t...@fuzzy.cz) wrote:
> On 6.7.2014 17:57, Stephen Frost wrote:
> > * Tomas Vondra (t...@fuzzy.cz) wrote:
> >> I can't find the thread / test cases in the archives. I've found this
> >> thread in hackers:
> >>
> >> http://www.postgresql.org/message-id/caoezvif-r-ilf966weipk5
On 07/03/2014 10:16 PM, Tom Lane wrote:
> Andreas Joseph Krogh writes:
>> Hi. Â I'm up for testing 9.4 but my JDBC-driver fails to connect due to
>> PG's
>> minor-version string: "4beta1". Is it possible to set this somewhere without
>> recompiling PG?
>
> No, and even if you could, that woul
On 2014-07-10 08:46:55 +0530, Amit Kapila wrote:
> As per my understanding of the general theory around barriers,
> read and write are defined to avoid reordering due to compiler and
> full memory barriers are defined to avoid reordering due to
> processors.
No, that's not the case. There's severa
Hi Amit,
On 2014-07-08 11:51:14 +0530, Amit Kapila wrote:
> On Thu, Jul 3, 2014 at 10:56 AM, Amit Kapila
> wrote:
> > On Tue, Jul 1, 2014 at 4:10 PM, Andres Freund
> wrote:
>
> Further review of patch:
> 1.
> /*
> * pg_atomic_test_and_set_flag - TAS()
> *
> * Acquire/read barrier semantics.
On 3.7.2014 19:36, Tomas Vondra wrote:
> On 1.7.2014 01:24, Tomas Vondra wrote:
>> On 30.6.2014 23:12, Tomas Vondra wrote:
>>> Hi,
>>
>> Hopefully I got it right this time. At least it seems to be working
>> for cases that failed before (no file leaks, proper rowcounts so
>> far).
>
> Attached v7,
On Sun, Jul 13, 2014 at 10:32 PM, Stefan Kaltenbrunner
wrote:
> On 07/12/2014 03:08 PM, Magnus Hagander wrote:
>> As an administrator, I find that you fairly often want to know what
>> your current connections are actually using as SSL parameters, and
>> there is currently no other way than gdb to
On 07/12/2014 03:08 PM, Magnus Hagander wrote:
> As an administrator, I find that you fairly often want to know what
> your current connections are actually using as SSL parameters, and
> there is currently no other way than gdb to find that out - something
> we definitely should fix.
Yeah that wo
On 11.7.2014 19:25, Tomas Vondra wrote:
> 2) walking through the tuples sequentially
> --
>
> The other option is not to walk the tuples through buckets, but by
> walking throught the chunks - we know the tuples are stored as
> HashJoinTuple/MinimalTuple, so
On 13.7.2014 12:27, Simon Riggs wrote:
> On 12 July 2014 12:43, Tomas Vondra wrote:
>
>>> So lets just this change done and then do more later.
>>
>> There's no way back, sadly. The dense allocation turned into a
>> challenge. I like challenges. I have to solve it or I won't be able
>> to sleep.
Hi Robert,
On 2014-07-07 15:57:00 -0400, Robert Haas wrote:
> 1. I tried to write a single allocator which would be better than
> aset.c in two ways: first, by allowing allocation from dynamic shared
> memory; and second, by being more memory-efficient than aset.c.
> Heikki told me at PGCon that h
David Rowley writes:
> I had another look at this and it appears you were right the first time, we
> need to ensure there's no NULLs on both sides of the join condition.
Ugh. I'm back to being discouraged about the usefulness of the
optimization.
> The only other way I could imagine fixing this
On 2014-07-13 23:06:15 +1200, David Rowley wrote:
> I had another look at this and it appears you were right the first time, we
> need to ensure there's no NULLs on both sides of the join condition.
The patch is currently marked as 'ready for committer' - that doesn't
seem to correspond to the dis
On Fri, Jul 11, 2014 at 1:11 PM, Tom Lane wrote:
> I wrote:
> > We could no doubt fix this by also insisting that the left-side vars
> > be provably not null, but that's going to make the patch even slower
> > and even less often applicable. I'm feeling discouraged about whether
> > this is wort
On 12 July 2014 12:43, Tomas Vondra wrote:
>> So lets just this change done and then do more later.
>
> There's no way back, sadly. The dense allocation turned into a
> challenge. I like challenges. I have to solve it or I won't be able to
> sleep.
I admire your tenacity, but how about we solve
17 matches
Mail list logo
