On Fri, Mar 29, 2013 at 07:03:05PM -0400, Tom Lane wrote:
> Andres Freund 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 JO
On Friday, March 29, 2013 11:04 PM Andres Freund wrote:
> On 2013-03-29 12:28:59 -0400, Tom Lane wrote:
> > Andres Freund 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
On Fri, 2013-03-29 at 16:37 -0400, Tom Lane wrote:
> Jeff Davis 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
>
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
it
Alvaro Herrera 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;
UPDATE serializable_updat
On Fri, Mar 29, 2013 at 8:22 AM, Andres Freund 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 me put a lot of thi
Andres Freund 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 to collect regular tab
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 writes:
> > > Should I just patch pg_upgrade to remove the "indisvalid", skip
> > > "indisvalid" indexes, and backpatch it? Users should be using the
> > > version of p
Bruce Momjian 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. Previously pg_upgrade
On 2013/03/30, at 2:33, Andres Freund 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 bit more in
On Thu, Mar 28, 2013 at 05:27:28PM -0400, Tom Lane wrote:
> Bruce Momjian 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 where
> >
Jeff Davis 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 logic in dete
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 fo
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 commi
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 d
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 se
On 2013-03-29 12:28:59 -0400, Tom Lane wrote:
> Andres Freund 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
On Fri, Mar 29, 2013 at 11:05:46AM -0400, Tom Lane wrote:
> Bruce Momjian 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:
>
>
Andres Freund 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:
> - replace plugins dire
Magnus Hagander writes:
> On Fri, Mar 29, 2013 at 4:05 PM, Tom Lane 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 we could write some draft
>> rel
Kevin Grittner writes:
> Tom Lane 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, or do I need to start trac
On 03/29/2013 11:05 AM, Tom Lane wrote:
Bruce Momjian 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:
https://commitfest.postgr
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!
> https://commitf
On Fri, Mar 29, 2013 at 4:05 PM, Tom Lane wrote:
> Bruce Momjian 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:
>
>> https
Bruce Momjian 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:
> https://commitfest.postgresql.org/action/commitfest_view?id=17
On 29 March 2013 01:17, Michael Paquier 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 code using in xlog.c
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 timefr
On Fri, Mar 29, 2013 at 01:56:50PM +, Simon Riggs wrote:
> On 29 March 2013 13:24, Michael Paquier wrote:
> > On Fri, Mar 29, 2013 at 9:59 PM, Simon Riggs wrote:
> >>
> >> On 29 March 2013 01:17, Michael Paquier wrote:
> >> > On Fri, Mar 29, 2013 at 12:48 AM, Simon Riggs
> >> > wrote:
> >>
On 29 March 2013 13:24, Michael Paquier wrote:
> On Fri, Mar 29, 2013 at 9:59 PM, Simon Riggs wrote:
>>
>> On 29 March 2013 01:17, Michael Paquier wrote:
>> > On Fri, Mar 29, 2013 at 12:48 AM, Simon Riggs
>> > wrote:
>> Early discussions had difficulties because of the lack of config
>> directo
On Fri, Mar 29, 2013 at 9:59 PM, Simon Riggs wrote:
> On 29 March 2013 01:17, Michael Paquier wrote:
> > On Fri, Mar 29, 2013 at 12:48 AM, Simon Riggs
> wrote:
> Early discussions had difficulties because of the lack of config
> directories, include_if_exists and this patch. We now have the
> t
On 29 March 2013 01:17, Michael Paquier 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 wrote:
>> What we want to do is mak
Hi,
Thanks you for testing and reporting those strange bugs, I should be
able to fix them by Tuesday at the earliest.
Heikki Linnakangas writes:
> create template for extension sslinfo version '1.0' with (schema public) as
> $$ DO EVIL STUFF $$;
What you're saying is that we should restrict the
Alvaro Herrera 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 decided to do this was
On 2013-03-28 21:02:06 -0400, Robert Haas wrote:
> On Wed, Mar 27, 2013 at 10:15 AM, Andres Freund
> wrote:
> > On 2013-03-27 10:06:19 -0400, Robert Haas wrote:
> >> On Mon, Mar 18, 2013 at 4:31 PM, Greg Smith wrote:
> >> > to get them going again. If the install had checksums, I could have
>
34 matches
Mail list logo
