Tom Lane [EMAIL PROTECTED] writes:
What it comes down to is that a mailing list encourages many-eyes-on-
one-bug synergy, whereas Bugzilla is designed to send a bug report
to just one pair of eyes, or at most a small number of eyes. I haven't
used RT but I doubt it's fundamentally
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
What it comes down to is that a mailing list encourages many-eyes-on-
one-bug synergy, whereas Bugzilla is designed to send a bug report
to just one pair of eyes, or at most a small number of eyes. I haven't
used RT but
Joshua,
does RT has full support of PostgreSQL ?
Oleg
On Tue, 17 May 2005, Joshua D. Drake wrote:
discuss it, and contribute to resolving it. More often than not, a
web-based interface like Bugzilla leads to a single bug master, who does
most of this work by themselves. Besides the fact we
Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
What it comes down to is that a mailing list encourages many-eyes-on-
one-bug synergy, whereas Bugzilla is designed to send a bug report
to just one pair of eyes, or at most a small number of eyes. I
On E, 2005-05-16 at 12:35 -0400, Tom Lane wrote:
Given the lack of impressive advantage to the 64-bit code even on 64-bit
architectures, it might be best to go with the 32-bit code everywhere,
but I also think we have grounds to file a gcc bug report.
Maybe on other platforms , but 20% on
On T, 2005-05-17 at 11:22 -0400, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
On T, 2005-05-17 at 00:42 -0400, Tom Lane wrote:
I seem to recall some discussion of how to do this in the past;
have you trolled the pghackers archives?
I think that Jasons inspiration for doing it
On T, 2005-05-17 at 22:37 -0400, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I don't understand why we are testing 64-bit CRC when I thought we
agreed that 32-bit was good enough for our purposes.
Well, we need to understand exactly what is going on here. I'd not
like to
On K, 2005-05-18 at 02:23 -0400, Bruce Momjian wrote:
What we do now is not to require the reporter or the developers to
classify the email traffic, and the burden is on the people looking for
specific information to find it.
I am not suggesting we change that, but this the trade-off we
On K, 2005-05-18 at 10:24 +0300, Hannu Krosing wrote:
On T, 2005-05-17 at 22:37 -0400, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I don't understand why we are testing 64-bit CRC when I thought we
agreed that 32-bit was good enough for our purposes.
Well, we need to
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 18 May 2005 06:12
To: Greg Stark
Cc: Bruce Momjian; Manfred Koizar; Mark Cave-Ayland
(External); pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Cost of XLogInsert CRC calculations
Greg Stark [EMAIL
Hi,
On the TODO list, if found the following information :
Automatically create rules on views so they are updateable, per SQL99
Does anyone already work on such a tool inside PostgreSQL ? I'm
interessed by giving some contribution to this task ... if you're
interessed also ?
Bernard
LAMBEAU Bernard wrote:
Hi,
On the TODO list, if found the following information :
Automatically create rules on views so they are updateable, per SQL99
Does anyone already work on such a tool inside PostgreSQL ? I'm
interessed by giving some contribution to this task ... if you're
interessed also
Tom Lane said:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
What it comes down to is that a mailing list encourages many-eyes-on-
one-bug synergy, whereas Bugzilla is designed to send a bug report to
just one pair of eyes, or at most a small number of eyes. I
Hi
I have a dump from an Ingres database, one file per table it seems. I went
looking on www.postgresql.org for documentation for people who want to move
to PostgreSQL from other databases, but I couldn't find any such thing.
So, does a convert utility from ingres dump files to PostgreSQL
On Wed, 18 May 2005 01:12:26 -0400, Tom Lane [EMAIL PROTECTED] wrote:
Wait, par for 32-bit CRCs? Or for 64-bit CRCs calculated using 32-bit ints?
Right, the latter. We haven't actually tried to measure the cost of
plain 32bit CRCs... although I seem to recall that when we originally
decided to
On Tue, 17 May 2005 22:12:17 -0700, Jeffrey W. Baker [EMAIL PROTECTED]
wrote:
Incrementing random_page_cost from 4 (the default) to 5 causes the
planner to make a better decision.
We have such a low default random_page_cost primarily to mask other
problems in the optimizer, two of which are
.
On K, 2005-05-18 at 12:57 +0200, Kaare Rasmussen wrote:
Hi
I have a dump from an Ingres database, one file per table it seems. I went
looking on www.postgresql.org for documentation for people who want to move
to PostgreSQL from other databases, but I couldn't find any such thing.
So,
Tom Lane wrote:
On the other hand, it seems to me a client-side SO_KEEPALIVE would only
be interesting for completely passive clients (perhaps one that sits
waiting for NOTIFY messages?) A normal client will try to issue some
kind of database command once in awhile, and as soon as that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Oliver Jowett wrote:
If you're unlucky, the server could go down while you're blocked waiting
for a query response..
That is exactly what happens to us, and you have to be not so unlucky for
that happen if the engine have ~100 query at time.
Oliver Jowett wrote:
If you're unlucky, the server could go down while you're blocked waiting
for a query response..
That is exactly what happens to us, and you have to be not so unlucky for
that happen if the engine have ~100 query at time.
Regards
Gaetano Mendola
Jeffrey W. Baker [EMAIL PROTECTED] writes:
... If bitmap
scan is disabled, the planner will pick index scan even in cases when
sequential scan is 10x faster:
scratch=# set enable_bitmapscan to off;
SET
scratch=# explain analyze select count(1) from test where random =
1429076987 and
Tom Lane [EMAIL PROTECTED] writes:
[ shrug... ] BZ sends me email too --- for the things *it* thinks I
should know about.
Right, what I'm saying is that in RT it's more flexible; you can set it up to
send mail for the things *you* think people should know about.
Also, BZ and most bug tracking
* Tom Lane ([EMAIL PROTECTED]) wrote:
I think most of the real advantages of bug trackers that have been
mentioned in this thread have to do with history and searchability.
We have the raw info for that, in the pgsql-bugs and pgsql-commmitters
mail archives, and so it seems to me that this
Kaare,
I have a utility which will read Ingres r3 data files directly but I
don't think it would be that reliable to use. I suggest you get one of
the open source database conversion utilities written in Java, they work
pretty well. You can find a few of them on SourceForge/Freshmeat.
On Tue, May 17, 2005 at 11:24:19PM +0300, Hannu Krosing wrote:
On T, 2005-05-17 at 11:22 -0400, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
On T, 2005-05-17 at 00:42 -0400, Tom Lane wrote:
I seem to recall some discussion of how to do this in the past;
have you trolled the
On Wed, 2005-05-18 at 11:27 -0400, Tom Lane wrote:
Jeffrey W. Baker [EMAIL PROTECTED] writes:
Obviously in this case sequential scan was (would have been) a huge win.
Incrementing random_page_cost from 4 (the default) to 5 causes the
planner to make a better decision.
But to get the
People:
I think maybe we're putting on the frosting without the cake here. The
primary purpose of bug trackers is to help get bugs fixed. Over the last
couple of days, we've had a lot of comments from major bug-fixers that a BT
isn't *needed* to get bugs fixed. Let's look at tools which
Thanks for the reply Tom!
I managed to get the cvs version and I made more progress compiling tsearch2
Here is where it errors out.
touch libtsearch2.a
../../src/backend/port/aix/mkldexport.sh libtsearch2.a libtsearch2.exp
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels
On Wednesday 18 May 2005 04:54, Andrew Dunstan wrote:
Meanwhile, how about the earlier suggestions related to improving the TODO
list a bit (e.g. a beginner's list)?
I think it would be simple enough to tag certain items on the list as low
hanging fruit that there is no reason not to do it.
Oleg Bartunov wrote:
Joshua,
does RT has full support of PostgreSQL ?
It support's Postgres, but it uses a dynamic query builder that is
pretty brain dead. It only implements features that are cross DB
compatible. It comes up with some pretty ugly queries.
--
Brad Nicholson 416-673-4106
On Tuesday 17 May 2005 01:41, Josh Berkus wrote:
To put it much more bluntly: PostgreSQL development (both the process
and the codebase) has one of the steepest learning curves around,
You haven't looked at the OpenOffice.org code. wince
Yes, I have. Yes, it's steeper.
--
Lamar Owen
Hi there,
I got a problem playing with schema and dump/restore process (8.0.3).
I created schema 'contrib' for my database and added it to search_path
in postgresql.conf. Then I loaded a bunch of modules to 'contrib schema' and
populated database with various tables. Everything is ok, I could
Oleg Bartunov oleg@sai.msu.su writes:
any problem in restore. Unfortunately, pg_dump explicitly defines
search path to 'public, pg_catalog' and any objects from 'contrib' schema
doesn't seen, which cause many errors, for example, table uses type tsvector,
which defined in tsearch2 module, so
Markus,
Thank you for your reply.
We considered embedding of an XML schema first followed by data. We decided
to stick to our current data format to make sure stateless XML parsers can
process it as well. Would it be better to add an option to the COPY command,
to allow embedding an XML schema,
Neil,
We think that putting it in the backend will make access from other
components easier.
Thank you,
Sergey
-Original Message-
From: Neil Conway [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 17, 2005 7:11 PM
To: Sergey Ten
Cc: 'Bruce Momjian'; 'Christopher Kings-Lynne'; pgsql-
I've started to look seriously at Heikki's patch for two-phase commit.
There are a few issues that probably deserve discussion:
* The major missing issue that I've come across so far is that
subtransaction and multixact state isn't preserved across a crash.
Assuming that we want to store only
* Lamar Owen ([EMAIL PROTECTED]) wrote:
On Tuesday 17 May 2005 01:41, Josh Berkus wrote:
To put it much more bluntly: PostgreSQL development (both the process
and the codebase) has one of the steepest learning curves around,
You haven't looked at the OpenOffice.org code. wince
On Wed, 18 May 2005, Tom Lane wrote:
Oleg Bartunov oleg@sai.msu.su writes:
any problem in restore. Unfortunately, pg_dump explicitly defines
search path to 'public, pg_catalog' and any objects from 'contrib' schema
doesn't seen, which cause many errors, for example, table uses type tsvector,
which
Oleg Bartunov oleg@sai.msu.su writes:
unfortunately, no, because I deleted dump file. But, I just tried to
reproduce my problem with 8.0.3 and got no problem. I think, I tried
dump from 7.4.
Possibly it was just that 7.4's pg_dump isn't bright enough about dump
order? I can't think of any
Is there any particular reason that RelOptInfo doesn't have a debugging
output function?
Seems too obvious an omission not have have some reasoning
there...perhaps just too complex and rapidly changing?
Best Regards, Simon Riggs
---(end of
Simon Riggs [EMAIL PROTECTED] writes:
Is there any particular reason that RelOptInfo doesn't have a debugging
output function?
The planner structs involving RelOptInfo are self-referential, so if you
just do the obvious thing you will find outfuncs.c going into infinite
recursion. I haven't
On Wed, 18 May 2005, Tom Lane wrote:
Oleg Bartunov oleg@sai.msu.su writes:
unfortunately, no, because I deleted dump file. But, I just tried to
reproduce my problem with 8.0.3 and got no problem. I think, I tried
dump from 7.4.
Possibly it was just that 7.4's pg_dump isn't bright enough about dump
Hi,
One thing I would suggest is to start a global transaction in begin, not in
prepare. That is way to be compliance with XA.
Thanks
Joe
On 5/18/05 2:15 PM, Tom Lane [EMAIL PROTECTED] wrote:
I've started to look seriously at Heikki's patch for two-phase commit.
There are a few issues that
On Wed, May 18, 2005 at 05:19:55PM -0400, Stephen Frost wrote:
* Lamar Owen ([EMAIL PROTECTED]) wrote:
On Tuesday 17 May 2005 01:41, Josh Berkus wrote:
To put it much more bluntly: PostgreSQL development (both the process
and the codebase) has one of the steepest learning curves
On Wed, May 18, 2005 at 05:15:09PM -0400, Tom Lane wrote:
I've started to look seriously at Heikki's patch for two-phase commit.
Hum. I started a few days ago doing some reviewing, with the intention
of correcting some things here and there in order to present it all to
you later, with a
Alvaro Herrera [EMAIL PROTECTED] writes:
On Wed, May 18, 2005 at 05:15:09PM -0400, Tom Lane wrote:
Similarly, we've got to reconstruct MultiXactIds that any prepared
xacts are members of, else row-level locks taken out by prepared xacts
won't be enforced correctly. I think this can be handled
While thinking about Heikki's 2PC patch, I've been getting annoyed about
how the SInvalLock is being overused. (The connection is that the
separate LWLock he proposes in his patch isn't going to work: addition
and removal of entries in the prepared-xact list has to be guarded by
SInvalLock,
On Wed, May 18, 2005 at 07:29:38PM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
On Wed, May 18, 2005 at 05:15:09PM -0400, Tom Lane wrote:
Similarly, we've got to reconstruct MultiXactIds that any prepared
xacts are members of, else row-level locks taken out by prepared
On Wed, May 18, 2005 at 08:16:47PM -0400, Tom Lane wrote:
The reason things got this way is that we've been loading more and more
functionality onto the array of PGPROC pointers that is, more or less
incidentally, maintained by sinval.c. I'm thinking that it'd be a good
idea to remove most
Josh Berkus wrote:
1) The TODO list is a bit impenetrable for new hackers wanting to get started
with PostgreSQL tasks.
[snip]
In fact, I'd
advocate a project task list for (1) (which we conveninetly have in
pgFoundry)
It belongs as part of the TODO list, I believe, or keeping it in
Sergey Ten wrote:
We think that putting it in the backend will make access from other
components easier.
In what way?
It seems to me that this can be done just as easily in a client
application / library, without cluttering the backend with yet another
COPY output format. It would also avoid the
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
I havn't actually gotten anything real into PostgreSQL *yet*, but I've
been spending a fair bit of time on implementing support for SQL Roles
and have had alot of help developing the approach for best implementing
it (thanks Tom!) and help with
Alvaro Herrera [EMAIL PROTECTED] writes:
On Wed, May 18, 2005 at 07:29:38PM -0400, Tom Lane wrote:
What I had in mind was that each prepared xact's state file would just
list the MultiXactIds it belongs to.
Hm, this assumes the transaction knows what MultiXactIds it belongs to.
This is not
Stephen Frost [EMAIL PROTECTED] writes:
Say, how are you doing on that front?
Current status is- it now compiles with a few pieces still missing:
[snip]
It's essential IMHO that we provide pg_shadow and pg_group as reasonably
backward-compatible views on the new pg_roles catalog. It's not at
54 matches
Mail list logo
