On Sun, May 08, 2016 at 12:29:27PM -0400, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > My suggestion is that, from this point forward, we add new tests to
> > 9.6 only if they are closely related to a bug that is getting fixed or
> > a feature that is new in 9.6. I think
On Sun, May 22, 2016 at 9:32 PM, Andreas Seltenreich
wrote:
>
> Amit Kapila writes:
>
> > avoid_restricted_clause_below_gather_v1.patch
> > prohibit_parallel_clause_below_rel_v1.patch
>
> I didn't observe any parallel worker related coredumps since applying
> these. The same amount of testing don
Andres Freund writes:
> On 2016-05-21 17:18:14 -0400, Tom Lane wrote:
>> What remains unclear is how come this only fails once in a blue moon.
>> Seems like any valgrind run of the regression tests should have caught it.
> Looks like a timing issue.
Yeah, I came to the same conclusion after awhi
On Sun, May 22, 2016 at 6:53 PM, Teodor Sigaev wrote:
>
> to_tsquery(' Berkus & "PostgreSQL Version 10.0" ')
>>
>> ... would be equivalent to:
>>
>> to_tsquery(' Berkus & ( PostgreSQL <-> version <-> 10.0 )')
>>
>
> select to_tsquery('Berkus') && phraseto_tsquery('PostgreSQL Version 10.0');
> doe
tl;dr
Semantic changes to SRF-in-target-list processing are undesirable when they
are all but deprecated.
I'd accept a refactoring that trades a performance gain for unaffected
queries for a reasonable performance hit of those afflicted.
Preamble...
Most recent thread that I can recall seeing o
Andreas Seltenreich wrote:
> There was one instance of this PANIC when testing with the regression db
> of master at 50e5315.
>
> ,
> | WARNING: specified item offset is too large
> | PANIC: failed to add BRIN tuple
> | server closed the connection unexpectedly
> `
>
> It is reproducibl
On 23 May 2016 at 08:53, Andres Freund wrote:
> Hi,
>
> discussing executor performance with a number of people at pgcon,
> several hackers - me included - complained about the additional
> complexity, both code and runtime, required to handle SRFs in the target
> list.
>
> One idea I circulated
Hi,
discussing executor performance with a number of people at pgcon,
several hackers - me included - complained about the additional
complexity, both code and runtime, required to handle SRFs in the target
list.
One idea I circulated was to fix that by interjecting a special executor
node to pro
Hi tom,
On 2016-05-21 17:18:14 -0400, Tom Lane wrote:
> Andres Freund writes:
> > The valgrind animal just reported a large object related failure on 9.4:
>
> The proximate cause seems to be that _bt_newroot isn't bothering to
> fill the buffer_std field here:
>
> /* Make a full-p
to_tsquery(' Berkus & "PostgreSQL Version 10.0" ')
... would be equivalent to:
to_tsquery(' Berkus & ( PostgreSQL <-> version <-> 10.0 )')
select to_tsquery('Berkus') && phraseto_tsquery('PostgreSQL Version 10.0');
does it as you wish
I realize we're already in beta, but pgCon was actuall
On Sun, May 22, 2016 at 10:36 AM, Tatsuo Ishii wrote:
>> The brief introudce of MPI(Message Passing Interface) as following URL,
>> which is a message protocol used for parallel computinng, just like DSM
>> does in parallel query. The DSM play a message passing role(in fact, it's.
>> by passing th
Hello,
I think I've managed to improve pg_bsd_indent's handling of two types of
cases.
The first are like in this example:
- hashp = (HTAB *) DynaHashAlloc(sizeof(HTAB) + strlen(tabname) +1);
+ hashp = (HTAB *) DynaHashAlloc(sizeof(HTAB) + strlen(tabname) + 1);
Pristine pg_bsd_inde
On Sun, May 22, 2016 at 3:00 PM, Thom Brown wrote:
> On 22 May 2016 at 18:52, Josh berkus wrote:
> > Folks,
> >
> > This came up at pgCon.
> >
> > The 'word <-> word <-> word' syntax for phrase search is not
> > developer-friendly. While we need the <-> operator for SQL and for the
> > sophisti
On 22 May 2016 at 18:52, Josh berkus wrote:
> Folks,
>
> This came up at pgCon.
>
> The 'word <-> word <-> word' syntax for phrase search is not
> developer-friendly. While we need the <-> operator for SQL and for the
> sophisticated cases, it would be really good to support an alternate
> syntax
Folks,
This came up at pgCon.
The 'word <-> word <-> word' syntax for phrase search is not
developer-friendly. While we need the <-> operator for SQL and for the
sophisticated cases, it would be really good to support an alternate
syntax for the simplest case of "words next to each other". My p
> The brief introudce of MPI(Message Passing Interface) as following URL,
> which is a message protocol used for parallel computinng, just like DSM
> does in parallel query. The DSM play a message passing role(in fact, it's.
> by passing the query plan/raw node tree to anthor worker) in parallel
>
I wrote:
> There's another class of parallel worker core dumps when testing master
> with sqlsmith. In these cases, the following assertion fails for all
> workers simulataneously:
>
> TRAP: FailedAssertion("!(mqh->mqh_partial_bytes <= nbytes)", File:
> "shm_mq.c", Line: 386)
I no longer observ
Amit Kapila writes:
> avoid_restricted_clause_below_gather_v1.patch
> prohibit_parallel_clause_below_rel_v1.patch
I didn't observe any parallel worker related coredumps since applying
these. The same amount of testing done before applying them yielded
about a dozend.
Dilip Kumar writes:
> So n
What's MPI?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> Maybe we can refere to the MPI test cases.
>
> On Sun, May 22, 2016 at 3:19 PM, Hao Lee wrote:
>
>> What kind of cases do you want to run? beside the m
On Sun, May 22, 2016 at 12:39 PM, Amit Kapila
wrote:
> On Mon, Mar 28, 2016 at 4:35 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> Hackers,
>>
>> one our customer meet near xid wraparound situation. xid counter
>> reached xidStopLimit value. So, no transactions could be execu
There was one instance of this PANIC when testing with the regression db
of master at 50e5315.
,
| WARNING: specified item offset is too large
| PANIC: failed to add BRIN tuple
| server closed the connection unexpectedly
`
It is reproducible with the query below on this instance only.
On Mon, Mar 28, 2016 at 4:35 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> Hackers,
>
> one our customer meet near xid wraparound situation. xid counter
> reached xidStopLimit value. So, no transactions could be executed in
> normal mode. But what I noticed is strange behaviour o
There's another class of parallel worker core dumps when testing master
with sqlsmith. In these cases, the following assertion fails for all
workers simulataneously:
TRAP: FailedAssertion("!(mqh->mqh_partial_bytes <= nbytes)", File: "shm_mq.c",
Line: 386)
The backtraces of the controlling proce
Thank you for the suggesion. Currently no particular test cases are
in my mind. That's the reason why I need input from
community. Regarding the test schedule, PGECons starts the planning
from next month or so. So I guess test starts no earlier than July.
Best regards,
--
Tatsuo Ishii
SRA OSS, In
24 matches
Mail list logo
