Re: [HACKERS] WALWriteLock contention

On Mon, May 18, 2015 at 1:53 AM, Robert Haas wrote: > > On May 17, 2015, at 11:04 AM, Amit Kapila wrote: > > On Sun, May 17, 2015 at 7:45 AM, Robert Haas wrote: > > > > I wonder if we could write WAL to two different files in > > alternation, so that we could be writing to one file which fsync-i

Re: [HACKERS] a few thoughts on the schedule

On 2015-05-18 23:34:16 -0400, Robert Haas wrote: > On May 18, 2015, at 10:41 PM, Andres Freund wrote: > > [first 9.6 CF around 2015-07-15] > Honestly, that seems awful soon. I would have thought maybe August 15th. Maybe we should just rename it to 9.6-1 for now? And then look how things look a

Re: [HACKERS] a few thoughts on the schedule

On 2015-05-18 23:30:20 -0400, Tom Lane wrote: > Michael Paquier writes: > > On Tue, May 19, 2015 at 11:41 AM, Andres Freund wrote: > >> On 2015-05-19 11:34:49 +0900, Michael Paquier wrote: > >>> There are many remaining open items. > > >> At least on https://wiki.postgresql.org/wiki/PostgreSQL_9

Re: [HACKERS] collations in shared catalogs?

Andres Freund writes: > On 2015-05-18 23:22:33 -0400, Tom Lane wrote: >> I'm inclined to think I should revert b82a7be603f1811a and instead make >> the seclabel provider columns use text_pattern_ops. That would fix >> their collation problem with less of a backwards compatibility hazard. > Sound

Re: [HACKERS] a few thoughts on the schedule

On May 18, 2015, at 10:41 PM, Andres Freund wrote: >> On 2015-05-19 11:34:49 +0900, Michael Paquier wrote: >> +1 for moving it at least 1 month. > > 2015-06-15 also collides with pgcon, which probably isn't the best > idea. I do think we should try hard doing a triage at the start of a CF > and n

Re: [HACKERS] collations in shared catalogs?

On 2015-05-18 23:22:33 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2015-05-18 19:59:29 -0400, Tom Lane wrote: > >> I think that's fragile as can be. > > > Hm. I think actually just forcing a collation would bring this on-par > > with name, right? We don't have any guarantees about the co

Re: [HACKERS] a few thoughts on the schedule

Michael Paquier writes: > On Tue, May 19, 2015 at 11:41 AM, Andres Freund wrote: >> On 2015-05-19 11:34:49 +0900, Michael Paquier wrote: >>> There are many remaining open items. >> At least on https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items >> there not really that many? > On top of

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/18/2015 04:54 PM, David G. Johnston wrote: On Mon, May 18, 2015 at 12:12 PM, Josh Berkus >wrote: On 05/18/2015 11:58 AM, Peter Geoghegan wrote: > As you say, hstore isn't nested, and so this simply doesn't come up > there. We have failed to adopt "||"

Re: [HACKERS] collations in shared catalogs?

Andres Freund writes: > On 2015-05-18 19:59:29 -0400, Tom Lane wrote: >> I think that's fragile as can be. > Hm. I think actually just forcing a collation would bring this on-par > with name, right? We don't have any guarantees about the contents of > e.g. pg_database.datname being meaningful in

Re: [HACKERS] a few thoughts on the schedule

On Tue, May 19, 2015 at 11:41 AM, Andres Freund wrote: > On 2015-05-19 11:34:49 +0900, Michael Paquier wrote: >> +1 for moving it at least 1 month. > > 2015-06-15 also collides with pgcon, which probably isn't the best > idea. I do think we should try hard doing a triage at the start of a CF > and

Re: [HACKERS] Bug in jsonb minus operator

On Mon, May 18, 2015 at 7:11 AM, Andrew Dunstan wrote: > Here's an patch along those lines. It seems to do the trick, at least for > your test case, and it has the merit of being very small, so small I'd like > to backpatch it - accepting jbvBinary as is in pushJsonbValue seems like a > bug to me.

Re: [HACKERS] a few thoughts on the schedule

On 2015-05-19 11:34:49 +0900, Michael Paquier wrote: > +1 for moving it at least 1 month. 2015-06-15 also collides with pgcon, which probably isn't the best idea. I do think we should try hard doing a triage at the start of a CF and not many with experience in the project are going to have time ar

