Hello all,
what I saw on PHP unconference told me that I should ask all again.
I feel lonely. Believe me it is a bad feeling when it seems that nobody has
interests in what you are doing.
Since 4 years I am PostgreSQL representative in SQL Standard committee.
Always, when I suggested to talk
On 16 September 2011 16:24, Susanne Ebrecht susa...@2ndquadrant.com wrote:
Isn't it possible to create a closed mailing list - a list that won't get
published - on which
I can discuss SQL Standard stuff with the folk who wants to support me?
I don't fear to make decisions on my own - but
Fujii Masao masao.fu...@gmail.com writes:
We have three choices. Which do you like the best?
I'm in favor of defining a separate, content-free trigger file to enable
archive recovery. Not sure about the name recovery.ready, though ---
that makes it look like one of the WAL archive transfer
On 16.09.2011 09:24, Susanne Ebrecht wrote:
The next ISO meeting will be soon - and of course there are lots of
drafts that needs
decisions.
I am not allowed to share the drafts in public. Because the drafts are
confidential.
I think that's a big part of the problem. It's hard to get excited
On 15.09.2011 21:46, Alexander Korotkov wrote:
On Thu, Sep 15, 2011 at 7:27 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I've looked at the patch, and took a brief look at the paper - but I still
don't understand the algorithm. I just can't get my head around the concepts
On fre, 2011-09-16 at 01:32 -0400, Tom Lane wrote:
As far as the other issues go, I think there is actually a
prerequisite
discussion to be had here, which is whether we are turning the
recovery
parameters into plain old GUCs or not. If they are plain old GUCs,
then
they will presumably
On fre, 2011-09-16 at 11:54 +0900, Fujii Masao wrote:
#1
Use empty recovery.ready file to enter arhicve recovery. recovery.conf
is not read automatically. All recovery parameters are expected to be
specified in postgresql.conf. If you must specify them in recovery.conf,
you need to add
On Fri, Sep 16, 2011 at 7:24 AM, Susanne Ebrecht
susa...@2ndquadrant.com wrote:
Since 4 years I am PostgreSQL representative in SQL Standard committee.
With respect, I believe you are on the committee as you were an
employee of MySQL. We've had a number of discussions both online and
at one of
On Fri, Sep 16, 2011 at 1:24 AM, Susanne Ebrecht
susa...@2ndquadrant.com wrote:
The next ISO meeting will be soon - and of course there are lots of drafts
that needs
decisions.
So, generally speaking, what kinds of things are going to be brought
up at the ISO meeting? Is this an opportunity
Dave,
On 16.09.2011 14:33, Dave Page wrote:
On Fri, Sep 16, 2011 at 7:24 AM, Susanne Ebrecht
susa...@2ndquadrant.com wrote:
Since 4 years I am PostgreSQL representative in SQL Standard committee.
With respect, I believe you are on the committee as you were an
employee of MySQL.
Nope. As
On Fri, Sep 16, 2011 at 1:43 PM, Susanne Ebrecht
susa...@2ndquadrant.com wrote:
Since 4 years I am PostgreSQL representative in SQL Standard committee.
With respect, I believe you are on the committee as you were an
employee of MySQL.
Nope. As Sun employee - I always was responsible for
Excerpts from Susanne Ebrecht's message of vie sep 16 03:24:58 -0300 2011:
Isn't it possible to create a closed mailing list - a list that won't
get published - on which
I can discuss SQL Standard stuff with the folk who wants to support me?
It's certainly possible to create a private
Heikki,
On 16.09.2011 08:49, Heikki Linnakangas wrote:
Even if you can't share drafts, would it be possible to give a summary
of things that are being discussed in the committee? That way if
there's people in the community with interests in particular topics,
they could contact you and get
hi
On 08/08/2011 07:50 PM, Robert Haas wrote:
On Mon, Aug 8, 2011 at 1:31 PM, Andres Freundand...@anarazel.de wrote:
If its ok I will write a mail to lkml referencing this thread and your numbers
inline (with attribution obviously).
That would be great. Please go ahead.
I've just
On Friday 16 Sep 2011 15:19:07 Andrea Suisani wrote:
hi
On 08/08/2011 07:50 PM, Robert Haas wrote:
On Mon, Aug 8, 2011 at 1:31 PM, Andres Freundand...@anarazel.de wrote:
If its ok I will write a mail to lkml referencing this thread and your
numbers inline (with attribution obviously).
On 15-09-2011 23:54, Fujii Masao wrote:
#1
Use empty recovery.ready file to enter arhicve recovery. recovery.conf
is not read automatically. All recovery parameters are expected to be
specified in postgresql.conf. If you must specify them in recovery.conf,
you need to add include 'recovery.conf'
On 16.09.2011 14:47, Dave Page wrote:
My point remains - Sun were never in a position to say who represents
PostgreSQL.
Dave,
the procedure works different. The country representation ask for you.
Because you represent your product on one side - but you also represent
your country.
For
On Fri, Sep 16, 2011 at 8:47 AM, Susanne Ebrecht
susa...@2ndquadrant.com wrote:
On 16.09.2011 14:47, Dave Page wrote:
My point remains - Sun were never in a position to say who represents
PostgreSQL.
Dave,
the procedure works different. The country representation ask for you.
Because you
On 16-09-2011 10:26, Susanne Ebrecht wrote:
On 16.09.2011 08:49, Heikki Linnakangas wrote:
Even if you can't share drafts, would it be possible to give a summary of
things that are being discussed in the committee? That way if there's people
in the community with interests in particular
That also holds the plan's output tuple descriptor. If you tried to
remove it, I think the ExecAssignResultTypeFromTL call would crash.
And if you removed *that*, upper nodes would get unhappy, cf
ExecGetResultType.
Yes, this is true. However upper nodes doesn't need in all cases, so is it
That also holds the plan's output tuple descriptor. If you tried to
remove it, I think the ExecAssignResultTypeFromTL call would crash.
And if you removed *that*, upper nodes would get unhappy, cf
ExecGetResultType.
Yes, this is true. However upper nodes doesn't need in all cases, so is it
On 16.09.2011 14:38, Merlin Moncure wrote:
So, generally speaking, what kinds of things are going to be brought
up at the ISO meeting? Is this an opportunity to get postgres special
syntax drafted into the sql standard?
Yes and no.
You first need to convince your country and then - as
On 16.09.2011 15:59, Dave Page wrote:
other plans less than 2 years ago. For me, a representative would have
been reporting back to us after each meeting, and discussing points to
raise before each meeting - not working in isolation, without the
knowledge of others.
Dave,
I exactly did this
While testing 9.1 RPMs on Fedora 15 (2.6.40 kernel), I notice
messages like these in the kernel log:
Sep 11 13:38:56 rhl kernel: [ 415.308092] postgres (18040):
/proc/18040/oom_adj is deprecated, please use /proc/18040/oom_score_adj instead.
These don't show up on every single PG process
On Fri, Sep 16, 2011 at 9:49 AM, Susanne Ebrecht
susa...@2ndquadrant.com wrote:
On 16.09.2011 15:59, Dave Page wrote:
other plans less than 2 years ago. For me, a representative would have
been reporting back to us after each meeting, and discussing points to
raise before each meeting - not
On Fri, Sep 16, 2011 at 3:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Does anyone want
to argue for doing something more complicated, and if so what exactly?
Well there's no harm trying to write to oom_score_adj and if that
fails with EEXISTS trying to write to oom_adj.
--
greg
--
Sent via
Greg Stark st...@mit.edu writes:
On Fri, Sep 16, 2011 at 3:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Does anyone want
to argue for doing something more complicated, and if so what exactly?
Well there's no harm trying to write to oom_score_adj and if that
fails with EEXISTS trying to write to
Excerpts from Tom Lane's message of vie sep 16 13:37:46 -0300 2011:
Greg Stark st...@mit.edu writes:
On Fri, Sep 16, 2011 at 3:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Does anyone want
to argue for doing something more complicated, and if so what exactly?
Well there's no harm trying
Alvaro Herrera alvhe...@commandprompt.com writes:
Now the problem is that we have defined the LINUX_OOM_ADJ symbol as
meaning the value we're going to write. Maybe this wasn't the best
choice. I mean, it's very flexible, but it doesn't seem to offer any
benefit over a plain boolean choice.
Hi,
On Friday 16 Sep 2011 17:36:20 Matthew Wilcox wrote:
On Fri, Sep 16, 2011 at 04:16:49PM +0200, Andres Freund wrote:
I sent an email containing benchmarks from Robert Haas regarding the
Subject. Looking at lkml.org I can't see it right now, Will recheck when
I am at home.
He
Excerpts from Andres Freund's message of vie sep 16 14:27:33 -0300 2011:
Hi,
On Friday 16 Sep 2011 17:36:20 Matthew Wilcox wrote:
Does the query planner need to know the exact number of bytes in the file,
or is it after an order-of-magnitude? Or to-the-nearest-gigabyte?
It depends on
On Fri, Sep 16, 2011 at 10:37, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@mit.edu writes:
On Fri, Sep 16, 2011 at 3:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Does anyone want
to argue for doing something more complicated, and if so what exactly?
Well there's no harm trying to write
Jeff Davis pg...@j-davis.com writes:
On Wed, 2011-06-08 at 17:29 -0500, Kevin Grittner wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
AFAICS, the check for page lock is actually unnecessary.
Absolutely correct. Patch attached.
I like the change, but the comment is
I'm in favor of defining a separate, content-free trigger file to
enable
archive recovery. Not sure about the name recovery.ready, though
---
that makes it look like one of the WAL archive transfer trigger
files,
which does not seem like a great analogy. The pg_standby
documentation
Shigeru Hanada shigeru.han...@gmail.com writes:
(2011/09/09 0:47), Kohei Kaigai wrote:
makeString() does not copy the supplied string itself, so it is not
preferable to reference
NameStr(attr-attname) across ReleaseSysCache().
Oops, fixed.
[ I should check some of my projects for this
On Friday, September 16, 2011 10:08:17 PM Benjamin LaHaise wrote:
On Fri, Sep 16, 2011 at 07:27:33PM +0200, Andres Freund wrote:
many tuples does the table have. Those statistics are only updated every
now and then though.
So it uses those old stats to check how many tuples are normally
On Friday, September 16, 2011 11:02:38 PM Andres Freund wrote:
Also with fstat() instead of lseek() there was no bottleneck anymore, so I
don't think the benefits would warrant that.
At least thats what I observed on a 4 x 6 machine without the patch applied
(can't reboot it). That shouldn't
On Fri, Sep 16, 2011 at 9:08 PM, Benjamin LaHaise b...@kvack.org wrote:
For such tables, can't Postgres track the size of the file internally? I'm
assuming it's keeping file descriptors open on the tables it manages, in
which case when it writes to a file to extend it, the internally stored
Pavel Stehule pavel.steh...@gmail.com writes:
this patch significantly reduce a ccache searching.
I looked at this patch a little bit. It's got a very serious problem:
it supposes that the parent of an ARRAYELEM datum must be a VAR datum,
which is not so. As an example, it gets an Assert
One other thing we're interested in is portability. I mean, even if
Linux were to introduce a new hypothetical syscall that was able to
return the file size at a ridiculously low cost, we probably wouldn't
use it because it'd be Linux-specific. So an improvement of lseek()
seems to be the
On Fri, Sep 16, 2011 at 04:16:49PM +0200, Andres Freund wrote:
I sent an email containing benchmarks from Robert Haas regarding the Subject.
Looking at lkml.org I can't see it right now, Will recheck when I am at home.
He replaced lseek(SEEK_END) with fstat() and got speedups up to 8.7 times
41 matches
Mail list logo
