Bruce Momjian <[EMAIL PROTECTED]> writes:
> 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 multi
Jan Wieck <[EMAIL PROTECTED]> writes:
> So either we do the random signature thing, which I would favor as a one
> time be all, end all solution - or you do the actual from-address based
> implementation by restoring the old IPV4 behaviour and adding correct
> IPV6 behaviour.
My feeling at this
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
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 functio
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are all the IPv6 issues resolved in current CVS?
AFAIK, yes ... but I don't run IPv6 here, so I might not be the best
authority on the subject ...
regards, tom lane
---(end of broadcast)--
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-threa
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 pla
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 offe
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
>
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 o
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:
> 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.
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 (sor
""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
Philip Yarra wrote:
> 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.
Baffler is my m
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 cr
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
Note: forwarded message attached.
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software--- Begin Message ---
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 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
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
>
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 th
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-
V
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 i
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 table
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 da
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
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
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 tha
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, y
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 a
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 multi-mast
-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 Wer
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 concerned
> -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 [200
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 li
Jeroen Ruigrok/asmodai <[EMAIL PROTECTED]> writes:
> -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.
> The 1
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 m
-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 s
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 16T
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
[EMA
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
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 no
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
luke wrote:
> Someone know if already exist a libpq++
>
> written in VC++ (6.x or above) ?!
>
>
>
> I'm trying libpq retrieved from CVS but with VC++
> 7.1 (VS 2003) doesn't work very well.
Sure libpq++ and libpqpp are on http://gborg.postgresql.org.
--
Bruce Momjian
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 b
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 cas
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-typ
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
t
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 _expre
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 constru
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,
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,
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.
Someone know if already exist a libpq++
written in VC++ (6.x or above) ?!
I’m trying libpq retrieved from CVS but with VC++
7.1 (VS 2003) doesn’t work very well…
Thanks
Regards
Luke
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
"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
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,
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 its
> 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 a
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
> > c
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
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 hand
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, b
63 matches
Mail list logo
