Re: [HACKERS][PROPOSAL] Covering + unique indexes.

On Tue, Sep 15, 2015 at 12:57 PM, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > > Proposal Clarification. > I see that discussion become too complicated. So, I'd like to clarify > what we are talking about. > > We are discussing 2 different improvements of index. > The one is

[HACKERS] pg_resetxlog sentences

Hi, While updating translations, I came across those almost similar sentences. pg_controldata.c 273 printf(_("Latest checkpoint's oldestCommitTs: %u\n"), 274ControlFile.checkPointCopy.oldestCommitTs); pg_resetxlog.c 668 printf(_("Latest checkpoint's oldest CommitTs:

Re: [HACKERS] Additional LWLOCK_STATS statistics

On Wed, Sep 16, 2015 at 1:21 AM, Jesper Pedersen wrote: > > On 09/15/2015 03:42 PM, Robert Haas wrote: >> >> I haven't really, just the email. But it seems like a neat concept. >> So if I understand this correctly: >> >> 74.05% of spin delays are attributable to

Re: [HACKERS] creating extension including dependencies

On 2015-09-08 04:06, Michael Paquier wrote: On Tue, Sep 8, 2015 at 10:44 AM, Michael Paquier wrote: Attached are as well changes for the documentation that I spotted in earlier reviews but were not included in the last version sent by Petr yesterday. Feel free to

Re: [HACKERS] Can extension build own SGML document?

On 9/15/15 11:45 AM, Robert Haas wrote: > On Tue, Sep 15, 2015 at 9:43 AM, Tom Lane wrote: >> AFAICT from a quick look at its documentation, asciidoc can produce >> either html or docbook output; so as soon as you want something other >> than html output (in particular, PDF),

Re: [HACKERS] [PATCH] Microvacuum for gist.

On Tue, Sep 8, 2015 at 2:35 PM, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > > Fixed patch is attached. > > The commit of this patch seems to have created a bug in which updated tuples can disappear from the index, while remaining in the table. It looks like the bug depends on

[HACKERS] T_PrivGrantee is left in NodeTag

Hi, I found that codes about T_PrivGrantee was removed by the following commit; http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=31eae6028eca4365e7165f5f33fee1ed0486aee0 but T_PrivGrantee is left in NodeTag in src/include/nodes/nodes.h. Is it intended? -- Yugo Nagata

Re: [HACKERS] proposal: function parse_ident

2015-09-16 2:41 GMT+02:00 Peter Eisentraut : > On 9/11/15 6:25 AM, Pavel Stehule wrote: > > new update of parse_ident function patch > > How would you actually use this? > > I know several people have spoken up that they could use this, but could > you provide a few actual

Re: [HACKERS] pgbench progress with timestamp

--progress-timestamp use Unix epoch timestamps in ms for progress A quibble, but it isn't in ms, it is in seconds. The digits after the decimal point give a precision to the ms level, but they don't change the base unit. Yes. The issue is mostly to keep the description under 80

Re: [HACKERS] src/test/ssl broken on HEAD

On Tue, Sep 15, 2015 at 5:23 PM, Peter Eisentraut wrote: > The only trick, as I remember, was that clients tend to prefer SSL > automatically, which we probably don't want for Unix-domain sockets, so > we'd need to tweak those settings a bit. > > The "old patch" referred to in that old thread

Re: [HACKERS] proposal: function parse_ident

On 9/11/15 6:25 AM, Pavel Stehule wrote: > new update of parse_ident function patch How would you actually use this? I know several people have spoken up that they could use this, but could you provide a few actual practical examples? -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Unicode mapping scripts cleanup

On 9/1/15 7:27 PM, Tatsuo Ishii wrote: >> On Tue, Sep 1, 2015 at 5:13 AM, Peter Eisentraut wrote: >>> So apparently, the >>> CJK to Unicode mappings are still evolving and should be updated >>> occasionally. Next steps would be to commit some or all of these >>> differences

Re: [HACKERS] src/test/ssl broken on HEAD

On 9/2/15 7:15 PM, Andres Freund wrote: >> Add a regression test suite for SSL support. >> >> It's not run by the global "check" or "installcheck" targets, because the >> temporary installation it creates accepts TCP connections from any user >> the same host, which is insecure. >

Re: [HACKERS] Unicode mapping scripts cleanup

>> I think so. We must be very careful updating the maps. Adding new >> mapping data would cause less problem, but replacing existing mappings >> will be definitely a big problem for users. > > Note that I'm not actually proposing to change the mappings, I just want > to get the scripts into

[HACKERS] Re: [COMMITTERS] pgsql: Add --synchronous option to pg_receivexlog, for more reliable WA

On Wed, Sep 16, 2015 at 11:25 AM, Peter Eisentraut wrote: > On 11/17/14 12:34 PM, Fujii Masao wrote: >> Add --synchronous option to pg_receivexlog, for more reliable WAL writing. > > The last two sentences of this piece of documentation are a bit > hand-wavy and hard to parse.

Re: [HACKERS] [DOCS] max_worker_processes on the standby

On 2015-09-03 15:03, Fujii Masao wrote: On Sat, Aug 8, 2015 at 11:02 PM, Robert Haas wrote: There's no existing precedent for a feature that lets the standby be different from the master *in any way*. So I don't see why we should start here. I think the reasonable

[HACKERS] What is the extent of FDW join pushdown support in 9.5?

The 9.5 release notes contain this promising but cryptic item: - Allow foreign data wrappers and custom scans to implement join pushdown (KaiGai Kohei) As phrased, this seems to mean, "it can be done, but we haven't done it". But there is no link to any documentation that explains how to do

Re: [HACKERS] What is the extent of FDW join pushdown support in 9.5?

> The 9.5 release notes contain this promising but cryptic item: > > - Allow foreign data wrappers and custom scans to implement join > pushdown (KaiGai Kohei) > > As phrased, this seems to mean, "it can be done, but we haven't done > it". But there is no link to any documentation that explains

[HACKERS] Re: [COMMITTERS] pgsql: Add --synchronous option to pg_receivexlog, for more reliable WA

On 11/17/14 12:34 PM, Fujii Masao wrote: > Add --synchronous option to pg_receivexlog, for more reliable WAL writing. The last two sentences of this piece of documentation are a bit hand-wavy and hard to parse. Could you clarify this? -S slotname --slot=slotname

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

On 16 September 2015 at 10:38, Rod Taylor wrote: > > > On Tue, Sep 15, 2015 at 12:57 PM, Anastasia Lubennikova < > a.lubennik...@postgrespro.ru> wrote: > >> >> Proposal Clarification. >> I see that discussion become too complicated. So, I'd like to clarify >> what we are

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

Why not normal syntax with optional INCLUDE ? CREATE UNIQUE INDEX ON table (f1,f2,f3) INCLUDE (f4) That's not the same thing. Then you're including f3 in the unique constraint, which you may not want for uniqueness purposes, but may want in the index for sorting. But then saying

Re: [HACKERS] pg_hba_lookup function to get all matching pg_hba.conf entries

Hi 2015-07-21 11:15 GMT+02:00 Haribabu Kommi : > Hi Hackers, > > This is the patch adds a new function called pg_hba_lookup to get all > matching entries > from the pg_hba.conf for the providing input data.The rows are > displayed from the other > the hba conf entries

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

CREATE INDEX ... ON table (f1, f2, f3) UNIQUE(f1, f2) INCLUDE(f4); I don't see an advantage this form. What is f3 column? just order? and f4 will not be used for compare? At least now it requires additional checks that UNIQUE() fields are the same as first columns in definition. Non

Re: [HACKERS] Review: GiST support for UUIDs

Paul Jungwirth wrote: Or something like this in pseudocode: numeric = int8_numeric(*(uint64 *)(>data[0])) * int8_numeric(MAX_INT64) + int8_numeric(*(uint64 *)(>data[8])) This is more like what I was hoping for, rather than converting to a string and back. Would you mind confirming for me:

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

On Tue, Sep 15, 2015 at 12:44 PM, Ildus Kurbangaliev wrote: > On Mon, 14 Sep 2015 06:32:22 -0400 > Robert Haas wrote: > >> On Sun, Sep 13, 2015 at 5:05 PM, Ildus Kurbangaliev >> wrote: >> > Yes, that is because

Re: [HACKERS] Mention column name in error messages

On Tue, Sep 15, 2015 at 7:12 AM, Alvaro Herrera wrote: > > I think you need errcontext(), not errdetail(). The most important > difference is that you can have multiple CONTEXT lines but only one > DETAIL; I think if you attach a second errdetail(), the first one is >

Re: [HACKERS] row_security GUC, BYPASSRLS

Joe Conway writes: > On 09/15/2015 10:58 AM, Robert Haas wrote: >> I can't argue with that, I suppose, but I think row_security=force is >> a pretty useful convenience. If we must remove it, so be it, but I'd >> be a little sad. > There are use cases where row_security=force

Re: [HACKERS] One question about security label command

On 09/13/2015 10:29 AM, Kouhei Kaigai wrote: > 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. >

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

On 2015-09-15 14:39:51 -0400, Robert Haas wrote: > We could, but since that would be strictly more annoying and less > flexible than what we've already got, why would we? I don't find the current approach of having to define tranches in every backend all that convenient. It also completely breaks

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

On Tue, Sep 15, 2015 at 2:44 PM, and...@anarazel.de wrote: > On 2015-09-15 14:39:51 -0400, Robert Haas wrote: >> We could, but since that would be strictly more annoying and less >> flexible than what we've already got, why would we? > > I don't find the current approach of

Re: [HACKERS] Additional LWLOCK_STATS statistics

On Tue, Sep 15, 2015 at 10:27 AM, Jesper Pedersen wrote: > Hi, > > I have been using the attached patch to look at how each LWLock relates to > each other in various types of runs. > > The patch adds the following fields to a LWLOCK_STATS build: > > sh_acquire_max

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

Proposal Clarification. I see that discussion become too complicated. So, I'd like to clarify what we are talking about. We are discussing 2 different improvements of index. The one is "partially unique index" and the other "index with included columns". Let's look at example. - We have a

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

Kevin Grittner wrote: > Alvaro Herrera wrote: > > I would place it inside src/test/modules, so that buildfarm > > runs it automatically; I'm not sure it will pick up things in > > src/test. > > As it stands now, the test is getting run as part of `make > check-world`,

Re: [HACKERS] row_security GUC, BYPASSRLS

On 09/15/2015 12:53 PM, Tom Lane wrote: > Joe Conway writes: >> There are use cases where row_security=force will be set in production >> environments, not only in testing. > > What cases, exactly, and is there another way to solve those problems? > I concur with Noah's

[HACKERS] Could the configure script detect the endianness for a Power CPU with endianness mode change

Hello, Some Power CPU can switch the endianness mode. If one such CPU switches from big endian to little endian, could the configure script detect the real endianness mode? Thanks, Rui Hai

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Tuesday 15 September 2015 04:06:25 Andres Freund wrote: > And here's an actual implementation of that approach. It's definitely > work-in-progress and could easily be optimized further. Don't have any > big machines to play around with right now tho. Thanks. Interesting. We had a version like

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Mon, Sep 14, 2015 at 7:27 PM, Pavel Stehule wrote: > > 2015-09-14 18:46 GMT+02:00 Shulgin, Oleksandr < > oleksandr.shul...@zalando.de>: > >> >> I have a radical proposal to remove the need for locking: make the >> CmdStatusSlot struct consist of a mere dsm_handle and

Re: [HACKERS] Attach comments to functions' parameters and return value

Hello Jim > -Original Message- > From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers- > ow...@postgresql.org] On Behalf Of Charles Clavadetscher > Sent: Dienstag, 15. September 2015 07:35 > To: Jim Nasby ; pgsql-hackers@postgresql.org > Subject: Re:

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

On 12 September 2015 at 00:45, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > I've started work on a patch that allows to combine covering and unique > functionality. > Great to hear someone is working on this! > Next issue is pg_index changes. > Now there's only a boolean flag

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On Wed, Sep 9, 2015 at 10:03 PM, Greg Stark wrote: > On Sun, Sep 6, 2015 at 1:25 PM, Andres Freund wrote: >> My vote is that we should try to get freeze maps into 9.6 - that seems >> more realistic given that we have a patch right now. Yes, it might end >> up

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

On 15 September 2015 at 18:16, Teodor Sigaev wrote: > CREATE INDEX ... ON table (f1, f2, f3) UNIQUE(f1, f2) INCLUDE(f4); >> > > I don't see an advantage this form. What is f3 column? just order? and f4 > will not be used for compare? At least now it requires additional checks

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

On 09/15/2015 10:57 AM, David Rowley wrote: >> I agree, that form >> > CREATE UNIQUE INDEX i ON t (f1, f2, f3) INCLUDE (f4) >> > is clear. f4 will be used in row compare and actually planner will be able >> > to use it as unique index (f1, f2, f3) with additional f4 or as >> > as unique index (f1,

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Saturday 12 September 2015 04:15:43 David Rowley wrote: > I've run this on a single CPU server and don't see any speedup, so I assume > I'm not getting enough contention. > As soon as our 4 socket machine is free I'll try a pgbench run with that. Excellent! Will wait. > Just for fun, what's

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

On 15 September 2015 at 15:22, Stephen Frost wrote: > Updated patch attached for review. > > Unless there are other concerns or issues raised, I'll push this later > today. > Looks good to me. Thanks for doing all this. Regards, Dean -- Sent via pgsql-hackers mailing list

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

Hi Stephen > On 15.09.2015, at 17:13, Stephen Frost wrote: > > Charles, > > * Charles Clavadetscher (clavadetsc...@swisspug.org) wrote: >> Yes, that helped a lot! In the attachment now a single patch file >> with all changes. > > I've pushed this fix now. > > Thanks! > >

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2015-09-15 19:43:28 +0300, YUriy Zhuravlev wrote: > On Tuesday 15 September 2015 16:50:44 Andres Freund wrote: > > No, they can't in a a relevant manner. We hold the buffer header lock. > I'm sorry, I did not notice of a LockBufHdr. > > In this embodiment, your approach seems to be very

Re: [HACKERS] [COMMITTERS] pgsql: Fix an O(N^2) problem in foreign key references.

I wrote: > Jan Wieck writes: >> I'm able to reproduce that failure with CLOBBER_CACHE_ALWAYS and it >> definitely is caused by this commit. Do you want to back it out for the >> time being? Kevin is on vacation right now. > I'll take a look today, and either fix it if I can

Re: [HACKERS] Can extension build own SGML document?

On Tue, Sep 15, 2015 at 9:43 AM, Tom Lane wrote: > AFAICT from a quick look at its documentation, asciidoc can produce > either html or docbook output; so as soon as you want something other > than html output (in particular, PDF), you're back to relying on the > exact same

Re: [HACKERS] [COMMITTERS] pgsql: Fix an O(N^2) problem in foreign key references.

On 09/15/2015 11:54 AM, Tom Lane wrote: Jan Wieck writes: Would it be appropriate to use (Un)RegisterXactCallback() in case of detecting excessive sequential scanning of that cache and remove all invalid entries from it at that time? Another idea is that it's not the size

Re: [HACKERS] row_security GUC, BYPASSRLS

On 09/15/2015 10:58 AM, Robert Haas wrote: > I can't argue with that, I suppose, but I think row_security=force is > a pretty useful convenience. If we must remove it, so be it, but I'd > be a little sad. There are use cases where row_security=force will be set in production environments, not

Re: [HACKERS] row_security GUC, BYPASSRLS

On Tue, Sep 15, 2015 at 1:00 AM, Noah Misch wrote: >> ...but I'm not sure I like this, either. Without row_security=force, >> it's hard for a table owner to test their policy, unless they have the >> ability to assume some other user ID, which some won't. If someone >> puts

Re: [HACKERS] [COMMITTERS] pgsql: Fix an O(N^2) problem in foreign key references.

Jan Wieck writes: > Would it be appropriate to use (Un)RegisterXactCallback() in case of > detecting excessive sequential scanning of that cache and remove all > invalid entries from it at that time? Don't see how unregistering the callback would help? In any case, I'm -1 on

Re: [HACKERS] row_security GUC, BYPASSRLS

Robert Haas writes: > On Tue, Sep 15, 2015 at 1:00 AM, Noah Misch wrote: >> It also requires a DBA unwilling to >> furnish test accounts to custodians of sensitive data. With or without >> row_security=force, such a team is on the outer perimeter of the

Re: [HACKERS] row_security GUC, BYPASSRLS

On 09/15/2015 11:10 AM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Sep 15, 2015 at 1:00 AM, Noah Misch wrote: >>> It also requires a DBA unwilling to >>> furnish test accounts to custodians of sensitive data. With or without >>>

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

On Mon, 14 Sep 2015 06:32:22 -0400 Robert Haas wrote: > On Sun, Sep 13, 2015 at 5:05 PM, Ildus Kurbangaliev > wrote: > > Yes, that is because I tried to go with current convention working > > with shmem in Postgres (there are one function

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Tuesday 15 September 2015 16:50:44 Andres Freund wrote: > No, they can't in a a relevant manner. We hold the buffer header lock. I'm sorry, I did not notice of a LockBufHdr. In this embodiment, your approach seems to be very similar to s_lock. Cycle in PinBuffer behaves like s_lock. In

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Tue, Sep 15, 2015 at 9:56 AM, Andres Freund wrote: > On 2015-09-15 08:07:57 -0500, Merlin Moncure wrote: >> Also, I'm curious about your introduction of __builtin_expect() >> macros. Did you measure any gain from them? > > I introduced them because I was bothered by the

Re: [HACKERS] Can extension build own SGML document?

On 9/15/15 8:43 AM, Tom Lane wrote: Jim Nasby writes: I'm not sure SGML is the way to go anymore anyways. Asciidoc offers a lot of what our SGML does in a much easier to support toolchain. It's also natively supported by github, which makes it nice for others to view

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

15.09.2015 12:11, Vik Fearing: On 09/15/2015 10:57 AM, David Rowley wrote: I agree, that form CREATE UNIQUE INDEX i ON t (f1, f2, f3) INCLUDE (f4) is clear. f4 will be used in row compare and actually planner will be able to use it as unique index (f1, f2, f3) with additional f4 or as as

[HACKERS] Multiple Update queries

Hello, I am using a foreign data wrapper where i get a portion of my data pre-loaded , i.e I get a set of rows before hand . So now i want to run multiple update queries on this loaded data , write the changes to file , load the next set and continue with updates again. How should i

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

Seems, final form is CREATE INDEX idx ON tbl (f1, f2, f3) [UNIQUE ON (f1, f2)] [INCLUDE (f4)] f1, f2, f3 are participated in index row comparence (btre, gist etc) f1, f2 are participated in unique constrain and it gives warranty for (f1, f2, f3[, f4]) uniqueness. Now supported by Btree only

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

On 09/15/2015 12:45 PM, Anastasia Lubennikova wrote: > 15.09.2015 12:11, Vik Fearing: >> On 09/15/2015 10:57 AM, David Rowley wrote: I agree, that form > CREATE UNIQUE INDEX i ON t (f1, f2, f3) INCLUDE (f4) > is clear. f4 will be used in row compare and actually planner will > be

Re: [HACKERS] Small typo in timeline.h regarding the meaning of infinity for timeline history entry

On Tue, Sep 15, 2015 at 7:38 AM, Fujii Masao wrote: > Thanks for the report and patch! Applied. Thanks! -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] cache type info in json_agg and friends

On 09/14/2015 04:24 PM, Andrew Dunstan wrote: On 09/14/2015 03:42 PM, Teodor Sigaev wrote: Currently, json_agg, jsonb_agg, json_object_agg and jsonb_object_agg do type classification on their arguments on each call to the transition function. This is quite unnecessary, as the argument types

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

> That path is only taken if somebody else has already locked the buffer > (e.g. BufferAlloc()). If you have contention in PinBuffer() your > workload will be mostly cache resident and neither PinBuffer() nor > UnpinBuffer() set BM_LOCKED. Thanks. Now I understand everything. It might work. We

Re: [HACKERS] extend pgbench expressions with functions

Hello Kyotaro-san, 1.evalInt and evalDouble are mutually calling on single expr node. Indeed. It looks simple and seems to work but could easily broken to fall into infinite call and finally (in a moment) exceeds stack depth. The recursion is on the tree-structure of the expression,

Re: [HACKERS] extend pgbench expressions with functions

[...] Here is a v10 where I did that when it did not add too much code repetition (eg I kept the shared branches for MIN & MAX and for the 3 RANDOM functions so as to avoid large copy pastes). Ooops, forgotten attachement. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml

Re: [HACKERS] Can extension build own SGML document?

Jim Nasby writes: > On 9/15/15 8:43 AM, Tom Lane wrote: >> AFAICT from a quick look at its documentation, asciidoc can produce >> either html or docbook output; so as soon as you want something other >> than html output (in particular, PDF), you're back to relying on the

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

Charles, * Charles Clavadetscher (clavadetsc...@swisspug.org) wrote: > Yes, that helped a lot! In the attachment now a single patch file > with all changes. I've pushed this fix now. Thanks! Stephen signature.asc Description: Digital signature

Re: [HACKERS] [COMMITTERS] pgsql: Fix an O(N^2) problem in foreign key references.

On 09/15/2015 10:58 AM, Tom Lane wrote: I wrote: Jan Wieck writes: I'm able to reproduce that failure with CLOBBER_CACHE_ALWAYS and it definitely is caused by this commit. Do you want to back it out for the time being? Kevin is on vacation right now. I'll take a look

Re: [HACKERS] row_security GUC, BYPASSRLS

> I could also see a potential gap in such approach. Specifically, I > could see a case were there are two separate roles, one that is > entrusted with defining the policies but not able to create/modify > tables, and one with the opposite capability (I understand this to be > a fairly common

Re: [HACKERS] Additional LWLOCK_STATS statistics

On Tue, Sep 15, 2015 at 3:30 PM, Jesper Pedersen wrote: > X-axis is sort of "up in the air" with flame graphs -- similar call stacks > are grouped together, and here it is the queue size. > > Y-axis is the lock queue size -- e.g. CLogControlLock is "max'ed" out, since

Re: [HACKERS] Additional LWLOCK_STATS statistics

On 09/15/2015 03:42 PM, Robert Haas wrote: I haven't really, just the email. But it seems like a neat concept. So if I understand this correctly: 74.05% of spin delays are attributable to CLogControLock, 20.01% to ProcArrayLock, and 3.39% to XidGenLock. Incredibly, the queue length reaches

Re: [HACKERS] Additional LWLOCK_STATS statistics

On 09/15/2015 03:11 PM, Robert Haas wrote: If there is an interest I'll add the patch to the next CommitFest. Thanks for considering, and any feedback is most welcomed. Seems neat, but I can't understand how to read the flame graphs. X-axis is sort of "up in the air" with flame graphs --

Re: [HACKERS] pgbench progress with timestamp

On Wed, Sep 9, 2015 at 1:35 AM, Fabien COELHO wrote: > > In the sgml, second should be plural in 'intead of the number of second >> since the'. And 'intead' should be 'instead'. >> > > Ok. > > --progress-timestamp use a Unix-like epoch timestamp for progress >>

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

Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > On 15 September 2015 at 15:22, Stephen Frost wrote: > > Updated patch attached for review. > > > > Unless there are other concerns or issues raised, I'll push this later > > today. > > Looks good to me. Excellent,

Re: [HACKERS] Can extension build own SGML document?

On Tue, Sep 15, 2015 at 8:45 AM, Robert Haas wrote: > I mean, I can't see that building a PDF of the documentation really > has much value, and I don't know even what else we can build. Who in > 2015 would use a PDF instead of HTML? > > (If there is somebody, that is fine.

Re: [HACKERS] row_security GUC, BYPASSRLS

On Tue, Sep 15, 2015 at 2:26 PM, Joe Conway wrote: > On 09/15/2015 12:53 PM, Tom Lane wrote: >> Joe Conway writes: >>> There are use cases where row_security=force will be set in production >>> environments, not only in testing. >> >> What cases, exactly,

Re: [HACKERS] Multi-tenancy with RLS

On Tue, Sep 15, 2015 at 9:18 AM, Jim Nasby wrote: > Also, we've faced issues in the past with making catalog changes due to fear > of breaking user scripts. Instead of doubling down on that with RLS on top > of catalog tables, would it be better to move the tables to a

Re: [HACKERS] Multi-tenancy with RLS

* Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Sep 15, 2015 at 9:18 AM, Jim Nasby wrote: > > Also, we've faced issues in the past with making catalog changes due to fear > > of breaking user scripts. Instead of doubling down on that with RLS on top > > of catalog

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On Wed, Sep 9, 2015 at 6:03 AM, Greg Stark wrote: > On Sun, Sep 6, 2015 at 1:25 PM, Andres Freund wrote: > > My vote is that we should try to get freeze maps into 9.6 - that seems > > more realistic given that we have a patch right now. Yes, it might end > >

Re: [HACKERS] Can extension build own SGML document?

Michael Paquier writes: > On Tue, Sep 15, 2015 at 8:45 AM, Robert Haas wrote: >> I mean, I can't see that building a PDF of the documentation really >> has much value, and I don't know even what else we can build. Who in >> 2015 would use a PDF

Re: [HACKERS] Can extension build own SGML document?

Tom Lane wrote: > Michael Paquier writes: > > On Tue, Sep 15, 2015 at 8:45 AM, Robert Haas wrote: > >> I mean, I can't see that building a PDF of the documentation really > >> has much value, and I don't know even what else we can build. Who in

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

Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > A minor point -- this comment isn't quite right: Fixed. > because the policies that are fetched there are only used for > add_security_quals(), not for add_with_check_options(). It might be > cleaner if the 'if' statement that follows

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Fri, Sep 11, 2015 at 1:57 PM, Amit Kapila wrote: > On Fri, Sep 11, 2015 at 10:10 AM, Fujii Masao wrote: >> >> So I added the object type, i.e., file in this case, to the errdetail >> messages. Attached is the updated version of the patch. >> >>

[HACKERS] Additional LWLOCK_STATS statistics

Hi, I have been using the attached patch to look at how each LWLock relates to each other in various types of runs. The patch adds the following fields to a LWLOCK_STATS build: sh_acquire_max (int): The maximum shared locks in series for the lock ex_acquire_max (int): The maximum

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

15.09.2015 12:18, David Rowley: On 12 September 2015 at 00:45, Anastasia Lubennikova > wrote: I've started work on a patch that allows to combine covering and unique functionality. Great to hear someone is working on

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

On 15 September 2015 at 22:20, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > Hm, I think that it would be quite clear to set it to zero for non-unique > indexes. > *(nunique == 0)* is equal to *(indisunique==false)*. > > But maybe I've missed some reason why we should to save

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

2015-09-15 David Rowley : > I'm also a bit confused where f3 comes in here. If it's UNIQUE on (f1,f2) > and we include f4. Where's f3? Columns f1, f2, f3 are in the internal nodes of the tree (i.e., they are used to find the ultimate leaf nodes). f4 is only in the

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hello, Continuing testing: For pg_syncinfo.conf below an error is thrown. { "sync_info": { "quorum": 3, "nodes":

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

On 15 September 2015 at 23:51, Nicolas Barbier wrote: > 2015-09-15 David Rowley : > > > I'm also a bit confused where f3 comes in here. If it's UNIQUE on (f1,f2) > > and we include f4. Where's f3? > > Columns f1, f2, f3 are in the internal

Re: [HACKERS] Can extension build own SGML document?

Jim Nasby writes: > I'm not sure SGML is the way to go anymore anyways. Asciidoc offers a > lot of what our SGML does in a much easier to support toolchain. It's > also natively supported by github, which makes it nice for others to > view the output (see [1] as an

Re: [HACKERS] Could the configure script detect the endianness for a Power CPU with endianness mode change

Rui Hai Jiang writes: > Some Power CPU can switch the endianness mode. > If one such CPU switches from big endian to little endian, could the > configure script detect the real endianness mode? It would detect whatever endianness you run it under. No, we're not likely to

Re: [HACKERS] [COMMITTERS] pgsql: Fix an O(N^2) problem in foreign key references.

Jan Wieck writes: > On 09/14/2015 09:56 AM, Tom Lane wrote: >> Kevin Grittner writes: >>> Fix an O(N^2) problem in foreign key references. >> Judging from the buildfarm, this patch is broken under >> CLOBBER_CACHE_ALWAYS. See friarbird's results in

Re: [HACKERS] Multi-tenancy with RLS

On 9/14/15 7:38 PM, Haribabu Kommi wrote: On Fri, Sep 11, 2015 at 7:50 AM, Joe Conway wrote: On 09/01/2015 11:25 PM, Haribabu Kommi wrote: If any user is granted any permissions on that object then that user can view it's meta data of that object from the catalog tables.

Re: [HACKERS] [COMMITTERS] pgsql: Fix an O(N^2) problem in foreign key references.

On 09/14/2015 09:56 AM, Tom Lane wrote: Kevin Grittner writes: Fix an O(N^2) problem in foreign key references. Judging from the buildfarm, this patch is broken under CLOBBER_CACHE_ALWAYS. See friarbird's results in particular. I might be too quick to finger this

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hello, Thank you Thomas and Sameer for checking the patch and giving your comments! I will post an updated patch soon. Regards, Beena Emerson

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Mon, Sep 14, 2015 at 9:06 PM, Andres Freund wrote: > On 2015-09-14 17:41:42 +0200, Andres Freund wrote: >> I pointed out how you can actually make this safely lock-free giving you >> the interesting code. > > And here's an actual implementation of that approach. It's

Re: [HACKERS] Can extension build own SGML document?

On 9/14/15 6:06 PM, Michael Paquier wrote: On Tue, Sep 15, 2015 at 6:01 AM, Alvaro Herrera wrote: I think the only way upstream Postgres could offer this is as a way to build a separate "book", i.e. not a chapter/section within the main book. I think it would require huge complications in

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello Thom, >Okay, I've just tested this with a newly-loaded table (1,252,973 of jsonb >data), Thanks a lot! >but after it's finished, I end up with this: >json=# select * from pg_stat_vacuum_progress; >-[ RECORD 1 ]---+--- >pid | 5569 >total_pages | 217941

  1   2   >