Re: [HACKERS] a few thoughts on the schedule

On 05/18/2015 07:21 PM, Peter Geoghegan wrote: On Mon, May 18, 2015 at 7:10 PM, Andres Freund wrote: So +1 to moving it. +1 I for one would love to see a nice and solid focus on what we have now for a little while versus diverting resources yet again to new development. +1 -- Command

Re: [HACKERS] a few thoughts on the schedule

On Tue, May 19, 2015 at 11:10 AM, Andres Freund wrote: > On 2015-05-18 22:05:47 -0400, Noah Misch wrote: >> +1 for not starting a CommitFest on 2015-06-15. If we're going to take 9.5 >> from feature freeze to general availability in four months, we won't get >> there >> by diving into 9.6 develo

Re: [HACKERS] a few thoughts on the schedule

On Mon, May 18, 2015 at 7:10 PM, Andres Freund wrote: > So +1 to moving it. +1 -- Peter Geoghegan -- 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] a few thoughts on the schedule

On 2015-05-18 22:05:47 -0400, Noah Misch wrote: > +1 for not starting a CommitFest on 2015-06-15. If we're going to take 9.5 > from feature freeze to general availability in four months, we won't get there > by diving into 9.6 development in the first of those months. We could rechristen it a 're

Re: [HACKERS] Minor ON CONFLICT related fixes

On Mon, May 18, 2015 at 2:09 PM, Peter Geoghegan wrote: > You pointed out that the reason for this trivial bug on Jabber, but > here's the obvious fix, including an EXPLAIN regression test. Also, I attach a patch adding ruleutils.c deparsing support for INSERT statement target aliases. This was p

Re: [HACKERS] a few thoughts on the schedule

On Wed, May 13, 2015 at 10:32:03AM -0400, Robert Haas wrote: > We also need to start thinking about what happens after feature > freeze. The CommitFest application currently lists a 2015-06 > CommitFest which, according to previous practice, would be expected to > start on the 15th of the month.

Re: [HACKERS] collations in shared catalogs?

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > It's maybe not absolutely strictly necessary. In fact in earlier > versions of the patch it was name. But replication solutions like bdr, > slony, whatever will have to store a bunch of values identifying a node > in there. And that's much eas

Re: [HACKERS] collations in shared catalogs?

* Andres Freund (and...@anarazel.de) wrote: > On 2015-05-18 21:20:29 -0400, Stephen Frost wrote: > > * Andres Freund (and...@anarazel.de) wrote: > > > I'm right now toying with the idea of defining 'varname' as a text > > > equivalent that always has a C type collation, and no length > > > limitati

Re: [HACKERS] collations in shared catalogs?

On 2015-05-18 21:20:29 -0400, Stephen Frost wrote: > * Andres Freund (and...@anarazel.de) wrote: > > I'm right now toying with the idea of defining 'varname' as a text > > equivalent that always has a C type collation, and no length > > limitation. That'd generally imo be a good thing to have. A bu

Re: [HACKERS] collations in shared catalogs?

* Andres Freund (and...@anarazel.de) wrote: > On 2015-05-18 19:59:29 -0400, Tom Lane wrote: > > Andres Freund writes: > > > Hm, just forcing a collation and restricting the input to ascii should > > > work, right? > > > > I think that's fragile as can be. > > Hm. I think actually just forcing a

Re: [HACKERS] collations in shared catalogs?

On 2015-05-18 19:59:29 -0400, Tom Lane wrote: > Andres Freund writes: > > Hm, just forcing a collation and restricting the input to ascii should > > work, right? > > I think that's fragile as can be. Hm. I think actually just forcing a collation would bring this on-par with name, right? We don't

Re: [HACKERS] collations in shared catalogs?

On 2015-05-18 20:19:29 -0400, Tom Lane wrote: > Many people rely on UUIDs being impervious to chance collisions, so > it's not clear to me why uniqueness within 63 characters is unachievable. > Even more, if you can't do it in 63, what makes you think that 100 is > better? Well UUIDs are also hard

Re: [HACKERS] collations in shared catalogs?

