Robert Haas wrote:
> I've realized another problem with this patch. standby_keep_segments
> only controls the number of segments that we keep around for purposes
> of streaming: it doesn't affect archiving at all. And of course, a
> standby server based on archiving is every bit as much of a stan
Tom Lane wrote:
> Robert Haas writes:
>> So you'd prefer a message that is sometimes flat-out wrong over a
>> message that is correct but less informative in the common case? I
>> guess that could be right call, but it's not what I'd pick.
>
> Well, as I said, I think the only way to really impr
Robert Haas writes:
> So you'd prefer a message that is sometimes flat-out wrong over a
> message that is correct but less informative in the common case? I
> guess that could be right call, but it's not what I'd pick.
Well, as I said, I think the only way to really improve this message
is to us
Bruce Momjian wrote:
http://wiki.postgresql.org/wiki/User:Simon
Well, unless Simon wants to keep it for some reason, it should be
removed, and if kept, renamed. Simon?
I already retitled the copy left on the personal page and deleted the
one that was causing the confusion. I doubt anyone
Greg Smith wrote:
> Bruce Momjian wrote:
> > What is "Prioritised" Todo? It looks like a copy of the TODO list that
> > was created on March 23, 2010, and only you and Simon have modified it:
> >
> >
> > http://wiki.postgresql.org/index.php?title=Prioritised_Todo&action=history
> >
>
> We
Bruce Momjian wrote:
What is "Prioritised" Todo? It looks like a copy of the TODO list that
was created on March 23, 2010, and only you and Simon have modified it:
http://wiki.postgresql.org/index.php?title=Prioritised_Todo&action=history
Well, the updates I made to that one were
On Wed, Apr 14, 2010 at 11:15 PM, Magnus Hagander wrote:
>> http://archives.postgresql.org/pgsql-hackers/2010-04/msg00077.php
>>> As for the code itself, don't we need a CHECK_FOR_INTERRUPTS in there
>>> for it to be actually useful?
>>
>> Since the backend version of select() receives any incomin
On Wed, Apr 14, 2010 at 10:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> OK, how about "connection not authorized by pg_hba.conf"?
>
> This is still not especially helpful for novice DBAs. We want to point
> them in the direction that they need to add an entry to pg_hba.conf,
> which is 99% li
Kevin Grittner wrote:
> Koichi Suzuki wrote:
> > 2010/4/14 Simon Riggs :
>
> >> It would be a very useful test case to publish.
>
> > I'm still struggling to generate remaing WAL records.
>
> Sure, but when you've got it all, please share. I'd like to see us
> have a much larger set of test
Robert Haas writes:
> OK, how about "connection not authorized by pg_hba.conf"?
This is still not especially helpful for novice DBAs. We want to point
them in the direction that they need to add an entry to pg_hba.conf,
which is 99% likely to be what's wanted. The current wording provides
that
Magnus Hagander writes:
> Looking at the call-sites, there are bugs now - if PQexec() returns
> NULL, we don't deal with it. It also doesn't always free the result
> properly. I've added checks for that.
I think you're just adding useless complexity there. PQresultStatus
defends itself just fine
On Tue, Apr 13, 2010 at 11:56 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> On Mon, Apr 12, 2010 at 6:41 AM, Heikki Linnakangas
>> wrote:
Why is standby_keep_segments used even if max_wal_senders is zero?
In that case, ISTM we don't need to keep any WAL files in pg_xlog
for
Magnus Hagander writes:
> On Wed, Apr 7, 2010 at 21:01, Tom Lane wrote:
>> ... lack either the note about defaulting to GMT or the hint. I guess
>> we should add both of those to the failure cases in the Windows version
>> of identify_system_timezone. Should we also change the WARNING errlevel
Greg Smith wrote:
> Josh Kupershmidt wrote:
> > FWIW, I'm not religious about psql's formatting; I'd be happy with
> > this information being displayed only for \d+, in whatever form makes
> > folks happy.
> >
> > I unfortunately don't have much time to try a patch myself at the moment :(
> >
>
On Tue, Apr 13, 2010 at 03:03:58PM -0400, Tom Lane wrote:
> Joachim Wieland writes:
> > If we still cannot do this, then what I am asking is: What does the
> > project need to be able to at least link against such a compression
> > algorithm?
>
> Well, what we *really* need is a convincing argume
[ back to this... ]
Magnus Hagander writes:
> On Wed, Apr 7, 2010 at 21:06, Tom Lane wrote:
>> I suppose we had a reason for doing it the first way but I can't see
>> what. "GMT" seems a fairly English-centric way of referring to UTC
>> anyhow; translators might wish to put in "UTC" instead, or
Robert Haas wrote:
> On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga wrote:
> >
> >> From the implementers perspective, IMHO an extra catalog entry in pg_type
> >> is not bad on its own, you would have one anyway if the range type was
> >> explicitly programmed. About different kinds of range types -
On Wed, Apr 14, 2010 at 8:31 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>> > What's wrong with something like "connection not permitted" or
>> > "connection not authorized"?
>>
>> The case that we're trying to cater to with the existing wording is
>> novice DBAs, who are li
Tom Lane wrote:
> Robert Haas writes:
> > What's wrong with something like "connection not permitted" or
> > "connection not authorized"?
>
> The case that we're trying to cater to with the existing wording is
> novice DBAs, who are likely to stare at such a message and not even
> realize that pg
Dimitri Fontaine wrote:
> Tom Lane writes:
> > Well, what we *really* need is a convincing argument that it's worth
> > taking some risk for. I find that not obvious. You can pipe the output
> > of pg_dump into your-choice-of-compressor, for example, and that gets
> > you the ability to spread t
Robert Haas writes:
> What's wrong with something like "connection not permitted" or
> "connection not authorized"?
The case that we're trying to cater to with the existing wording is
novice DBAs, who are likely to stare at such a message and not even
realize that pg_hba.conf is what they need to
On Wed, Apr 14, 2010 at 8:19 PM, Tom Lane wrote:
> I'm thinking there isn't anything much we can do here without using a
> different message wording for a match to a REJECT entry. So it's a
> straight-up tradeoff of possible security information leakage against
> whether a different wording is re
I wrote:
> Robert Haas writes:
>> On Wed, Apr 14, 2010 at 4:24 PM, Aidan Van Dyk wrote:
>>> I think it sort of just died. I'm in favour of making sure we don't
>>> give out any extra information, so if the objection to the message is
>>> simply that "no pg_hba.conf entry" is "counterfactual" whe
Tom Lane wrote:
> On second thought, since there's no need for a particularly
> high-quality RNG here, we could just embed some brain-dead
> one-liner implementation, which should behave the same everywhere.
Sounds good to me.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
"Kevin Grittner" writes:
> Tom Lane wrote:
>> The seed alone wouldn't be enough to duplicate the behavior, since
>> the behavior of random() typically varies across platforms. So we
>> might get a report and still be unable to reproduce it.
> At least the person getting the initial failure wou
On Wed, Apr 14, 2010 at 6:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Apr 14, 2010 at 4:18 PM, Greg Smith wrote:
>>> As for updating the size recommendations, the text at
>>> http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server has been
>>> beaten into the status quo by a nu
Robert Haas writes:
> On Wed, Apr 14, 2010 at 4:24 PM, Aidan Van Dyk wrote:
>> I think it sort of just died. I'm in favour of making sure we don't
>> give out any extra information, so if the objection to the message is
>> simply that "no pg_hba.conf entry" is "counterfactual" when there is an
>
Robert Haas writes:
> On Wed, Apr 14, 2010 at 4:18 PM, Greg Smith wrote:
>> As for updating the size recommendations, the text at
>> http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server has been
>> beaten into the status quo by a number of people. Here's what might make
>> sense from th
On Wed, Apr 14, 2010 at 4:51 PM, Robert Haas wrote:
> On Wed, Apr 14, 2010 at 4:28 PM, Robert Haas wrote:
>> On Wed, Apr 14, 2010 at 4:24 PM, Aidan Van Dyk wrote:
>>> I think it sort of just died. I'm in favour of making sure we don't
>>> give out any extra information, so if the objection to t
Tom Lane wrote:
> I thought we'd fixed this ...
>
> regression=# select to_char('2009-01-01'::date, 'YY');
> to_char
> -
> 09
> (1 row)
>
> regression=# select to_char('2009-01-01'::date, 'FMYY');
> to_char
> -
> 09
> (1 row)
>
> Not a lot of zero suppression happening ther
On Wed, Apr 14, 2010 at 4:28 PM, Robert Haas wrote:
> On Wed, Apr 14, 2010 at 4:24 PM, Aidan Van Dyk wrote:
>> I think it sort of just died. I'm in favour of making sure we don't
>> give out any extra information, so if the objection to the message is
>> simply that "no pg_hba.conf entry" is "co
Tom Lane wrote:
> The seed alone wouldn't be enough to duplicate the behavior, since
> the behavior of random() typically varies across platforms. So we
> might get a report and still be unable to reproduce it.
At least the person getting the initial failure would be able to
recreate it, and
"Kevin Grittner" writes:
> Tom Lane wrote:
>> What this suggests is that CLOBBER_CACHE_ALWAYS is actually too
>> strong to provide a thorough test of cache flush hazards. Maybe
>> we need an alternate setting along the lines of
>> CLOBBER_CACHE_SOMETIMES that would randomly choose whether or not
Robert Haas wrote:
> This patch wouldn't apply for me for some reason (mangled
> whitespace?)
Yup. Somehow I stripped trailing spaces off of lines. I think my
editor was being a bit too "helpful". I'll try to watch that.
Although, maybe we should clean up trailing spaces in READMEs?:
fi
Rusty Conover writes:
> [ same stack trace for the simplified test case ]
Ah, got it finally. There *is* a relcache flush happening during INSERT
in the 8.4 code, because of FSM extension:
(gdb) bt
#0 RegisterRelcacheInvalidation (dbId=40264, relId=848094) at inval.c:439
#1 0x0067a30d
On Wed, Apr 14, 2010 at 4:24 PM, Aidan Van Dyk wrote:
> I think it sort of just died. I'm in favour of making sure we don't
> give out any extra information, so if the objection to the message is
> simply that "no pg_hba.conf entry" is "counterfactual" when there is an
> entry rejecting it, how a
* Bruce Momjian [100414 16:20]:
> Joshua Tolley wrote:
> -- Start of PGP signed section.
> > On Wed, Apr 07, 2010 at 01:07:21PM -0400, Robert Haas wrote:
> > > On Wed, Apr 7, 2010 at 10:46 AM, Tom Lane wrote:
> > > > Simon Riggs writes:
> > > >> When there is a specific reject rule, why does the
On Wed, Apr 14, 2010 at 4:18 PM, Greg Smith wrote:
> As for updating the size recommendations, the text at
> http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server has been
> beaten into the status quo by a number of people. Here's what might make
> sense from there to insert into the docs
On Wed, Apr 14, 2010 at 3:50 PM, Kevin Grittner
wrote:
> In the embarrassingly trivial department, I think I found a
> misspelled word in the GiST README file (unless it's a valid
> alternate spelling I've never seen).
This patch wouldn't apply for me for some reason (mangled
whitespace?), so I j
Joshua Tolley wrote:
-- Start of PGP signed section.
> On Wed, Apr 07, 2010 at 01:07:21PM -0400, Robert Haas wrote:
> > On Wed, Apr 7, 2010 at 10:46 AM, Tom Lane wrote:
> > > Simon Riggs writes:
> > >> When there is a specific reject rule, why does the server say
> > >> FATAL: ?no pg_hba.conf ent
Kevin Grittner wrote:
I wonder if we should add any hints telling people
what they might see as problems if they are too far one way or the
other. (Or does that go beyond the scope of what makes sense in TFM?)
It's hard to figure that out. One of the talks I'm doing at PGCon next
month is
On Apr 14, 2010, at 3:30 PM, Tom Lane wrote:
> Rusty Conover writes:
>> On Apr 14, 2010, at 2:31 PM, Tom Lane wrote:
>>> There is another slightly odd thing here, which is that the stack trace
>>> Rusty provided clearly shows the crash occurring during processing of a
>>> local relcache invalida
In the embarrassingly trivial department, I think I found a
misspelled word in the GiST README file (unless it's a valid
alternate spelling I've never seen).
-Kevin
*** a/src/backend/access/gist/README
--- b/src/backend/access/gist/README
***
*** 110,116 particularly, it is now
Rusty Conover writes:
> On Apr 14, 2010, at 2:31 PM, Tom Lane wrote:
>> There is another slightly odd thing here, which is that the stack trace
>> Rusty provided clearly shows the crash occurring during processing of a
>> local relcache invalidation message for the truncated relation.
> The test
On Apr 14, 2010, at 2:31 PM, Tom Lane wrote:
> I wrote:
>> [ theory about cause of Rusty's crash ]
>
> I started to doubt this theory after wondering why the problem hadn't
> been exposed by CLOBBER_CACHE_ALWAYS testing, which is done routinely
> by the buildfarm. That setting would surely caus
Tom Lane wrote:
> What this suggests is that CLOBBER_CACHE_ALWAYS is actually too
> strong to provide a thorough test of cache flush hazards. Maybe
> we need an alternate setting along the lines of
> CLOBBER_CACHE_SOMETIMES that would randomly choose whether or not
> to flush at any given oppor
I wrote:
> [ theory about cause of Rusty's crash ]
I started to doubt this theory after wondering why the problem hadn't
been exposed by CLOBBER_CACHE_ALWAYS testing, which is done routinely
by the buildfarm. That setting would surely cause the cache flush to
happen at the troublesome time. Afte
Robert Haas wrote:
> I think that would be reasonable provided someone can come up
> with some appropriate wording. My understanding is that if you
> have a really small system then you might need >25% and if you
> have a really big system you might need <25%, but I'm not sure
> where the edges
On Wed, Apr 14, 2010 at 11:15 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> I think this advice is badly outdated.
>
> Yeah.
>
>> s/tens/hundreds/ might be a good idea at a minimum,
>
> +1
>
>> but I'm thinking we might want to also mention the
>> one-quarter-of-system-memory heuristic.
>
>
On Wed, Apr 14, 2010 at 5:46 PM, Alvaro Herrera
wrote:
> Magnus Hagander wrote:
>> On Wed, Apr 14, 2010 at 5:18 PM, Stefan Kaltenbrunner
>> wrote:
>> > Magnus Hagander wrote:
>
>> >> How about we put it in RELEASE_CHANGES for major releases with
>> >> something like "if a major windows update has
Magnus Hagander wrote:
> On Wed, Apr 14, 2010 at 5:18 PM, Stefan Kaltenbrunner
> wrote:
> > Magnus Hagander wrote:
> >> How about we put it in RELEASE_CHANGES for major releases with
> >> something like "if a major windows update has been released, run ...
> >> "?
> >
> > is this really just rele
On Wed, Apr 14, 2010 at 5:18 PM, Stefan Kaltenbrunner
wrote:
> Magnus Hagander wrote:
>>
>> On Tue, Apr 13, 2010 at 9:00 PM, Alvaro Herrera
>> wrote:
>>>
>>> Tom Lane wrote:
Alvaro Herrera writes:
>
> Magnus Hagander wrote:
>>
>> This script should probably live in CVS,
Magnus Hagander wrote:
On Tue, Apr 13, 2010 at 9:00 PM, Alvaro Herrera
wrote:
Tom Lane wrote:
Alvaro Herrera writes:
Magnus Hagander wrote:
This script should probably live in CVS, and be run when Microsoft
releases new timezone data. Where should I put it - src/timezone or
somewhere in src
Robert Haas wrote:
> I think this advice is badly outdated.
Yeah.
> s/tens/hundreds/ might be a good idea at a minimum,
+1
> but I'm thinking we might want to also mention the
> one-quarter-of-system-memory heuristic.
Given how many people seem to find that a good guideline, it seems
l
TFM says:
Sets the amount of memory the database server uses for shared memory
buffers. The default is typically 32 megabytes (32MB), but might be
less if your kernel settings will not support it (as determined during
initdb). This setting must be at least 128 kilobytes. (Non-default
values of BLC
On Sat, Apr 10, 2010 at 12:23 AM, Jaime Casanova
wrote:
> On Fri, Apr 9, 2010 at 3:39 PM, Jaime Casanova
> wrote:
>>
>
> i think "make standbycheck" needs a little more work, why it isn't
> accesible from top of source dir?
>
what i want to do.
1) make standbycheck should be accesible from top
On Wed, Apr 14, 2010 at 10:02 AM, Fujii Masao wrote:
> On Tue, Apr 13, 2010 at 9:21 AM, Fujii Masao wrote:
>> On Tue, Apr 13, 2010 at 1:56 AM, Magnus Hagander wrote:
If adding new shared library is too big change at this point, I think
that we should postpone the fix only for dblink to
Koichi Suzuki wrote:
> 2010/4/14 Simon Riggs :
>> It would be a very useful test case to publish.
> I'm still struggling to generate remaing WAL records.
Sure, but when you've got it all, please share. I'd like to see us
have a much larger set of tests than the "make check" regression
tests
On Tue, Apr 13, 2010 at 9:00 PM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>> Alvaro Herrera writes:
>> > Magnus Hagander wrote:
>> >> This script should probably live in CVS, and be run when Microsoft
>> >> releases new timezone data. Where should I put it - src/timezone or
>> >> somewhere in src/
On Tue, 2010-04-13 at 10:41 -0500, Jaime Casanova wrote:
> On Mon, Apr 12, 2010 at 1:23 AM, Jaime Casanova
> wrote:
> >
> > another point, what happened with this:
> > http://archives.postgresql.org/message-id/1229549172.4793.105.ca...@ebony.2ndquadrant?
> > Obviously we still have the problem wit
Thanks for encouraging comment. I'm still struggling to generate
remaing WAL records.
--
Koichi Suzuki
2010/4/14 Simon Riggs :
> On Wed, 2010-04-14 at 11:13 +0900, Koichi Suzuki wrote:
>
>> Thank you for a great advice. I successfully generated all the WAL
>> records listed below.
On Wed, 2010-04-14 at 11:13 +0900, Koichi Suzuki wrote:
> Thank you for a great advice. I successfully generated all the WAL
> records listed below. By deleteing and VACUUMing a table with
> btree_gist based index, I was successful to generate all the GIST WAL
> records.
It would be a very us
On Tue, 2010-04-13 at 21:09 +0300, Heikki Linnakangas wrote:
> Heikki Linnakangas wrote:
> > I could reproduce this on my laptop, standby is about 20% slower. I ran
> > oprofile, and what stands out as the difference between the master and
> > standby is that on standby about 20% of the CPU time is
On Wed, 2010-04-14 at 07:07 -0400, Robert Haas wrote:
> On Wed, Apr 14, 2010 at 4:21 AM, Simon Riggs wrote:
> > On Sat, 2010-04-10 at 09:02 -0400, Robert Haas wrote:
> >
> >> So this can fail in either of two ways
> >
> > If I understand this correctly, it is unconvincing as a failure mode
> > sin
Hi
I've passed your report, and proposed fix, on to the -hackers list for
consideration. Thanks for taking the time to investigate this and report
it in detail.
--
Craig Ringer
--- Begin Message ---
Dear maintainers of PostgreSQL,
Build errors for PostgreSQL have been reported on Gentoo Linux, s
On Wed, Apr 14, 2010 at 4:21 AM, Simon Riggs wrote:
> On Sat, 2010-04-10 at 09:02 -0400, Robert Haas wrote:
>
>> So this can fail in either of two ways
>
> If I understand this correctly, it is unconvincing as a failure mode
> since it doesn't follow any of the documented procedures for creating a
On Tue, 2010-04-13 at 17:18 +0300, Heikki Linnakangas wrote:
> I've reviewed your changes and they look correct to me; the main chunk
> > of code is mine and that was tested by me.
>
> Ok, committed after fixing an obsoleted comment & other small
> editorialization.
Looks good, thanks.
--
Simo
Tom Lane writes:
> Well, what we *really* need is a convincing argument that it's worth
> taking some risk for. I find that not obvious. You can pipe the output
> of pg_dump into your-choice-of-compressor, for example, and that gets
> you the ability to spread the work across multiple CPUs in ad
Heikki Linnakangas writes:
> Changing the KnownAssignedXids data structure from
> hash table into something that's quicker to scan. Preferably something
> with O(N), where N is the number of entries in the data structure, not
> the maximum number of entries it can hold as it is with the hash tabl
On Wed, Apr 14, 2010 at 12:49 AM, Heikki Linnakangas
wrote:
> We have the emode_for_corrupt_record() function that's used in all the
> errors that indicate a corrupt WAL record, that's a perfect place to
> hook this into. See attached patch.
One problem of the patch is that even if the content of
Tom Lane wrote:
Joachim Wieland writes:
If we still cannot do this, then what I am asking is: What does the
project need to be able to at least link against such a compression
algorithm?
Well, what we *really* need is a convincing argument that it's worth
taking some risk for. I find that no
On Sat, 2010-04-10 at 09:02 -0400, Robert Haas wrote:
> So this can fail in either of two ways
If I understand this correctly, it is unconvincing as a failure mode
since it doesn't follow any of the documented procedures for creating a
standby. There are many ways to screw up that ignore the manu
On Tue, Apr 13, 2010 at 9:21 AM, Fujii Masao wrote:
> On Tue, Apr 13, 2010 at 1:56 AM, Magnus Hagander wrote:
>>> If adding new shared library is too big change at this point, I think
>>> that we should postpone the fix only for dblink to 9.1 or later. Since
>>> no one has complained about this l
73 matches
Mail list logo
