Re: [HACKERS] Enabling Checksums

2013-03-29 Thread Andres Freund
On 2013-03-28 21:02:06 -0400, Robert Haas wrote: On Wed, Mar 27, 2013 at 10:15 AM, Andres Freund and...@2ndquadrant.com wrote: On 2013-03-27 10:06:19 -0400, Robert Haas wrote: On Mon, Mar 18, 2013 at 4:31 PM, Greg Smith g...@2ndquadrant.com wrote: to get them going again. If the install

Re: [HACKERS] sql_drop Event Triggerg

2013-03-29 Thread Dimitri Fontaine
Alvaro Herrera alvhe...@2ndquadrant.com writes: Pushed, with some further minor changes. One not-so-minor change I Thanks a lot for all the work you did put into this patch! introduced was that pg_event_trigger_dropped_objects() now only works within a sql_drop event function. The reason I

Re: [HACKERS] in-catalog Extension Scripts and Control parameters (templates?)

2013-03-29 Thread Dimitri Fontaine
Hi, Thanks you for testing and reporting those strange bugs, I should be able to fix them by Tuesday at the earliest. Heikki Linnakangas hlinnakan...@vmware.com writes: create template for extension sslinfo version '1.0' with (schema public) as $$ DO EVIL STUFF $$; What you're saying is that

Re: [HACKERS] Changing recovery.conf parameters into GUCs

2013-03-29 Thread Simon Riggs
On 29 March 2013 01:17, Michael Paquier michael.paqu...@gmail.com wrote: The main argument on which this proposal is based on is to keep backward-compatibility. The main objective is to get recovery parameters as GUCs, as I said On Fri, Mar 29, 2013 at 12:48 AM, Simon Riggs

Re: [HACKERS] Changing recovery.conf parameters into GUCs

2013-03-29 Thread Michael Paquier
On Fri, Mar 29, 2013 at 9:59 PM, Simon Riggs si...@2ndquadrant.com wrote: On 29 March 2013 01:17, Michael Paquier michael.paqu...@gmail.com wrote: On Fri, Mar 29, 2013 at 12:48 AM, Simon Riggs si...@2ndquadrant.com wrote: Early discussions had difficulties because of the lack of config

Re: [HACKERS] Changing recovery.conf parameters into GUCs

2013-03-29 Thread Simon Riggs
On 29 March 2013 13:24, Michael Paquier michael.paqu...@gmail.com wrote: On Fri, Mar 29, 2013 at 9:59 PM, Simon Riggs si...@2ndquadrant.com wrote: On 29 March 2013 01:17, Michael Paquier michael.paqu...@gmail.com wrote: On Fri, Mar 29, 2013 at 12:48 AM, Simon Riggs si...@2ndquadrant.com

Re: [HACKERS] Changing recovery.conf parameters into GUCs

2013-03-29 Thread Bruce Momjian
On Fri, Mar 29, 2013 at 01:56:50PM +, Simon Riggs wrote: On 29 March 2013 13:24, Michael Paquier michael.paqu...@gmail.com wrote: On Fri, Mar 29, 2013 at 9:59 PM, Simon Riggs si...@2ndquadrant.com wrote: On 29 March 2013 01:17, Michael Paquier michael.paqu...@gmail.com wrote: On Fri,

[HACKERS] Getting to 9.3 beta

2013-03-29 Thread Bruce Momjian
Our final 9.3 commit-fest has has exceeded the two-month mark, so it is time to start targeting a date to close it and get to 9.3 beta. I see 25 items will needing attention before we can close it: https://commitfest.postgresql.org/action/commitfest_view?id=17 What is a reasonable

Re: [HACKERS] Changing recovery.conf parameters into GUCs

2013-03-29 Thread Simon Riggs
On 29 March 2013 01:17, Michael Paquier michael.paqu...@gmail.com wrote: I highly recommend that you use one of the latest updated version I sent. Fujii's version had some bugs, one of them being that as standbyModeRequested can be set to true if specified in postgresql.conf, a portion of the

Re: [HACKERS] Getting to 9.3 beta

2013-03-29 Thread Tom Lane
Bruce Momjian br...@momjian.us writes: Our final 9.3 commit-fest has has exceeded the two-month mark, so it is time to start targeting a date to close it and get to 9.3 beta. I see 25 items will needing attention before we can close it:

Re: [HACKERS] Getting to 9.3 beta

