On Fri, 2012-03-30 at 13:11 -0700, Jeff Davis wrote:
> I confirmed this bug upgrading 9.1 to master, and that this patch fixes
> it. Thank you for the report!
>
> Patch looks good to me as well, with one very minor nitpick: the added
> comment is missing an apostrophe.
>
> Bruce, can you take a l
On Wed, Apr 4, 2012 at 7:06 PM, Josh Berkus wrote:
> On 4/4/12 4:02 PM, Tom Lane wrote:
>> Greg Stark writes:
>>> On Wed, Apr 4, 2012 at 9:34 PM, Simon Riggs wrote:
Why is this pgbench run accessing so much unhinted data that is > 1
million transactions old? Do you believe those number
On Sat, Apr 7, 2012 at 4:19 AM, Tom Lane wrote:
> Shigeru HANADA writes:
>> Just after my post, Fujita-san posted another v7 patch[1], so I merged
>> v7 patches into v8 patch.
>
> I've committed a modified version of this, but right after pushing it
> I had a better idea about what the AnalyzeFor
On 6 April 2012 22:35, Tom Lane wrote:
> Thom Brown writes:
>> I can't explain why I'm seeing a range type installcheck failure as I
>> don't see the same problem on the buildfarm, but out of all the tests
>> run, the range types test is the only one to fail.
>
> I can duplicate that output order
Thom Brown writes:
> I can't explain why I'm seeing a range type installcheck failure as I
> don't see the same problem on the buildfarm, but out of all the tests
> run, the range types test is the only one to fail.
I can duplicate that output ordering if I force it to use indexscans,
but it's qu
On 6 April 2012 21:56, Peter Eisentraut wrote:
> On fre, 2012-04-06 at 01:24 +0100, Thom Brown wrote:
>> > I also found a couple typos in completely different sections. (patch
>> attached)
>>
>> Apologies, that last patch had one correction in the wrong place.
>> Reattached.
>>
> Committed.
Cheer
Hi,
I can't explain why I'm seeing a range type installcheck failure as I
don't see the same problem on the buildfarm, but out of all the tests
run, the range types test is the only one to fail.
I've attached the diff and the rangetypes.out file. It appears that
while the rows output are the sam
On fre, 2012-04-06 at 01:24 +0100, Thom Brown wrote:
> > I also found a couple typos in completely different sections. (patch
> attached)
>
> Apologies, that last patch had one correction in the wrong place.
> Reattached.
>
Committed.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
On tor, 2012-04-05 at 23:22 +0100, Thom Brown wrote:
> I attach a patch to correct various system catalog/view definitions in the
> docs.
Committed.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pg
Shigeru HANADA writes:
> Just after my post, Fujita-san posted another v7 patch[1], so I merged
> v7 patches into v8 patch.
I've committed a modified version of this, but right after pushing it
I had a better idea about what the AnalyzeForeignTable API should do.
An issue that I'd not previously
On 3/30/12 7:29 AM, Tom Lane wrote:
> Arun Chaitanya writes:
>> The link to the paper is
>> http://www.iith.ac.in/~ravig/courses/cs5050/papers/decorrelation-cesar.pdf
>
> Given the authorship of that paper, I'd have to wonder whether Microsoft
> has filed for any patents regarding these ideas.
F
On Fri, Apr 6, 2012 at 18:43, Tom Lane wrote:
> Magnus Hagander writes:
>> True. I guess I was just assuming that JDBC (and npgsql i think?) were
>> using TLS - I would assume that to be the default in both Java and
>> .NET. We'd have to check that before making a change of course - and
>> I'm no
Magnus Hagander writes:
> True. I guess I was just assuming that JDBC (and npgsql i think?) were
> using TLS - I would assume that to be the default in both Java and
> .NET. We'd have to check that before making a change of course - and
> I'm not convinced we need to make the change. But if we're
Shigeru Hanada writes:
> On Fri, Apr 6, 2012 at 11:20 PM, Tom Lane wrote:
>> In
>> particular I do not like the specific way it's done in the v7 patch
>> (I've not looked at v8 yet) because the interposed logic has a
>> hard-wired assumption that foreign tables do not have inheritance
>> children
On Fri, Apr 6, 2012 at 02:05, Tom Lane wrote:
> Magnus Hagander writes:
>> If anything, we should be changing it to TLSv1 in both client and
>> server, since every client out there now should be using that anyway,
>> given that the client has been specifying it for a long time.
>
> Huh? libpq is
On Fri, Apr 6, 2012 at 11:20 PM, Tom Lane wrote:
>> Another concern is the place where we hook the process of ANALYZE. IOW,
>> how much portion of ANALYZE should be overridable?
>
> Not much, IMO. The FDW should be able to decide whether or not to
> analyze a particular table, and it should be i
On 04/05/2012 12:32 PM, Joachim Wieland wrote:
> So here's a pg_dump benchmark from a real world database as requested
> earlier. This is a ~750 GB large 9.0.6 database, and the backup has
> been done over the internal network from a different machine. Both
> machines run Linux.
>
> I am attaching
On Fri, Apr 06, 2012 at 09:21:17AM +0300, Peter Eisentraut wrote:
> On l??r, 2012-03-24 at 10:01 +, Gianni Ciolli wrote:
> > ON (DELETE | UPDATE) actions for EACH foreign keys
> > ==
> >
> > -- --- ---
> >
On 04/05/2012 02:23 PM, Jim Nasby wrote:
If there's a fundamental flaw in how linux deals with heavy writes that
means you can't rely on certain latency windows, perhaps we should be
looking at using a different OS to test those cases...
Performance under this sort of write overload is somethin
On 29 March 2012 21:05, Tom Lane wrote:
> Barring objections I'll go fix this, and then this patch can be
> considered closed except for possible future tweaking of the
> sticky-entry decay rule.
Attached patch fixes a bug, and tweaks sticky-entry decay.
The extant code bumps usage (though not c
Shigeru HANADA writes:
> (2012/04/06 1:29), Tom Lane wrote:
>> The one thing that seems pretty clear from this discussion is that one
>> size doesn't fit all. I think we really ought to provide a hook so that
>> the FDW can determine whether ANALYZE applies to its foreign tables at
>> all, and ho
Excuse me for cutting in,
2012/4/6 Shigeru HANADA :
> To support foreign-table ANALYZE by adding a new hook, we would need a
> mechanism (or at least documented guide lines) to manage the chain of
> hook functions, because such hook might be used by multiple FDWs (or
> other plug-ins) at the same
On 05/04/12 08:02, Boszormenyi Zoltan wrote:
> 2012-04-04 21:30 keltezéssel, Alvaro Herrera írta:
>> I think this patch is doing two things: first touching infrastructure
>> stuff and then adding lock_timeout on top of that. Would it work to
>> split the patch in two pieces?
>>
>
> Sure. Attached
Well, the patent argument, used like this, looks like a wild card, which
can be freely interpreted as a mortal danger for some, and a non-issue for
others. A perfect scare-mongerer.
Quite frankly, I don't buy that one implementation is safer because there
is "Google backing it". I can't think of an
(2012/04/06 1:29), Tom Lane wrote:
> "Albe Laurenz" writes:
>> Maybe the FDW API could be extended so that foreign data wrappers
>> can provide a random sample to avoid a full table scan.
>
> The one thing that seems pretty clear from this discussion is that one
> size doesn't fit all. I think w
On 04/05/2012 05:03 PM, Daniel Farina wrote:
To get to the point, I wonder if it makes sense for someone who has a
better sense a-priori what they're looking for in a committable patch
(i.e. a committer, or someone with a telepathic link to one or more)
to delegate specific pieces of patches for
Greg Smith writes:
> On 04/05/2012 04:27 PM, Simon Riggs wrote:
>> It's shocking since after months of work and an especially extended
>> edition CF, we expect people to deliver something, not just shunt the
>> whole thing off as rejected with 1 days's notice to alter that
>> outcome.
> I don't t
27 matches
Mail list logo