Andres Freund writes: > On 2015-05-18 19:59:29 -0400, Tom Lane wrote: >> I think that's fragile as can be. Is there a *really really* good >> argument why these things shouldn't be subject to identifier length >> restrictions? > It's maybe not absolutely strictly necessary. In fact in earlier >

Re: [HACKERS] collations in shared catalogs?

On 2015-05-18 19:59:29 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2015-05-18 19:23:59 -0400, Tom Lane wrote: > > Hm, just forcing a collation and restricting the input to ascii should > > work, right? > > I think that's fragile as can be. Is there a *really really* good > argument why

Re: [HACKERS] Run pgindent now?

On 05/18/2015 07:04 PM, Bruce Momjian wrote: On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote: Robert Haas writes: On Mon, May 18, 2015 at 12:10 PM, Bruce Momjian wrote: There was talk last time of pgindent-ing head and all back branches, because a patch applied to head and back bra

Re: [HACKERS] collations in shared catalogs?

Andres Freund writes: > On 2015-05-18 19:23:59 -0400, Tom Lane wrote: >> Is it okay to change pg_replication_origin.roname to type "name", >> and if not what do you want to do instead? > It was turned into text after it initially was name, because of length > concerns. > Hm, just forcing a colla

Re: [HACKERS] Disabling trust/ident authentication configure option

On May 18, 2015, at 3:32 PM, Volker Aßmann wrote: > I know these measures won't protect against an experienced attacker who gains > root access, but hope it slows them down sufficiently so the admins may have > a chance to detect the attack. It won't. ...Robert -- Sent via pgsql-hackers mail

Re: [HACKERS] collations in shared catalogs?

On 2015-05-18 19:23:59 -0400, Tom Lane wrote: > OK, now I'm on the warpath, because I went to fix this and discovered > that since that discussion, somebody named Freund committed yet another > shared catalog with a collation-dependent index. This time, at least, > we can fix it *before* it gets i

Re: [HACKERS] collations in shared catalogs?

Andres Freund writes: > On 2015-02-25 12:08:32 -0500, Tom Lane wrote: >> Andrew Gierth writes: >>> So while helping someone with an unrelated issue, I did a quick query to >>> look for collation-dependent indexes, and was rather shocked to find >>> that not only are there two such in the system c

Re: [HACKERS] Run pgindent now?

On Mon, May 18, 2015 at 07:10:00PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote: > >> (BTW, one practical issue is where would we get typedef lists relevant > >> to the back branches. I'm not sure if the buildfarm infrastructure is >

Re: [HACKERS] Run pgindent now?

Bruce Momjian writes: > On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote: >> (BTW, one practical issue is where would we get typedef lists relevant >> to the back branches. I'm not sure if the buildfarm infrastructure is >> capable of collecting branch-specific data, or if we'd need to ra

Re: [HACKERS] PATCH: use foreign keys to improve join estimates v1

Hi David, On 05/17/15 14:31, David Rowley wrote: Hi Tomas, I did glance at this patch a while back, but just thinking on it again. I think if you find any quals that are a part of *any* foreign key between the 2 join tables, then you should be never assume these quals to reduce the number of r

Re: [HACKERS] Run pgindent now?

On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote: > Robert Haas writes: > > On Mon, May 18, 2015 at 12:10 PM, Bruce Momjian wrote: > >> There was talk last time of pgindent-ing head and all back branches, > >> because a patch applied to head and back branches was historically only > >> pg

Re: [HACKERS] Run pgindent now?

Robert Haas writes: > On Mon, May 18, 2015 at 12:10 PM, Bruce Momjian wrote: >> There was talk last time of pgindent-ing head and all back branches, >> because a patch applied to head and back branches was historically only >> pgindented in head, meaning that any future patches in that area could

Re: [HACKERS] 9.5 open items

> Just so we're all in the same page, there are some further open items > (both addressed and not yet addressed) in the usual Wiki page, > https://wiki.postgresql.org/wiki/Open_Items > I added the problem around foreign/custom-join still not resolved. Thanks, -- NEC Business Creation Division / PG

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On Mon, May 18, 2015 at 3:31 PM, Bruno Harbulot wrote: > On Sun, May 17, 2015 at 5:15 PM, Greg Sabino Mullane > wrote: > > >> >> > In that case my vote is new operators. This has been a sore point for >> the >> > JDBC driver >> >> Um, no, new operators is a bad idea. Question marks are used by h

Re: [HACKERS] Run pgindent now?

On Mon, May 18, 2015 at 12:10 PM, Bruce Momjian wrote: > On Sat, May 16, 2015 at 01:05:27PM -0400, Tom Lane wrote: >> Magnus Hagander writes: >> > On Sat, May 16, 2015 at 5:58 PM, Tom Lane wrote: >> >> With feature freeze behind us, I'd like to propose that now is a good >> >> time for a pginden

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On Sun, May 17, 2015 at 5:15 PM, Greg Sabino Mullane wrote: > > > In that case my vote is new operators. This has been a sore point for the > > JDBC driver > > Um, no, new operators is a bad idea. Question marks are used by hstore, > json, geometry, and who knows what else. I think the onus is s

Re: [HACKERS] 9.5 open items

On Mon, May 18, 2015 at 05:52:22PM -0300, Alvaro Herrera wrote: > Bruce Momjian wrote: > > I have processed all the open email items I can through mid-March, > > though I do have two pg_upgrade fixes pending application today. I will > > continue processing doc fixes and major bug fixes for 9.5, b

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

Hello! [3] First of all few words about concatenation of jsonb values in my mind. Jsonb values concatenation result may follow this rules: 1) array of both values if both are scalars 2) concatenated array if both are arrays 3) prepended or appended array if only one is array 4) recursive concatena

