> Tatsuo Ishii writes:
>>> When pg_ctl tries to connect to postmaster, it uses "0.0.0.0" as the
>>> target ip address. Unfortunately "0.0.0.0" is not a valid address on
>>> Windows and it fails. Shouldn't pg_ctl translate "0.0.0.0" to
>>> "127.0.0.1" in this case?
>
>> I think this is definitely
Tatsuo Ishii writes:
>> When pg_ctl tries to connect to postmaster, it uses "0.0.0.0" as the
>> target ip address. Unfortunately "0.0.0.0" is not a valid address on
>> Windows and it fails. Shouldn't pg_ctl translate "0.0.0.0" to
>> "127.0.0.1" in this case?
> I think this is definitely a bug. I
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hello.
I installed centos 6.7 version on virtualbax, have cl
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:tested, failed
Hello.
I installed centos 6.7 version on virtualbax, have cl
> The following bug has been logged on the website:
>
> Bug reference: 13611
> Logged by: Kondo Yuta
> Email address: ko...@sraoss.co.jp
> PostgreSQL version: 9.4.4
> Operating system: Windows 7
> Description:
>
> Hello,
>
> According to PostgreSQL document, listen_a
I want to thank everyone for the community improvement I have seen in
the past three months. I have said some harsh words during the past
year, but our current teamwork, attention to detail, and wise balance of
priorities makes me confident we are well placed to continue
accomplishing the dramatic
Dean,
On Sunday, September 13, 2015, Dean Rasheed
wrote:
> On 13 September 2015 at 20:59, Stephen Frost > wrote:
> > I've been through this and definitely like it more than what we had
> > previously, as I had mentioned previously. I've also added the
> > RETURNING handling, per the discussion
On 13 September 2015 at 20:59, Stephen Frost wrote:
> I've been through this and definitely like it more than what we had
> previously, as I had mentioned previously. I've also added the
> RETURNING handling, per the discussion between you, Robert, Tom, and
> Kevin.
>
> Would be great to get your
Hi,
On 09/13/2015 08:03 PM, Kevin Grittner wrote:
In my view, the most disappointing thing about the patch is that
when both indexes are present, it doesn't use the narrower one. If
*only* the narrower index is present, it runs the index-only scan
using that index for count(b) and count(*), wh
> On Sep 13, 2015, at 11:32 PM, Robert Haas wrote:
>
> On Sun, Sep 13, 2015 at 12:43 PM, Ildus Kurbangaliev
> wrote:
>> Added changes related to the latest master (for individual LWLocks
>> definitions)
>
> If I haven't said this clearly enough already, I'm not OK with
> changing the tranche n
On Sun, Sep 13, 2015 at 12:43 PM, Ildus Kurbangaliev
wrote:
> Added changes related to the latest master (for individual LWLocks
> definitions)
If I haven't said this clearly enough already, I'm not OK with
changing the tranche name from char * to a fixed-size character array.
Nor am I OK with li
On Sun, Sep 13, 2015 at 11:09 AM, Ildus Kurbangaliev
wrote:
> This is pretty much the same that my patch does. There is
> two API calls (for a size determination and a tranche creation), except
> MainLWLockArray is used only for individual LWLocks.
It's not really the same. Your patch doesn't pr
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> OK, here's a rebased version of the patch.
Thanks!
> There are no significant changes from last time this was discussed. I
> believe the module regression test changes are harmless --- a result
> of a change in the order that SB quals are
Thanks to both Steve and Álvaro for review and comments. I won't
be able to address all of those within the time frame of the
current CF, so I have moved it to the next CF and flagged it as
"Waiting on Author". I will post a patch to address all comments
before that CF starts. I will discuss now
Thomas Munro writes:
> In various places we have int pageno = offset / (uint32) 1636, expanded
> from this macro (which calls the offset an xid):
It appears to depend on the context it is expanded in, as some of the
code must have gotten the segment number right:
,[ ls -sh pg_multixact/membe
Tomas Vondra wrote:
> That means I've been unable to measure any significant overhead
> of the patch.
I've run a lot of benchmarks, and with anything resembling a common
query the differences in planning time are lost in the noise. (I
didn't create a better example than Tomas of where a lot of
Added changes related to the latest master (for individual LWLocks
definitions)
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
lwlocks_refactor_v3.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
Hi Stephen
On 13/09/2015 16:56, Stephen Frost wrote:
Charles,
* Charles Clavadetscher (clavadetsc...@swisspug.org) wrote:
I noticed that the position of the parameter "policy_name" in the
description list of parameters was not at the (alphabetically)
correct position. I changed that and the re
Hi Joe,
The attached one is the regression test fixup in v9.2.
As we applied to the v9.3 or later, it replaces unconfined_t domain
by the self defined sepgsql_regtest_superuser_t.
Unfortunately, I found a bug to process SELECT INTO statement.
Because v9.2 didn't have ObjectAccessPostCreate to inf
> On Sep 13, 2015, at 5:36 AM, Robert Haas wrote:
>
> On Sat, Sep 12, 2015 at 8:24 AM, Amit Kapila wrote:
>> 1. Modify the tranche mechanism so that information about LWLocks
>> can be tracked easily. For this already there is some discussion, ideas
>> and initial patch is floated in this thre
Charles,
* Charles Clavadetscher (clavadetsc...@swisspug.org) wrote:
> I noticed that the position of the parameter "policy_name" in the
> description list of parameters was not at the (alphabetically)
> correct position. I changed that and the result is attached.
Thanks!
> I think/hope that is
Stephen
On 13/09/2015 15:26, Charles Clavadetscher wrote:
Hello Stephen
On 13/09/2015 14:49, Stephen Frost wrote:
Charles,
Just FYI, on these lists, we'd prefer it if you wouldn't top-post.
* Charles Clavadetscher (clavadetsc...@swisspug.org) wrote:
Yes, of course. I will take care of that
On 11 September 2015 at 15:51, Joe Conway wrote:
> On 09/11/2015 04:33 AM, Stephen Frost wrote:
>> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>>> I will happily work up a rebased version of the patch, but only if I
>>> get a serious commitment from a committer to review it. Otherwise,
>>> I'
Hello Stephen
On 13/09/2015 14:49, Stephen Frost wrote:
Charles,
Just FYI, on these lists, we'd prefer it if you wouldn't top-post.
* Charles Clavadetscher (clavadetsc...@swisspug.org) wrote:
Yes, of course. I will take care of that and send a new patch.
Thanks!
Who will then git push it?
On Fri, Sep 11, 2015 at 7:52 AM, Костя Кузнецов wrote:
> old version:
>
> INFO: vacuuming "public.point_tbl"
> INFO: scanned index "gpointind" to remove 11184520 row versions
> DETAIL: CPU 84.70s/72.26u sec elapsed 27007.14 sec.
> [...]
>
> new vacuum is about
> INFO: vacuuming "public.point_tbl"
On 12 September 2015 at 21:19, Andres Freund wrote:
> On 2015-09-12 13:12:26 +0100, Simon Riggs wrote:
> > Why do we have to do buffer lookups using the full buffer tag?
>
> We don't necessarily.
>
> > Why not just use (relNode, blockNum) and resolve hash collisions, if any?
>
> I tried that and
Charles,
Just FYI, on these lists, we'd prefer it if you wouldn't top-post.
* Charles Clavadetscher (clavadetsc...@swisspug.org) wrote:
> Yes, of course. I will take care of that and send a new patch.
Thanks!
> Who will then git push it?
I'd be happy to take care of it, though any of the commi
Hello Stephen
Yes, of course. I will take care of that and send a new patch.
Who will then git push it?
Thank you for your feedback.
Bye
Charles
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Stephen Frost
> Sen
Charles,
* Charles Clavadetscher (clavadetsc...@swisspug.org) wrote:
> Well I gave it a try. I am still not very well aware how the process for
> suggesting or submitting corrections work, but this is as far as I got.
> In the attachment is a patch for the missing entry for POLICY in the
> documen
On 12 September 2015 at 04:24, Andres Freund wrote:
> On 2015-09-12 04:00:26 +1200, David Rowley wrote:
> > I've not done anything yet to remove the #ifdef HAVE_INT64_TIMESTAMP from
> > AppendSeconds(). The only way I can think to handle this is to just
> > make fsec_t unconditionally an int64 (s
30 matches
Mail list logo