Re: [HACKERS] The plan for FDW-based sharding

On 02/26/2016 08:06 AM, Robert Haas wrote: On Fri, Feb 26, 2016 at 7:21 PM, Oleg Bartunov wrote: Right now tm is hardcoded and it's doesn't matter "if other people might need" at all. We at least provide developers ("other people") ability to work on their

Re: [HACKERS] Relaxing SSL key permission checks

On 02/18/2016 08:22 PM, Tom Lane wrote: Now, I have heard it argued that the OpenSSH/L authors are a bunch of idiots who know nothing about security. But it's not like insisting on restrictive permissions on key files is something we invented out of the blue. It's pretty standard practice,

Re: [HACKERS] Defaults for replication/backup

On 02/13/2016 05:37 AM, Michael Paquier wrote: On Sat, Feb 13, 2016 at 10:15 PM, Magnus Hagander wrote: So, I suggest the following changes to the defaults: wal_level=hot_standby max_wal_senders=10 max_replication_slots=10 10 seems a bit high. I would think that max_wal_senders and

Re: [HACKERS] Defaults for replication/backup

Hello, I would like to add the idea of having archiving on by default. Not everyone uses streaming replication, some people use PITR. The one that I see is archive_command and I am not sure how to deal with that. Sincerely, JD -- Command Prompt, Inc.

Re: [HACKERS] Multi-tenancy with RLS

a super user, it doesn't matter either way. From my perspective, I should not have to enable row security as a non-super user to take a pg_dump. It should just work for what I am allowed to see. In other words: pg_dump -U $non-super_user Should just work, period. Sincerely, Joshua D

Re: [HACKERS] Multi-tenancy with RLS

On 02/09/2016 12:28 PM, Stephen Frost wrote: JD, * Joshua D. Drake (j...@commandprompt.com) wrote: pg_dump -U $non-super_user Should just work, period. That ship has sailed already, where you're running a pg_dump against objects you don't own and which have RLS enabled on them. Just

Re: [HACKERS] a raft of parallelism-related bug fixes

On 02/08/2016 10:45 AM, Robert Haas wrote: On Mon, Feb 8, 2016 at 10:17 AM, Andres Freund wrote: On 2016-02-02 15:41:45 -0500, Robert Haas wrote: I realize that this stuff has all been brewing long, and that there's still a lot to do. So you gotta keep moving. And I'm

Re: [HACKERS] enable parallel query by default?

On 02/08/2016 01:07 PM, Robert Haas wrote: Hi, One of the questions I have about parallel query is whether it should be enabled by default. That is, should we make the default value of max_parallel_degree to a value higher than 0? Perhaps 1, say? O.k. after some googling where I found your

Re: [HACKERS] a raft of parallelism-related bug fixes

