On Fri, Aug 27, 2010 at 9:49 PM, Tom Lane wrote:
> Robert Haas writes:
>> What's a bit odd about this is that I do get warnings for this kind of
>> thing in general, which get turned into errors since I compile with
>> -Werror; and in fact the version of the patch that I committed has no
>> fewer
Robert Haas writes:
> What's a bit odd about this is that I do get warnings for this kind of
> thing in general, which get turned into errors since I compile with
> -Werror; and in fact the version of the patch that I committed has no
> fewer than four places where there is a comment that says "pl
On Sat, Aug 28, 2010 at 2:26 AM, Tom Lane wrote:
> That gets in the way of our plan for world domination,
> no? If you can't have a PG sitting unobtrusively in the background,
> waiting for you to have a need for it, it won't get installed in the
> first place. People will pick mysql, or someth
On Fri, Aug 27, 2010 at 9:35 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Didn't we inject some smarts so that the compiler would notice that
>> elog(ERROR) doesn't return?
>
> No. If you know a portable (as in "works on every compiler") way
> to do that, we could talk. If only some compiler
Alvaro Herrera writes:
> Didn't we inject some smarts so that the compiler would notice that
> elog(ERROR) doesn't return?
No. If you know a portable (as in "works on every compiler") way
to do that, we could talk. If only some compilers understand it,
we'll probably end up worse off --- the on
Excerpts from Robert Haas's message of vie ago 27 18:07:55 -0400 2010:
> On Fri, Aug 27, 2010 at 5:57 PM, Kevin Grittner
> wrote:
> > Robert Haas wrote:
> >> I suppose this is unhappy because it things elog(ERROR) might
> >> return?
> >
> > If I set these fields right in front of the elog(ERROR)
Greg Smith writes:
> Tom Lane wrote:
>> Well, yes they are. They cause unnecessary process wakeups and thereby
>> consume cycles even when the database is idle. See for example a
>> longstanding complaint here:
>> https://bugzilla.redhat.com/show_bug.cgi?id=252129
> ... The only clear case whe
Robert Haas writes:
> On Fri, Aug 27, 2010 at 5:54 PM, Greg Smith wrote:
>> The way the background writer wakes up periodically to absorb fsync requests
>> is already way too infrequent on a busy system.
> Maybe instead of a fixed-duration sleep we could wake it up when it
> needs to do somethin
On Fri, Aug 27, 2010 at 5:54 PM, Greg Smith wrote:
> Tom Lane wrote:
>>
>> Well, yes they are. They cause unnecessary process wakeups and thereby
>> consume cycles even when the database is idle. See for example a
>> longstanding complaint here:
>> https://bugzilla.redhat.com/show_bug.cgi?id=252
Robert Haas wrote:
> I set them right after the ERROR so that those statements needn't
> actually be executed.
Good thinking.
I checked and that also eliminates the warnings for me. (No
surprise there, of course.)
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
On Fri, Aug 27, 2010 at 5:57 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> I suppose this is unhappy because it things elog(ERROR) might
>> return?
>
> If I set these fields right in front of the elog(ERROR) the warnings
> go away for me. (Hopefully this observation will make up, to some
> e
Kevin Grittner wrote:
I actually understood that part, but was already wondering if it
could be bent to slightly different purposes. It seems as though
there would be value to using it to evaluate the performance impact
of a proposed patch, at least on a limited basis, *before* a commit
Eventu
Robert Haas wrote:
> I suppose this is unhappy because it things elog(ERROR) might
> return?
If I set these fields right in front of the elog(ERROR) the warnings
go away for me. (Hopefully this observation will make up, to some
extent, for my earlier brain fart.)
-Kevin
--
Sent via pgsql-
Tom Lane wrote:
Well, yes they are. They cause unnecessary process wakeups and thereby
consume cycles even when the database is idle. See for example a
longstanding complaint here:
https://bugzilla.redhat.com/show_bug.cgi?id=252129
If we're going to go to the trouble of having a mechanism like
Robert Haas wrote:
> OK, I must be missing something. Go through that a little slower?
No, my mistake. Please ignore.
I am getting the same warnings, but I think your take on the cause
must be right.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Fri, Aug 27, 2010 at 5:35 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> I suppose this is unhappy because it things elog(ERROR) might
>> return?
>
> It looks more like this code uses it without initialization:
>
> case OBJECT_INDEX:
> case OBJECT_SEQUENCE:
> case OBJEC
Robert Haas wrote:
> I suppose this is unhappy because it things elog(ERROR) might
> return?
It looks more like this code uses it without initialization:
case OBJECT_INDEX:
case OBJECT_SEQUENCE:
case OBJECT_TABLE:
case OBJECT_VIEW:
relation =
On Fri, Aug 27, 2010 at 4:16 PM, Peter Eisentraut wrote:
> On fre, 2010-08-27 at 07:49 -0400, Robert Haas wrote:
>> Anyway, committed.
>
> I suppose this is responsible for this:
>
> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Wendif-labels -fno-strict-alias
On Fri, Aug 27, 2010 at 2:17 PM, Markus Wanner wrote:
>> In addition, it means that maximum_message_queue_size_per_backend (or
>> whatever it's called) can be changed on-the-fly; that is, it can be
>> PGC_SIGHUP rather than PGC_POSTMASTER.
>
> That's certainly a point. However, as you are proposin
Alanoly Andrews writes:
> I have tried all the LIBPATH's that you suggested. Besides, I don't
> think the problem is that postgres cannot find the "libpqwalreceiver"
> library. It does find it, but crashes on loading it.
I thought the point of Steve's remarks was that it might be loading
the wron
On fre, 2010-08-27 at 07:49 -0400, Robert Haas wrote:
> Anyway, committed.
I suppose this is responsible for this:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing
-fwrapv -g -Werror -Wno-inline -I../../../src/include -D_GNU_SOUR
Magnus Hagander writes:
> On Fri, Aug 27, 2010 at 21:30, Tom Lane wrote:
>> OK, the list works now, but the commitdiff links in the messages do
>> not. Looks like they are pointing at the wrong repository.
> Well, actually, they point to the right one, but the mirroring off to
> that one is tur
Steve,
I have tried all the LIBPATH's that you suggested. Besides, I don't think the
problem is that postgres cannot find the "libpqwalreceiver" library. It does
find it, but crashes on loading it. See below a repeat of the copy and paste
from my first post, showing the sequence just before the
Alanoly Andrews wrote:
Fujii,
All my tests so far were done on "clean" installs. Every version I tested on,
beta2 through beta4, was compiled and installed in different and unique directories.
Regards.
Alanoly,
If you do an
export LIBPATH=/apps/pg_9.0_b4/lib
before starting postgres on the
On Fri, Aug 27, 2010 at 21:30, Tom Lane wrote:
> Magnus Hagander writes:
>> On Fri, Aug 27, 2010 at 20:29, Tom Lane wrote:
>>> Hm, is the pgsql-committers-test thing actually working?
>
>> Um, it seems the list is broken somehow.
>
> OK, the list works now, but the commitdiff links in the messag
Fujii,
All my tests so far were done on "clean" installs. Every version I tested on,
beta2 through beta4, was compiled and installed in different and unique
directories.
Regards.
Alanoly.
-Original Message-
From: Fujii Masao [mailto:masao.fu...@gmail.com]
Sent: Thursday, August 26, 2
Magnus Hagander writes:
> On Fri, Aug 27, 2010 at 20:29, Tom Lane wrote:
>> Hm, is the pgsql-committers-test thing actually working?
> Um, it seems the list is broken somehow.
OK, the list works now, but the commitdiff links in the messages do
not. Looks like they are pointing at the wrong rep
"Marc G. Fournier" writes:
> should be fixed ...
Ah, now I got something. Thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
should be fixed ...
On Fri, 27 Aug 2010, Magnus Hagander wrote:
On Fri, Aug 27, 2010 at 20:29, Tom Lane wrote:
Magnus Hagander writes:
... This is all available for testing now.
Marc has set up a mailinglist at pgsql-committers-t...@postgresql.org where
commit messages from the new syst
looking into it ...
On Fri, 27 Aug 2010, Magnus Hagander wrote:
On Fri, Aug 27, 2010 at 20:29, Tom Lane wrote:
Magnus Hagander writes:
... This is all available for testing now.
Marc has set up a mailinglist at pgsql-committers-t...@postgresql.org where
commit messages from the new syst
On Fri, Aug 27, 2010 at 20:29, Tom Lane wrote:
> Magnus Hagander writes:
>> ... This is all available for testing now.
>
>> Marc has set up a mailinglist at pgsql-committers-t...@postgresql.org where
>> commit messages from the new system is sent. If you care about what they look
>> like, subscri
Magnus Hagander writes:
> ... This is all available for testing now.
> Marc has set up a mailinglist at pgsql-committers-t...@postgresql.org where
> commit messages from the new system is sent. If you care about what they look
> like, subscribe there and wait for one to show up :-) Subscription i
Hi,
On 08/26/2010 11:57 PM, Robert Haas wrote:
It wouldn't require you to preallocate a big chunk of shared memory
Agreed, you wouldn't have to allocate it in advance. We would still want
a configurable upper limit. So this can be seen as another approach for
an implementation of a dynamic a
Josh Berkus writes:
> Should we hold off on RC1 for this issue?
rc1 was already wrapped yesterday.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hack
On 8/27/10 10:17 AM, Fujii Masao wrote:
> On Sat, Aug 28, 2010 at 2:08 AM, Tom Lane wrote:
>> Fujii Masao writes:
>>> On Fri, Aug 27, 2010 at 11:25 PM, Heikki Linnakangas
>>> wrote:
Hmm, agreed, seems like an oversight in hot standby. Before that, we didn't
update pg_subtrans during re
On Sat, Aug 28, 2010 at 2:08 AM, Tom Lane wrote:
> Fujii Masao writes:
>> On Fri, Aug 27, 2010 at 11:25 PM, Heikki Linnakangas
>> wrote:
>>> Hmm, agreed, seems like an oversight in hot standby. Before that, we didn't
>>> update pg_subtrans during recovery, so there was no point truncating it. Bu
Fujii Masao writes:
> On Fri, Aug 27, 2010 at 11:25 PM, Heikki Linnakangas
> wrote:
>> Hmm, agreed, seems like an oversight in hot standby. Before that, we didn't
>> update pg_subtrans during recovery, so there was no point truncating it. But
>> in hot standby, we do update it, so we need to trun
Heikki Linnakangas writes:
> Ok. If we have to, we can keep that, it just requires more
> programming. After searching for a \n, we can peek at the previous byte to
> check if it's a backslash (and if it is, the one before that to see if it's
> a backslash too, and so forth until we find a non-bac
On Fri, Aug 27, 2010 at 11:25 PM, Heikki Linnakangas
wrote:
> Hmm, agreed, seems like an oversight in hot standby. Before that, we didn't
> update pg_subtrans during recovery, so there was no point truncating it. But
> in hot standby, we do update it, so we need to truncate it too.
Yes. The attac
On 27/08/10 16:39, Fujii Masao wrote:
I received the off-list email reporting that pg_subtrans keeps bloating up
in the standby, from Harald (Thanks!). I investigated this issue and found
that the standby doesn't truncate pg_subtrans at all even though HS keeps
extending it. In the master, a chec
Hi,
I received the off-list email reporting that pg_subtrans keeps bloating up
in the standby, from Harald (Thanks!). I investigated this issue and found
that the standby doesn't truncate pg_subtrans at all even though HS keeps
extending it. In the master, a checkpoint calls TruncateSUBTRANS() and
2010/8/25 KaiGai Kohei :
> 7. I think we need to write and include in the fine documentation some
> "big picture" documentation about enhanced security providers. Of
> course, we have to decide what we want to say. But the SECURITY LABEL
> documentation is just kind of hanging out t
On Fri, Aug 27, 2010 at 12:52 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Aug 19, 2010 at 3:34 PM, Tom Lane wrote:
>>> Robert Haas writes:
Any other kibitzing before I commit this?
>>>
>>> Sure ...
>>>
>>> [kibitzing]
>
>> v4.
>
> For my money, you could just have said "Applied wi
On 27/08/10 10:39, Fujii Masao wrote:
On Thu, Aug 26, 2010 at 7:40 PM, Heikki Linnakangas
wrote:
There's two kinds of latches, local and global. Local latches can only be
set from the same process - allowing you to replace pg_usleep() with
something that is always interruptible by signals (by
On Thu, Aug 26, 2010 at 7:40 PM, Heikki Linnakangas
wrote:
> Here's a first attempt at implementing that. To demonstrate how it works, I
> modified walsender to use the new latch facility, also to respond quickly to
> SIGHUP and SIGTERM.
Great!
> There's two kinds of latches, local and global. L
45 matches
Mail list logo
