2010/11/5 Shigeru HANADA :
> On Fri, 5 Nov 2010 16:27:49 +0900
> Itagaki Takahiro wrote:
>> PL/Proxy has a similar functionality with RUN ON ALL to start queries
>> in parallel. So, I think it's a infrastructure commonly required.
> I noticed the lack of consideration about cache invalidation from
On 06.11.2010 00:39, Tom Lane wrote:
Andrew Dunstan writes:
On 11/05/2010 05:45 PM, Tom Lane wrote:
Anyway, what this points up is that we are making a very conservative
assumption about what to do when getrlimit() returns RLIM_INFINITY.
It does not seem real reasonable to interpret that as 10
A customer of ours is quite bothered about finding zero pages in an index
after
a system crash. The task now is to improve the diagnosability of such an
issue
and be able to definitively point to the source of zero pages.
The proposed solution below has been vetted in-house at EnterpriseDB and am
On Fri, Nov 05, 2010 at 09:01:50PM -0400, Robert Haas wrote:
> On Fri, Nov 5, 2010 at 4:02 PM, Tom Lane wrote:
> > The latter is an intentional security feature and will not get changed.
>
> I see that there could be a problem here with SECURITY DEFINER
> functions, but I'm not clear whether it g
On ons, 2010-11-03 at 16:34 +0200, Peter Eisentraut wrote:
> On tis, 2010-11-02 at 10:21 -0400, Tom Lane wrote:
> > Do we have a handle on how many buildfarm members this will break?
>
> I suppose we don't. One way to find out would be to commit just this
> bit
>
> +# We need the $(eval) functio
On 6 November 2010 05:46, Josh Berkus wrote:
> I'm continuing in my efforts now to document how to deploy and manage
> replication on our wiki. One of the things a DBA needs to do is to use
> pg_current_xlog_location() (and related functions) to check how far
> behind the master the standby is.
>
Do you think now patch is ready for committer or it require further review
by you or somebody else?
With best regards,
Alexander Korotkov.
Is there any way to have the database tell you if a particular SQL function can
be inlined?
--
Jim C. Nasby, Database Architect j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
Alexander Korotkov wrote:
Do you think now patch is ready for committer or it require further
review by you or somebody else?
It's probably ready for committer, however the code now doesn't mention
any reference or bit of information that it is faster than the original
one. I was wondering how
Hitoshi Harada writes:
> And if we really make this async query come true, I suggest designing
> resource (i.e. remote connection) management very carefully. When the
> executor fails in the middle of its execution, it possibly fails to
> release its own resource; close() in ExecutorEnd() will nev
Since we now install PL/pgSQL by default, should we configure
shared_preload_libraries to preload PL/pgSQL?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hacker
Martijn van Oosterhout writes:
> On Fri, Nov 05, 2010 at 09:01:50PM -0400, Robert Haas wrote:
>> I see that there could be a problem here with SECURITY DEFINER
>> functions, but I'm not clear whether it goes beyond that?
> IIRC correctly it's because even unpriveledged users can make things in
>
Gurjeet Singh writes:
> .) The basic idea is to have a magic number in every PageHeader before it is
> written to disk, and check for this magic number when performing page
> validity
> checks.
Um ... and exactly how does that differ from the existing behavior?
> .) To avoid adding a new field t
Jim Nasby writes:
> Is there any way to have the database tell you if a particular SQL function
> can be inlined?
Easiest way is to EXPLAIN a query using it and see if it did get inlined.
For example,
regression=# create function foo(int) returns int as
regression-# 'select $1 + 1' language sql
Bruce Momjian writes:
> Since we now install PL/pgSQL by default, should we configure
> shared_preload_libraries to preload PL/pgSQL?
I don't think that follows. The fact that it's there doesn't mean
everyone is using it. In any case, I've seen no evidence that says
you'd get a performance win
Peter Eisentraut has suggested that we should run "make -k" instead of
plain "make" for most or all of the buildfarm steps. This flag
essentially instructs make to keep going rather than fail at the first
error. We haven't done that for the last five or six years that the
buildfarm has been r
On Fri, Nov 5, 2010 at 5:16 AM, Pavel Stehule wrote:
> 2010/11/4 Daniele Varrazzo :
>> Just wanted to warn you that I have implemented the 2pc protocol in psycopg.
>
> I read a notice, but I didn't find a link for download, where is it, please?
We have just released a beta package including this
Hannu Krosing writes:
> To make pg_basebackup.py self-sufficient it should also open 2nd
> connection to the same master and make sure that all WAL files are
> copied for the duration of base copy.
Excellent idea, will make that happen soon'ish.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.f
Andrew Dunstan writes:
> Peter Eisentraut has suggested that we should run "make -k" instead of
> plain "make" for most or all of the buildfarm steps. This flag
> essentially instructs make to keep going rather than fail at the first
> error. We haven't done that for the last five or six years
On Sat, Nov 6, 2010 at 11:36 AM, Tom Lane wrote:
> Martijn van Oosterhout writes:
>> On Fri, Nov 05, 2010 at 09:01:50PM -0400, Robert Haas wrote:
>>> I see that there could be a problem here with SECURITY DEFINER
>>> functions, but I'm not clear whether it goes beyond that?
>
>> IIRC correctly it
On Fri, Nov 05, 2010 at 01:39:07PM -0700, Josh Berkus wrote:
>
> > Of course, there are containers too, which are not in your list at all.
> > How do you intend to represent the tree-ish structure in a flat table?
>
> Andrew: we'll use a proximity tree.
Adjacency list?
If so, in my experience,
Sergey was kind enough to lend me use of buildfarm member dugong
(IA64, Debian Etch) so I could poke into why its behavior in the
recursion-related regression tests was so odd. I had previously
tried and failed to reproduce the behavior on a Red Hat IA64 test
machine (running RHEL of course) so I
Robert Haas writes:
> On Sat, Nov 6, 2010 at 11:36 AM, Tom Lane wrote:
>> Yeah, we changed that behavior as part of the fix for CVE-2007-2138.
>> You'd need either SECURITY DEFINER functions or very careless use of
>> SET ROLE/SET SESSION AUTHORIZATION for the issue to be exploitable.
> Would it
On Sat, 2010-11-06 at 18:02 +0100, Dimitri Fontaine wrote:
> Hannu Krosing writes:
> > To make pg_basebackup.py self-sufficient it should also open 2nd
> > connection to the same master and make sure that all WAL files are
> > copied for the duration of base copy.
>
> Excellent idea, will make th
On Nov 5, 2010, at 1:42 PM, David E. Wheeler wrote:
>> http://git.postgresql.org/gitweb?p=postgresql.git;a=blob;f=src/backend/commands/explain.c;h=f494ec98e510c23120e072bd5ee8821ea12738a4;hb=HEAD#l617
>
> Ah, great, thanks.
So based on this, I've come up with:
"Node Type" TEXT,
On 11/06/2010 01:07 PM, Tom Lane wrote:
What I *have* occasionally
wished for is that the buildfarm script would act more like make -k with
respect to the various test stages. That is, not abandon the whole test
after one stage fails, but allow stages that don't logically depend on
the failed
Andrew Dunstan writes:
> On 11/06/2010 01:07 PM, Tom Lane wrote:
>> What I *have* occasionally
>> wished for is that the buildfarm script would act more like make -k with
>> respect to the various test stages.
> I'm not sure that would be a great advance. Certainly, right now I'm
> going to be p
I'm gradually slogging my way through the KNNGIST patches which were
posted here:
http://archives.postgresql.org/pgsql-hackers/2010-07/msg01183.php
I have a couple of conceptual questions.
1. Is KNNGIST intended to work if there's more than one pathkey? If
so, how? Example:
SELECT * FROM tab
On Sat, Nov 6, 2010 at 1:43 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Nov 6, 2010 at 11:36 AM, Tom Lane wrote:
>>> Yeah, we changed that behavior as part of the fix for CVE-2007-2138.
>>> You'd need either SECURITY DEFINER functions or very careless use of
>>> SET ROLE/SET SESSION AUT
Robert Haas writes:
> I guess. If you search pg_temp always then it's pretty much
> impossible to avoid having a security hole, if you use any non-trivial
> SQL. But if you search pg_temp for non-SD only then you'll only have
> a security hole if you assume (presumably without testing) that the
On Sat, Nov 6, 2010 at 5:34 PM, Tom Lane wrote:
> As I said above, I don't know of any good way to measure register stack
> depth directly. It's probably possible to find out by asking the kernel
> or something like that, but we surely do not want to introduce a kernel
> call into check_stack_dep
Greg Stark writes:
> On Sat, Nov 6, 2010 at 5:34 PM, Tom Lane wrote:
>> As I said above, I don't know of any good way to measure register stack
>> depth directly. It's probably possible to find out by asking the kernel
>> or something like that, but we surely do not want to introduce a kernel
>>
Greg Stark writes:
> It seems more likely it would be some kind of asm than a trap.
I seem to be getting plausible results from this bit of crockery:
#include
static __inline__ void *
get_bsp(void)
{
void *ret;
#ifndef __INTEL_COMPILER
__asm__ __volatile__(
";;\n
On Nov 6, 2010, at 11:44 AM, David E. Wheeler wrote:
> On Nov 5, 2010, at 1:42 PM, David E. Wheeler wrote:
>
>>> http://git.postgresql.org/gitweb?p=postgresql.git;a=blob;f=src/backend/commands/explain.c;h=f494ec98e510c23120e072bd5ee8821ea12738a4;hb=HEAD#l617
>>
>> Ah, great, thanks.
>
> So base
Hannu Krosing writes:
>> > To make pg_basebackup.py self-sufficient it should also open 2nd
>> > connection to the same master and make sure that all WAL files are
>> > copied for the duration of base copy.
Done now, please have a look and try it if possible:
https://github.com/dimitri/pg_base
On Fri, Oct 29, 2010 at 6:17 AM, Robert Haas wrote:
> On Fri, Oct 29, 2010 at 2:58 AM, Itagaki Takahiro
> wrote:
>> On Fri, Oct 29, 2010 at 3:23 PM, Heikki Linnakangas
>> wrote:
>>> Simon's argument in the thread that the todo item points to
>>> (http://archives.postgresql.org/pgsql-patches/2008
I wrote:
> I don't know why icc is so much worse than gcc on this measure of
> stack depth consumption, but clearly the combination of that and
> the 100kB max_stack_depth explains why dugong is failing to do
> very many levels of recursion before erroring out.
I figured out why icc looked so much
On 11/06/2010 07:35 AM, Peter Eisentraut wrote:
So far, two machines have reported an older make version:
dawn_bat
narwhal
both of the mingw type. Andrew, Dave, could you see about upgrading the
GNU make installation there?
dawn_bat is done.
cheers
andrew
--
Sent via pgsql-hackers mail
On Sat, Nov 6, 2010 at 7:25 PM, Jeff Janes wrote:
>> There are really two separate things here:
>>
>> (1) trying to do all the writes to file A before you start doing
>> writes to file B, and
>> (2) trying to write out blocks to each file in ascending logical block
>> number order
>>
>> I'm much m
On Sat, Nov 6, 2010 at 8:01 PM, Tom Lane wrote:
> I wrote:
>> I don't know why icc is so much worse than gcc on this measure of
>> stack depth consumption, but clearly the combination of that and
>> the 100kB max_stack_depth explains why dugong is failing to do
>> very many levels of recursion bef
On Fri, Nov 5, 2010 at 7:49 PM, Daniel Farina wrote:
> On Fri, Nov 5, 2010 at 4:20 PM, Robert Haas wrote:
>> Can you give us a self-contained example of the problem you're talking about?
>
> Sure. Consider the following:
>
> CREATE TABLE t1 (
> id integer PRIMARY KEY
> );
>
> CREATE TABLE t2 (
On Sat, Nov 6, 2010 at 6:09 PM, Robert Haas wrote:
> If we're going to try to fix this, we probably ought to try to make
> sure that we are fixing it fairly completely. How confident are you
> that this is the only problem?
I haven't tried to isolate problems on really complicated schemas yet,
b
On Sat, Nov 6, 2010 at 11:48 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > .) The basic idea is to have a magic number in every PageHeader before it
> is
> > written to disk, and check for this magic number when performing page
> > validity
> > checks.
>
> Um ... and exactly how does that diff
On Sun, Nov 7, 2010 at 4:23 AM, Gurjeet Singh wrote:
> I understand that it is a pretty low-level change, but IMHO the change is
> minimal and is being applied in well understood places. All the assumptions
> listed have been effective for quite a while, and I don't see these
> assumptions being a
44 matches
Mail list logo
