[HACKERS] [DOCS] Missing COMMENT ON POLICY

Hello 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 documentation on COMMENT that I mentioned earlier on pgsql-docs. Hope this

Re: [HACKERS] WIP: Make timestamptz_out less slow.

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

Re: [HACKERS] [DOCS] Missing COMMENT ON POLICY

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

Re: [HACKERS] [DOCS] Missing COMMENT ON POLICY

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 >

Re: [HACKERS] [DOCS] Missing COMMENT ON POLICY

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

Re: [HACKERS] One question about security label command

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] Reducing the size of BufferTag & remodeling forks

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?

Re: [HACKERS] New gist vacuum.

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

Re: [HACKERS] [DOCS] Missing COMMENT ON POLICY

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 >

Re: [HACKERS] [DOCS] Missing COMMENT ON POLICY

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?

Re: [HACKERS] [DOCS] Missing COMMENT ON POLICY

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

Re: [HACKERS] RLS open items are vague and unactionable

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

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

> 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,

Re: [HACKERS] [DOCS] Missing COMMENT ON POLICY

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: [HACKERS] PATCH: index-only scans with partial indexes

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] PATCH: index-only scans with partial indexes

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(*),

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

> 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

Re: [HACKERS] snapshot too old, configured by time

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

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

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

Re: [HACKERS] 9.3.9 and pg_multixact corruption

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

Re: [HACKERS] RLS open items are vague and unactionable

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

Re: [HACKERS] RLS open items are vague and unactionable

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.

[HACKERS] We are doing well

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

Re: [HACKERS] RLS open items are vague and unactionable

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

Re: [HACKERS] extend pgbench expressions with functions

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

Re: [HACKERS] extend pgbench expressions with functions

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

[HACKERS] Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::')

> 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,

Re: [HACKERS] Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::')

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

Re: [HACKERS] Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::')

> 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