2013-03-29 Thread Magnus Hagander
On Fri, Mar 29, 2013 at 4:05 PM, Tom Lane t...@sss.pgh.pa.us wrote: Bruce Momjian br...@momjian.us writes: Our final 9.3 commit-fest has has exceeded the two-month mark, so it is time to start targeting a date to close it and get to 9.3 beta. I see 25 items will needing attention before we

Re: [HACKERS] Getting to 9.3 beta

2013-03-29 Thread Andres Freund
On 2013-03-29 10:15:42 -0400, Bruce Momjian wrote: Our final 9.3 commit-fest has has exceeded the two-month mark, so it is time to start targeting a date to close it and get to 9.3 beta. I see 25 items will needing attention before we can close it: Very much agreed!

Re: [HACKERS] Getting to 9.3 beta

2013-03-29 Thread Andrew Dunstan
On 03/29/2013 11:05 AM, Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Our final 9.3 commit-fest has has exceeded the two-month mark, so it is time to start targeting a date to close it and get to 9.3 beta. I see 25 items will needing attention before we can close it:

Re: [HACKERS] Drastic performance loss in assert-enabled build in HEAD

2013-03-29 Thread Tom Lane
Kevin Grittner kgri...@ymail.com writes: Tom Lane t...@sss.pgh.pa.us wrote: So maybe I'm nuts to care about the performance of an assert-enabled backend, but I don't really find a 4X runtime degradation acceptable, even for development work.  Does anyone want to fess up to having caused this,

Re: [HACKERS] Getting to 9.3 beta

2013-03-29 Thread Tom Lane
Magnus Hagander mag...@hagander.net writes: On Fri, Mar 29, 2013 at 4:05 PM, Tom Lane t...@sss.pgh.pa.us wrote: Next week is going to be tied up with the back-branch releases, but maybe we could target beta for the week after? The main gating factor at this point really would be how quickly

Re: [HACKERS] Getting to 9.3 beta

2013-03-29 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: On 2013-03-29 10:15:42 -0400, Bruce Momjian wrote: What is a reasonable timeframe to target for completion of these items? Here's my take on it: Thanks for annotating these! I've commented on the ones where I come to a different conclusion: -

Re: [HACKERS] Getting to 9.3 beta

2013-03-29 Thread Bruce Momjian
On Fri, Mar 29, 2013 at 11:05:46AM -0400, Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Our final 9.3 commit-fest has has exceeded the two-month mark, so it is time to start targeting a date to close it and get to 9.3 beta. I see 25 items will needing attention before we can close

Re: [HACKERS] Getting to 9.3 beta

2013-03-29 Thread Andres Freund
On 2013-03-29 12:28:59 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2013-03-29 10:15:42 -0400, Bruce Momjian wrote: What is a reasonable timeframe to target for completion of these items? Here's my take on it: Thanks for annotating these! I've commented on the

Re: [HACKERS] Enabling Checksums

2013-03-29 Thread Jim Nasby
On 3/25/13 8:25 AM, Bruce Momjian wrote: On Fri, Mar 22, 2013 at 11:35:35PM -0500, Jim Nasby wrote: On 3/20/13 8:41 AM, Bruce Momjian wrote: Also, if a users uses checksums in 9.3, could they initdb without checksums in 9.4 and use pg_upgrade? As coded, the pg_controldata checksum settings

Re: [HACKERS] [COMMITTERS] pgsql: Add parallel pg_dump option.

2013-03-29 Thread David Fetter
On Sun, Mar 24, 2013 at 03:39:44PM +, Andrew Dunstan wrote: Add parallel pg_dump option. This is great! While testing, I noticed that the only supported -F option when -j is specified is directory, which is fine as far as it goes, but I think it would be easier on users if there were some

Re: [HACKERS] Getting to 9.3 beta

2013-03-29 Thread Pavel Stehule
Hello - plpgsql_check_function: Tom says (27661.1364267...@sss.pgh.pa.us) that even if the approach can be aggreed uppon it needs quite a bit more work = move Can we talk about this patch little bit more before moving to next commitfest? I would to have some plan to next commitfest.

Re: [HACKERS] Hash Join cost estimates

2013-03-29 Thread Jeff Davis
On Thu, 2013-03-28 at 19:56 -0400, Stephen Frost wrote: 41K hashed, seqscan 4M: 115030.10 + 1229.46 = 116259.56 4M hashed, seqscan 41K: 1229.46 + 211156.20 = 212385.66 I think those are backwards -- typo? In the end, I think the problem here is that we are charging far too much for

Re: [HACKERS] Hash Join cost estimates

