Fujii Masao 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 trigger files,
which do
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 a
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 concept
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 presuma
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 "i
On Fri, Sep 16, 2011 at 7:24 AM, Susanne Ebrecht
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 the more recent develo
On Fri, Sep 16, 2011 at 1:24 AM, Susanne Ebrecht
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 to get postgres specia
Dave,
On 16.09.2011 14:33, Dave Page wrote:
On Fri, Sep 16, 2011 at 7:24 AM, Susanne Ebrecht
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 wa
On Fri, Sep 16, 2011 at 1:43 PM, Susanne Ebrecht
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 taking care of
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 mai
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 i
hi
On 08/08/2011 07:50 PM, Robert Haas wrote:
On Mon, Aug 8, 2011 at 1:31 PM, Andres Freund 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 stumbled across this threa
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 Freund 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 examp
On Fri, Sep 16, 2011 at 8:47 AM, Susanne Ebrecht
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 represent yo
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 topics,
> 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 i
> 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
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 country
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 wi
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 launch
On Fri, Sep 16, 2011 at 9:49 AM, Susanne Ebrecht
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 working in isola
On Fri, Sep 16, 2011 at 3:57 PM, Tom Lane 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 pgsql-hackers mai
Greg Stark writes:
> On Fri, Sep 16, 2011 at 3:57 PM, Tom Lane 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.
Well, (1) what
Excerpts from Tom Lane's message of vie sep 16 13:37:46 -0300 2011:
> Greg Stark writes:
> > On Fri, Sep 16, 2011 at 3:57 PM, Tom Lane 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
Alvaro Herrera 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.
> Is your proposal to c
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.
> >
> >
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 Fri, Sep 16, 2011 at 10:37, Tom Lane wrote:
> Greg Stark writes:
>> On Fri, Sep 16, 2011 at 3:57 PM, Tom Lane 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
Jeff Davis writes:
> On Wed, 2011-06-08 at 17:29 -0500, Kevin Grittner wrote:
>> Heikki Linnakangas wrote:
>>> AFAICS, the check for page lock is actually unnecessary.
>> Absolutely correct. Patch attached.
> I like the change, but the comment is slightly confusing.
I've committed this patch
> 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
> document
Shigeru Hanada 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 issue... ]
I've co
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 normal
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 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 size
> could b
Pavel Stehule 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 failure on this:
create ta
> 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 t
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 ti
39 matches
Mail list logo