On Tue, Aug 21, 2001 at 10:00:50AM +0900, Tatsuo Ishii wrote:
> > I found some other things:
> >
> > - why database encoding for new DB check 'createdb' script and not
> > CREATE DATABASE statement? (means client only encodings, like BIG5)?
> >
> > Bug?
>
> Oh, that must be a bug. Do yo wa
On Tue, Aug 21, 2001 at 10:00:21AM +0900, Hiroshi Inoue wrote:
> Karel Zak wrote:
> >
> > I found some other things:
> >
> > - ODBC -- here is some multibyte stuff too. Why ODBC code don't use
> > pg_wchar.h where is all defined? In odbc/multibyte.h is again defined
> > all encoding identif
Hi all,
I'm currently trying to develop a log analyzer for PostgreSQL logs and at
the first
stage I'm finding a little problem with the postgresql.conf option
log_timestamp.
The problem is that if this option is set to false we have no idea of when
the backend
is started:
DEBUG: database syste
> On Tue, Aug 21, 2001 at 10:00:50AM +0900, Tatsuo Ishii wrote:
> > > I found some other things:
> > >
> > > - why database encoding for new DB check 'createdb' script and not
> > > CREATE DATABASE statement? (means client only encodings, like BIG5)?
> > >
> > > Bug?
> >
> > Oh, that must
Tom Lane wrote:
>
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > NOTICE: ctid (0,5) xmin 645188 xmax 645190 cmin 2 cmax 2
> > This is odd too, since xmax > 0 or cmax > 0 should never happen with
> > visible tuples, in my understanding.
>
> That's what the docs presently say, but they're in erro
If anyone was concerned about our bug database being visible and giving
the impression we don't fix any bugs, see this URL:
http://www.isthisthingon.org/nisca/postgres.html
Not only does it show the problems he had with PostgreSQL, he uses our
bug list as an example of how PostgreSQL isn
Thus spake Bruce Momjian
> If anyone was concerned about our bug database being visible and giving
> the impression we don't fix any bugs, see this URL:
>
> http://www.isthisthingon.org/nisca/postgres.html
Jeez, Louise. Talk about a blaming the tools because you don't know
anything about
>
>We better remove that web page soon:
>
> http://www.ca.postgresql.org/bugs/bugs.php?2
>
Do we have any pages to alter the status of bugs, or assign them? There are
a number of bugs in the list that I know are fixed.
Phili
On Tue, 21 Aug 2001, Bruce Momjian wrote:
> If anyone was concerned about our bug database being visible and giving
> the impression we don't fix any bugs, see this URL:
>
> http://www.isthisthingon.org/nisca/postgres.html
>
> Not only does it show the problems he had with PostgreSQL, he us
At 08:32 21/08/01 -0400, Vince Vielhaber wrote:
>
>Yes but noone was interested in it. It's still there but you're really
>the first to show interest in about a year.
>
That's good (and depressing); where are they?
Philip Warner
On Tue, 21 Aug 2001, Philip Warner wrote:
> >
> >We better remove that web page soon:
> >
> > http://www.ca.postgresql.org/bugs/bugs.php?2
> >
>
> Do we have any pages to alter the status of bugs, or assign them? There are
> a number of bugs in the list that I know are fixed.
Yes but noone w
On Tue, 21 Aug 2001, Bruce Momjian wrote:
> If anyone was concerned about our bug database being visible and giving
> the impression we don't fix any bugs, see this URL:
>
> http://www.isthisthingon.org/nisca/postgres.html
>
> Not only does it show the problems he had with PostgreSQL, he us
At 08:22 21/08/01 -0400, Vince Vielhaber wrote:
>
>I removed the link to the page a few days ago. I guess I should disable
>it as well. Woulda been a whole lot easier if the database was just
>updated periodically.
>
I don't think this is a good solution. We really do need a list of bugs. We
pr
> > > Ok the functionality as well as the menu item are gone. You do realize
> > > it's going to give the impression that we're trying to hide something,
> > > don't you?
> >
> > Uh, what choices do we have? Do we want to update that database, seeing
> > as only a small percentage of bug reports
On Tue, 21 Aug 2001, Bruce Momjian wrote:
> > On Tue, 21 Aug 2001, Bruce Momjian wrote:
> >
> > > If anyone was concerned about our bug database being visible and giving
> > > the impression we don't fix any bugs, see this URL:
> > >
> > > http://www.isthisthingon.org/nisca/postgres.html
> > >
We could install the Postgres version of Bugzilla.
Yes, there's a version that runs on Postgres rather than MySQL.
That way we don't have to maintain the bug system.
> Ok the functionality as well as the menu item are gone. You do realize
> it's going to give the impression that we're trying to
> On Tue, 21 Aug 2001, Bruce Momjian wrote:
>
> > If anyone was concerned about our bug database being visible and giving
> > the impression we don't fix any bugs, see this URL:
> >
> > http://www.isthisthingon.org/nisca/postgres.html
> >
> > Not only does it show the problems he had with Pos
> >
> >It's up to the group to decide. If we have a database of bugs, I think
> >it has to be complete. I think a partial list is worse than no list at
> >all.
> >
>
> I disagree. Unless you are omniscient, we will only ever have a partial list.
>
> Perhaps more importantly, the more common o
On Tue, 21 Aug 2001, Colin 't Hart wrote:
> We could install the Postgres version of Bugzilla.
> Yes, there's a version that runs on Postgres rather than MySQL.
> That way we don't have to maintain the bug system.
And how does it know when bugs are fixed?
Vince.
--
Philip Warner wrote:
> I don't think this is a good solution. We really do need a list of bugs.
We
> probably need to list status and the releases they apply to.
Bugzilla can do this -- it has the concept of a Milestone and a Version.
> I don't think anybody but the most naieve (or biased) user
> > Can someone point me to a bug that is _not_ on the TODO list? If not,
> > what does a complete bug database do for us except list reported bugs
> > and possible workarounds.
>
> Do you actually expect someone to go thru the 400+ items in the database
> and compare them to the TODO list? Se
On Tuesday 21 August 2001 05:30, Andy wrote:
> Where is the MX RPM ? I didn't see this in the 7.1.3 RPM, for RH 7.1 and
> also Mdk 8.0. And by the way, it was asked when I tried to install the
> PostgreSQL Python module. I know 7.1.2 RH 7.1 has this MX RPM.
The 7.1 DB-API 2.0 Python client _requi
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > We could try going the other way, attaching URL's to the TODO items so
> > people can get more information about an existing bug.
>
> That might be worth doing, but I think it's mostly orthogonal to the
> question of a bug database. The set of prob
> On Tue, 21 Aug 2001, Bruce Momjian wrote:
>
> > > > Yes, but we have to add items that don't come in through the database,
> > > > and mark them as done/duplicates if we want it to be useful.
> > >
> > > Not necessarily. If someone discovers one that's not in the database
> > > they'll add it.
How about we trial it, but with the understanding that bugs we fix will
be marked as such?
After all, every bug is given an ID, so whomever fixes the bug with that
ID should also mark it off.
Looking at the present situation, it seems we began a good idea, but
never really followed through with
On Tue, 21 Aug 2001, Tom Lane wrote:
> Vince Vielhaber <[EMAIL PROTECTED]> writes:
> >> That is the real question. Do we want to rely more heavily on a bug
> >> database rather than the email lists? I haven't heard many say they
> >> want that.
>
> > The database keeps track of it. When someon
A web-based interface allows people to submit bug reports they might
otherwise not be able to report. Not everyone is able/willing to
sign-up to a mailing list, nor have newsfeed access.
The one we have (had) allows the reporting, but has the flaw of not
showing when something has been done abou
MySQL has to first add some features in order to have some bugs, don't they?
:-)
Some people crack me up in their opinions.. If it took him 6 hours to figure
out "int8" then I'm not really interested in anything else he has to say...
Lord...
-Mitch
- Original Message -
From: "Bruce Mom
On Tue, 21 Aug 2001, Bruce Momjian wrote:
> > How about we trial it, but with the understanding that bugs we fix will
> > be marked as such?
> >
> > After all, every bug is given an ID, so whomever fixes the bug with that
> > ID should also mark it off.
> >
> > Looking at the present situation, i
> > Yes, but we have to add items that don't come in through the database,
> > and mark them as done/duplicates if we want it to be useful.
>
> Not necessarily. If someone discovers one that's not in the database
> they'll add it. If it's already fixed it'll get closed out but will
> still be i
Vince Vielhaber <[EMAIL PROTECTED]> writes:
>> That is the real question. Do we want to rely more heavily on a bug
>> database rather than the email lists? I haven't heard many say they
>> want that.
> The database keeps track of it. When someone uses the bugtool to
> report a bug it's mailed
Bruce Momjian writes:
> OK, what value does a bug database have over a TODO list?
The former is a database, the latter is a flat-text file. The former is
mult-user, the latter is single-user. You figure out the rest. ;-)
Seriously, IMHO a real bug database would be useful. A number of
soluti
On Tue, 21 Aug 2001, Lamar Owen wrote:
> On Tuesday 21 August 2001 11:11, Bruce Momjian wrote:
> > OK, what value does a bug database have over a TODO list?
>
> The TODO list isn't just a list of bugs that need fixing.
>
> A bug database is just that -- a list of bugs in existing features. While
- Original Message -
From: Bruce Momjian <[EMAIL PROTECTED]>
Sent: Tuesday, August 21, 2001 8:48 AM
> > On Tue, 21 Aug 2001, Bruce Momjian wrote:
> >
> > >
> > > Not only does it show the problems he had with PostgreSQL, he uses our
> > > bug list as an example of how PostgreSQL isn't
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> Some of the discussions could go on for weeks. Are you saying that
> wading thru a few hundred posts to find out what a solution was is
> better than a quick searchable summary?
Given a threaded index, you aren't wading through "a few hundred posts".
Hiroshi Inoue writes:
> I would object even if there's such a way.
> People in Japan have hardly noticed that the strange
> behabior is due to the strange locale(LC_COLLATE).
I don't think we should design our systems in a way that inconveniences
many users because some users are using broken op
On Tue, 21 Aug 2001, Bruce Momjian wrote:
> > > Yes, but we have to add items that don't come in through the database,
> > > and mark them as done/duplicates if we want it to be useful.
> >
> > Not necessarily. If someone discovers one that's not in the database
> > they'll add it. If it's alre
> > > Do you actually expect someone to go thru the 400+ items in the database
> > > and compare them to the TODO list? Seems to me that's something the
> > > maintainer of the TODO list would be doing. Can you point me to the form
> > > that gets something on the TODO list that the average us
> yep:
> lock "tablename.colname.val=1"
> select count(*) from tablename where colname=1
> If no rows, insert, else update.
> (dunno if the locks would scale to a scenario with hundreds
> of concurrent inserts - how many user locks max?).
I don't see problem here - just a few bytes in shmem for
k
On Tue, 21 Aug 2001, Bruce Momjian wrote:
> > > Can someone point me to a bug that is _not_ on the TODO list? If not,
> > > what does a complete bug database do for us except list reported bugs
> > > and possible workarounds.
> >
> > Do you actually expect someone to go thru the 400+ items in th
Tom Lane wrote:
>
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> That's what the docs presently say, but they're in error --- nonzero
> >> xmax could represent a not-yet-committed deleting xact (or one that
> >> did commit, but not in your snapshot); or it could be from a de
>
>It's up to the group to decide. If we have a database of bugs, I think
>it has to be complete. I think a partial list is worse than no list at
>all.
>
I disagree. Unless you are omniscient, we will only ever have a partial list.
Perhaps more importantly, the more common ones will be in the
On Tue, 21 Aug 2001, Bruce Momjian wrote:
> > >
> > >It's up to the group to decide. If we have a database of bugs, I think
> > >it has to be complete. I think a partial list is worse than no list at
> > >all.
> > >
> >
> > I disagree. Unless you are omniscient, we will only ever have a partial
> > That is the real question. Do we want to rely more heavily on a bug
> > database rather than the email lists? I haven't heard many say they
> > want that.
>
> The database keeps track of it. When someone uses the bugtool to
> report a bug it's mailed to the bugs list.
Yes, but we have to
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> That's what the docs presently say, but they're in error --- nonzero
>> xmax could represent a not-yet-committed deleting xact (or one that
>> did commit, but not in your snapshot); or it could be from a deleting
>> xact that rolled ba
On Tue, 21 Aug 2001, Bruce Momjian wrote:
> > > That is the real question. Do we want to rely more heavily on a bug
> > > database rather than the email lists? I haven't heard many say they
> > > want that.
> >
> > The database keeps track of it. When someone uses the bugtool to
> > report a b
Philip Warner <[EMAIL PROTECTED]> writes:
> Please reinstate the page, and allow some facility to edit them. I will try
> to work through them *slowly* to verify they are reproducible/not
> reproducible in 7.1.3 and in the current CVS, then mark them as fixed in
> the appropriate release. Hopefull
On Tue, 21 Aug 2001, Bruce Momjian wrote:
> > > Yes, but we have to add items that don't come in through the database,
> > > and mark them as done/duplicates if we want it to be useful.
> >
> > Not necessarily. If someone discovers one that's not in the database
> > they'll add it. If it's alre
> Vince Vielhaber <[EMAIL PROTECTED]> writes:
> > Some of the discussions could go on for weeks. Are you saying that
> > wading thru a few hundred posts to find out what a solution was is
> > better than a quick searchable summary?
>
> Given a threaded index, you aren't wading through "a few hun
On Tue, Aug 21, 2001 at 09:51:29AM -0400, Bruce Momjian wrote:
> > >
> > >It's up to the group to decide. If we have a database of bugs, I think
> > >it has to be complete. I think a partial list is worse than no list at
> > >all.
> > >
> >
> > I disagree. Unless you are omniscient, we will onl
On Tuesday 21 August 2001 11:59, Vince Vielhaber wrote:
> On Tue, 21 Aug 2001, Lamar Owen wrote:
> > Red Hat makes mission-critical use of bugzilla running on Oracle. See
> > bugzilla.redhat.com. And ask the Red Hat people on these lists their
> > opinions of bugzilla.
> What who thinks of what
Hi All,
Looking at my message about the bug webpage and
some other posts, I see that it was delayed for
about 2h and a half. Some of the post were
delayed for days... Why is that? Looks like
the list has problems of some sort which cause
these irregular delays.
Just an annoying observation.
S.
gcc -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include
-c -o auth.o auth.c
In file included from auth.c:22:
/usr/include/sys/ucred.h:50: `NGROUPS' undeclared here (not in a function)
% uname -a
FreeBSD xor 4.3-STABLE FreeBSD 4.3-STABLE #2: Thu May 24 14:05:34 MSD 2001
> Regarding the licencing of the code, I always release my code
> under GPL, which is the licence I prefer, but my code in the
> backend is obviously released under the original postgres
> licence. Since the module is loaded dynamically and not linked
> into the backend I don't see a problem here.
> On Tue, 21 Aug 2001, Lamar Owen wrote:
[...]
>
> What who thinks of what has actually become irrelevant. The following
> is clear:
>
> o No tool will replace the mailing lists
> o The mailing lists are where discussion will be held
> o Many/most maintainers have no desire to
Hi;
I am reverse engineering a PostgreSQL database by querying catalog
tables. I have run into a problem where I can not determine the exact
info used in i.e. the CREATE TABLE statement. For example; how to
determine the exact precision/length and scale used in a NUMERIC(p,s)
column def.
Looking
Peter Harvey <[EMAIL PROTECTED]> writes:
> Is this information availible somewhere in the catalog tables?
Yes, in the atttypmod column of pg_attribute.
I'd recommend looking at psql's \d commands (describe.c), or at
pg_dump, to see the approved way to retrieve catalog info. Those
are kept up to
Justin Clift <[EMAIL PROTECTED]> writes:
> After all, every bug is given an ID, so whomever fixes the bug with that
> ID should also mark it off.
Oh? I've never seen a bug ID. Certainly the traffic in pgsql-bugs
doesn't show any such thing.
This isn't going to happen unless there's some fairly
Gilles DAROLD writes:
> Is it possible to have it into the last line as we have the information of
> the database
> shutdown timestamp in the first line ?
We not just turn time stamping on?
> Also, an other question is why using timestamp into the other log instead of
> the value
> of time in
I know I am not on the kernel team, but I have been a software developer for
almost 20 years. ;-)
A bug database is a useful tool IF it has been setup to be so. If it is a
bare bones repository for bug reports it will not work. People won't use it.
A "good" bug database, i.e. one which will be u
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> The project is outgrowing its infrastructure.
Perhaps so. I think what's *really* needed here is someone who is
willing to take responsibility for maintaining a bug database, ie,
removing cruft (non-bug messages), making sure that old bugs are
ma
> > I would object even if there's such a way.
> > People in Japan have hardly noticed that the strange
> > behabior is due to the strange locale(LC_COLLATE).
>
> I don't think we should design our systems in a way that
inconveniences
> many users because some users are using broken operating sy
On Tuesday 21 August 2001 11:06, Mitch Vincent wrote:
> Some people crack me up in their opinions.. If it took him 6 hours to
> figure out "int8" then I'm not really interested in anything else he has to
> say... Lord...
Hmmm...
Let's look at the guy's bulleted list.
The first item he can't sta
> Face it, everything has locale support these day. PostgreSQL is one
of
> the few packages that even has it as an option to turn it off. Users
of
> binary packages of PostgreSQL are all invariably faced with locale
> features. So it's not like sudden unasked-for locale support is going
to
> b
> How about we trial it, but with the understanding that bugs we fix will
> be marked as such?
>
> After all, every bug is given an ID, so whomever fixes the bug with that
> ID should also mark it off.
>
> Looking at the present situation, it seems we began a good idea, but
> never really follow
> > If your solution is short-lived, your change would be not
> > only useless but also harmful. So I expect locale-aware
> > people to confirm that we are in the right direction.
>
> I am a bit confused here. We have tinkered with LIKE indexing at
least a
> year. Now that a solution is found
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> (dunno if the locks would scale to a scenario with hundreds
>> of concurrent inserts - how many user locks max?).
> I don't see problem here - just a few bytes in shmem for
> key. Auxiliary table would keep refcounters for keys.
I think that runnin
On Tuesday 21 August 2001 12:59, Serguei Mokhov wrote:
> Looking at my message about the bug webpage and
> some other posts, I see that it was delayed for
> about 2h and a half. Some of the post were
> delayed for days... Why is that? Looks like
> the list has problems of some sort which cause
> t
Zeugswetter Andreas SB SD writes:
> > I am a bit confused here. We have tinkered with LIKE indexing at
> least a
> > year. Now that a solution is found that *works*, it is claimed that
> it is
> > harmful because LIKE was doing the wrong thing in the first place.
> OTOH,
> > I have not seen any
I need to manage a large number of various databases, some assigned to
different people, others only internal to the company I work for. I would
like to be able to update the pg_hba.conf file from inside a psql console
connection but only if I an connected to template1 AND the main postgres
user.
Has anyone thought of using Bugzilla? (It is MySQL based, of course) but it
might answer the bug database issues. (If you guys want a bug database)
RedHat has a version which can use Oracle, but it seems there is a file:
ftp://people.redhat.com/dkl/pgzilla-latest.tar.gz that my be interesting.
> > I don't see problem here - just a few bytes in shmem for
> > key. Auxiliary table would keep refcounters for keys.
>
> I think that running out of shmem *would* be a problem for such a
> facility. We have a hard enough time now sizing the lock table for
Auxiliary table would have fixed size
On Tuesday 21 August 2001 12:47, Bruce Momjian wrote:
> > Justin Clift <[EMAIL PROTECTED]> writes:
> > > After all, every bug is given an ID, so whomever fixes the bug with
> > > that ID should also mark it off.
> That would be pretty cool, using the mailing list archives as an
> _answer_ to the
> > > I disagree. Unless you are omniscient, we will only ever have a partial
> > > list.
> but there wasn't enough interest for someone to take on
> the maintenance.
We need someone willing to be a kibo. Or is that too arcane a reference?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
-
Vince Vielhaber wrote:
>
> What who thinks of what has actually become irrelevant. The following
> is clear:
>
> o No tool will replace the mailing lists
> o The mailing lists are where discussion will be held
> o Many/most maintainers have no desire to update bug report
Lamar Owen <[EMAIL PROTECTED]> writes:
> The best thing to do is simply to expect propagation delay.
Actually, I just sent a gripe off to Marc about this. I've been
noticing large and variable propagation delay for a few months now,
but I just today realized that the problem is entirely local to
Lamar Owen <[EMAIL PROTECTED]> writes:
> Let's look at the guy's bulleted list.
> The first item he can't stand is that you can't add a column after any
> arbitrary column, that it goes at the end. Well, this is really
> clueless, as you order the columns when you SELECT or when the
> applicatio
Tatsuo Ishii writes:
> > Tatsuo Ishii writes:
> >
> > > I wouldn't object it if there is a way to disable locale support.
> >
> > export LC_ALL=C
>
> It's not a solution. My point is people should not be troubled by the
> useless feature (at least for Japanese) even if they set their locale
> oth
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We could try going the other way, attaching URL's to the TODO items so
> people can get more information about an existing bug.
That might be worth doing, but I think it's mostly orthogonal to the
question of a bug database. The set of problems that ar
> Justin Clift <[EMAIL PROTECTED]> writes:
> > After all, every bug is given an ID, so whomever fixes the bug with that
> > ID should also mark it off.
>
> Oh? I've never seen a bug ID. Certainly the traffic in pgsql-bugs
> doesn't show any such thing.
>
> This isn't going to happen unless the
On Tuesday 21 August 2001 11:11, Bruce Momjian wrote:
> OK, what value does a bug database have over a TODO list?
The TODO list isn't just a list of bugs that need fixing.
A bug database is just that -- a list of bugs in existing features. While
Requests of Enhancements certainly can be accomo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, what value does a bug database have over a TODO list?
A TODO list is forward-looking. Many of the entries in a bug database
would be backward-looking (already fixed). We shouldn't try to make
either one serve the purpose of the other.
Hiroshi Inoue writes:
> If your solution is short-lived, your change would be not
> only useless but also harmful. So I expect locale-aware
> people to confirm that we are in the right direction.
I am a bit confused here. We have tinkered with LIKE indexing at least a
year. Now that a solution
Lamar Owen <[EMAIL PROTECTED]> writes:
> Mailing lists don't scale well to large numbers of subscribers. I see this
> delay constantly,on multiple lists. The bigger the list gets, the slower the
> list gets (and the more loaded the server gets, right Marc? :-)).
Note that the postgresql.org
Tom Lane <[EMAIL PROTECTED]> writes:
> All the delay seems to be in transferring the message from
> postgresql.org to webmail.postgresql.org ... which are the same
> machine, or at least the same IP address. What's up with that?
You are seeing sendmail's poorly designed queuing behaviour in act
Hi,
fortunately the problems with a malfunctioning client during
the authentication don't cause the v7.2 postmaster to hang
any more (thanks to Peter and Tom). The client authentication
is moved into the forked off process.
Now one little problem remains. If a bogus clie
Peter Eisentraut wrote:
> We've had some problem reports that the current practice of initdb
> assigning to the postgres user the same usesysid as the user id of the
> Unix user running initdb has caused some clashes.
> ...
> I think the simplest fix would be to assign a fixed usesysid of 1.
I wa
On Tue, 21 Aug 2001, Lamar Owen wrote:
> > > > I disagree. Unless you are omniscient, we will only ever have a partial
> > > > list.
> > but there wasn't enough interest for someone to take on
> > the maintenance.
>
> We need someone willing to be a kibo. Or is that too arcane a reference?
Gotta
On 21 Aug 2001, Ian Lance Taylor wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
>
> > Mailing lists don't scale well to large numbers of subscribers. I see this
> > delay constantly,on multiple lists. The bigger the list gets, the slower the
> > list gets (and the more loaded the server gets,
I've had great luck with Postfix as well.
-Mitch
- Original Message -
From: "Ian Lance Taylor" <[EMAIL PROTECTED]>
To: "Lamar Owen" <[EMAIL PROTECTED]>
Cc: "Serguei Mokhov" <[EMAIL PROTECTED]>; "PostgreSQL Hackers"
<[EMAIL PROTECTED]>
Sent: Tuesday, August 21, 2001 4:24 PM
Subject: [HAC
Hi all,
Here is a first draft generated by a log analyzer for postgres I've wrote today:
http://www.samse.fr/GPL/log_report/
In all this html report there is what I'm able to extract minus the statistics.
I need to know what people want to see reported to have a powerfull log analyzer,
I
Gilles DAROLD wrote:
>
> Hi all,
>
> Here is a first draft generated by a log analyzer for postgres I've wrote today:
>
> http://www.samse.fr/GPL/log_report/
>
> In all this html report there is what I'm able to extract minus the statistics.
>
> I need to know what people want to see repo
Bruce Momjian writes:
> Can someone point me to a bug that is _not_ on the TODO list?
Just looking through pgsql-bugs of the last two weeks, the following all
look reasonable.
http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00088.html
http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2
Zeugswetter Andreas SB SD writes:
> What makes you so opposed to a GUC for disabling locale support ?
Nothing. It may in fact be the best solution.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)--
> I see no evidence that this guy wants to learn about or contribute to
> Postgres development at all; he's just looking for things to rag on.
> (And not even doing very well at that --- I could name ten worse
> problems than these without taking a breath...) The TODO list is
> mentioned prominen
Jan Wieck <[EMAIL PROTECTED]> writes:
> Now one little problem remains. If a bogus client causes a
> child to hang before becoming a real backend, this child is
> in the backend list of the postmaster, but has all signals
> blocked. Thus, preventing the postmaster from bee
> Bruce Momjian writes:
>
> > Can someone point me to a bug that is _not_ on the TODO list?
>
> Just looking through pgsql-bugs of the last two weeks, the following all
> look reasonable.
>
> http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00088.html
> http://www.ca.postgresql.org/mh
On Tue, 21 Aug 2001, Lamar Owen wrote:
> On Tuesday 21 August 2001 12:59, Serguei Mokhov wrote:
> > Looking at my message about the bug webpage and
> > some other posts, I see that it was delayed for
> > about 2h and a half. Some of the post were
> > delayed for days... Why is that? Looks like
>
In the seemingly hundreds of thousands of messages on the bug database
topic I think I've come up with the following..
Needs
---
easy reporting of bugs - sent to bugs list
easy lookup of previous bugs
summary of fix or workaroun
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> Now some history.. Over the last couple of years we've tried a
> number (5 I think) of bug tracking packages. Either Marc or me
> or both have had to learn it, install it, get it going and the
> result has been the same - the maintainers don't want
1 - 100 of 117 matches
Mail list logo
