Any chance one of you fine people could start another thread?
This has very little to do with "Feature freeze date for 8.1"...
Thanks,
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Wed, 2005-05-04 at 10:56 +1000, Neil Conway wrote:
> Dag-Erling SmÃrgrav wrote:
> > It doesn't stress the system anywhere near enough to reveal bugs in,
> > say, the shared memory or semaphore code.
>
> I agree -- I think we definitely need more tests for the concurrent
> behavior of the syste
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > I'm not saying pgfoundry should be shut down. But trying to force
> > projects out into the sterile landscape where they get little use and
> > little support is a death warrant. And unnecessary.
>
> > I think what
Greg Stark <[EMAIL PROTECTED]> writes:
> I'm not saying pgfoundry should be shut down. But trying to force
> projects out into the sterile landscape where they get little use and
> little support is a death warrant. And unnecessary.
> I think what I would suggest is going through pgfoundry, and ch
Josh Berkus writes:
> Look at other large projects with lots of options. Apache, Perl, Linux,
> Java,
> emacs, KDE, etc., all of them strike a balance between including stuff and
> leaving stuff as add-ins (some more narrowly than others), and exclude a lot
> of popular and useful stuff on
On Tue, May 03, 2005 at 09:19:41PM -0700, Josh Berkus wrote:
> I do find it kind of funny that we include the PLs but not the server-side
> drivers, but that decision precedes my tenure on Core.
Sorry, you lost me -- what are server-side drivers?
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
"Postgr
"John Hansen" <[EMAIL PROTECTED]> writes:
> Errm.. UTF-16/32
Ah, I thought that was what you meant.
Right now we have a *ton* of problems with supporting encodings that
need embedded zero bytes, because there are APIs all over the place
that use zero-terminated strings. I don't foresee that it w
Josh Berkus writes:
> Look at other large projects with lots of options. Apache, Perl,
> Linux, Java, emacs, KDE, etc., all of them strike a balance between
> including stuff and leaving stuff as add-ins (some more narrowly than
> others), and exclude a lot of popular and useful stuff on a variet
Dave,
> My main concern was pushing out existing code, not adding code that was
> not in the tarball.
> I would have to agree deciding which to include would be onerous.
I personally am not proposing pushing stuff out, except some of the legacy
(i.e. not maintained) contrib modules.
I do find i
Josh Berkus wrote:
Dave, all:
This issue has come up before, and I opposed it then when the interfaces
were removed from the main tarball.
I really don't see the upside to reducing the size of the tarball at the
expense of ease of use. ÂSeems to me we are
bending over backwards
Andrew,
> OK, *you* choose. I'm getting a little annoyed with how many people tell
> me "oh, it should be easy to pick the stuff to include with standard
> PostgreSQL", and then expect core to do the choosing.
Sorry, that came off kinda harsh.Seriously, I personally would love to see
a p
Errm.. UTF-16/32
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of John Hansen
> Sent: Wednesday, May 04, 2005 1:22 PM
> To: Tom Lane; Tatsuo Ishii
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] A proper fix for the
> conversion-function
On Tue, May 03, 2005 at 11:43:41PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > I wish you wouldn't since http://rrs.decibel.org uses it.
>
> Don't worry, I'll veto any immediate removal of functionality ;-)
Yes, but will core (or worse, that Bruce guy) over-ride your v
"John Hansen" <[EMAIL PROTECTED]> writes:
>> Are there any encodings we care about that require embedded zero
> bytes?
> UTF-8 does!
Surely not. Were you thinking of UTF-16 or UCS-2 or whatever it's
called?
regards, tom lane
---(end of broadcast)
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> As for CVS - if we can't do development the way we want using it then it's
> time to replace it.
CVS's capabilities (or lack of same) are completely unrelated to the
matter in hand. What we are talking about is packaging, ie what should
sensibly go o
Andrew,
> I was not around at the time of the libpq++/libpqxx issue. But, honestly,
> fear of making a wrong decision should not be a reason not to make one.
OK, *you* choose. I'm getting a little annoyed with how many people tell me
"oh, it should be easy to pick the stuff to include with sta
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Tue, May 03, 2005 at 10:22:08AM -0400, Merlin Moncure wrote:
>> 1998 when the oid played a larger role, it is now quite rightly
>> deprecated and my intention is to remove it from the userlock module.
> I wish you wouldn't since http://rrs.decibel.or
On 2005-05-04, "John Hansen" <[EMAIL PROTECTED]> wrote:
>> Are there any encodings we care about that require embedded zero
>> bytes?
>
> UTF-8 does!
nonsense
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of broadcast)
On Tue, 2005-05-03 at 18:06 -0700, Josh Berkus wrote:
> 1) If we start including everything that's "useful", where do we stop? There
> are enough pg add-ins to fill a CD -- 200 projects on GBorg and pgFoundry and
> others elsewhere. And some of them probably conflict with each other. Any
> de
> Are there any encodings we care about that require embedded zero
bytes?
UTF-8 does!
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Quoting Josh Berkus :
> Mischa,
>
> > Okay, although given the track record of page-based sampling for
> > n-distinct, it's a bit like looking for your keys under the
> streetlight,
> > rather than in the alley where you dropped them :-)
>
> Bad analogy, but funny.
Bad analogy? Page-
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> Going forward, though, I really think we need to revisit the API
>> for conversion functions. It seems a bit silly to have the
>> infrastructure to let ordinary users create conversions if they
>> can't create the functions needed to support them.
> Why
On Tue, May 03, 2005 at 10:22:08AM -0400, Merlin Moncure wrote:
> > On Mon, May 02, 2005 at 02:12:33PM -0400, Merlin Moncure wrote:
> > Well, there's nothing that says you have to actually refer to locks by
> > name. When I proposed this what I proposed is that the userlock module
> > provide a ded
Josh Berkus said:
> Dave, all:
>
>> This issue has come up before, and I opposed it then when the
>> interfaces were removed from the main tarball.
>> I really don't see the upside to reducing the size of the tarball at
>> the expense of ease of use. Â Seems to me we are
>> bending over backwards t
Dave, all:
> This issue has come up before, and I opposed it then when the interfaces
> were removed from the main tarball.
> I really don't see the upside to reducing the size of the tarball at the
> expense of ease of use. ÂSeems to me we are
> bending over backwards to make it easy for people w
Dag-Erling Smørgrav wrote:
It doesn't stress the system anywhere near enough to reveal bugs in,
say, the shared memory or semaphore code.
I agree -- I think we definitely need more tests for the concurrent
behavior of the system.
-Neil
---(end of broadcast)
John,
> But doesn't an index only sample one column at a time, whereas with
> page-based sampling, you can sample all of the columns at once.
Hmmm. Yeah, we're not currently doing that though. Another good idea ...
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
--
> I tried disabling public EXECUTE access on the built-in conversion
> functions, as we recommended yesterday, and found that it has one
> small problem: the conversion regression test fails. The test is
> expecting that unprivileged users can create conversions, but since
> CREATE CONVERSION requ
On Tue, 3 May 2005, Joshua D. Drake wrote:
Marc G. Fournier wrote:
On Tue, 3 May 2005, Dave Cramer wrote:
How come we have never seen anyone complain on the lists that the tarball
is too big ( or have we )
Because ppl are downloading the "split distributions" instead of the whole
tarball ... *ev
On Tue, 3 May 2005, Dave Cramer wrote:
So nobody has complained about the tarball being too big; yet we made it
harder to use just in case someone might complain ?
Made what harder to use? You don't like the split, download the full tar
ball ... both options are available to you ... myself, I f
Dave Held wrote:
> So it seems that a possible solution to that problem is to
> have a separate connection for keepalive packets that doesn't
> block and doesn't interfere with normal client/server
> communication.
What does this do that TCP keepalives don't? (other than add extra
connection man
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Dave Held
> Sent: Tuesday, May 03, 2005 3:41 PM
> To: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Feature freeze date for 8.1
>
> > -Original Message-
> > From: Tom La
Tom Lane <[EMAIL PROTECTED]> writes:
> "Dave Held" <[EMAIL PROTECTED]> writes:
>> How about an optional second connection to send keepalive pings?
>> It could be unencrypted and non-blocking. If authentication is
>> needed on the ping port (which it doesn't seem like it would need
>> to be), it c
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 03, 2005 4:20 PM
> To: Dave Held
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Feature freeze date for 8.1
>
>
> "Dave Held" <[EMAIL PROTECTED]> writes:
> > How about an optional second conn
Mischa,
> Okay, although given the track record of page-based sampling for
> n-distinct, it's a bit like looking for your keys under the streetlight,
> rather than in the alley where you dropped them :-)
Bad analogy, but funny.
The issue with page-based vs. pure random sampling is that to do, fo
Quoting Markus Schaber <[EMAIL PROTECTED]>:
> Hi, Josh,
>
> Josh Berkus wrote:
>
> > Yes, actually. We need 3 different estimation methods:
> > 1 for tables where we can sample a large % of pages (say, >= 0.1)
> > 1 for tables where we sample a small % of pages but are "easily
> estimated"
> >
On 5/3/05, Dave Held <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > From: Tom Lane [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, May 03, 2005 12:39 PM
> > To: Heikki Linnakangas
> > Cc: Hannu Krosing; Neil Conway; Oliver Jowett;
> > [EMAIL PROTECTED]; Peter Eisentraut; Alvaro Herrera;
"Dave Held" <[EMAIL PROTECTED]> writes:
> How about an optional second connection to send keepalive pings?
> It could be unencrypted and non-blocking. If authentication is
> needed on the ping port (which it doesn't seem like it would need
> to be), it could be very simple, like this:
> * client
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 03, 2005 3:36 PM
> To: Dave Held; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Feature freeze date for 8.1
>
> [...]
> Yes, this looks like good.But ;
>
> 1. Do client interfaces
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> The whole point of make check is to check correctness, not
> performance.
I understand that.
> It has concurrent loading as well.
It doesn't stress the system anywhere near enough to reveal bugs in,
say, the shared memory or semaphore code.
On Tue, 3 May 2005 13:02:46 -0500
"Dave Held" <[EMAIL PROTECTED]> wrote:
>How about an optional second connection to send keepalive
>pings?
>It could be unencrypted and non-blocking. If
authentication is needed
>on the ping port (which it doesn't seem like itwould
needto be),
>it could be very
On Tue, 2005-05-03 at 14:26 -0400, Mitch Pirtle wrote:
> If you guys are planning on running Gforge, then you better make 'box' plural.
>
> I'm running MamboForge.net, and the poor thing is getting beat into
> the cold hard earth every day. We (Mambo) should really have two
> servers, at least to
So nobody has complained about the tarball being too big; yet we made
it harder to use just in case someone might complain ?
--dc--
Marc G. Fournier wrote:
On Tue, 3 May 2005, Dave Cramer wrote:
How come we have never seen anyone complain on the lists that the
tarball is too big ( or have we )
Marc G. Fournier wrote:
On Tue, 3 May 2005, Dave Cramer wrote:
How come we have never seen anyone complain on the lists that the
tarball is too big ( or have we )
Because ppl are downloading the "split distributions" instead of the
whole tarball ... *every* PostgreSQL related port in FreeBSD use
On Tue, 3 May 2005, Dave Cramer wrote:
How come we have never seen anyone complain on the lists that the tarball is
too big ( or have we )
Because ppl are downloading the "split distributions" instead of the whole
tarball ... *every* PostgreSQL related port in FreeBSD uses the
split-dists (only
On Tuesday 03 May 2005 13:51, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Is telling the rpm maintainers to go fix their rpm's an option? As has
> > been hashed out before, the only thing that makes plphp different from
> > other pl's is that some of the current packagers are ta
Never mind. multi is in effect a TransactionId in that code path, and thus
the assertion makes sense. Sorry for the noise.
On Tue, 3 May 2005, Heikki Linnakangas wrote:
There's an assertion in multixact.c, MultiXactIdExpand function, line 273:
Assert(!TransactionIdEquals(multi, xid));
where
Marc G. Fournier wrote:
On Tue, 3 May 2005, Marc G. Fournier wrote:
On Tue, 3 May 2005, Joshua D. Drake wrote:
My primary desire is to avoid having to download several Meg of tar
ball(s) in order to add a module to an existing server ... if that
can be accomplished, then my main objection to ad
Marc G. Fournier wrote:
How ugly. [remaining comments unprintable]
That's a matter of opinion ... in our environment, it means that
clients can enable/disable PHP features on a per VM basis without
having to build a new PHP binary for each ... *shrug*
Different issue. You can do that on RH
That's a matter of opinion ... in our environment, it means that clients
can enable/disable PHP features on a per VM basis without having to
build a new PHP binary for each ... *shrug*
Gentoo also does this :)
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> No problem ... shall I write a patch, or did you do it already?
I'll take care of it --- wouldn't take much longer than applying
someone else's patch anyway ...
regards, tom lane
---(end of broadcast)---
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> > Just to point it out, Debian handles circular dependencies like these
> > without too much difficulty. It's really only an issue when first
> > building the various packages, and then you just build one without
> > all the su
On Tue, May 03, 2005 at 02:48:20PM -0400, Tom Lane wrote:
> I wrote:
> > Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> >> Isn't this bogus?
>
> > No. Note the comment immediately above, as well as the header comment
> > for the function.
>
> OTOH, now that I think about it there's no reason w
On Tue, 3 May 2005, Andrew Dunstan wrote:
Marc G. Fournier wrote:
Now it is true that you don't need this in for plphp. But if you want php
to have pg client support you need pg built first. And no sane packager is
going to build php twice.
Actually, if you look through FreeBSD ports, this is e
* Marc G. Fournier ([EMAIL PROTECTED]) wrote:
> On Tue, 3 May 2005, Joshua D. Drake wrote:
> >We could break out all of the pls at that point? Where if you downloaded
> >postgresql-opt you would get plPHP, plPerl etc...
>
> Optimally, you would get rid of -opt altogether, and leave it as the
> i
Stephen Frost wrote:
> Just to point it out, Debian handles circular dependencies like these
> without too much difficulty. It's really only an issue when first
> building the various packages, and then you just build one without
> all the support initially, build the other, then rebuild the first
* Marc G. Fournier ([EMAIL PROTECTED]) wrote:
> On Tue, 3 May 2005, Andrew Dunstan wrote:
> >Now it is true that you don't need this in for plphp. But if you want php
> >to have pg client support you need pg built first. And no sane packager is
> >going to build php twice.
>
> Actually, if you l
Marc G. Fournier wrote:
Now it is true that you don't need this in for plphp. But if you want
php to have pg client support you need pg built first. And no sane
packager is going to build php twice.
Actually, if you look through FreeBSD ports, this is exactly what
happens ... when you build /u
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> There's an assertion in multixact.c, MultiXactIdExpand function, line 273:
> Assert(!TransactionIdEquals(multi, xid));
> where multi is a MultiXactId and xid is a TransactionId.
> Isn't this bogus?
No. Note the comment immediately above,
I wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> Isn't this bogus?
> No. Note the comment immediately above, as well as the header comment
> for the function.
OTOH, now that I think about it there's no reason whatever for that
bizarre call convention. Let's split the function into t
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Is telling the rpm maintainers to go fix their rpm's an option? As has
> > been hashed out before, the only thing that makes plphp different from
> > other pl's is that some of the current packagers are taking sho
On Tue, May 03, 2005 at 09:33:30PM +0300, Heikki Linnakangas wrote:
> There's an assertion in multixact.c, MultiXactIdExpand function, line 273:
>
>Assert(!TransactionIdEquals(multi, xid));
>
> where multi is a MultiXactId and xid is a TransactionId.
>
> Isn't this bogus? If I understand
On Tue, 3 May 2005, Andrew Dunstan wrote:
Robert Treat wrote:
On Tuesday 03 May 2005 13:46, Andrew Dunstan wrote:
Robert Treat wrote:
Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that so
There's an assertion in multixact.c, MultiXactIdExpand function, line 273:
Assert(!TransactionIdEquals(multi, xid));
where multi is a MultiXactId and xid is a TransactionId.
Isn't this bogus? If I understand the code correctly, multixactids and
regular xids live in completely separate id sp
* Robert Treat ([EMAIL PROTECTED]) wrote:
> If your compiling it from source, it works similarly to perl... you only need
> pg when compiling pg support into php, but you dont need tthis in for plphp.
>
> The problem stems from things like the php rpm spec, which has a module
> dependency on po
Mitch Pirtle wrote:
On 4/30/05, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
If money's not an issue anymore, can we get a bigger box to host
pgfoundry on then? :)
If you guys are planning on running Gforge, then you better make 'box' plural.
Well we already run it :) For pgFoundry and you are correct
Robert Treat wrote:
On Tuesday 03 May 2005 13:46, Andrew Dunstan wrote:
Robert Treat wrote:
Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are ta
On Tue, 3 May 2005, Marc G. Fournier wrote:
On Tue, 3 May 2005, Joshua D. Drake wrote:
My primary desire is to avoid having to download several Meg of tar
ball(s) in order to add a module to an existing server ... if that can be
accomplished, then my main objection to adding things to the core C
On Tue, 3 May 2005, Joshua D. Drake wrote:
My primary desire is to avoid having to download several Meg of tar ball(s)
in order to add a module to an existing server ... if that can be
accomplished, then my main objection to adding things to the core CVS are
eliminated ...
I guess I don't see t
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 03, 2005 12:39 PM
> To: Heikki Linnakangas
> Cc: Hannu Krosing; Neil Conway; Oliver Jowett;
> [EMAIL PROTECTED]; Peter Eisentraut; Alvaro Herrera;
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Fea
On Tuesday 03 May 2005 13:46, Andrew Dunstan wrote:
> Robert Treat wrote:
> >Is telling the rpm maintainers to go fix their rpm's an option? As has
> >been hashed out before, the only thing that makes plphp different from
> >other pl's is that some of the current packagers are taking shortcuts
> >
Robert Treat <[EMAIL PROTECTED]> writes:
> Is telling the rpm maintainers to go fix their rpm's an option? As has
> been hashed out before, the only thing that makes plphp different from
> other pl's is that some of the current packagers are taking shortcuts
> with the packaging scripts which intr
Robert Treat wrote:
Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are taking shortcuts
with the packaging scripts which introduces dependency issues. IM
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Does statement_timeout fire on that scenario? How about the new
> transaction_timeout option discussed in other threads?
Probably neither, since very likely you aren't in a transaction at all.
I'd not expect the server to send these messages except
Dave Held wrote:
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: Monday, May 02, 2005 7:05 PM
To: [EMAIL PROTECTED]
Cc: Dave Held; [EMAIL PROTECTED];
pgsql-hackers@postgresql.org
Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS:
Increased
company involv
My primary desire is to avoid having to download several Meg of tar
ball(s) in order to add a module to an existing server ... if that can
be accomplished, then my main objection to adding things to the core CVS
are eliminated ...
I guess I don't see the problem of the PostgreSQL distribution b
On Tue, 3 May 2005, Joshua D. Drake wrote:
I don't mind if its *also* ship'd in the main distribution as well, I just
want that 'quick to download since I already have the libraries/headers
installed' package ...
We could break out all of the pls at that point? Where if you downloaded
postgresql
Peter Eisentraut wrote:
Joshua D. Drake wrote:
Not really that ugly. It is just an extra compile step. Besides
you don't have to package it just because it is in the Tarball.
Since you keep raising that point: Not packaging something is not a
valid solution to something being hard to package.
Exc
On Tue, 2005-05-03 at 12:40, Peter Eisentraut wrote:
> Joshua D. Drake wrote:
> > Not really that ugly. It is just an extra compile step. Besides
> > you don't have to package it just because it is in the Tarball.
>
> Since you keep raising that point: Not packaging something is not a
> valid sol
On Tue, 3 May 2005, Thomas Hallgren wrote:
Marc G. Fournier wrote:
On Tue, 3 May 2005, Tom Lane wrote:
I think the idea is that plphp would be in our CVS, but would not be
shipped as part of the main tarball, rather as its own separate tarball.
That is what I'm hoping for ... if it can be shipped
I don't mind if its *also* ship'd in the main distribution as well, I
just want that 'quick to download since I already have the
libraries/headers installed' package ...
Any other PL's not currently in your CVS that you might consider to
bring in while you're at it?
/me heres the sound of the p
I tried disabling public EXECUTE access on the built-in conversion
functions, as we recommended yesterday, and found that it has one
small problem: the conversion regression test fails. The test is
expecting that unprivileged users can create conversions, but since
CREATE CONVERSION requires you t
I don't mind if its *also* ship'd in the main distribution as well, I
just want that 'quick to download since I already have the
libraries/headers installed' package ...
We could break out all of the pls at that point? Where if you downloaded
postgresql-opt you would get plPHP, plPerl etc...
Si
Peter Eisentraut wrote:
Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.
How will a "separate compile stage" wo
Marc G. Fournier wrote:
On Tue, 3 May 2005, Tom Lane wrote:
I think the idea is that plphp would be in our CVS, but would not be
shipped as part of the main tarball, rather as its own separate tarball.
That is what I'm hoping for ... if it can be shipped as a seperate
tarball, my arguments *again
On Tue, 3 May 2005, Tom Lane wrote:
I am a tad worried about the possibility that if the client does nothing
for long enough, the TCP output buffer will fill causing the backend to
block at send(). A permanently blocked backend is bad news from a
performance point of view (it degrades the sinval p
mohammad izwan ibrahim wrote:
> does postgresql support distributed database
The answer is no, but please pick the correct mailing list for such
questions in the future.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)--
hello there
does postgresql support distributed database
tq
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Joshua D. Drake wrote:
> Not really that ugly. It is just an extra compile step. Besides
> you don't have to package it just because it is in the Tarball.
Since you keep raising that point: Not packaging something is not a
valid solution to something being hard to package.
--
Peter Eisentraut
h
Hi, Josh,
Josh Berkus wrote:
> Yes, actually. We need 3 different estimation methods:
> 1 for tables where we can sample a large % of pages (say, >= 0.1)
> 1 for tables where we sample a small % of pages but are "easily estimated"
> 1 for tables which are not easily estimated by we can't afford
> -Original Message-
> From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 02, 2005 7:05 PM
> To: [EMAIL PROTECTED]
> Cc: Dave Held; [EMAIL PROTECTED];
> pgsql-hackers@postgresql.org
> Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS:
> Increased
> company involv
Stephen Frost wrote:
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency probl
On Tue, 3 May 2005, Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive de
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 03, 2005 9:31 AM
> To: Hannu Krosing
> Cc: Heikki Linnakangas; Neil Conway; Oliver Jowett;
> [EMAIL PROTECTED]; Peter Eisentraut; Alvaro Herrera;
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Feat
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
>> I posted this compromise and no one replied so I thought everyone was OK
>> with it. It gets it into CVS, but has a separate compile stage to deal
>> with the recursive dependency problem.
> How
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Why actual rows=0?
I couldn't think of any reasonably cheap way to count the actual rows
(especially in the presence of lossy bitmaps), so I just punted.
regards, tom lane
---(end of broadcast)
Hannu Krosing <[EMAIL PROTECTED]> writes:
>> What we can do in PostgreSQL is to introduce an application-level
>> heartbeat. A simple "Hello world" message sent from server to client that
>> the client would ignore would do the trick.
> Actually we would need a round-trip indicator (some there-a
Are there any regression tests or unit tests beyond 'make check', or
possibly benchmarks which not only measure performance but also verify
that the results are correct? I have patches which I want to test
under high load from multiple concurrent clients, so 'make check'
isn't enough. Google has
> On Mon, May 02, 2005 at 02:12:33PM -0400, Merlin Moncure wrote:
> Well, there's nothing that says you have to actually refer to locks by
> name. When I proposed this what I proposed is that the userlock module
> provide a dedicated means to map a lock name to a lock number, and
> reserve one of t
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
> Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
> > I posted this compromise and no one replied so I thought everyone was OK
> > with it. It gets it into CVS, but has a separate compile stage to deal
> > with the recursive dependency problem.
>
1 - 100 of 110 matches
Mail list logo