On 02/08/2016 01:11 PM, Peter Geoghegan wrote: On Mon, Feb 8, 2016 at 12:18 PM, Robert Haas wrote: I accept that this might have been a somewhat isolated incident (that I couldn't easily get *at least* a little instant gratification), but it still should be avoided.

Re: [HACKERS] a raft of parallelism-related bug fixes

On 02/08/2016 11:24 AM, Robert Haas wrote: On Mon, Feb 8, 2016 at 2:00 PM, Joshua D. Drake <j...@commandprompt.com> wrote: If I am off base, please feel free to yell Latin at me again but isn't this exactly what different trees are for in Git? Would it be possible to say: Robert says

Re: [HACKERS] PostgreSQL Auditing

On 02/02/2016 07:26 PM, Robert Haas wrote: On Tue, Feb 2, 2016 at 8:25 PM, Curtis Ruck wrote: Additionally Robert, given your professional status, you are by no means an unbiased contributor in this discussion. Your stance on this matter shows that you

Re: [HACKERS] Idle In Transaction Session Timeout, revived

On 02/03/2016 02:52 PM, Robert Haas wrote: On Wed, Feb 3, 2016 at 5:36 PM, Jim Nasby wrote: I think killing the session is a perfectly sensible thing to do in this case. Everything meaningful that was done in the session will be rolled back - no need to waste

Re: [HACKERS] PostgreSQL Audit Extension

On 02/03/2016 10:36 AM, Robert Haas wrote: I'll be the first to admit that the design is not the prettiest. Trying It's entirely reasonable for the community NOT to want to privilege one implementation over another. This, not so much. No, this is ABSOLUTELY critical. Suppose EnterpriseDB

Re: [HACKERS] PostgreSQL Auditing

On 02/02/2016 02:47 AM, José Luis Tallón wrote: On 02/02/2016 02:05 AM, Curtis Ruck wrote: [snip] P.S., do you know what sucks, having a highly performant PostGIS database that works great, and being told to move to Oracle or SQL Server (because they have auditing). Even though they charge

Re: [HACKERS] PostgreSQL Auditing

On 02/02/2016 08:13 AM, Michael Banck wrote: On Tue, Feb 02, 2016 at 07:24:23AM -0800, Joshua D. Drake wrote: PostgreSQL has auditing. It is available now, just not in core. Postgis isn't available in core either and it seems to do just fine. I don't really buy that argument. For one, PostGIS

Re: [HACKERS] PostgreSQL Auditing

On 02/02/2016 07:31 AM, curtis.r...@gmail.com wrote: Its not available in rpm or premade binary forms in its current instantiation, not a big deal for me, but it raises the barrier to entry. If it was packaged into an RPM, what would be the process to get it added to postgresql's yum

Re: [HACKERS] PostgreSQL Audit Extension

On 02/01/2016 08:23 PM, Robert Haas wrote: It also appears to me that if we did want to do that, it would need quite a lot of additional cleanup. I haven't dug in enough to have a list of specific issues, but it does look to me like there would be quite a bit. Maybe that'd be worth doing if

Re: [HACKERS] PostgreSQL Audit Extension

On 01/31/2016 05:07 AM, Alvaro Herrera wrote: David Steele wrote: The attached patch implements audit logging for PostgreSQL as an extension. I believe I have addressed the concerns that were raised at the end of the 9.5 development cycle. This patch got no feedback at all during the

Re: [HACKERS] Template for commit messages

On 01/29/2016 03:05 PM, Alvaro Herrera wrote: Joshua D. Drake wrote: I think the best question to ask is: "What is the problem we are trying to solve?" The problem is alluring more patch reviewers, beta testers and bug reporters. Do we really want patch reviewers, beta teste

Re: [HACKERS] Template for commit messages

On 01/31/2016 04:34 PM, Michael Paquier wrote: On Mon, Feb 1, 2016 at 2:44 AM, Joshua D. Drake wrote: On 01/29/2016 03:05 PM, Alvaro Herrera wrote: Joshua D. Drake wrote: One of the offers is to credit them (I'm not exactly clear on what is the group to benefit from this, but the phrasing used

Re: [HACKERS] Template for commit messages

what we add is actually useful, and that we don't add noise to the commit messages unnecessarily. - Heikki I think the best question to ask is: "What is the problem we are trying to solve?" "A bunch of work that probably could be automated" Does not answer that question. Si

Re: [HACKERS] Template for commit messages

on: Individuals who provided notable review which may or may not have been code review. Sincerely, Joshua D. Drake -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. --

Re: [HACKERS] New committer

On 01/28/2016 06:37 AM, Magnus Hagander wrote: Hello! The PostgreSQL core team would like to welcome Dean Rasheed as a new committer for the PostgreSQL project. Dean - welcome! Now let's see how quickly you can break the buildfarm! Congrats! -- Magnus Hagander Me:

Re: [HACKERS] Template for commit messages

a fixed format except for you, we might as well just forget the whole thing, because the percentage of commits that are done by you is quite high. Yes, we are either all in or we may as well forgo this. Sincerely, Joshua D. Drake -- Command Prompt, Inc. http

Re: [HACKERS] pglogical - logical replication contrib module

want to do? Sincerely, Joshua D. Drake -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make chang

Re: [HACKERS] Releasing in September

ayed is a good thing, not a bad one. I believe we need to be much more willing to push a button that says, "It isn't done." Which goes back to the idea in #1 of having a release "window" versus date. We aren't a company. We don't need to adhere to an exact release

Re: [HACKERS] Releasing in September

On 01/20/2016 09:31 AM, Joel Jacobson wrote: On Wed, Jan 20, 2016 at 5:29 PM, Andres Freund wrote: I think one thing we should work on, is being absolutely religious about requiring, say, 2 reviews for every nontrivial contribution. We currently seem to have a

Re: [HACKERS] Releasing in September

On 01/20/2016 09:48 AM, David E. Wheeler wrote: On Jan 20, 2016, at 9:42 AM, Joshua D. Drake <j...@commandprompt.com> wrote: 4. Submit a patch, review a patch. Don't review patches? Don't submit patches. There will always be patches desirable-enough that they will be reviewed w

Re: [HACKERS] Releasing in September

On 01/20/2016 09:17 AM, Andres Freund wrote: On 2016-01-20 09:15:01 -0800, Joshua D. Drake wrote: On 01/20/2016 09:03 AM, Andres Freund wrote: If people don't fix the issues in time, there needs to be direct pushback, leading to much less stuff getting in next time round. We have been

Re: [HACKERS] Releasing in September

On 01/20/2016 09:03 AM, Andres Freund wrote: If people don't fix the issues in time, there needs to be direct pushback, leading to much less stuff getting in next time round. We have been slowly moving to a more dictator based release anyway. It used to be that we released "when it's done",

Re: [HACKERS] Releasing in September

hink about the multixact problem) that will run any software because it is new. Let's put the proper disclaimers on there and let them run it. Sincerely, Joshua D. Drake -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered

Re: [HACKERS] Releasing in September

On 01/20/2016 10:53 AM, Simon Riggs wrote: On 20 January 2016 at 15:40, Bruce Momjian > wrote: Many people where happy with our consistent releasing major releases in September, e.g. 9.0 to 9.3: What is the point in having a special mailing

[HACKERS] PgConf.US Hackers Track CFP

The organization committee for PGConf.US invites all Pg Hackers to the PGConf.US 2016 hackers track. We want to showcase your talents to the general PostgreSQL community, potential new hackers plus provide a forum for feedback and deep discussion by having you present! We have also brought

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 01/11/2016 03:31 AM, Magnus Hagander wrote: We can argue about if it's actually an easier management interface ;) (as long as it is manageable via email as well as web?) I'd agree with Robert in that it will cause some more such bickering -- but only because the discussions become

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 01/10/2016 06:19 PM, Robert Haas wrote: [snip] No arguments with what was written above. If we had an "issue" tracker rather than a bug tracker, I'd expect a lot more unproductive bickering. This I disagree with. It wouldn't be any worse than we have now. An issue tracker (if it is a

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 01/06/2016 04:18 PM, Greg Stark wrote: On Wed, Jan 6, 2016 at 11:42 PM, Jim Nasby wrote: Right. Personally, I feel the TODO has pretty much outlived it's usefulness. An issue tracker would make maintaining items like this a lot more reasonable, but it certainly

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 01/07/2016 12:32 PM, Jim Nasby wrote: On 1/7/16 1:49 PM, Josh Berkus wrote: Yeah, we could also get rid of this conversation: "Here's a patch for X, which is on the TODO list" "Oh, we've obsolesced that, that was added to the TODO before we had Y" ... by auto-closing TODO items at a

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 01/06/2016 03:57 PM, Jim Nasby wrote: On 1/6/16 5:51 PM, Tom Lane wrote: Having said that, it occurs to me that one way to contribute without actually writing C code would be to try to drive those unfinished discussions to consensus, and come up with specs for features that people agree are

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

? Joshua D. Drake -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. Announcing "I'm offended" is basically telling the world you can't control your own emotions, so everyone else should do it for you.

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 01/05/2016 04:53 PM, Michael Paquier wrote: On Wed, Jan 6, 2016 at 7:32 AM, Joshua D. Drake <j...@commandprompt.com> wrote: Hello, So I was on #postgresql today. I convinced a newer user that they could easily contribute to PostgreSQL even if it was just doc patches. I described the

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

On 12/23/2015 10:16 AM, Tom Lane wrote: Depending on timing, this scheme might accidentally fail to fail, but it seems fragile as can be. I would bet that it's prone to deadlocks, quite aside from the SIGPIPE problem. Considering how amazingly ugly the underlying code is (exit_horribly is in

Re: [HACKERS] Remove Windows crash dump support?

On 12/23/2015 06:14 PM, Craig Ringer wrote: On 22 December 2015 at 23:48, Alex Ignatov > wrote: I think that you can debug crash dump since windbg exists. Nobody in their right mind uses windbg though. Visual Studio is really

Re: [HACKERS] Possible marginally-incompatible change to array subscripting

On 12/22/2015 10:01 AM, Robert Haas wrote: On Tue, Dec 22, 2015 at 12:55 PM, Tom Lane wrote: Robert Haas writes: On Tue, Dec 22, 2015 at 11:51 AM, Tom Lane wrote: ISTM that if we'd had Yury's code in there from the beginning,

Re: [HACKERS] Remove array_nulls?

On 12/18/2015 09:12 AM, Robert Haas wrote: On Fri, Dec 18, 2015 at 12:10 PM, Andres Freund wrote: On 2015-12-18 12:06:43 -0500, Robert Haas wrote: Well, Tom, Alvaro, and I all pretty much said that removing things when it's blocking further development makes sense, but

Re: [HACKERS] Disabling an index temporarily

On 12/11/2015 06:25 PM, Tatsuo Ishii wrote: What about inventing a new SET command something like: SET disabled_index to This adds to "disabled index list". The disabled index list let the planner to disregard the indexes in the list. SET enabled_index to This removes from the disabled

Re: [HACKERS] Remaining 9.5 open items

On 12/02/2015 05:27 AM, Robert Haas wrote: On Mon, Nov 30, 2015 at 4:55 PM, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: Well, it's December nearly, and we don't seem to be making much progress towards pushing out 9.5.0. I see the following items on

Re: [HACKERS] Remaining 9.5 open items

On 12/02/2015 08:39 AM, Andres Freund wrote: On 2015-12-02 08:25:13 -0800, Joshua D. Drake wrote: A feature does not exist without documentation. Uh, you do realize there's actually documentation about RLS? The issues mentioned here are some small adjustments, not entirely new docs. No I

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On 11/04/2015 01:55 PM, Stephen Frost wrote: * Joe Conway (m...@joeconway.com) wrote: On 11/04/2015 01:24 PM, Alvaro Herrera wrote: I agree with Pavel. Having a transaction timeout just does not make any sense. I can see absolutely no use for it. An idle-in-transaction timeout, on the other

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On 11/04/2015 02:15 PM, Stephen Frost wrote: Yeah but anything holding a lock that long can be terminated via statement_timeout can it not? Well, no? statement_timeout is per-statement, while transaction_timeout is, well, per transaction. If there's a process which is going and has an open

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On 11/04/2015 12:31 PM, Merlin Moncure wrote: My issue isn't long statements, but broken client, that is broken in wrong state - connect is still active, but no any statement will coming. Right, 'Idle in transaction'. Agree that a setting directed purely at that problem could set a much

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On 11/04/2015 01:11 PM, Pavel Stehule wrote: I am sorry, but I have a different experience from GoodData. The few hours autovacuum is usual. So probably, there should be exception for autovacuum, dump, .. But autovacuum and dump are not idle in transaction or am I missing something? JD

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On 11/04/2015 02:53 PM, Stephen Frost wrote: This implies that a statement used takes a long time. It may not. The lock is held at the transaction level not the statement level, which is why a transaction level timeout is actually more useful than a statement level timeout. What I'm most

Re: [HACKERS] pg_basebackup and replication slots

On 10/26/2015 08:14 PM, Michael Paquier wrote: On Tue, Oct 27, 2015 at 7:18 AM, José Luis Tallón wrote: Given the rest of the thread any possibility whatsoever that it'd be backpatched into 9.5 before release? Guess it'd be a very welcome addition This will be available in 9.6.

[HACKERS] pg_basebackup and replication slots

Hello, The fact that pg_basebackup doesn't use replicaiton slots, is that a technical limitation or just a, "we need a patch"? JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. Announcing "I'm offended"

Re: [HACKERS] bugs and bug tracking

On 10/13/2015 11:41 AM, Bruce Momjian wrote: FYI, I think we already have two limits for the first line summary of commit messages. The limits are 64 for commit message subjects and 50 characters for gitweb summary pages --- anything longer is truncated. My commit template shows me the limits

Re: [HACKERS] pg_restore cancel TODO

On 10/19/2015 09:47 AM, Jeff Janes wrote: On Mon, Oct 19, 2015 at 9:37 AM, Bruce Momjian > wrote: Sorry, I don't know how I managed to screw this up so much. pg_restore, not pg_upgrade. I've never looked into pg_restore much until recently, so my

Re: [HACKERS] plpython is broken for recursive use

On 10/15/2015 02:16 PM, Josh Berkus wrote: On 10/15/2015 01:10 PM, Tom Lane wrote: I think this means that we should get rid of proc->globals and instead manufacture a new globals dict locally in each call to PLy_exec_function or PLy_exec_trigger. For SETOF functions it would be necessary to

Re: [HACKERS] bugs and bug tracking

On 10/13/2015 08:15 AM, Tom Lane wrote: Andres Freund writes: On 2015-10-13 16:21:54 +0200, �lvaro Hern�ndez Tortosa wrote: (50 chars for the commit summary, 72 chars line wrapping) -1 - imo 50 chars too often makes the commit summary too unspecific, requiring to read

Re: [HACKERS] bugs and bug tracking

On 10/06/2015 10:57 AM, Josh Berkus wrote: On 10/06/2015 10:17 AM, Bruce Momjian wrote: This is kind of like CVS. We didn't upgrade so Subversion, becuase we said "we already have a user-friendly interface to CVS, called Marc." We only moved to git when it could provide us with solid

Re: [HACKERS] bugs and bug tracking

On 10/06/2015 11:33 AM, Alvaro Herrera wrote: Joshua D. Drake wrote: On 10/06/2015 10:57 AM, Josh Berkus wrote: On 10/06/2015 10:17 AM, Bruce Momjian wrote: Speaking of which ... this project is rich in skilled users who are involved in the community but don't code. Bug triage is exactly

Re: [HACKERS] bugs and bug tracking

On 10/06/2015 11:51 AM, Alvaro Herrera wrote: Joshua D. Drake wrote: [I have heated water with wood till boiling point, FWIW] Hahahah I have no doubt. It should be, "I once heated water with wood and it didn't boil. How can I change my process so that it will?" Oh, I am not

Request for dogfood volunteers (was [HACKERS] No Issue Tracker - Say it Ain't So!)

Hello, I believe it is pretty obvious we are moving in the direction of having a tracker at this point. The problem is exactly which direction. Stephen has offered some resources for his ideas and now I am offering some resources for mine. I am proposing to setup a redmine instance on a VM.

Re: Request for dogfood volunteers (was [HACKERS] No Issue Tracker - Say it Ain't So!)

On 10/02/2015 11:36 AM, Robert Haas wrote: I don't know what this has to do with anything Andres said. I am sorry if I wasn't clear. Put succinctly, I am willing to put resources into testing Redmine for our needs. I will need help to do so because I am not a committer/hacker. Andres

Re: Request for dogfood volunteers (was [HACKERS] No Issue Tracker - Say it Ain't So!)

On 10/02/2015 09:34 AM, Dave Page wrote: Thoughts? Volunteers? I swore to myself that I'd stay out of this bikeshed, but... we already have a Redmine instance. I know but I didn't want to dogfood in an installation that was production. I am not going to put up vanilla redmine, I actually

Re: Request for dogfood volunteers (was [HACKERS] No Issue Tracker - Say it Ain't So!)

On 10/02/2015 09:41 AM, Andres Freund wrote: Hi, On 2015-10-02 09:28:02 -0700, Joshua D. Drake wrote: I am proposing to setup a redmine instance on a VM. I am happy to do a lot of the legwork and should be able to get most of it done before EU. This is what I think I need from my fellows: -1

Re: Request for dogfood volunteers (was [HACKERS] No Issue Tracker - Say it Ain't So!)

On 10/02/2015 12:52 PM, Robert Haas wrote: OK. My reading of the thread is that the hackers who expressed an opinion mostly preferred debbugs and the people less involved in the project wanted something more like GitHub/GitLab. Some people also argued for and against Bugzilla and JIRA. I

Re: Request for dogfood volunteers (was [HACKERS] No Issue Tracker - Say it Ain't So!)

On 10/02/2015 01:26 PM, Alvaro Herrera wrote: However, the contact surface between these two options wasn't really well polished. Formatting would be lost very frequently: I could write a nice email, and the customer would get a nice email, but if you looked at it in the web, it was very

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 10/01/2015 07:48 AM, Magnus Hagander wrote: But using the bugtracker for the discussion itself is usually not a win. I know you said usually but: In fact, I'd say in most cases it's counterproductive because it forces a single tool upon everybody, instead of email which allows each

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 10/01/2015 08:18 AM, Tom Lane wrote: Andres Freund writes: On 2015-10-01 11:07:12 -0400, Tom Lane wrote: I'm inclined to think that commit messages are not really the right medium for that at all. Commit messages ought to be primarily text for consumption by humans.

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/30/2015 10:45 AM, Andrew Dunstan wrote: Frankly, an insistence on moving to some integrated solution is likely to result in the adoption of nothing. And your "educating hackers who don't understand" is more than a little patronizing. What makes you think your experience in software

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/30/2015 12:02 AM, Jim Nasby wrote: If people are hell-bent on every tool being separate then fine, but I get the distinct impression that everyone is discarding GitLab out of hand based on completely bogus information. Right, we need to stop thinking that every task is not interrelated.

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/30/2015 11:23 AM, Christopher Browne wrote: It's well and nice to think that an issue tracker resolves all of this, and, if we had tiny numbers of issues, we could doubtless construct a repository indicating so. (Seems to me that the bit of "fan service" for GitHub's bug tracker fits

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/30/2015 11:33 AM, Andrew Dunstan wrote: Who exactly is "some guy sitting in a den pushing out code"? And if that's not a patronizing put down I don't know what is. If you're referring to me you couldn't be more wrong. I have been a development director managing a couple of substantial

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/30/2015 03:28 PM, Josh Berkus wrote: On 09/30/2015 03:27 PM, Tom Lane wrote: Josh Berkus writes: On 09/30/2015 03:10 PM, Tom Lane wrote: I'd be feeling a lot more positive about this whole thread if any people had stepped up and said "yes, *I* will put in a lot of

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/30/2015 03:49 PM, Alvaro Herrera wrote: Josh Berkus wrote: Well, it's hard for anyone to volunteer when we don't know what the actual volunteer tasks are. I certainly intend to do *something* to support the bug tracker system, but I don't know yet what that something is. I volunteer

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/30/2015 07:44 AM, Merlin Moncure wrote: I'm not trolling in any way. I'm just challenging you to back up your blanket assertions with evidence. For example, you're assertion that mailing lists are insufficient is simply stated and expected to be taken on faith: *How* is it insufficient

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/29/2015 03:46 PM, Tom Lane wrote: Alvaro Herrera writes: Merlin Moncure wrote: I've read this email about three times now and it's not clear at all to me what a issue/bug tracker brings to the table. In my opinion, this thread is about a bug tracker, not a

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/29/2015 07:25 AM, Merlin Moncure wrote: On Wed, Sep 23, 2015 at 1:18 PM, Kam Lasater wrote: Hello, Last night I heard that Postgres had no issue/bug tracker. At first I thought the guy was trolling me. Seriously, how could this be. Certainly a mature open source

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/28/2015 05:50 AM, YUriy Zhuravlev wrote: On Thursday 24 September 2015 12:10:07 Ryan Pedela wrote: Kam Lasater wrote: I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in that order). There are tens to hundreds of other great ones out there, I'm sure one of them would also

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/28/2015 03:40 PM, Alvaro Herrera wrote: Tom Lane wrote: Now, running gitlab on community-owned hardware would potentially be an option, if we find gitlab attractive from a functionality standpoint. The question I'd have about that is whether it has a real development community, or is

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/28/2015 04:08 PM, Gavin Flower wrote: JD Linux kernel project uses bugzilla (https://bugzilla.kernel.org) and so does LibreOffice (https://bugs.documentfoundation.org) I think they are both fairly big projects in for the long haul. I am not anti-bugzilla, just not all that familiar

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/28/2015 07:18 PM, Stephen Frost wrote: JD, debbugs is being used by Debian, and has been since before our first release (I believe- according to wikipedia, it started in 1994..). Further, it's now being used by the GNU project for things as important (well, to some ;) as Emacs. I

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

(requirement for most hackers) In short, although we are talking about an issue tracker this is something that can be integrated into our existing workflow, habits of the current hackers would have to adapt not completely change. Joshua D. Drake EDIT: Note that I am not trying to start an argument

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/25/2015 09:55 AM, Joe Conway wrote: On 09/25/2015 09:32 AM, Tom Lane wrote: 2. There's no visibility for outsiders as to what issues are open or recently fixed. Not being outsiders, I'm not sure that we are terribly well qualified to describe this problem precisely or identify a good

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/25/2015 10:27 AM, Simon Riggs wrote: 2. There's no visibility for outsiders as to what issues are open or recently fixed. Not being outsiders, I'm not sure that we are terribly well qualified to describe this problem precisely or identify a good solution --- but I grant

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/25/2015 10:11 AM, Simon Riggs wrote: > > I do not know how much emphasis the project should place on point #2. > By definition, fixing that will not return any direct benefit to us. I would argue that there is some benefit for us in terms of advocacy. There are also some

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/23/2015 11:33 AM, Stephen Frost wrote: * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: Kam Lasater wrote: I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in that order). There are tens to hundreds of other great ones out there, I'm sure one of them would also work.

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/23/2015 11:23 AM, Alvaro Herrera wrote: Kam Lasater wrote: I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in that order). There are tens to hundreds of other great ones out there, I'm sure one of them would also work. If you install debbugs and feed it from our lists,

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

Wow, 1960s feminazis, eh? I originally thought you were just a narrow minded, pedantic and antiquated grammarian. Now I realize that's the least of your troubles. Please take your misogyny elsewhere. I hear the Rabid Puppies have openings. The term feminazi has zero business in this

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

Hello, - environment variable); any user can make such a change for his session. + environment variable); any user can make such a change for the session. Or + environment variable); any user can make such a change for the connected session. - allowed to change his

[HACKERS] PSA: Upcoming Linux scheduler changes

Folks, This is something we should be watching for and if people have time, testing to see how it affects us: http://lkml.iu.edu/hypermail/linux/kernel/1508.3/04818.html -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting

Re: [HACKERS] Horizontal scalability/sharding

On 09/02/2015 03:56 PM, Bruce Momjian wrote: On Wed, Sep 2, 2015 at 02:41:46PM -0400, Robert Haas wrote: 4. Therefore, I think that we should instead use logical replication, which might be either synchronous or asynchronous. When you modify one copy of the data, that change will then be

Re: [HACKERS] Horizontal scalability/sharding

On 09/01/2015 10:06 AM, Josh Berkus wrote: On 09/01/2015 02:39 AM, Bruce Momjian wrote: On Mon, Aug 31, 2015 at 01:16:21PM -0700, Josh Berkus wrote: Our real future bottlenecks are: * ability to handle more than a few hundred connections This, 1000 times this. No a connection pooler

Re: [HACKERS] 9.4 broken on alpha

On 09/01/2015 01:18 PM, Peter Geoghegan wrote: On Tue, Sep 1, 2015 at 1:00 PM, Tom Lane wrote: I think we've probably beat this to death. Nobody here believes that it's sane to try to support Alpha without access to hardware, and no offer of hardware has been forthcoming.

Re: [HACKERS] Horizontal scalability/sharding

On 09/01/2015 09:08 AM, Robert Haas wrote: On Tue, Sep 1, 2015 at 12:00 AM, Pavan Deolasee From my point of view, and EnterpriseDB's point of view, anything that doesn't go into the core PostgreSQL distribution isn't really getting us where we need to be. If there's code in XL that would be

Re: [HACKERS] Horizontal scalability/sharding

On 09/01/2015 02:48 AM, Bruce Momjian wrote: On Tue, Sep 1, 2015 at 09:30:41AM +0530, Pavan Deolasee wrote: There is no question that using XC/XL will get us to a usable solution faster, but see my recent post to Josh Berkus --- the additional code will be so burdensome that I doubt it would

Re: [HACKERS] Horizontal scalability/sharding

about design and what we think distributed data/sharding etc should provide *before* grabbing hold of FDW as *the answer*! Agreed. Sincerely, Joshua D. Drake -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting

Re: [HACKERS] Horizontal scalability/sharding

On 08/31/2015 01:16 PM, Josh Berkus wrote: All, Bruce: I'm also going to pontificate that, for a future solution, we should not focus on write *IO*, but rather on CPU and RAM. The reason for this thinking is that, with the latest improvements in hardware and 9.5 improvements, it's

Re: [HACKERS] (full) Memory context dump considered harmful

On 08/20/2015 08:51 AM, Stefan Kaltenbrunner wrote: This is 9.1.14 on Debian Wheezy/amd64 fwiw - but I dont think we have made relevant changes in more recent versions. It seems we may also want to consider a way to drop those prepared queries after a period time of non use. JD

Re: [HACKERS] Badly broken logic in plpython composite-type handling

On 08/19/2015 05:05 PM, Tom Lane wrote: Barring objections, I propose to commit and back-patch this. The crash can be demonstrated back to 9.1. regards, tom lane +1 -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full

<    1   2   3   4   5   6   7   8   9   10   >