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

On Thu, Dec 31, 2015 at 3:36 AM, Amit Kapila wrote: > Going further on this work, I have written a patch for separating the > tranches for extensions. The basic idea is to expose two new API's, > first to request a new tranche and second to assign a lock from that >

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

On Mon, Jan 4, 2016 at 11:16 AM, Tom Lane wrote: > Jim Nasby writes: >> regrole and regnamespace don't run their output through quote_ident(). >> That's contrary to all the other reg* operators. > >> Worse, they also don't *allow* quoted input. Not

Re: [HACKERS] Broken lock management in policy.c.

On Sun, Jan 3, 2016 at 6:09 PM, Peter Geoghegan wrote: >> I think we should get rid of it altogether (since I also agree with the >> upthread comment that it's in the wrong place) and instead put an example >> into section 5.7 saying directly that sub-selects, or in general >>

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

I wrote: > There's no real advantage to that anyway, compared with just doing > stringToQualifiedNameList and then complaining if its list_length isn't 1. Or just use SplitIdentifierString directly ... regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Improved tab completion for FDW DDL

On Wed, Dec 30, 2015 at 01:21:06PM +0100, Andreas Karlsson wrote: > Hi, > > Here is a patch which adds the below missing tab completions for the FDW DDL > commands. I noticed these were missing while playing around with FDWs a > while ago. > > "ALTER SERVER " with "RENAME TO" > "CREATE SERVER

[HACKERS] row_security GUC does not behave as documented

The fine manual says that when row_security is set to off, "queries fail which would otherwise apply at least one policy". However, a look at check_enable_rls() says that that is a true statement only when the user is not table owner. If the user *is* table owner, turning off row_security seems

Re: [HACKERS] Broken lock management in policy.c.

On Sun, Jan 3, 2016 at 6:00 PM, Stephen Frost wrote: >> I'm not sure what you mean. The CREATE POLICY changes in commit >> 43cd468cf01007f3 specifically call out the issue illustrated in my >> example test case. There are some other changes made in that commit, >> but they

[HACKERS] Description tweak for vacuumdb

Hi Like the docs say, vacuumdb is a "wrapper around the SQL command VACUUM" which I used to use in dim-and-distant pre-autovacuum days came for cronjobs, but until messing around with pg_upgrade recently I hadn't really had much use for it. Anyway, the docs also say "There is no effective

Re: [HACKERS] Broken lock management in policy.c.

Peter Geoghegan writes: > On Sun, Jan 3, 2016 at 5:18 PM, Tom Lane wrote: >> In any case, the text in create_policy.sgml seems to be a misleading >> description of the problem, as it's talking about DDL modifications >> which are *not* what's happening here.

Re: [HACKERS] Broken lock management in policy.c.

Peter, On Sunday, January 3, 2016, Peter Geoghegan wrote: > On Sun, Jan 3, 2016 at 6:09 PM, Peter Geoghegan > wrote: > >> I think we should get rid of it altogether (since I also agree with the > >> upthread comment that it's in the wrong place)

Re: [HACKERS] Broken lock management in policy.c.

Tom, Peter, On Sunday, January 3, 2016, Peter Geoghegan wrote: > On Sun, Jan 3, 2016 at 4:32 PM, Tom Lane > > wrote: > > CREATE POLICY takes AccessExclusiveLock on the table a policy is being > > added to -- good -- and then releases it when

Re: [HACKERS] row_security GUC does not behave as documented

Tom Lane wrote: > Stephen Frost writes: > > On Sunday, January 3, 2016, Tom Lane wrote: > >> The fine manual says that when row_security is set to off, "queries fail > >> which would otherwise apply at least one policy". However, a look at > >>

Re: [HACKERS] row_security GUC does not behave as documented

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > On Sunday, January 3, 2016, Tom Lane wrote: > >> The fine manual says that when row_security is set to off, "queries fail > >> which would otherwise apply at least one policy". However, a

[HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

I didn't see this discussed on the thread... regrole and regnamespace don't run their output through quote_ident(). That's contrary to all the other reg* operators. Worse, they also don't *allow* quoted input. Not only is that different from reg*, it's the *opposite*: select 'with

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

Jim Nasby writes: > regrole and regnamespace don't run their output through quote_ident(). > That's contrary to all the other reg* operators. > Worse, they also don't *allow* quoted input. Not only is that different > from reg*, it's the *opposite*: BTW, there's a

Re: [HACKERS] row_security GUC does not behave as documented

Alvaro Herrera writes: > Tom Lane wrote: >> Well, I tried changing the code to act the way I gather it should, and >> it breaks a whole bunch of regression test cases. See attached. > I think this means we need to postpone 9.5.0 for a week. I think the regression

Re: [HACKERS] pg_upgrade in 9.5 broken for adminpack

Bruce Momjian writes: > On Thu, Apr 16, 2015 at 11:29:07PM -0700, Jeff Janes wrote: >> Of course after sending that it became obvious.  The C function is not >> getting >> called because the SQL function is marked as being strict, yet is called with >> NULL arguments. >> >> Trivial patch

Re: [HACKERS] pg_upgrade in 9.5 broken for adminpack

Andreas Seltenreich writes: > Shouldn't there be some validation of arguments now that the function is > no longer marked strict? Currently, unprivileged users can crash the > server calling binary_upgrade_create_empty_extension with null > arguments. Found using sqlsmith.

Re: [HACKERS] Broken lock management in policy.c.

Tom, On Sunday, January 3, 2016, Tom Lane wrote: > CREATE POLICY takes AccessExclusiveLock on the table a policy is being > added to -- good -- and then releases it when done -- bad. Correct > behavior is to hold the lock till commit, because otherwise there is > no

Re: [HACKERS] Broken lock management in policy.c.

Tom, On Sunday, January 3, 2016, Tom Lane wrote: > Peter Geoghegan > writes: > > On Sun, Jan 3, 2016 at 4:32 PM, Tom Lane > wrote: > >> If we fix this, I believe we could also remove the weasel wording that >

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

Michael Paquier writes: > On Mon, Jan 4, 2016 at 11:16 AM, Tom Lane wrote: >> I'm inclined to think that you're right, and that this is something that >> ought to be changed. It's not quite too late ... > Well, I can send a patch with some tests

Re: [HACKERS] count_nulls(VARIADIC "any")

2016-01-03 21:37 GMT+01:00 Pavel Stehule : > Hi > > > 2015-08-12 19:18 GMT+02:00 Marko Tiikkaja : > >> Hi, >> >> I'd like to suggest $SUBJECT for inclusion in Postgres 9.6. I'm sure >> everyone would've found it useful at some point in their lives, and the

Re: [HACKERS] count_nulls(VARIADIC "any")

Hi 2015-08-12 19:18 GMT+02:00 Marko Tiikkaja : > Hi, > > I'd like to suggest $SUBJECT for inclusion in Postgres 9.6. I'm sure > everyone would've found it useful at some point in their lives, and the > fact that it can't be properly implemented in any language other than C I >

[HACKERS] Very confusing installcheck behavior with PGXS

The rule that gets executed if you do `make installcheck` with something using PGXS is pgxs.mk:$(pg_regress_installcheck) $(REGRESS_OPTS) $(REGRESS) where $(pg_regress_installcheck) is set in Makefile.global.in to pg_regress_installcheck = $(top_builddir)/src/test/regress/pg_regress

Re: [HACKERS] row_security GUC does not behave as documented

Tom, On Sunday, January 3, 2016, Tom Lane wrote: > The fine manual says that when row_security is set to off, "queries fail > which would otherwise apply at least one policy". However, a look at > check_enable_rls() says that that is a true statement only when the user > is

Re: [HACKERS] Broken lock management in policy.c.

Peter Geoghegan writes: > On Sun, Jan 3, 2016 at 4:32 PM, Tom Lane wrote: >> If we fix this, I believe we could also remove the weasel wording that was >> added to create_policy.sgml in commit 43cd468cf01007f3 about how the >> system might transiently fail to

Re: [HACKERS] Broken lock management in policy.c.

Stephen Frost writes: > On Sunday, January 3, 2016, Tom Lane wrote: >> CREATE POLICY takes AccessExclusiveLock on the table a policy is being >> added to -- good -- and then releases it when done -- bad. Correct >> behavior is to hold the lock till

Re: [HACKERS] Broken lock management in policy.c.

On Sun, Jan 3, 2016 at 5:18 PM, Tom Lane wrote: > Hmm. I agree that this test case's behavior does not depend on CREATE > POLICY's lock mismanagement. I think what is going on here is that the > RLS quals are being checked with an older snapshot than what controls > the

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

Jim Nasby writes: > regrole and regnamespace don't run their output through quote_ident(). > That's contrary to all the other reg* operators. > Worse, they also don't *allow* quoted input. Not only is that different > from reg*, it's the *opposite*: I'm inclined to

Re: [HACKERS] count_nulls(VARIADIC "any")

On 1/3/16 2:37 PM, Pavel Stehule wrote: + /* num_nulls(VARIADIC NULL) is defined as NULL */ + if (PG_ARGISNULL(0)) + return false; Could you add to the comment explaining why that's the desired behavior? + /* +*

Re: [HACKERS] Broken lock management in policy.c.

Peter, On Sunday, January 3, 2016, Peter Geoghegan wrote: > On Sun, Jan 3, 2016 at 5:18 PM, Tom Lane > > wrote: > > In any case, the text in create_policy.sgml seems to be a misleading > > description of the problem, as it's talking about DDL

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

Jim Nasby writes: > On 1/3/16 9:23 PM, Tom Lane wrote: >> I'm inclined to leave to_regrole and to_regnamespace alone, though, since >> they have no numeric-OID path, and they will provide an "out" for anyone >> who wants to handle nonquoted names. (Though at least in

Re: [HACKERS] Broken lock management in policy.c.

On Sun, Jan 3, 2016 at 7:01 PM, Peter Geoghegan wrote: > I would also advise only referencing a single relation within the > SELECT FOR UPDATE. To state what may be obvious: We should recommend that SELECT FOR SHARE appear in the CREATE POLICY USING qual as part of this

[HACKERS] Proposal for JSONB functions for internal representation casting insted text-casting

The usefulness of ->> operator is indisputable, but even with boolean or numeric values, with good binary internal representation, it returns JSONB value as text data type. The simple *(myJSONB->>'myField')::expectedType* is not enough because: 1) there are no internal optimization, need

[HACKERS] PGCon 2016 call for papers

In case you've overlooked it, you have about two weeks to submit your proposal. PGCon 2016 will be on 17-21 May 2016 at University of Ottawa. * 17-18 (Tue-Wed) tutorials * 19 & 20 (Thu-Fri) talks - the main part of the conference * 17 & 21 (Wed & Sat) The Developer Unconference & the User

[HACKERS] Broken lock management in policy.c.

CREATE POLICY takes AccessExclusiveLock on the table a policy is being added to -- good -- and then releases it when done -- bad. Correct behavior is to hold the lock till commit, because otherwise there is no guarantee that other backends will see the updated catalog rows in time, or indeed at

Re: [HACKERS] Broken lock management in policy.c.

On Sun, Jan 3, 2016 at 6:09 PM, Tom Lane wrote: >> Really? But the problem happens as a consequence of having a >> subqueries within CREATE POLICY's USING quals > > If that's what we're talking about, let's say it in precisely that many > words. With an example. The current

Re: [HACKERS] row_security GUC does not behave as documented

Stephen Frost writes: > On Sunday, January 3, 2016, Tom Lane wrote: >> The fine manual says that when row_security is set to off, "queries fail >> which would otherwise apply at least one policy". However, a look at >> check_enable_rls() says that that is

Re: [HACKERS] Broken lock management in policy.c.

On Sun, Jan 3, 2016 at 6:41 PM, Stephen Frost wrote: > A security defined function could be used to address that, of course. That > could have performance implications, naturally. True. I would also advise only referencing a single relation within the SELECT FOR UPDATE. --

Re: [HACKERS] Broken lock management in policy.c.

On Sun, Jan 3, 2016 at 4:32 PM, Tom Lane wrote: > CREATE POLICY takes AccessExclusiveLock on the table a policy is being > added to -- good -- and then releases it when done -- bad. Correct > behavior is to hold the lock till commit, because otherwise there is > no guarantee

Re: [HACKERS] Broken lock management in policy.c.

On Sun, Jan 3, 2016 at 6:04 PM, Tom Lane wrote: > I'm going to state it as an incontrovertible fact that that paragraph > is so vague as to be useless, because I sure misunderstood it, and in > fact just copy-edited it to talk about changes to RLS policies. I now > see that

Re: [HACKERS] Broken lock management in policy.c.

Peter Geoghegan writes: > On Sun, Jan 3, 2016 at 6:00 PM, Stephen Frost wrote: >> I believe Tom's complaint was that the overall page is about CREATE POLICY, >> technically, and that the text in attempting to address the concern might be >> taken under the

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

On 1/3/16 9:23 PM, Tom Lane wrote: Jim Nasby writes: regrole and regnamespace don't run their output through quote_ident(). That's contrary to all the other reg* operators. Worse, they also don't *allow* quoted input. Not only is that different from reg*, it's the

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

Jim Nasby writes: > What I went with. Now to figure out why this is happening... >SELECT regnamespace('pg_catalog'); > ! ERROR: schema "Y" does not exist > ! LINE 1: SELECT regnamespace('pg_catalog'); Confusion between a C string and a string Value node, mayhap?

Re: [HACKERS] Additional role attributes && superuser review

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Tue, Dec 29, 2015 at 11:55 PM, Stephen Frost wrote: > > I could go either way on that, really. I don't find namespace to be > > confusing when used in that way, but I'll change it since others do. > > It seems to me

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

On Mon, Jan 4, 2016 at 1:20 PM, Jim Nasby wrote: > On 1/3/16 9:43 PM, Tom Lane wrote: >> >> Jim Nasby writes: >>> >>> On 1/3/16 9:23 PM, Tom Lane wrote: >>> Another potential problem for regnamespace is that it doesn't allow an >>> entry for

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

On 1/3/16 10:20 PM, Jim Nasby wrote: What I went with. Now to figure out why this is happening... Nevermind, see my stupidity now. Should have full patch soon. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

On 1/3/16 11:05 PM, Michael Paquier wrote: I'll take a look, but Michael, if you have time to review, an extra set >of eyeballs wouldn't hurt. There is no margin for error right now. I'm just on it:) Will update in a couple of minutes, I noticed some stuff in Jim's patch. BTW, in case you

Re: [HACKERS] pgsql: Further tweaking of print_aligned_vertical().

On Fri, Jan 1, 2016 at 6:41 AM, Bruce Momjian wrote: > On Wed, Dec 2, 2015 at 01:16:09AM +, Greg Stark wrote: >> >> On 1 Dec 2015 19:48, "Tom Lane" wrote: >> > >> > In passing, avoid possible calculation of log10(0). Probably that's >> > harmless,

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

On Mon, Jan 4, 2016 at 4:49 AM, Robert Haas wrote: > > On Thu, Dec 31, 2015 at 3:36 AM, Amit Kapila wrote: > > LWLock *LWLockAssignFromTranche(const char *tranche_name) will > > assign a lock for the specified tranche. This also ensures that no >

Re: [HACKERS] pgsql: Further tweaking of print_aligned_vertical().

Michael Paquier writes: > On Fri, Jan 1, 2016 at 6:41 AM, Bruce Momjian wrote: >> Greg's lightning talk in Vienna about how he got the emulator working >> was priceless. I know he posted the VAX results, but how he got them >> was amazing. > +1. The

Re: [HACKERS] Keyword classifications

On Sat, Jan 2, 2016 at 4:06 AM, Tom Lane wrote: > I wrote: >> Now, one line of thought here is that flatten_reloptions() is out of its >> mind to not be worrying about quoting the reloption values. And perhaps >> it is, but I think if we go that direction, we may be fighting

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

On 1/3/16 10:46 PM, Jim Nasby wrote: Added. I'm gonna call this good for now. Note this is just against HEAD since I don't have 9.5 setup yet. Presumably the patch should still apply... BTW, in case it's helpful... https://github.com/decibel/postgres/tree/regquote -- Jim Nasby, Data

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

On 1/3/16 11:24 PM, Michael Paquier wrote: Sorry, didn't realize you were on it. No worries. I know it's already late where you are. And late where 9.5 is... ;) I would use != 1 instead here, even if the function is strict. Yeah, I effectively pulled the pattern from

Re: [HACKERS] pgsql: Further tweaking of print_aligned_vertical().

On Mon, Jan 4, 2016 at 3:22 PM, Tom Lane wrote: > Michael Paquier writes: >> On Fri, Jan 1, 2016 at 6:41 AM, Bruce Momjian wrote: >>> Greg's lightning talk in Vienna about how he got the emulator working >>> was priceless. I know

Re: [HACKERS] Additional role attributes && superuser review

On Thu, Dec 31, 2015 at 4:26 PM, Noah Misch wrote: > On Tue, Dec 29, 2015 at 08:35:50AM -0500, Stephen Frost wrote: >> * Noah Misch (n...@leadboat.com) wrote: >> I disagree that we would. Having a single >> set of default roles which provide a sensible breakdown of permissions

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

Jim Nasby writes: > On 1/3/16 9:23 PM, Tom Lane wrote: >> (Though at least in HEAD we ought to >> fix them to take type text as input. Using cstring for ordinary functions >> is just sloppy.) > BTW, *all* the reg*in() functions do that... Yeah, I noticed that.

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

On 1/3/16 10:26 PM, Michael Paquier wrote: Thanks, this is more or less what I... just did.. Sorry, didn't realize you were on it. +result = get_namespace_oid(nsp_name, false); This is incorrect, you should use strVal(linitial(names)) instead. Yup. Dur. +if (list_length(names) >

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

Michael Paquier writes: > Attached is an updated patch which passes > check-world in my environment. Pushed with trivial cosmetic changes to the code, and slightly more extensive work on the regression test cases. It strikes me that there might be an argument for

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

On Mon, Jan 4, 2016 at 3:09 PM, Tom Lane wrote: > Michael Paquier writes: >> Attached is an updated patch which passes >> check-world in my environment. > > Pushed with trivial cosmetic changes to the code, and slightly more > extensive work on the

Re: [HACKERS] Improved tab completion for FDW DDL

On Wed, Dec 30, 2015 at 9:21 PM, Andreas Karlsson wrote: > Hi, > > Here is a patch which adds the below missing tab completions for the FDW DDL > commands. I noticed these were missing while playing around with FDWs a > while ago. > > "ALTER SERVER " with "RENAME TO" > "CREATE

Re: [HACKERS] Remove Windows crash dump support?

On Fri, Dec 25, 2015 at 8:57 PM, Craig Ringer wrote: > On 25 December 2015 at 19:45, Michael Paquier > wrote: >> >> On Thu, Dec 24, 2015 at 5:57 PM, Dave Page wrote: >> > On Thu, Dec 24, 2015 at 2:14 AM, Craig Ringer

Re: [HACKERS] row_security GUC does not behave as documented

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > As we don't want to end up with the same behavior-change-due-to-GUC that > > we had with the original row_security implementation, we should change > > the code as your patch does and update the regression

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

On 1/3/16 9:43 PM, Tom Lane wrote: Jim Nasby writes: On 1/3/16 9:23 PM, Tom Lane wrote: Another potential problem for regnamespace is that it doesn't allow an entry for the catalog. I'm not sure what the spec says about that, but every other function allows

Re: [HACKERS] count_nulls(VARIADIC "any")

Hi 2016-01-03 22:49 GMT+01:00 Jim Nasby : > On 1/3/16 2:37 PM, Pavel Stehule wrote: > >> + /* num_nulls(VARIADIC NULL) is defined as NULL */ >> + if (PG_ARGISNULL(0)) >> + return false; >> > > Could you add to the

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

On Mon, Jan 4, 2016 at 2:01 PM, Tom Lane wrote: > Jim Nasby writes: >> On 1/3/16 10:26 PM, Michael Paquier wrote: >>> Thanks, this is more or less what I... just did.. > >> Sorry, didn't realize you were on it. > >>> A couple of tests in regproc.sql

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

On Mon, Jan 4, 2016 at 1:46 PM, Jim Nasby wrote: > On 1/3/16 10:26 PM, Michael Paquier wrote: >> >> Thanks, this is more or less what I... just did.. > > > Sorry, didn't realize you were on it. No worries. I know it's already late where you are. >> A couple of tests in

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

On 1/3/16 9:23 PM, Tom Lane wrote: (Though at least in HEAD we ought to fix them to take type text as input. Using cstring for ordinary functions is just sloppy.) BTW, *all* the reg*in() functions do that... -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics,

Re: [HACKERS] count_nulls(VARIADIC "any")

On 1/3/16 10:23 PM, Pavel Stehule wrote: Hi 2016-01-03 22:49 GMT+01:00 Jim Nasby >: On 1/3/16 2:37 PM, Pavel Stehule wrote: + /* num_nulls(VARIADIC NULL) is defined as NULL */ + if

Re: [HACKERS] row_security GUC does not behave as documented

Stephen Frost writes: > As we don't want to end up with the same behavior-change-due-to-GUC that > we had with the original row_security implementation, we should change > the code as your patch does and update the regression tests accordingly. I think probably the tests need

Re: [HACKERS] 9.5 BLOCKER: regrole and regnamespace and quotes

Jim Nasby writes: > On 1/3/16 10:26 PM, Michael Paquier wrote: >> Thanks, this is more or less what I... just did.. > Sorry, didn't realize you were on it. >> A couple of tests in regproc.sql would be a good addition as well. > Added. I'm gonna call this good for now.

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

On Sun, Jan 3, 2016 at 10:26 PM, Masahiko Sawada wrote: > On Fri, Dec 25, 2015 at 7:21 AM, Thomas Munro > wrote: >> On Fri, Dec 25, 2015 at 8:50 AM, Masahiko Sawada >> wrote: >>> On Wed, Dec 23, 2015 at 8:45 AM,

[HACKERS] commitfest html - wrong closing tag

Hi, I noticed (trying to parse out the "Latest patch" urls) that in the html of the commitfest pages, for instance in: https://commitfest.postgresql.org/8/ all rows of the html-table (I think it is the "Committer"-column) contain an erroneous ''. It should be ''. See example below, the

Re: [HACKERS] commitfest html - wrong closing tag

On Sun, Jan 3, 2016 at 9:26 AM, Erik Rijkers wrote: > Hi, > > I noticed (trying to parse out the "Latest patch" urls) that > in the html of the commitfest pages, for instance in: > >https://commitfest.postgresql.org/8/ > > all rows of the html-table (I think it is the

[HACKERS] \x auto and EXPLAIN

Hi, psql's "\x auto" is a nice feature, but it is made much less useful in my opinion due to the expanded output format making query plans unreadable (and query plans often end up using expanded display due to their width). I think we should never use the expanded format for EXPLAIN output

Re: [HACKERS] commitfest html - wrong closing tag

On 2016-01-03 10:06, Magnus Hagander wrote: On Sun, Jan 3, 2016 at 9:26 AM, Erik Rijkers wrote: an erroneous ''. It should be ''. Is there a particular thing you're trying to parse the data out for? As in is there some data that we should already be providing in a

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2016-01-03 10:03:41 +0530, Amit Kapila wrote: > On Sun, Jan 3, 2016 at 3:01 AM, Andres Freund wrote: > > Indeed it does use shutdown(). If I read the npgsql code that'll even be > > done in the exception handling path. So fixing the 0 byte case might > > already do the

Re: [HACKERS] Avoiding pin scan during btree vacuum

On 21 December 2015 at 21:28, Alvaro Herrera wrote: > Simon Riggs wrote: > > During VACUUM of btrees, we need to pin all pages, even those where > tuples > > are not removed, which I am calling here the "pin scan". This is > especially > > a problem during redo, where

Re: [HACKERS] Avoiding pin scan during btree vacuum

On 21 December 2015 at 21:36, Tom Lane wrote: > Alvaro Herrera writes: > > I think the new comment that talks about Toast Index should explain > > *why* we can skip the pinning in all cases except that one, instead of > > just saying we can do it. >

Re: [HACKERS] dynloader.h missing in prebuilt package for Windows?

On Dec 31, 2015, at 1:04 PM, Bruce Momjian wrote: >> On Thu, Dec 31, 2015 at 12:50:13AM -0500, Bruce Momjian wrote: >>> On Wed, Dec 30, 2015 at 11:57:45PM -0500, Tom Lane wrote: >>> Bruce Momjian writes: Oops. Once this patch is applied, it is only going

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

On Fri, Dec 25, 2015 at 7:21 AM, Thomas Munro wrote: > On Fri, Dec 25, 2015 at 8:50 AM, Masahiko Sawada > wrote: >> On Wed, Dec 23, 2015 at 8:45 AM, Thomas Munro >> wrote: >>> On Wed, Dec 23, 2015 at 3:50 PM,

Re: [HACKERS] rows estimate in explain analyze for the BRIN index

> But is it? Is it impossible for the BRIN bitmap index scan to return 0 rows > (say, if the value being matched is outside the min/max boundary for every > block range?) Granted, if we document that it always returns 0 and should be > ignored, then confusing the actual 0 with the 0 as a

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Andres Freund writes: > On January 3, 2016 6:23:20 PM GMT+01:00, Tom Lane wrote: >> Agreed. Let's do it and ship this puppy. > Unless somebody beats me to it, I'll push in the European morning. Um. For something that at least potentially has

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On January 3, 2016 7:04:29 PM GMT+01:00, Tom Lane wrote: >Andres Freund writes: >> On January 3, 2016 6:23:20 PM GMT+01:00, Tom Lane >wrote: >>> Agreed. Let's do it and ship this puppy. > >> Unless somebody beats me to it, I'll push

[HACKERS] Re: pglogical_output - a general purpose logical decoding output plugin

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: not tested Spec compliant: not tested Documentation:tested, failed Applies cleanly on current master

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Andres Freund writes: > On January 3, 2016 7:04:29 PM GMT+01:00, Tom Lane wrote: >> Um. For something that at least potentially has portability issues >> (we think not, but we could be wrong), it's pretty scary to push only >> a couple of hours before the

Re: [HACKERS] dynloader.h missing in prebuilt package for Windows?

Robert Haas writes: > On Dec 31, 2015, at 1:04 PM, Bruce Momjian wrote: >> Let's hold this for 9.5.1 and all minor releases will get it at the same >> time. > I vote for going ahead with this at once. It seems low risk, and having 9.5.1 > install

Re: [HACKERS] \x auto and EXPLAIN

Andreas Karlsson writes: > psql's "\x auto" is a nice feature, but it is made much less useful in > my opinion due to the expanded output format making query plans > unreadable (and query plans often end up using expanded display due to > their width). I think we should

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On January 3, 2016 6:23:20 PM GMT+01:00, Tom Lane wrote: >> I really think we have a host of buggy code around the event handling >- >> but most of it has been used for a long while. So I think fixing the >0 >> byte case for 9.5 is good enough. > >Agreed. Let's do it and

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Andres Freund writes: > On 2016-01-03 10:03:41 +0530, Amit Kapila wrote: >> I think this true for a TCP socket, but this code-path is used for UDP >> (SOCK_DGRAM) sockets as well and there is a comment below in >> that function which seems to be indicating why originally 0