On Mon, Jun 20, 2016 at 3:42 PM, Amit Kapila wrote:
> On Mon, Jun 20, 2016 at 11:48 AM, Masahiko Sawada
> wrote:
>>
>> Hi all,
>>
>> My colleague noticed that the output of EXPLAIN ANALYZE doesn't work
>> fine for parallel seq scan.
>>
>> postgres(1)=# explain analyze verbose select count(*) from
On Mon, Jun 20, 2016 at 11:48 AM, Masahiko Sawada
wrote:
>
> Hi all,
>
> My colleague noticed that the output of EXPLAIN ANALYZE doesn't work
> fine for parallel seq scan.
>
> postgres(1)=# explain analyze verbose select count(*) from
pgbench_accounts ;
>
Hi all,
My colleague noticed that the output of EXPLAIN ANALYZE doesn't work
fine for parallel seq scan.
postgres(1)=# explain analyze verbose select count(*) from pgbench_accounts ;
QUERY PLAN
---
On Mon, Jun 20, 2016 at 3:43 PM, Craig Ringer wrote:
> On 18 June 2016 at 11:28, Thomas Munro
> wrote:
>> Several times now when reading, debugging and writing code I've wished
>> that LWLockHeldByMe assertions specified the expected mode, especially
>> where exclusive locking is required.
>>
>>
On Mon, Jun 20, 2016 at 12:40 PM, Craig Ringer wrote:
> On 18 June 2016 at 02:42, Robert Haas wrote:
>>
>> On Fri, Jun 17, 2016 at 2:23 PM, Aleksey Demakov
>> wrote:
>> > Essentially this is pessimizing for the lowest common denominator
>> > among OSes.
>>
>> I totally agree. That's how we make
On 18 June 2016 at 11:28, Thomas Munro
wrote:
> Hi hackers,
>
> Several times now when reading, debugging and writing code I've wished
> that LWLockHeldByMe assertions specified the expected mode, especially
> where exclusive locking is required.
>
> What do you think about something like the att
On 18 June 2016 at 02:42, Robert Haas wrote:
> On Fri, Jun 17, 2016 at 2:23 PM, Aleksey Demakov
> wrote:
> > Essentially this is pessimizing for the lowest common denominator
> > among OSes.
>
> I totally agree. That's how we make the server portable.
>
> > Having a contiguous address space mak
Robert Haas writes:
> On Sun, Jun 19, 2016 at 5:22 PM, Peter Eisentraut
> wrote:
>> Well, the purpose of the test is to check the error passing between worker
>> and leader. If we just silently revert to not doing that, then we can't
>> really be sure that we're testing the right thing.
> I've
Robert Haas writes:
> On Sun, Jun 19, 2016 at 4:21 PM, Andreas Karlsson wrote:
>> Here they are. Shelve them if you like. They are some of the least important
>> extensions that still should be fixed so they can end up in 10 if you do not
>> find the time.
> Thanks. I think it's too late to try
On Sun, Jun 19, 2016 at 5:22 PM, Peter Eisentraut
wrote:
> Well, the purpose of the test is to check the error passing between worker
> and leader. If we just silently revert to not doing that, then we can't
> really be sure that we're testing the right thing. We've already seen some
> instances
On Sun, Jun 19, 2016 at 4:21 PM, Andreas Karlsson wrote:
> On 06/17/2016 09:11 PM, Robert Haas wrote:
>> I was kind of hoping you'd have a new version of this posted already.
>> beta2 is wrapping on Monday, and I'm inclined to shelve anything that
>> isn't done by then for the next release. And I
Peter Eisentraut writes:
> On 6/19/16 3:09 PM, Robert Haas wrote:
>> On Sun, Jun 19, 2016 at 11:36 AM, Tom Lane wrote:
>>> No, it *might* execute in a worker. If you can get one.
>> Right.
> Well, the purpose of the test is to check the error passing between
> worker and leader. If we just s
On 6/19/16 3:09 PM, Robert Haas wrote:
On Sun, Jun 19, 2016 at 11:36 AM, Tom Lane wrote:
Amit Kapila writes:
On Sun, Jun 19, 2016 at 10:10 AM, Tom Lane wrote:
Would this not result in unstable test output depending on whether the
code executes in the leader or a worker?
Before doing that
On 06/17/2016 09:11 PM, Robert Haas wrote:
I was kind of hoping you'd have a new version of this posted already.
beta2 is wrapping on Monday, and I'm inclined to shelve anything that
isn't done by then for the next release. And I don't really plan to
work much this weekend.
Here they are. Shel
On Sun, Jun 19, 2016 at 11:36 AM, Tom Lane wrote:
> Amit Kapila writes:
>> On Sun, Jun 19, 2016 at 10:10 AM, Tom Lane wrote:
>>> Would this not result in unstable test output depending on whether the
>>> code executes in the leader or a worker?
>
>> Before doing that test, we set force_parallel_
Michael Paquier writes:
> On Sun, Jun 19, 2016 at 12:51 AM, Tom Lane wrote:
>> What seems like a more conservative answer to me is to revert c869a7d5b
>> in 9.1 only, and address the buildfarm stability issue it sought to
>> resolve by increasing the fixed timeout from 5 seconds to, say, 10.
> +
Amit Kapila writes:
> On Sun, Jun 19, 2016 at 10:10 AM, Tom Lane wrote:
>> Would this not result in unstable test output depending on whether the
>> code executes in the leader or a worker?
> Before doing that test, we set force_parallel_mode=1, so it should always
> execute in worker which will
On Sun, Jun 19, 2016 at 7:38 PM, Vik Fearing wrote:
> On 19/06/16 12:28, Michael Paquier wrote:
>> On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier
>> Or in short the attached.
>
> The code looks good to me but why no documentation?
Because that's a long day... Thanks! Now you have it.
--
Michae
On 06/18/2016 06:14 PM, Tom Lane wrote:
Robert Haas writes:
On Fri, Jun 17, 2016 at 10:41 PM, Tom Lane wrote:
Ordinarily I'd just summarily back-patch a fix, but that commit shipped
in 9.0, which means it's been broken a long time. I'm worried that
back-patching a change might be more likely
On Sun, Jun 19, 2016 at 12:51 AM, Tom Lane wrote:
> What seems like a more conservative answer to me is to revert c869a7d5b
> in 9.1 only, and address the buildfarm stability issue it sought to
> resolve by increasing the fixed timeout from 5 seconds to, say, 10.
+1 for doing that. Knowing that s
Hi
On 06/18/2016 06:52 PM, Tom Lane wrote:
Tomas Vondra writes:
A few more comments, about re-reading the patch more thoroughly. I
wouldn't say any of those qualify as bugs, but rather as discussion
about some of the design choices:
1) NULL handling
I'd argue that we should do something
On 19/06/16 12:28, Michael Paquier wrote:
> On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier
> wrote:
>> The new pg_stat_wal_receiver does not include primary_conninfo.
>> Looking at that now, it looks almost stupid not to include it...
>> Adding it now would require a catalog bump, so I am not su
On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier
wrote:
> The new pg_stat_wal_receiver does not include primary_conninfo.
> Looking at that now, it looks almost stupid not to include it...
> Adding it now would require a catalog bump, so I am not sure if this
> is acceptable at this stage for 9.6.
Hi all,
The new pg_stat_wal_receiver does not include primary_conninfo.
Looking at that now, it looks almost stupid not to include it...
Adding it now would require a catalog bump, so I am not sure if this
is acceptable at this stage for 9.6...
Regards,
--
Michael
--
Sent via pgsql-hackers ma
24 matches
Mail list logo
