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 fi
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)--
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 Bugzilla
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 mome
>
>> 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
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
>
> 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
> 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 (current
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 th
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
> PostgreSQL
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. We're
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
"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.
Sort of related, I was thinking about adding some more thread-related
code such that if a connection wasn't explicitely specified then the
last connection SET or CONNECTed to for the current thread is used,
rather than just the "last connection".
But yeah, specifying the connection by variable (be
"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 dele
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 d
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 siz
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
> > databa
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.
>
> H
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 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 S
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 en
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
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
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 var
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 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
> does
> -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
> tr
> 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 groupi
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 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'
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 local
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 PG
> 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
> > 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 th
35 matches
Mail list logo
