Asserts on data-consistency checks aren't really a good idea.
(IOW this is can't happen only as long as your database isn't
corrupt...)
Then why not change this to an ereport(PANIC ...)?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Peter Eisentraut pete...@gmx.net wrote:
ITAGAKI Takahiro wrote:
Here is a patch to allow 'on' and 'off' as input texts for boolean.
Regarding your FIXME comment, I think parse_bool* should be in bool.c
and declared in builtins.h, which guc.c already includes.
(Conceptually, the valid
Jacky Leng wrote:
Asserts on data-consistency checks aren't really a good idea.
(IOW this is can't happen only as long as your database isn't
corrupt...)
Then why not change this to an ereport(PANIC ...)?
If you have a corrupted database, you want to be able to read it, not
panic. If
Right, can't do that on a hot standby server.
Is anywhere applicable hot standby patch? Last version on wiki is 9g and it
can't be applied cleanly.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW:
Andrew Dunstan wrote:
Cédric Villemain wrote:
-j [jobs], --jobs[=jobs]
Specifies the number of jobs (pg_restore) to run simultaneously.
If the -j
option is given without an argument, pg_restore will not limit the
number of
jobs that can run simultaneously.
Quite apart from anything
Tom Lane wrote:
Couldn't you get rid of PMSIGNAL_RECOVERY_COMPLETED altogether? If the
startup process exits with code 0, recovery is complete, else there
was trouble. I find this SetPostmasterSignal bit quite ugly anyway.
Right now, the startup process exits with code 0 also when it's told
Teodor Sigaev wrote:
Right, can't do that on a hot standby server.
Is anywhere applicable hot standby patch? Last version on wiki is 9g and
it can't be applied cleanly.
The latest version is in Simon's git repository at:
I was revisiting the issue of how to prevent psql from prompting for a
password, for batch operations, previously discussion here:
http://www.mail-archive.com/pgsql-b...@postgresql.org/msg18440.html
http://www.mail-archive.com/pgsql-b...@postgresql.org/msg20002.html
I noticed that there appear
Tom Lane wrote:
How about introducing a varchar2 type as in Oracle?
Maybe. I think right now we don't allow input functions to decide
that a non-null input string should be converted to a NULL, but
that might be fixable. It'd still be an ugly mess though, since
I suspect you'd have to
On Thu, 19 Feb 2009, Andrew Dunstan wrote:
Date: Thu, 19 Feb 2009 21:58:18 -0500
From: Andrew Dunstan and...@dunslane.net
To: Tom Lane t...@sss.pgh.pa.us
Cc: o...@pyrenet.fr, pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pg_restore new option -m
Tom Lane wrote:
Curiously enough, Oracle has it so that || of null arguments treats the
arguments as empty string.
It's beyond comprehension.
what is result of '' || '' ?
Pavel
But yeah, a varchar2 type with a full set of functions and operators could
work. If you choose not to bother with supporting
Pavel Stehule pavel.steh...@gmail.com writes:
Curiously enough, Oracle has it so that || of null arguments treats the
arguments as empty string.
It's beyond comprehension.
what is result of '' || '' ?
Well the result of this is NULL of course (which is the same as '')
What's more puzzling
Peter Eisentraut wrote:
Andrew Dunstan wrote:
Cédric Villemain wrote:
-j [jobs], --jobs[=jobs]
Specifies the number of jobs (pg_restore) to run
simultaneously. If the -j
option is given without an argument, pg_restore will not limit the
number of
jobs that can run simultaneously.
I wrote:
Hence semijoins can be rearranged just as freely as inner joins.
I guess nobody checked my work, because that claim is bogus. Consider
A semijoin (B innerjoin C on (Pbc)) on (Pab)
=? (A semijoin B on (Pab)) innerjoin C on (Pbc)
In the second form the inner join is now
On Fri, Feb 20, 2009 at 10:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Hence semijoins can be rearranged just as freely as inner joins.
I guess nobody checked my work, because that claim is bogus.
I spent some time reading your email and thinking through the cases,
but I completely
On Fri, 2009-02-20 at 09:33 -0500, Andrew Dunstan wrote:
The short answer is that we don't know yet. There is anecdotal evidence
that the number of CPUs on the server is a good place to start, but we
should be honest enough to say that this is a new feature and we are
still gathering
Joshua D. Drake wrote:
On Fri, 2009-02-20 at 09:33 -0500, Andrew Dunstan wrote:
The short answer is that we don't know yet. There is anecdotal evidence
that the number of CPUs on the server is a good place to start, but we
should be honest enough to say that this is a new feature and we
On Fri, Feb 20, 2009 at 09:22:58AM -0800, Joshua D. Drake wrote:
On Fri, 2009-02-20 at 09:33 -0500, Andrew Dunstan wrote:
The short answer is that we don't know yet. There is anecdotal evidence
that the number of CPUs on the server is a good place to start, but we
should be honest
Andrew Dunstan and...@dunslane.net wrote:
Joshua D. Drake wrote:
the fastest restore time for
220G was performed with 24 threads with an 8 core box.
It is important to point out that this was a machine with 50
spindles.
Which is where your bottleneck is going to be immediately after
On Fri, 2009-02-20 at 11:57 -0600, Kevin Grittner wrote:
But you are right that there isn't a simple formula.
Perhaps the greater of the number of CPUs or effective spindles?
(24 sounds suspiciously close to effective spindles on a 50 spindle
box
with RAID 10.)
It does except that
create table foo(a int, b int);
postgres=# create function rfoo() returns setof foo as $$ begin return
query select foo from foo; end; $$ language plpgsql;
CREATE FUNCTION
Time: 25.606 ms
postgres=#
postgres=#
postgres=# select rfoo();
ERROR: structure of query does not match function result type
Merlin Moncure mmonc...@gmail.com writes:
create table foo(a int, b int);
postgres=# create function rfoo() returns setof foo as $$ begin return
query select foo from foo; end; $$ language plpgsql;
Use select * from ... instead.
regards, tom lane
--
Sent via
On Fri, Feb 20, 2009 at 3:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
create table foo(a int, b int);
postgres=# create function rfoo() returns setof foo as $$ begin return
query select foo from foo; end; $$ language plpgsql;
Use select * from ...
On Fri, Feb 20, 2009 at 3:25 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Fri, Feb 20, 2009 at 3:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
create table foo(a int, b int);
postgres=# create function rfoo() returns setof foo as $$ begin return
query
Merlin Moncure mmonc...@gmail.com writes:
On Fri, Feb 20, 2009 at 3:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Use select * from ... instead.
Yeah...I was thinking maybe that shouldn't be required:
If you allow both interpretations then you create a syntactic ambiguity
(at least for the case
On Wed, 18 Feb 2009, Kris Jurka wrote:
I have reviewed pljava's handling of misrepresented alignment, length, and by
value parameters [and it doesn't all work.]
I have fixed pljava to now correctly handle all of these being defined
incorrectly. So a trusted language can be used to
On Feb 17, 2009, at 11:23 PM, Robert Haas wrote:
Actually, a simple algorithm that might work really well would be to
calculate relation cache odds as ( number of page accesses for
relation /
number of page accesses for all relations ) * ( sum(relpages)*BLKSZ /
eff_cache_size ), where number
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
There is an unfinished TODO item here: we really ought to make it work
for tar-format archives. That's probably not hugely difficult, but
I didn't look into it, and don't think we should hold up applying the
On Fri, Feb 20, 2009 at 7:25 PM, decibel deci...@decibel.org wrote:
On Feb 17, 2009, at 11:23 PM, Robert Haas wrote:
Actually, a simple algorithm that might work really well would be to
calculate relation cache odds as ( number of page accesses for relation /
number of page accesses for all
29 matches
Mail list logo
