>> Yeah this is my basic confusion. But wouldn't the arguments be
>> evaluated afresh on the subsequent call for this SRF?
>
> No, see ExecMakeFunctionResult(). If we did that we'd have serious
> problems with volatile functions, ie srf(random()).
>
Ok thanks. So if someone uses a really long-run
On Fri, 7 May 2010, Robert Haas wrote:
On Fri, May 7, 2010 at 5:35 PM, Tom Lane wrote:
Robert Haas writes:
[ argues, in effect, for starting 9.1 development right now ]
I can't stop you from spending your time as you please. My development
time for at least the next month or two is going
Sorry about a error in my previous example (mixed width and precision).
But the conclusion is the same - it works on bytes:
#include
main () {
char s[] = "ni\xc3\xb1o"; /* 5 bytes , 4 utf8 chars */
printf("|%*s|\n",6,s); /* this should pad a black */
printf("|%.*s|\n",4,s);
However, it appears that glibc's printf
code interprets the parameter as the number of *characters* to print,
and to determine what's a character it assumes the string is in the
environment LC_CTYPE's encoding.
Well, I myself have problems to believe that :-)
This would be nasty... Are you sure?
--On 7. Mai 2010 19:49:15 -0400 Tom Lane wrote:
Bernd Helmle writes:
I've recently even started to wonder if the performance gain with
fsync=off is still that large on modern hardware. While testing large
migration procedures to a new version some time ago (on an admitedly
fast storage) i
Bernd Helmle writes:
> I've recently even started to wonder if the performance gain with fsync=off
> is still that large on modern hardware. While testing large migration
> procedures to a new version some time ago (on an admitedly fast storage) i
> forgot here and then to turn it off, without
hernan gonzalez writes:
> The issue is that psql tries (apparently) to convert to UTF8
> (even when he plans to output the raw text -LATIN9 in this case)
> just for computing the lenght of the field, to build the table.
> And because for this computation he (apparently) rely on the string
> routin
--On 7. Mai 2010 09:48:53 -0500 Kevin Grittner
wrote:
I think it goes beyond "tweaking" -- I think we should have a bald
statement like "don't turn this off unless you're OK with losing the
entire contents of the database cluster." A brief listing of some
cases where that is OK might be il
2010/5/6 Tom Lane :
> Bruce Momjian writes:
>> OK, seems people like pg_upgrade, but do we call it "pgupgrade" or
>> "pg_upgrade"?
>
pg_upgrade sounds good. I just bet that some users will want it to
upgrade their postgresql from 9.0.0 to 9.0.1..
> The latter. The former is unreadable.
>
>
On Fri, May 7, 2010 at 5:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> [ argues, in effect, for starting 9.1 development right now ]
>
> I can't stop you from spending your time as you please. My development
> time for at least the next month or two is going to be spent on
> code-reading the H
Robert Haas writes:
> [ argues, in effect, for starting 9.1 development right now ]
I can't stop you from spending your time as you please. My development
time for at least the next month or two is going to be spent on
code-reading the HS/SR code and fixing bugs as they come in. I don't
foresee
On Fri, May 7, 2010 at 10:44 AM, Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of vie may 07 07:33:55 -0400 2010:
>> On Thu, May 6, 2010 at 3:29 PM, Andy Lester wrote:
>> > I was looking for how to undo a CLUSTER call earlier today. Nothing on
>> > the CLUSTER page told me how to d
On Fri, May 7, 2010 at 11:31 AM, Tom Lane wrote:
> I would say the expectation for individual developers is "test, and
> read code". It's certainly not time to be starting new feature
> development yet.
I am humbly of the opinion that the expectation you have enclosed in
quotation marks is far t
On Fri, May 07, 2010 at 02:14:12PM -0400, Tom Lane wrote:
> That's ecpg, not "C interface" --- the latter term is unlikely to
> draw the attention of the right person, namely Michael.
Right, thanks Tom. I have an email filter that filters all emails containing
"ecpg" anf puts them into a special d
Josh Berkus writes:
> Can someone verify that these two C interface issues are intentional?
> If not, they're bugs:
> http://archives.postgresql.org/pgsql-testers/2010-05/msg00011.php
> http://archives.postgresql.org/pgsql-testers/2010-05/msg00010.php
That's ecpg, not "C interface" --- the latter
All,
BTW, it would be good if some other folks than me were monitoring -testers.
Can someone verify that these two C interface issues are intentional?
If not, they're bugs:
http://archives.postgresql.org/pgsql-testers/2010-05/msg00011.php
http://archives.postgresql.org/pgsql-testers/2010-05/msg0
I never meant to suggest any statement in that section is factually
wrong; it's just all too rosy, leading people to believe it's no big
deal to turn it off.
Yeah, that section is overdue for an update. I'll write some new text
and post it to pgsql-docs.
--
Tom Lane wrote:
Josh Berkus writes:
quietly removing NULL is maybe good for compatibility but is wrong for
functionality.
I agree. I wasn't aware of this little misfeature.
Default display for NULL should be a zero-length string.
That's just as broken as Pave
Robert Haas writes:
> I am fuzzier on what happens now. I understand that it depends on
> what bug reports we get as a result of beta testing, but what I don't
> quite know is what the expectations are for individual developers, how
> we're tracking what issues still need to be resolved, or what
Nikhil Sontakke writes:
>> Consider
>> srf(foo(col))
>> where foo returns a pass-by-reference datatype.
> Yeah this is my basic confusion. But wouldn't the arguments be
> evaluated afresh on the subsequent call for this SRF?
No, see ExecMakeFunctionResult(). If we did that we'd have seri
Andrew Dunstan wrote:
> I think the critical question is really whether you are prepared
> to lose your database.
Precisely; and the docs don't make that at all clear. They mention
the possibility of database corruption, but downplay it:
| When fsync is disabled, the operating system is all
> nly
> one sentence I think we should add it adjacent to the existing
> sentence discussing remembering the index. My proposed patch
> attached; thoughts?
As long as there's a pointer to the answer I'm happy.
xoa
--
Andy Lester => a...@petdance.com => www.theworkinggeek.com => AIM:petdance
Excerpts from Robert Haas's message of vie may 07 07:33:55 -0400 2010:
> On Thu, May 6, 2010 at 3:29 PM, Andy Lester wrote:
> > I was looking for how to undo a CLUSTER call earlier today. Nothing on
> > the CLUSTER page told me how to do it, or pointed me to the ALTER TABLE
> > page. I figure a
Kevin Grittner wrote:
There are dire-sounding statements interspersed with:
| using fsync results in a performance penalty
| Due to the risks involved, there is no universally correct setting
| for fsync.
| If you trust your operating system, your hardware, and your
| utility company (
On Mon, Jan 11, 2010 at 10:45 PM, Bruce Momjian wrote:
>> > What amazes me is how many people who closely follow our development are
>> > mystified by what we do during that pre-beta period.
>>
>> Hey, I'm still mystified. Maybe you and Tom could do twice-a-week
>> status updates on what you're w
"Kevin Grittner" writes:
> | If you trust your operating system, your hardware, and your
> | utility company (or your battery backup), you can consider
> | disabling fsync.
> Isn't this a little too rosy a picture to paint?
I think that statement is true as far as it goes, but I agree with
reji
On Fri, May 7, 2010 at 16:00, Robert Haas wrote:
> On Fri, May 7, 2010 at 9:47 AM, Kevin Grittner
> wrote:
>> Someone just posted to the -admin list with a database corrupted
>> while running with fsync=off. I was all set to refer him to the
>> documentation explaining why he should stop doing t
On Fri, May 7, 2010 at 9:47 AM, Kevin Grittner
wrote:
> Someone just posted to the -admin list with a database corrupted
> while running with fsync=off. I was all set to refer him to the
> documentation explaining why he should stop doing this, but to my
> surprise the documentation waffles on th
Someone just posted to the -admin list with a database corrupted
while running with fsync=off. I was all set to refer him to the
documentation explaining why he should stop doing this, but to my
surprise the documentation waffles on the issue way past what I
think is reasonable.
http://www.postg
Erik Rijkers wrote:
Everything together: the raid is what Areca call 'raid10(1E)'.
(to be honest I don't remember what that 1E exactly means -
extra flexibility in the number of disks, I think).
Standard RAID10 only supports an even number of disks. The 1E variants
also allow putting an od
On Thu, May 6, 2010 at 3:29 PM, Andy Lester wrote:
> I was looking for how to undo a CLUSTER call earlier today. Nothing on
> the CLUSTER page told me how to do it, or pointed me to the ALTER TABLE
> page. I figure a pointer to would help the next person in my situation.
I've been annoyed by th
Robert Haas wrote:
Oh, I see. Well, that might be reasonable syntactic sugar, although I
think you should make it wrap the path in exists() unconditionally,
rather than testing for an existing wrap.
I'll leave it out for now, it saves me some effort after all.
Please email your patch to t
On Thu, 2010-05-06 at 15:00 +0100, Simon Riggs wrote:
> On Thu, 2010-05-06 at 12:08 +0200, Yeb Havinga wrote:
>
> > That's funny because when I was reading this thread, I was thinking the
> > exact opposite: having max_standby_delay always set to 0 so I know the
> > standby server is as up-to-da
33 matches
Mail list logo