2013-03-29 Thread Tom Lane
Jeff Davis pg...@j-davis.com writes: Yes, I have run into this issue (or something very similar). I don't understand why the bucketsize even matters much -- assuming few hash collisions, we are not actually evaluating the quals any more times than necessary. So why all of the hashjoin-specific

[HACKERS] Fix for pg_upgrade and invalid indexes

2013-03-29 Thread Bruce Momjian
On Thu, Mar 28, 2013 at 05:27:28PM -0400, Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Should I just patch pg_upgrade to remove the indisvalid, skip indisvalid indexes, and backpatch it? Users should be using the version of pg_upgrade to match new pg_dump. Is there any case

Re: [HACKERS] Getting to 9.3 beta

2013-03-29 Thread Michael Paquier
On 2013/03/30, at 2:33, Andres Freund and...@2ndquadrant.com wrote: On 2013-03-29 12:28:59 -0400, Tom Lane - REINDEX CONCURRENTLY: Imo pretty close to being comittable and pretty useful, but it got redesigned pretty late and it mostly had review from me and fujii and it could use a

Re: [HACKERS] Fix for pg_upgrade and invalid indexes

2013-03-29 Thread Tom Lane
Bruce Momjian br...@momjian.us writes: Attached is a patch that implements the suggested pg_upgrade changes of not copying invalid indexes now that pg_dump doesn't dump them. This should be backpatched back to 8.4 to match pg_dump. It might require release note updates; not sure.

Re: [HACKERS] Fix for pg_upgrade and invalid indexes

2013-03-29 Thread Andres Freund
On 2013-03-29 16:57:06 -0400, Bruce Momjian wrote: On Thu, Mar 28, 2013 at 05:27:28PM -0400, Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Should I just patch pg_upgrade to remove the indisvalid, skip indisvalid indexes, and backpatch it? Users should be using the version of

Re: [HACKERS] Fix for pg_upgrade and invalid indexes

2013-03-29 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: Those columns cannot be NULL, so using IS DISTINCT FROM seems a bit clumsy. That was what I started to write, too, but actually I think the IS DISTINCT is correct and the RIGHT JOIN should be a LEFT JOIN. Note that the query appears to be intended

Re: [HACKERS] Getting to 9.3 beta

2013-03-29 Thread Daniel Farina
On Fri, Mar 29, 2013 at 8:22 AM, Andres Freund and...@2ndquadrant.com wrote: - pg_stat_statements: query, session, and eviction identification: Seems to need at least docs = wait for author, seems to be easy enough? I would have responded by now, but recent events have unfortunately made

Re: [HACKERS] [COMMITTERS] pgsql: Add sql_drop event for event triggers

2013-03-29 Thread Tom Lane
Alvaro Herrera alvhe...@alvh.no-ip.org writes: Add sql_drop event for event triggers The buildfarm members that use -DCLOBBER_CACHE_ALWAYS don't like this patch: *** *** 760,771 FROM generate_series(1, 50) a; BEGIN; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

Re: [HACKERS] [COMMITTERS] pgsql: Add parallel pg_dump option.

2013-03-29 Thread Andrew Dunstan
On 03/29/2013 03:12 PM, David Fetter wrote: On Sun, Mar 24, 2013 at 03:39:44PM +, Andrew Dunstan wrote: Add parallel pg_dump option. This is great! While testing, I noticed that the only supported -F option when -j is specified is directory, which is fine as far as it goes, but I think

Re: [HACKERS] Hash Join cost estimates

2013-03-29 Thread Jeff Davis
On Fri, 2013-03-29 at 16:37 -0400, Tom Lane wrote: Jeff Davis pg...@j-davis.com writes: Yes, I have run into this issue (or something very similar). I don't understand why the bucketsize even matters much -- assuming few hash collisions, we are not actually evaluating the quals any more

Re: [HACKERS] Getting to 9.3 beta

2013-03-29 Thread Amit Kapila
On Friday, March 29, 2013 11:04 PM Andres Freund wrote: On 2013-03-29 12:28:59 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2013-03-29 10:15:42 -0400, Bruce Momjian wrote: What is a reasonable timeframe to target for completion of these items? Here's my

Re: [HACKERS] Fix for pg_upgrade and invalid indexes

2013-03-29 Thread Bruce Momjian
On Fri, Mar 29, 2013 at 07:03:05PM -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: Those columns cannot be NULL, so using IS DISTINCT FROM seems a bit clumsy. That was what I started to write, too, but actually I think the IS DISTINCT is correct and the RIGHT JOIN