I attached wrong patch in previous message, sorry ! Here is a last version.
This is a new WIP of SP-GiST patch, which provides support for:
1. Concurrent vacuum
2. Vacuum logging
3. WAL replay
Oleg
On Thu, 1 Sep 2011, Oleg Bartunov wrote:
This is updates SP-GiST patch, which fixed one bug and
Attached is updated SP-GiST patch, which provides full logging support and
fixed several bugs (Thanks ALexander Korotkov for help).
Regards,
Oleg
On Thu, 1 Sep 2011, Oleg Bartunov wrote:
This is updates SP-GiST patch, which fixed one bug and replaced test to the
locale independent one.
On
Thanks for the review.
(2011/09/05 3:55), Kohei KaiGai wrote:
> I tried to review this patch.
>
> It seems to me its implementation is reasonable and enough simple.
> All the works of this patch is pick-up "force_not_null" option from
> pg_attribute.attfdwoptions and transform its data structure
I wrote:
> On a longer-term basis, I'm looking into what we could do with
> extracting stats from subqueries, but that doesn't seem like material
> for a backpatch. I have a draft patch that I've been playing with
> (attached).
I've committed a heavily rewritten version of that patch. Git HEAD
s
I tried to review this patch.
It seems to me its implementation is reasonable and enough simple.
All the works of this patch is pick-up "force_not_null" option from
pg_attribute.attfdwoptions and transform its data structure into suitable
form to the existing BeginCopyFrom().
So, I'd almost like t
On Fri, Sep 2, 2011 at 6:52 PM, Magnus Hagander wrote:
> Attached patch implements a "low watermark wal location" in the
> walsender shmem array. Setting this value in a walsender prevents
> transaction log removal prior to this point - similar to how
> wal_keep_segments work, except with an abso
Andrew Dunstan writes:
> On 09/04/2011 11:31 AM, Tom Lane wrote:
>> I think the real question that needs to be asked here is why there's not
>> a buildfarm member running the tests in Czech locale. And maybe some
>> of the other ones that have been problematic in the past. We should not
>> have
On 09/04/2011 11:31 AM, Tom Lane wrote:
Andrew Dunstan writes:
Well, I don't think we are obliged to cater for locales that break ASCII
ordering.
The logical conclusion of that position is that there's no need to make
the regression tests pass in any other locale than C. Which is not the
pr
Andrew Dunstan writes:
> Well, I don't think we are obliged to cater for locales that break ASCII
> ordering.
The logical conclusion of that position is that there's no need to make
the regression tests pass in any other locale than C. Which is not the
project policy, and we (including you, wit
Andrew Dunstan writes:
> On 09/04/2011 10:23 AM, Peter Eisentraut wrote:
>> On sön, 2011-09-04 at 08:57 -0400, Andrew Dunstan wrote:
> In what locale does 'sc' sort before 's4'?
>> In Czech.
> Well, I don't think we are obliged to cater for locales that break ASCII
> ordering.
We've changed r
On sön, 2011-09-04 at 10:47 -0400, Andrew Dunstan wrote:
> Well, I don't think we are obliged to cater for locales that break ASCII
> ordering.
We do cater for that. See
commit 8cd375526790c5be8ae24c77f13ac446adda88b6
Author: Peter Eisentraut
Date: Mon Mar 9 15:04:21 2009 +
Tweak th
On 09/04/2011 10:23 AM, Peter Eisentraut wrote:
On sön, 2011-09-04 at 08:57 -0400, Andrew Dunstan wrote:
In what locale does 'sc' sort before 's4'?
In Czech.
(And I'd humbly suggest that whatever locale it is is possibly
broken.)
There were some discussions about this in the past; it's app
On sön, 2011-09-04 at 08:57 -0400, Andrew Dunstan wrote:
> In what locale does 'sc' sort before 's4'?
In Czech.
> (And I'd humbly suggest that whatever locale it is is possibly
> broken.)
There were some discussions about this in the past; it's apparently
based on a national standard and complet
On 09/04/2011 08:57 AM, Andrew Dunstan wrote:
> In what locale does 'sc' sort before 's4'? (And I'd humbly suggest that
> whatever locale it is is possibly broken.)
EBCDIC?
Joe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
On 09/04/2011 08:23 AM, Pavel Stehule wrote:
Hello
there is one regress test, that failed on my f14
[pavel@nemesis postgresql]$ uname -a
Linux nemesis 2.6.35.14-95.fc14.i686.PAE #1 SMP Tue Aug 16 21:12:22
UTC 2011 i686 i686 i386 GNU/Linux
regression.diffs
Hello
there is one regress test, that failed on my f14
[pavel@nemesis postgresql]$ uname -a
Linux nemesis 2.6.35.14-95.fc14.i686.PAE #1 SMP Tue Aug 16 21:12:22
UTC 2011 i686 i686 i386 GNU/Linux
regression.diffs
3676/3676 100%
*** /home/pavel/src
Jeremy Drake writes:
> On Sun, 4 Sep 2011, Tom Lane wrote:
>> Right now I have a feeling that this is a compiler bug.
> That's my feeling, also.
>> Don't know
>> whether you have the interest/energy to try to reduce it to a reportable
>> test case.
> If you mean reporting it to the compiler ven
On Sun, 4 Sep 2011, Tom Lane wrote:
> Jeremy Drake writes:
> > I didn't see any changes that looked like they affected
> > CurrentMemoryContext, but I attached the compressed context diff in case
> > you want to look at it.
>
> Right now I have a feeling that this is a compiler bug.
That's my fe
18 matches
Mail list logo