Re: [HACKERS] Minor ON CONFLICT related fixes

On Sat, May 16, 2015 at 11:48 PM, Peter Geoghegan wrote: > FYI, I found an unrelated bug within ruleutils.c (looks like the > targetlist kludge in set_deparse_planstate() isn't sufficiently > general): > > postgres=# explain insert into upsert as u values('Bat', 'Bar') on > conflict (key) do updat

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 12:12 PM, Josh Berkus wrote: > On 05/18/2015 11:58 AM, Peter Geoghegan wrote: > > As you say, hstore isn't nested, and so this simply doesn't come up > > there. We have failed to adopt "||" to jsonb in a way that makes > > sense. We should have adopted it to jsonb in exact

Re: [HACKERS] Minor ON CONFLICT related fixes

On Mon, May 18, 2015 at 1:49 PM, Peter Geoghegan wrote: > Here is a cumulative version of what was previously posted. BTW, this could result in more calls to get_opclass_family() and get_opclass_input_type() than before. However, because we'll have eliminated so many candidates (e.g. by seeing th

Re: [HACKERS] 9.5 open items

Bruce Momjian wrote: > I have processed all the open email items I can through mid-March, > though I do have two pg_upgrade fixes pending application today. I will > continue processing doc fixes and major bug fixes for 9.5, but > everything else I do will be for 9.6. Thanks, Bruce. Just so we'r

Re: [HACKERS] Minor ON CONFLICT related fixes

On Tue, May 12, 2015 at 3:16 PM, Andres Freund wrote: > Could you rebase and adjust your patch? I'd rather have the inference > structure refactoring separate. I realized that I didn't split out the patch as requested. Here is a cumulative version of what was previously posted. Thanks -- Peter

Re: [HACKERS] ERROR: cannot GetMultiXactIdMembers() during recovery

Simon Riggs wrote: > On 15 May 2015 at 19:03, Alvaro Herrera wrote: > > > Andres Freund wrote: > > > > > Alternatively we could make MultiXactIdIsRunning() return false < 9.3 > > > when in recovery. I think that'd end up fixing things, but it seems > > > awfully fragile to me. > > > > Hm, why fra

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 1:19 PM, Catalin Iacob wrote: > In hstore @> means unnested containment, in jsonb it means nested > containment. Therefore, when an hstore operator is applied to jsonb it gets > "nestedness" as jsonb is nested and adds that nestedness is an important > thing that sets it ap

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 9:03 PM Andrew Dunstan wrote: > So you're arguing that we shouldn't call the operation in question || > because it's pretty much the same, mutatis mutandis, as the hstore > operation of the same name. You've lost me. > Hopefully this helps. Peter's argument, as I understa

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 1:03 PM, Robert Haas wrote: > Realistically, as much as we might try to fool ourselves into > believing otherwise, operators are not self-documenting, except for > the ones you knew by the fourth grade. People will have to read the > documentation no matter what we do here

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 2015-05-18 22:10, Josh Berkus wrote: On 05/18/2015 01:04 PM, Ryan Pedela wrote: In the context of splitting shallow and deep merge into two operators, I think + is better for shallow and || better for deep. The reason for + is because many programming languages have this behavior. If I see th

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/18/2015 01:04 PM, Ryan Pedela wrote: > Let me back up a little. I always like to think about what is the ideal > interface first and then worry about implementation because > implementation can always be changed but interface can't. I think the > current concat/merge interface is the ideal. I

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 12:24 PM, Josh Berkus wrote: > > On 05/18/2015 08:57 AM, Ryan Pedela wrote: > > If not, deep concatenation would solve this problem, but I can also see > > another solution. Use + for shallow concatenation since it really means > > "add element to top-level path" as Peter s

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 3:21 PM, Peter Geoghegan wrote: > What is hard to understand about that? What is hard to understand is why you're going on and on about what is basically a matter of opinion after several people have said they don't agree with your opinion. Realistically, as much as we mi

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/18/2015 03:21 PM, Peter Geoghegan wrote: The only question worth discussing is whether we change the operator to "+" (or, for that matter, something else). I've seen your vote on this, so, does anyone else have an opinion on "+" vs. "||"? Preferably with a justification with some kind

Re: [HACKERS] Disabling trust/ident authentication configure option

On Mon, May 18, 2015 at 05:00:41PM -0300, Alvaro Herrera wrote: > Bruce Momjian wrote: > > On Mon, May 18, 2015 at 09:32:23PM +0200, Volker Aßmann wrote: > > > > But I like the more general approach proposed by Alvaro, so in case this > > > patch > > > would have a chance to not be immediately re

Re: [HACKERS] Disabling trust/ident authentication configure option

Bruce Momjian wrote: > On Mon, May 18, 2015 at 09:32:23PM +0200, Volker Aßmann wrote: > > But I like the more general approach proposed by Alvaro, so in case this > > patch > > would have a chance to not be immediately rejected, I would try to implement > > the more generic approach. I would also

Re: [HACKERS] Disabling trust/ident authentication configure option

On Mon, May 18, 2015 at 09:32:23PM +0200, Volker Aßmann wrote: > That's what we are currently doing with the patch Bernd posted at the > beginning > of this thread. But we thought we might post the patch for consideration here > as the use case might be sufficiently general that it may be of use t

Re: [HACKERS] upper planner path-ification

On Mon, May 18, 2015 at 2:50 PM, Tom Lane wrote: >> I don't know, but it seems like this might be pulling in the opposite >> direction from your previously-stated desire to get subquery_planner >> to output Paths rather than Plans as soon as possible. > > Sorry, I didn't mean to suggest that that

Re: [HACKERS] upper planner path-ification

Simon Riggs writes: > On 18 May 2015 at 14:50, Tom Lane wrote: >> So for the moment, let's assume that we still rigidly follow the sequence >> of upper-level steps currently embodied in grouping_planner. (I'm not >> sure if it even makes sense to consider other orderings of those >> processing s

Re: [HACKERS] Disabling trust/ident authentication configure option

On Mon, May 18, 2015 at 5:58 AM, Josh Berkus wrote: > Let's say we offered a compile-time option, and then someone built a > package postgresql-9.6-secureauth.deb. So, your lazy admin is having > trouble debugging an auth problem and wants to set "trust". But they > can't. So they search on G

Re: [HACKERS] Disabling trust/ident authentication configure option

On 05/18/2015 08:36 AM, Jim Nasby wrote: > On 5/17/15 10:58 PM, Josh Berkus wrote: >> The goal here was stated to preventing authentication misconfiguration >> by shortsighted admins who have superuser access and the ability to >> change pg_hba.conf. This is tantamount to giving someone a gun and

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 12:12 PM, Josh Berkus wrote: > OK, you've flagellated this deceased equine enough that I'm calling the > ASPCA. I get that you're unhappy that we don't have deep append. > Everyone gets this. I simply don't care; shallow append is better than > no append at all, and havin

Re: [HACKERS] upper planner path-ification

On 18 May 2015 at 14:50, Tom Lane wrote: > Robert Haas writes: > > On Sun, May 17, 2015 at 12:11 PM, Tom Lane wrote: > >> Rather than adding tlists per se to Paths, I've been vaguely toying with > >> a notion of identifying all the "interesting" subexpressions in a query > >> (expensive functio

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/18/2015 11:58 AM, Peter Geoghegan wrote: > As you say, hstore isn't nested, and so this simply doesn't come up > there. We have failed to adopt "||" to jsonb in a way that makes > sense. We should have adopted it to jsonb in exactly the same way as > the "@>" operator was. OK, you've flagell

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 11:45 AM, Josh Berkus wrote: > On 05/18/2015 11:34 AM, Peter Geoghegan wrote: >> I'm not necessarily attached to "+". I just want to make this >> different to hstore's "||" operator. There should be a similar idiom >> with jsonb, but that can come later. > > This argument s

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/18/2015 02:45 PM, Josh Berkus wrote: On 05/18/2015 11:34 AM, Peter Geoghegan wrote: I'm not necessarily attached to "+". I just want to make this different to hstore's "||" operator. There should be a similar idiom with jsonb, but that can come later. This argument still makes no sense t

Re: [HACKERS] upper planner path-ification

Robert Haas writes: > On Sun, May 17, 2015 at 12:11 PM, Tom Lane wrote: >> Rather than adding tlists per se to Paths, I've been vaguely toying with >> a notion of identifying all the "interesting" subexpressions in a query >> (expensive functions, aggregates, etc), giving them indexes 1..n, and t

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/18/2015 11:34 AM, Peter Geoghegan wrote: > I'm not necessarily attached to "+". I just want to make this > different to hstore's "||" operator. There should be a similar idiom > with jsonb, but that can come later. This argument still makes no sense to me. Hstore is not nested. If anything,

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 11:24 AM, Josh Berkus wrote: > On 05/17/2015 09:11 PM, Peter Geoghegan wrote:> As I said, I don't think > that my preference for deep concatenation is >> a matter of taste. I think that shallow concatenation is fundamentally >> and objectively at odds with what jsonb is sup

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 11:16 AM, Andrew Dunstan wrote: > I could argue at least as convincingly that what the jsonb || operator does > is exactly analogous to what hstore's || does. Again, my concern is not primarily a theoretical one. It's primarily a practical concern. We are no closer to supp

Re: [HACKERS] upper planner path-ification

On Sun, May 17, 2015 at 12:11 PM, Tom Lane wrote: > Rather than adding tlists per se to Paths, I've been vaguely toying with > a notion of identifying all the "interesting" subexpressions in a query > (expensive functions, aggregates, etc), giving them indexes 1..n, and then > marking Paths with b

Re: [HACKERS] Disabling trust/ident authentication configure option

On 05/17/2015 08:58 PM, Josh Berkus wrote: > You've added exactly one additional step in their way, and not a > particularly difficult one. It simply doesn't solve the problem you're > trying to solve, which is unsurprising, because technology has never > been able to solve the problem of untrustw

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/17/2015 09:11 PM, Peter Geoghegan wrote:> As I said, I don't think that my preference for deep concatenation is > a matter of taste. I think that shallow concatenation is fundamentally > and objectively at odds with what jsonb is supposed to be (as long as > concatenation is the way "nested a

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/18/2015 01:43 PM, Peter Geoghegan wrote: On Mon, May 18, 2015 at 10:29 AM, Andrew Dunstan wrote: Having trouble scanning this. Since hstore isn't nested what the heck does "nested assignment" mean w.r.t. hstore? It means assigning to one "subdatum" in the hstore datum, as opposed to sim

Re: [HACKERS] WALWriteLock contention

> > > > > My goal there was to further improve group commit. When running pgbench > > -j10 -c10, it was common to see fsyncs that alternated between flushing 1 > > transaction, and 9 transactions. Because the first one to the gate would > go > > through it and slam it on all the others, and it wou

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 10:29 AM, Andrew Dunstan wrote: > Having trouble scanning this. Since hstore isn't nested what the heck does > "nested assignment" mean w.r.t. hstore? It means assigning to one "subdatum" in the hstore datum, as opposed to simply assigning an entirely new hstore (granted,

Re: [HACKERS] How does MSVC's fetchRegressOpts() work at all?

On 05/18/2015 01:37 PM, Tom Lane wrote: I wrote: If I were to fix fetchRegressOpts so it picks up all the makefile's additions to REGRESS_OPTS, would we be able to eliminate that hack? Or do we need the python-version kluge anyway? Oh, scratch that, there's no very easy way to deal with the if

Re: [HACKERS] Making the regression tests halt to attach a debugger

On Mon, May 18, 2015 at 6:44 AM, Tom Lane wrote: > Peter Geoghegan writes: >> I came up with a simple approach to conveniently attaching a debugger >> when a bug manifested itself from within the regression tests, by >> patching Postgres. This worked quite well. The backend would look for >> the

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/18/2015 01:18 PM, Peter Geoghegan wrote: So I think we should use the + operator to distance this from the hstore concatenate operator, which *is* widely understood to be mostly useful for "nested assignment". Having trouble scanning this. Since hstore isn't nested what the heck does

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 5:05 AM, Andrew Dunstan wrote: > As between || and + I'm personally moderately indifferent. I think you're > representing some body of understanding about the effects of certain > operators as being widespread when that's very far from clear. > > You really still haven't sa

Re: [HACKERS] How does MSVC's fetchRegressOpts() work at all?

I wrote: > If I were to fix fetchRegressOpts so it picks up all the makefile's > additions to REGRESS_OPTS, would we be able to eliminate that hack? > Or do we need the python-version kluge anyway? Oh, scratch that, there's no very easy way to deal with the ifeq() business in the makefile. So I'l

Re: [HACKERS] ERROR: cannot GetMultiXactIdMembers() during recovery

Andres Freund wrote: > On 2015-05-18 14:13:51 -0300, Alvaro Herrera wrote: > > Hmm, AFAICS the problematic check was introduced by this commit: > > > > commit 9f1e051adefb2f29e757cf426b03db20d3f8a26d > > Author: Alvaro Herrera > > Date: Fri Nov 29 11:26:41 2013 -0300 > > > > so it isn't hot of

Re: [HACKERS] ERROR: cannot GetMultiXactIdMembers() during recovery

On 18 May 2015 at 12:59, Tom Lane wrote: > Alvaro Herrera writes: > > Marko Tiikkaja wrote: > >> Any chance to get this fixed in time for 9.1.16? > > > I hope you had pinged some days earlier. Here's a patch, but I will > > wait until this week's releases have been tagged before pushing. > > Is

Re: [HACKERS] How does MSVC's fetchRegressOpts() work at all?

Andrew Dunstan writes: > On 05/18/2015 12:48 PM, Tom Lane wrote: >> Looking at vcregress.pl's sub fetchRegressOpts, it seems that it only >> notices "REGRESS_OPTS =" lines not "REGRESS_OPTS +=" lines, so that >> isn't surprising --- but how is it that the tests *are* still loading >> plpythonu and

Re: [HACKERS] ERROR: cannot GetMultiXactIdMembers() during recovery

On 2015-05-18 14:13:51 -0300, Alvaro Herrera wrote: > Hmm, AFAICS the problematic check was introduced by this commit: > > commit 9f1e051adefb2f29e757cf426b03db20d3f8a26d > Author: Alvaro Herrera > Date: Fri Nov 29 11:26:41 2013 -0300 > > so it isn't hot off the oven, but it is a regression.

Re: [HACKERS] Making the regression tests halt to attach a debugger

On 05/18/2015 01:05 PM, Tom Lane wrote: Meh. You could also add "select pg_backend_pid()" or some such. But really, the way I generally do this is to run gdb via a script that auto-attaches to the right postgres process if at all possible. Removes the whole problem. This should go on the wik

Re: [HACKERS] How does MSVC's fetchRegressOpts() work at all?

On 05/18/2015 12:48 PM, Tom Lane wrote: The MSVC members of the buildfarm seem to not like my recent patch b14cf229f4bd7238, which basically did this to contrib/hstore_plpython's Makefile: SHLIB_LINK += ../hstore/libhstore.a $(wildcard ../../src/pl/plpython/libpython*.a) $(wildcard ../../sr

Re: [HACKERS] ERROR: cannot GetMultiXactIdMembers() during recovery

Tom Lane wrote: > Alvaro Herrera writes: > > Marko Tiikkaja wrote: > >> Any chance to get this fixed in time for 9.1.16? > > > I hope you had pinged some days earlier. Here's a patch, but I will > > wait until this week's releases have been tagged before pushing. > > Is this a recent regression

Re: [HACKERS] Making the regression tests halt to attach a debugger

Jim Nasby writes: > On 5/18/15 8:44 AM, Tom Lane wrote: >> If your approach involves modifying a target query in a regression test, >> it really seems unnecessary to do all this. Just insert something like >> "select pg_sleep(60)" into the test script before the target query. >> >> A variant is

Re: [HACKERS] ERROR: cannot GetMultiXactIdMembers() during recovery

On 2015-05-18 12:59:47 -0400, Tom Lane wrote: > If the former, maybe we should take the risk of fixing it today > (the patch certainly looks safe enough). But if it's been this > way a long time and nobody noticed till now, I'd agree with waiting. It's a old regression, and nobody noticed it unti

Re: [HACKERS] "Bugs" CF?

On May 12, 2015 4:13 PM, "Stephen Frost" wrote: > > * Magnus Hagander (mag...@hagander.net) wrote: > > On Tue, May 12, 2015 at 3:21 PM, Stephen Frost wrote: > > > * Magnus Hagander (mag...@hagander.net) wrote: > > > > We could also use the category that we have now, or even create the > > > conce

Re: [HACKERS] ERROR: cannot GetMultiXactIdMembers() during recovery

Alvaro Herrera writes: > Marko Tiikkaja wrote: >> Any chance to get this fixed in time for 9.1.16? > I hope you had pinged some days earlier. Here's a patch, but I will > wait until this week's releases have been tagged before pushing. Is this a recent regression, or has it been busted all alon

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

> creates the specified path if it does not exist. Does it? No, jsonb_replace() doesn't create an element, if it doesn't exist. I think, otherwise it can be confusing, so probably jsonb_add() may be more appropriate (and, actually, this function was already mentioned in previous discussions). On

[HACKERS] How does MSVC's fetchRegressOpts() work at all?

The MSVC members of the buildfarm seem to not like my recent patch b14cf229f4bd7238, which basically did this to contrib/hstore_plpython's Makefile: SHLIB_LINK += ../hstore/libhstore.a $(wildcard ../../src/pl/plpython/libpython*.a) $(wildcard ../../src/pl/plpython/libplpython*.a) endif -REGR

Re: [HACKERS] ERROR: cannot GetMultiXactIdMembers() during recovery

Marko Tiikkaja wrote: > Hi hackers, > > Any chance to get this fixed in time for 9.1.16? I hope you had pinged some days earlier. Here's a patch, but I will wait until this week's releases have been tagged before pushing. I checked 9.2, and it doesn't look like it's subject to the same problem:

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

Bruce Momjian wrote: > On Sun, May 17, 2015 at 09:31:47PM +0200, José Luis Tallón wrote: > > On 05/17/2015 07:39 PM, Tom Lane wrote: > > >=?windows-1252?Q?Jos=E9_Luis_Tall=F3n?= > > >writes: > > >>On the other hand, ISTM that what we all intend to achieve is some > > >>Postgres equivalent of the

Re: [HACKERS] 9.5 open items

On Sun, May 17, 2015 at 08:35:49PM -0700, Josh Berkus wrote: > On 05/15/2015 05:58 AM, Bruce Momjian wrote: > > I have processed all the open email items I can through mid-March, > > though I do have two pg_upgrade fixes pending application today. I will > > continue processing doc fixes and major

Re: [HACKERS] Run pgindent now?

On Sat, May 16, 2015 at 01:05:27PM -0400, Tom Lane wrote: > Magnus Hagander writes: > > On Sat, May 16, 2015 at 5:58 PM, Tom Lane wrote: > >> With feature freeze behind us, I'd like to propose that now is a good > >> time for a pgindent run. > > > +1, except I suggest we at least delay it until

  1   2   >