Bruce Momjian [EMAIL PROTECTED] writes:
Is our maximum table size limited by the maximum block number?
Certainly.
Is the 16TB number a hold-over from when we weren't sure block number
was unsigned, though now we are pretty sure it is handled as unsigned
consistenly?
It's a holdover. As to
hello
there is an alternate sql server, designed almost for your needs, it's
name is SQLite. it's a very simple one, but you can statically compile it
into your programs. search sf or freshmeat for it(or google, ofcourse)
Bye,
Gergely Czuczy
mailto: [EMAIL PROTECTED]
PGP:
Tom Lane wrote:
[EMAIL PROTECTED] writes:
This analysis makes sense - I think using memcmp is clearly wrong here.
Yeah, now that I think about it, we're betting on the kernel to
faithfully zero all unused bits in addrinfo structures. In an ideal
world, all kernels would do that, but in
On Tue, 9 Sep 2003, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Is our maximum table size limited by the maximum block number?
Certainly.
Is the 16TB number a hold-over from when we weren't sure block number
was unsigned, though now we are pretty sure it is handled as
The particular assertion that was proposed doesn't strike me as terribly
useful - It should be checked at the point of call rather than inside
pstrdup, I should have thought.
Of course, that would make for lots of code bloat ... cases like this
are when gdb is your friend.
cheers
andrew
Tom
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Is our maximum table size limited by the maximum block number?
Certainly.
Is the 16TB number a hold-over from when we weren't sure block number
was unsigned, though now we are pretty sure it is handled as unsigned
consistenly?
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Is our maximum table size limited by the maximum block number?
Certainly.
Is the 16TB number a hold-over from when we weren't sure block number
was unsigned, though now we are pretty sure it is handled as unsigned
Well, then if i have a transaction1 that does the following:
begin work;
select * from students where age=19 for update;.
and then another transaction2 comes along and tries to lock the same row and
is made to wait.
Does it find out the row hes trying to lock is already locked after it
builds
Bruce Momjian [EMAIL PROTECTED] writes:
I guess the big question is what do we report as the maximum table size?
Do we report 32TB and fix any bug that happen over 16TB?
[shrug] I'm happy with what the docs say now. I'd rather underpromise
than overpromise.
regards,
Andrew Dunstan [EMAIL PROTECTED] wrote:
The particular assertion that was proposed doesn't strike me as terribly
useful - It should be checked at the point of call rather than inside
pstrdup, I should have thought.
Are you going to trust the client of that function ?
Here the question is
On Tue, Sep 09, 2003 at 02:04:43AM -0400, Tom Lane wrote:
It's a holdover. As to how certain we are that all the
signed-vs-unsigned bugs are fixed, who have you heard from running a
greater-than-16Tb table? And how often have they done CLUSTER, REINDEX,
or even VACUUM FULL on it? AFAIK we
Someone know if already exist a libpq++
written in VC++ (6.x or above) ?!
Im trying libpq retrieved from CVS but with VC++
7.1 (VS 2003) doesnt work very well
Thanks
Regards
Luke
On Tue, Sep 09, 2003 at 04:53:06PM +0200, Gaetano Mendola wrote:
Andrew Dunstan [EMAIL PROTECTED] wrote:
The particular assertion that was proposed doesn't strike me as terribly
useful - It should be checked at the point of call rather than inside
pstrdup, I should have thought.
Are
Alvaro Herrera Munoz wrote:
On Tue, Sep 09, 2003 at 04:53:06PM +0200, Gaetano Mendola wrote:
Andrew Dunstan [EMAIL PROTECTED] wrote:
The particular assertion that was proposed doesn't strike me as terribly
useful - It should be checked at the point of call rather than inside
pstrdup, I
Tom Lane wrote:
4. Use the parser's coerce_to_boolean procedure, so that nonbooleans
will be accepted in exactly the same cases where they'd be accepted
in a boolean-requiring SQL construct (such as CASE). (By default,
none are, so this isn't really different from #2. But people could
create
On Tue, Sep 09, 2003 at 02:10:20AM -0700, Kevin Brown wrote:
I could go for Jan's idea of putting a random key into the messages,
if anyone feels that we should not trust to the kernel to enforce the
packet source address restriction. But the memcmp() test seems a clear
loser given
Tatsuo Ishii wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Is our maximum table size limited by the maximum block number?
Certainly.
Is the 16TB number a hold-over from when we weren't sure block number
was unsigned, though now we are pretty sure it is
On Tue, Sep 09, 2003 at 01:57:47PM -0400, Bruce Momjian wrote:
Sure libpq++ and libpqpp are on http://gborg.postgresql.org.
Ahem.
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Jeroen T. Vermeulen wrote:
On Tue, Sep 09, 2003 at 01:57:47PM -0400, Bruce Momjian wrote:
Sure libpq++ and libpqpp are on http://gborg.postgresql.org.
Uh, sorry, libpqpp and libpqxx. libpqxx is the newer one.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL
On Tue, 9 Sep 2003 14:25:19 -0400 (EDT), [EMAIL PROTECTED] (Bruce
Momjian) wrote:
Tatsuo Ishii wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Is our maximum table size limited by the maximum block number?
Certainly.
Is the 16TB number a hold-over from when
-On [20030909 20:32], Bruce Momjian ([EMAIL PROTECTED]) wrote:
I know Tom is concerned because we haven't tested it, but I don't think
anyone has tested 16TB either, nor our 1600-column limit.
If I had the space free on my SAN right now I'd try it.
The 1600 column limit should be easy to test
Is true, but sometimes programers needgood database engine for simply
program.I think that postgres is one of the best sql db for free and with
open source, but its too much to install server form only one application,
on one workstation . So i thought that there could be the way out , to
build
From: Gaetano Mendola [EMAIL PROTECTED]
Why this ? just because bigger is better? I agree with Tom Lane, is
better underpromise than overpromise.
My $0.02:
You are talking about pg teoretical limits.
Why not add to the docs some information about the lack of resources
for testing these limits
-Original Message-
From: Jeroen Ruigrok/asmodai [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 09, 2003 1:23 PM
To: Bruce Momjian
Cc: Tatsuo Ishii; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Maximum table size
-On [20030909 20:32], Bruce Momjian ([EMAIL
Jeroen Ruigrok/asmodai wrote:
At work right now I have a bunch of 2-3 TB databases using Oracle 8.
We're expected to be using 60 TB in total storage about 2 years down the
road (right now we're using about 20).
I guess GIS databases and image databases might be the ones who would be
more
-On [20030909 23:02], Andrew Dunstan ([EMAIL PROTECTED]) wrote:
They must be very big images or there must be an awful lot of them :-)
*grin*
I was more thinking of organizations such as NASA and commercial
entities storing satellite images in databases.
--
Jeroen Ruigrok van der Werven
I haven't seen any comment on this email.
From our previous discussion of 2-phase commit, there was concern that
the failure modes of 2-phase commit were not solvable. However, I think
multi-master replication is going to have similar non-solvable failure
modes, yet people still want
I assume we never came to a final conclusion on how to do CREATE
FUNCTION without double-quoting.
---
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
In that case, though, the solution will presumably look at
Bruce Momjian wrote:
I haven't seen any comment on this email.
From our previous discussion of 2-phase commit, there was concern that
the failure modes of 2-phase commit were not solvable. However, I think
multi-master replication is going to have similar non-solvable failure
modes, yet
On Thu, 4 Sep 2003 05:36 am, Bruce Momjian wrote:
I would like every operating system that supports thread-safety to run
this program and report back the results.
Okay, here's results from the machines I have access to... I think what you're
going to find is that an awful lot of platforms that
I think if it could be done in a reasonably aesthetic way in psql that
would satisfy many people, without any need to disturb the backend,
which Tom objects to.
That's a big if, IMNSHO :-).
I'd hate to see this dropped, though
cheers
andrew
Bruce Momjian wrote:
I assume we never came to a
Mike Mascari wrote:
Bruce Momjian wrote:
I haven't seen any comment on this email.
From our previous discussion of 2-phase commit, there was concern that
the failure modes of 2-phase commit were not solvable. However, I think
multi-master replication is going to have similar
Hi,
I have asked my question on pgsql-general, and Tom Lane suggested I post
here too. I would really appreciate your opinion.
At NC State University, my students and I are working on a project called
self-organizing databases, please see description below. I would like to
use an open-source
Hey guys, not sure if this is the right place to post.
Not even sure if this is a bug or a feature :)
When I create a temp table and then try to copy some data into the
table, if the data is corrupt and the synchronization is lost - the
table also seems to get lost.
For example
create temp
On Fri, 2003-09-05 at 15:16, Manfred Spraul wrote:
Another question:
Is it possible to apply patches to postgresql before a DBT-2 run, or is
only patching the kernel supported?
--
Manfred
As Mark indicated, we currently only support kernel patches via our PLM
system, but we are in the
Philip Yarra wrote:
On Thu, 4 Sep 2003 05:36 am, Bruce Momjian wrote:
I would like every operating system that supports thread-safety to run
this program and report back the results.
Okay, here's results from the machines I have access to... I think what you're
going to find is that an
On Mon, 8 Sep 2003, Konstantin Goudkov wrote:
Hey guys, not sure if this is the right place to post.
Not even sure if this is a bug or a feature :)
When I create a temp table and then try to copy some data into the
table, if the data is corrupt and the synchronization is lost - the
table
On Tue, 9 Sep 2003, Rada Chirkova wrote:
Hi,
I have asked my question on pgsql-general, and Tom Lane suggested I post
here too. I would really appreciate your opinion.
At NC State University, my students and I are working on a project called
self-organizing databases, please see
Note: forwarded message attached.
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software---BeginMessage---
hi
it seems we are sharing the same problem at different levels.
here is my original porblem which I posted couple of days ago:
On Wed, 10 Sep 2003 11:46 am, Bruce Momjian wrote:
I see --- looks bad failures below for OSF, Solaris, and FreeBSD
below.
Actually, I am not sure the OSF failure is correctly reported... your test app
had me a little baffled in that case.
We would have to get some thread mutex, make
Dann Corbit [EMAIL PROTECTED] wrote:
/*
** This will generate a 28 megabyte SQL script.
** 1600 table definitions will be created for tables
** with from 1 to 1600 columns.
*/
That's easy, now you shall do real query, real vacuum, real
reindex on it
Regards
Gaetano Mendola
On Wed, 10 Sep 2003 12:29 pm, Bruce Momjian wrote:
--- anyway, it is probably threadsafe, but strerror isn't, so we are
dead anyway. :-)
Oh, I see. Yep, good point. Strange that strerror isn't threadsafe when
everything else is... maybe Strange is OSF's middle name.
#ifdef SOME_DEF (sorry,
Bruce Momjian [EMAIL PROTECTED] writes:
Tripple-yuck. :-)
It doesn't seem to me that we should take on the job of providing
thread-safe implementations of basic libc functions. If a particular
OS cannot manage to offer that functionality, then we should mark it
not-thread-safe and move on.
Have we determined there _isn't_ a memory leak problem in beta2?
---
Tom Lane wrote:
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
The interesting thing was that my postmaster needed around 4mb of
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tripple-yuck. :-)
It doesn't seem to me that we should take on the job of providing
thread-safe implementations of basic libc functions. If a particular
OS cannot manage to offer that functionality, then we should mark it
Bruce Momjian [EMAIL PROTECTED] writes:
Have we determined there _isn't_ a memory leak problem in beta2?
I am not sure. I have a suspicion that there is no real leak, but
rather we are seeing some artifact of the way Linux' top(1) reports
memory usage. I cannot prove that --- I can only offer
Are all the IPv6 issues resolved in current CVS?
---
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
OK, now we are getting somewhere. I see that this would work. It's a bit
ugly, though - with this plan the
On Wed, 10 Sep 2003 02:15 pm, Bruce Momjian wrote:
Tom Lane wrote:
It doesn't seem to me that we should take on the job of providing
thread-safe implementations of basic libc functions. If a particular
OS cannot manage to offer that functionality, then we should mark it
not-thread-safe
Philip Yarra [EMAIL PROTECTED] writes:
On Wed, 10 Sep 2003 02:15 pm, Bruce Momjian wrote:
Tom Lane wrote:
It doesn't seem to me that we should take on the job of providing
thread-safe implementations of basic libc functions. If a particular
OS cannot manage to offer that functionality, then
Kurt Roeckx wrote:
On Tue, Sep 09, 2003 at 02:10:20AM -0700, Kevin Brown wrote:
I could go for Jan's idea of putting a random key into the messages,
if anyone feels that we should not trust to the kernel to enforce the
packet source address restriction. But the memcmp() test seems a clear
Tom Lane wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
On Mon, 08 Sep 2003 11:40:32 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
4. Use the parser's coerce_to_boolean procedure, so that nonbooleans
will be accepted in exactly the same cases where they'd be accepted
in a boolean-requiring
On Mon, 08 Sep 2003 11:40:32 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
4. Use the parser's coerce_to_boolean procedure, so that nonbooleans
will be accepted in exactly the same cases where they'd be accepted
in a boolean-requiring SQL construct (such as CASE). (By default,
none are, so
Manfred Koizar [EMAIL PROTECTED] writes:
On Mon, 08 Sep 2003 11:40:32 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
4. Use the parser's coerce_to_boolean procedure, so that nonbooleans
will be accepted in exactly the same cases where they'd be accepted
in a boolean-requiring SQL construct (such as
Define the language! If it breaks code, so be it.
2. Throw an error if the _expression_ doesn't return boolean.
Yes, yes, absolutely.
By definition "an IF, WHILE, or EXIT statement is a boolean _expression_"
SO
if "some stupid piece of text" THEN
should not compile, there is no BOOLEAN
Tom Lane wrote:
Following up this gripe
http://archives.postgresql.org/pgsql-sql/2003-09/msg00044.php
I've realized that plpgsql just assumes that the test expression
of an IF, WHILE, or EXIT statement is a boolean expression. It
doesn't take any measures to ensure this is the case or convert
Jan Wieck [EMAIL PROTECTED] writes:
ERROR is the cleanest way, but I'd vote for conversion to boolean to
keep the damage within reason.
Which style of conversion did you like? These were the choices:
3. Try to convert nonbooleans to boolean using plpgsql's usual method
for cross-type
I would suggest to throw a error, or at least a warning.
This will FORCE people to program in the correct way.
I also thought that 'IF $1 THEN ...' should work ok but giving it a other
thought it's indeed stuped to write that way (I'm from the C world...)
Ries
-Oorspronkelijk bericht-
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
ERROR is the cleanest way, but I'd vote for conversion to boolean to
keep the damage within reason.
Which style of conversion did you like? These were the choices:
3. Try to convert nonbooleans to boolean using plpgsql's usual method
for
58 matches
Mail list logo
