Ahh. I forgot to detail my ideas on this. It seems to me that we cannot
drop a table space until the directory is empty.
Agreed.
How would it get to be empty? Are you thinking of some sort of connect
database to tablespace and disconnect database from tablespace
commands that would
I'm not sure I understand you correctly. The SQL standard says you can
call your statement as this:
exec sql at CONNECTION select 1;
Here CONNECTION of course is a string, the name of the connection. So,
yes, we have to maintain that list to make sure we get the right
connection.
I
Michael Meskes wrote:
On Mon, Feb 23, 2004 at 09:27:40PM +0530, Shridhar Daithankar wrote:
What I wonder is, do we really need to maintain that level of lookup? Can't we
just say a connection is a 'struct connection *' which should be opaque and
should not be touched or poked inside, just like
I am asking for CONNECTION being a variable of data type 'connection *' rather
than 'const char *'. That would avoid name lookups.
Is that out of spec?
Yes, but the preprocessor could still add an optimization ala 'connection *' for
the hardcoded cases (exec sql set connection 'myconn1';
Zeugswetter Andreas SB SD wrote:
I am asking for CONNECTION being a variable of data type 'connection *' rather
than 'const char *'. That would avoid name lookups.
Is that out of spec?
Yes, but the preprocessor could still add an optimization ala 'connection *' for
the hardcoded cases (exec sql
I do not intend to undertake raw disk tablespaces for 7.5. I'd be
interested if anyone could provide some real world benchmarking of file
system vs. raw disk. Postgres benefits a lot from kernel file system cache
at the moment.
Yes, and don't forget that pg also relys on the OS for grouping
-Original Message-
From: Greg Stark [mailto:[EMAIL PROTECTED]
Sent: Friday, February 27, 2004 12:17 AM
To: [EMAIL PROTECTED]
Subject: Re: [HACKERS] [pgsql-www] Collaboration Tool Proposal
[...snip...]
I might suggest again RT. It's open source and has serious commercial
traction.
On Thu, Feb 26, 2004 at 17:09:21 -0500,
Tom Lane [EMAIL PROTECTED] wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Should we have a pgmon process that watches the postmaster
and restarts it if required?
I doubt it; in practice the postmaster is *very* reliable (because it
doesn't do much),
Josh Berkus wrote:
Tom,
Possibly workable, but what's your definition of registered user?
Signing up via a webform, getting an e-mailed password back, logging in.
I'd hope that anyone subscribed to any of the mailing lists would be
considered registered, for instance. Not sure if
On Friday 27 February 2004 19:59, Andrew Dunstan wrote:
I believe it should not be hard to do a one-time bulk registration of
everyone on the lists, if that was desired.
I agree. If possible we could also run postgresql registration system where we
can track general usage of postgresql on
On Fri, 27 Feb 2004 09:17:13 -0500
Bort, Paul [EMAIL PROTECTED] wrote:
-Original Message-
From: Greg Stark [mailto:[EMAIL PROTECTED]
[...snip...]
I might suggest again RT. It's open source and has serious
commercial traction. The postgres port needs a lot of work for it to
Tom Lane [EMAIL PROTECTED] writes:
As for raising the barrier, you can presently submit bug reports to
pgsql-bugs by either mail or webform. Most of the bug trackers I'm
aware of are webform-only. I don't consider that a step forward,
especially since a webform isn't very conducive to
I first tried to take care of the problem by removing -L $libpath
from the arg list passed to createlang. This worked in a way that
probin in pg_proc had value $libdir/plpgsql.
Later it turned out the embedded library path was used, and install
failed when there was no access to the build
On Fri, Feb 27, 2004 at 04:22:33PM +0530, Shridhar Daithankar wrote:
How about, allowing 'connection *'? If somebody puts a 'connection *' there
it is used. If it is a string a name search is performed. Best of both
worlds.
How shall anyone put a pointer to a connection struct inside the SQL
Sorry, I forgot to mention that I also considered bypassing createlang
and using direct sql:
... RETURNS LANGUAGE_HANDLER AS '${pglib}/plpgsql' ...
but I'm not sure if this is much better then updating pg_proc.
-
I first tried to take care of the problem by removing -L $libpath
On Friday 27 February 2004 20:54, Michael Meskes wrote:
On Fri, Feb 27, 2004 at 04:22:33PM +0530, Shridhar Daithankar wrote:
How about, allowing 'connection *'? If somebody puts a 'connection *'
there it is used. If it is a string a name search is performed. Best of
both worlds.
How shall
On Fri, 27 Feb 2004, Zeugswetter Andreas SB SD wrote:
Ahh. I forgot to detail my ideas on this. It seems to me that we cannot
drop a table space until the directory is empty.
Agreed.
How would it get to be empty? Are you thinking of some sort of connect
database to tablespace
On Fri, 27 Feb 2004, Gavin Sherry wrote:
On Thu, 26 Feb 2004, Alex J. Avriette wrote:
On Thu, Feb 26, 2004 at 11:22:28PM +1100, Gavin Sherry wrote:
Certainly, table spaces are used in many ways in oracle, db2, etc. You can
mirror data across them, have different buffer sizes for
Michael Meskes [EMAIL PROTECTED] writes:
At this point I think our first question is whether flex 2.5.31 is
correctly detecting a hole in the ecpg lexer rules that was missed by
flex 2.5.4, or whether the warning is simply wrong.
Yes, that's it. The big problem seems to be that flex does not
scott.marlowe [EMAIL PROTECTED] writes:
On Fri, 27 Feb 2004, Zeugswetter Andreas SB SD wrote:
How would it get to be empty? Are you thinking of some sort of connect
database to tablespace and disconnect database from tablespace
commands that would respectively create and delete the
scott.marlowe [EMAIL PROTECTED] writes:
Is possible / reasonable / smart and or dumb to look at implementing the
tablespaces as riding atop the initlocation handled stuff.
In my mind, one of the main benefits of this work will be that we'll be
able to get *rid* of the initlocation stuff. It's
On Fri, 27 Feb 2004, Tom Lane wrote:
scott.marlowe [EMAIL PROTECTED] writes:
Is possible / reasonable / smart and or dumb to look at implementing the
tablespaces as riding atop the initlocation handled stuff.
In my mind, one of the main benefits of this work will be that we'll be
able
Folks:
ALTERNATIVE BUG TRACKERS:
Jira: Core did look at and consider (and debate) Jira. Atlassian are
enthusiastic PostgreSQL supporters and offered to host Jira for us.
However, Jira is not OSS and for various reasons it would be difficult to
host a Jira installation at Hub.org.
Paul,
Your main concern about RT isn't true, at least here at my office. I
installed RT, with no prior experience with any OSS tracker, back in
October, and it worked on PostgreSQL the first time. (PostgreSQL support was
one of the main reasons I chose it to track issues on my
Greg Stark wrote:
I also dislike BZ for aesthetic reasons. If one person is editing a ticket
while another person updates the same ticket, it refuses your edits and you
have to start all over. I think all the updates are stored in one big field.
AFAICS it's one row per comment, at least in
Tom Lane wrote:
Red Hat's still shipping 2.5.4a according to a quick look...
Well Red Hat's still ship Postgres 7.3.4 ...
I'm not considering anymore RH to be up to date with various versions
:-(
Gaetano
Not to jump immediately to RH's defense, but Fedora Core 2 (currently in
beta)
My apologies, then! I was operating off of the statements
of others, and the
fact that the only RT impelementations I've used were running
on MySQL. So,
questions:
1) can you compare/contrast RT vs. BZ vs. Simplified
bug-tracking, like
GForge?
I've used Bugzilla for
When compiling the 2004-02-27 snapshot with make -j 2, the compile of
libpq fails with the following error.
dlltool --export-all --output-def pq.def fe-auth.o fe-connect.o fe-exec.o
fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o
pqsignal.o fe-secure.o dllist.o md5.o
I do not intend to undertake raw disk tablespaces for 7.5. I'd be
interested if anyone could provide some real world benchmarking of file
system vs. raw disk. Postgres benefits a lot from kernel file system
cache
at the moment.
Yes, and don't forget that pg also relys on the OS for
On Fri, 27 Feb 2004 [EMAIL PROTECTED] wrote:
I do not intend to undertake raw disk tablespaces for 7.5. I'd be
interested if anyone could provide some real world benchmarking of file
system vs. raw disk. Postgres benefits a lot from kernel file system
cache
at the moment.
Yes, and
Bort, Paul wrote:
My apologies, then! I was operating off of the statements
of others, and the
fact that the only RT impelementations I've used were running
on MySQL. So,
questions:
1) can you compare/contrast RT vs. BZ vs. Simplified
bug-tracking, like
GForge?
I've used
Mikhail,
For a standalone bug/issue tracking tool take a look on
http://roundup.sourceforge.net
I don't see PostgreSQL support listed -- just SQLite and MySQL.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
Gavin Sherry [EMAIL PROTECTED] writes:
I do not intend to work on such a system for the initial introduction of
table spaces. The problem is, of course, knowing when you're actually out
of space in a table space in any given transaction.
It should not be that hard, at least not on local
On Thu, Feb 26, 2004 at 09:16:03AM -0500, Tom Lane wrote:
Karel Zak [EMAIL PROTECTED] writes:
I think possible solution is special function used ORDER BY clause
which knows to switch by safe way to wanted locales, convert string by
strxfrm() and switch back to backend locales.
34 matches
Mail list logo
