[EMAIL PROTECTED] (Peter Eisentraut) writes:
Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat:
I'm not sure I follow this, since currently anyone can email the bugs list
or use the bugs - email form from the website. Are you looking to
increase the barrier for bug reporting?
Only a
Marc G. Fournier wrote:
Fixed, sorry for delay ...
Good, thank you. But I've already switched back to IMAP, with subfolders
and automatic filtering. Has the advantage of being available from any
IMAP capable client _and_ saving the flags.
Looks like the news server is not used that much,
a.hub.org[200.46.208.251], delay=1, status=sent (250 2.7.1 Ok,
discarded, id=258
35-09 - BANNED: P=p003,L=1,M=multipart/mixed |
P=p002,L=1/2,M=application/x-gzip ,T=gz,N=vcbuild.tar.gz |
P=p...)
Seems -patches is rejecting any mail with attached .tar.gz files,
if I
read that
Markus Schiltknecht wrote:
Marc G. Fournier wrote:
Fixed, sorry for delay ...
Good, thank you. But I've already switched back to IMAP, with subfolders
and automatic filtering. Has the advantage of being available from any
IMAP capable client _and_ saving the flags.
Looks like the news
Teodor, are the new attached regression results correct? If so, I will
apply the patch and update the expected file.
Patch isn't full, simple test (values are took from regression.diffs):
# create table tt (tv tsvector, tq tsquery);
# insert into tt values (E'''1 \\''2''', NULL);
# insert into
Kenneth Marshall wrote:
RT is easy to setup/configure/use and works well with PostgreSQL
as the backend.
RT works with Postgres, but I wouldn't say well. All queries in RT are
generated by a query generator due to a naive obsession with database
independance. They've achieved database
On Aug 17, 2006, at 4:10 PM, Martijn van Oosterhout wrote:
On Thu, Aug 17, 2006 at 02:54:20PM -0500, Jim C. Nasby wrote:
On Thu, Aug 17, 2006 at 02:23:48PM +0200, Martijn van Oosterhout
wrote:
On Thu, Aug 17, 2006 at 12:55:28PM +0900, ITAGAKI Takahiro wrote:
But the method has the above
On Aug 17, 2006, at 3:40 PM, Alvaro Herrera wrote:
The searching capabilities in debbugs are, well, non-existent,
which is
a real problem in my mind.
Well, we can set up our own indexing, like Oleg and Teodor have
done in
http://www.pgsql.ru/
That seems like quite a hack for something
seahorse just failed again with one of the dreaded permission denied
errors we seem to sporadically getting reported on the lists:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=seahorsedt=2006-08-22%2002:30:01
we seem to attribute those to AV and other security related software -
except
On 8/17/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
Alvaro Herrera wrote:
Have you tried to use debbugs?
If you can find up-to-date source code for debbugs, we might continue
that line of thought.
http://www.mail-archive.com/debian-debbugs@lists.debian.org/msg01266.html
( bzr get
Alvaro Herrera wrote:
Bruce Momjian wrote:
I will try to generate a list of open 8.2 items in 7-10 days so we can
start focusing on beta.
FYI, you have three emails about updatable views in the queue, but you
are missing the one I sent today which contains an updated patch that is
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, based on this feedback, I am adding COPY VIEW to the patches queue.
I think we have other things that demand our attention more than a
half-baked feature.
Well, the patch was submitted in time, and it is a desired feature. If
we
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, based on this feedback, I am adding COPY VIEW to the patches queue.
I think we have other things that demand our attention more than a
half-baked feature.
Well, the patch was submitted in time, and it is a
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Well, the patch was submitted in time, and it is a desired feature. If
we want to hold it for 8.3 due to lack of time, we can, but I don't
think we can decide now that it must wait.
well I thought the agreed approach to
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, based on this feedback, I am adding COPY VIEW to the patches queue.
I think we have other things that demand our attention more than a
half-baked feature.
Marko Kreen wrote:
On 8/17/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
Alvaro Herrera wrote:
Have you tried to use debbugs?
If you can find up-to-date source code for debbugs, we might continue
that line of thought.
http://www.mail-archive.com/debian-debbugs@lists.debian.org/msg01266.html
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
seahorse just failed again with one of the dreaded permission denied
errors we seem to sporadically getting reported on the lists:
seahorse is just a stock windows XP box (with all patches and
servicepacks applied) and msys/mingw.
There is no
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
seahorse just failed again with one of the dreaded permission denied
errors we seem to sporadically getting reported on the lists:
seahorse is just a stock windows XP box (with all patches and
servicepacks applied) and
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
seahorse just failed again with one of the dreaded permission denied
errors we seem to sporadically getting reported on the lists:
seahorse is just a stock windows XP box (with all patches and
servicepacks applied) and msys/mingw.
Michael Glaesemann wrote:
On Aug 22, 2006, at 2:52 , Bruce Momjian wrote:
Do we want to replace our /contrib/isbn with this, or have it pgfoundry?
If contrib/isbn is made obsolete by the pgfoundry ISBN/ISSN/ISMN/EAN13
code, unless there's a compelling reason that the pgfoundry be part of
Kenneth Marshall wrote:
RT is easy to setup/configure/use and works well with PostgreSQL as
the backend.
RT works with Postgres, but I wouldn't say well. All queries
in RT are generated by a query generator due to a naive
obsession with database independance. They've achieved
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
It would be interesting to know the actual underlying Windows error code
--- I see that win32error.c maps several different codes to EACCES.
It may be a good idea to put a elog(LOG) with the error code in the
failure path of
Going back on-list...
On Tue, Aug 22, 2006 at 08:47:04AM -0400, Alvaro Herrera wrote:
Jim Nasby wrote:
On Aug 17, 2006, at 3:19 PM, Alvaro Herrera wrote:
Nevermind -- it's just that if you vacuum a table which you haven't
touched (insert, update, delete) since the last stats reset, then
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
It would be interesting to know the actual underlying Windows error code
--- I see that win32error.c maps several different codes to EACCES.
It may be a good idea to put a elog(LOG) with the error
Andrew Dunstan wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
It would be interesting to know the actual underlying Windows error
code
--- I see that win32error.c maps several different codes to EACCES.
It may be a good idea to put a
On Tue, Aug 22, 2006 at 10:19:38AM -0400, Tom Lane wrote:
It may be a good idea to put a elog(LOG) with the error code in the
failure path of AllocateFile.
That seems like a plan to me. I had been thinking of making
win32error.c itself log the conversions, but that would not provide any
Martijn van Oosterhout kleptog@svana.org writes:
Would it be possible to get errcode_for_file_access() to report the
results of GetLastError() for windows, or would that roduce spurious
results. At DEBUG lavel maybe?
It would have to be at LOG level, because otherwise it wouldn't get
logged at
Jim C. Nasby [EMAIL PROTECTED] writes:
If there's a bunch of activity on a table but stats are reset before a
vacuum is run on it and then a vacuum is run, the user will still be
left thinking that the table needs to be vacuumed.
Except that autovac *won't* vacuum it if the stats have been
Andrew Dunstan [EMAIL PROTECTED] writes:
It's a close call. On balance I'd be inclined to accept the patch if it
reviews OK, even though we will throw the code away soon (we hope).
Well, the patch seems pretty ugly code-wise as well. I'd be willing to
clean it up if I thought it wouldn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
sorry if I'm on the wrong list (tell me so!). I'd like to know whether
hstore isn't supposed to be in contrib any more and where it is supposed
to live nowadays (I was close to file a complaint to my distributor
until I discovered that it isn't
[EMAIL PROTECTED] wrote:
Hi,
sorry if I'm on the wrong list (tell me so!). I'd like to know whether
hstore isn't supposed to be in contrib any more and where it is supposed
to live nowadays (I was close to file a complaint to my distributor
until I discovered that it isn't in the 8.1 upstream
[EMAIL PROTECTED] wrote:
Hi,
sorry if I'm on the wrong list (tell me so!). I'd like to know whether
hstore isn't supposed to be in contrib any more and where it is supposed
to live nowadays (I was close to file a complaint to my distributor
until I discovered that it isn't in the 8.1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Aug 22, 2006 at 04:06:22PM +, [EMAIL PROTECTED] wrote:
Hi,
sorry if I'm on the wrong list (tell me so!). I'd like to know whether
hstore [...]
I've been set right. Seems hstore was never in contrib. Sorry for the
noise.
BTW: any
Hans-Juergen Schoenig wrote:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Well, the patch was submitted in time, and it is a desired
feature. If
we want to hold it for 8.3 due to lack of time, we can, but I don't
think we can decide now that it
I see fairly nasty problems in the concurrent-index patch when it's
trying to build a unique index. I think it's solvable but want some
more eyeballs on my reasoning.
Look at the code in IndexBuildHeapScan where we are deciding whether or
not to include a tuple in the index (indexIt) and also
Andrew,
Why are we even dabating a system when it has been reported that the
authors believe it is completely unsuitable for use by the PostgreSQL
project?
Not *completely*. More that it would take a couple dozen hours of work to
make it good for us, and the resulting version then couldn't
Did you look at http://www.atlassian.com/software/jira/
- can use postgresql as database
- free to open source projects, used by apache, hiberate, OpenSymphony
- bugs may be submitted via email/web
- built-in configurable workflow
- runs as J2EE webapp on a number of OS's
- lots of other features
On 21 Aug 2006, at 10:48, [EMAIL PROTECTED] wrote:
On Mon, Aug 21, 2006 at 12:00:58PM +0300, Alexander Kirpa wrote:
WRT 64-bit and Postgres, it depends on the CPU as to whether you
see a simple performance benefit. On the Opteron you will see a
benefit when doing CPU bound work. When
Tom Lane [EMAIL PROTECTED] writes:
I think we can solve this by having IndexBuildHeapScan not index
DELETE_IN_PROGRESS tuples if it's doing a concurrent build.
Sure
It's entirely possible for a tuple that is RECENTLY_DEAD or
DELETE_IN_PROGRESS to have no entry in the index, if it was
Peter Eisentraut wrote:
Jim C. Nasby wrote:
Meet EXPLAIN ANALYZE.
Which does no good for apps that you don't control the code on. Even
if you do control the code, you have to find a way to stick EXPLAIN
ANALYZE in front of every query, and figure out how to deal with
what's comming back.
Alban Hertroys [EMAIL PROTECTED] writes:
I'm confused too. Would it be possible for you to send me a dump of
your database?
Attached is a cleaned out database, the full schema is included, but
only the relevant tables contain any data.
Thanks. After digging through it a bit, I understand
I wrote:
Thanks. After digging through it a bit, I understand what's happening,
but I'm not seeing any simple fix.
I forgot to mention that although I could reproduce your bad plan in
8.1, CVS HEAD doesn't fall into the trap. I don't believe we've done
anything to fix the fundamental problem
Tom Lane wrote:
We might be able to do something about actually solving the statistical
problem in 8.3, but I fear it's too late to think about it for 8.2.
I take it you mean you already have a very concrete idea on how to solve
it. Come on, illuminate us poor dumb souls.
--
Alvaro Herrera
Greg Stark [EMAIL PROTECTED] writes:
Is it not possible to brute force this adding an AM method to insert without
the uniqueness check?
Hm. Actually there already is a feature of aminsert to allow
suppressing the unique check, but I'm not sure whether using it for
RECENTLY_DEAD tuples helps.
Wow, that seems pretty unsatisfactory, all the waiting and locking sounds
awful.
Yeah, I'm very unhappy. The whole idea may be going down in flames :-(
It's fairly clear that we could support concurrent builds of nonunique
indexes, but is that enough of a use-case to justify it?
I believe
[ redirecting to pgsql-hackers since this is not a bug ]
Alvaro Herrera [EMAIL PROTECTED] writes:
Manuel A. Fernandez Montecelo wrote:
Well, I use around 10 libraries in my project, it's easier to use
standardized
methods to gather the compiler/linker options using pkg-config than calling
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
We might be able to do something about actually solving the statistical
problem in 8.3, but I fear it's too late to think about it for 8.2.
I take it you mean you already have a very concrete idea on how to solve
it. Come on,
Joshua D. Drake [EMAIL PROTECTED] writes:
It's fairly clear that we could support concurrent builds of nonunique
indexes, but is that enough of a use-case to justify it?
I believe there would be. Most PostgreSQL users I run into, develop in
production, which means being able to add an index
[EMAIL PROTECTED] writes:
I've been set right. Seems hstore was never in contrib. Sorry for the
noise.
BTW: any reason it isn't? It is very cool...
AFAIR the authors have never proposed it for inclusion.
regards, tom lane
---(end of
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
It's fairly clear that we could support concurrent builds of nonunique
indexes, but is that enough of a use-case to justify it?
I believe there would be. Most PostgreSQL users I run into, develop in
production, which means being able
True. They could even put it in .psqlrc if they want. Basically need
a way to modify \g. Seems a \set is the way we have always done such
modifications in the past. The big question is whether this is
somehow different. Personally, I don't think so.
If you want a \set variable, then at
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Well, the patch was submitted in time, and it is a desired feature. If
we want to hold it for 8.3 due to lack of time, we can, but I don't
think we can decide now that it must wait.
well I
Hans-Juergen Schoenig wrote:
It has been made as COPY FROM / TO view because people wanted it to be
done that way.
My original proposal was in favour of arbitrary SELECTs (just like
proposed by the TODO list) but this was rejected. So, we did it that way
(had to explain to customer why
Alvaro Herrera [EMAIL PROTECTED] writes:
It sucks that patches are posted and no action is taken on them for
months. I agree with that.
This particular patch was originally posted during the 8.1 feature
freeze window (2005-09-29), so it was doomed to a certain amount of
languishing on the
[EMAIL PROTECTED] wrote:
Did you look at http://www.atlassian.com/software/jira/
We had discussed that in an earlier round, but it's not free software,
so it's out of the question.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
On Aug 22, 2006, at 17:01 , Tom Lane wrote:
[EMAIL PROTECTED] writes:
I've been set right. Seems hstore was never in contrib. Sorry for the
noise.
BTW: any reason it isn't? It is very cool...
AFAIR the authors have never proposed it for inclusion.
According to
Tom Lane wrote:
Since that was two years ago, maybe we should take another look
and see if pkg-config has gotten better. If it hasn't evolved
some then the answer will probably be the same though.
For all intents and purposes, pkg-config is still as broken as it ever
was. And I still
AgentM [EMAIL PROTECTED] writes:
On Aug 22, 2006, at 17:01 , Tom Lane wrote:
AFAIR the authors have never proposed it for inclusion.
According to http://www.sai.msu.su/~megera/postgres/gist/hstore/
README.hstore :
Stable version, included into PostgreSQL distribution, ... version 2
(June
[EMAIL PROTECTED] writes:
To cut the Gordon knot I'm going to suggest we use:
\set CURSOR_FETCH fetch_count
and \g and ; are modified such that when they see
this variable set to fetch_count 0 and the buffer
is a select they would use the modified fetch/output code.
Does this sound
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Is it not possible to brute force this adding an AM method to insert without
the uniqueness check?
Hm. Actually there already is a feature of aminsert to allow
suppressing the unique check, but I'm not sure whether
Greg Stark [EMAIL PROTECTED] writes:
What would happen if we just insert DELETE_IN_PROGRESS tuples normally? Would
the only risk be that the index build would fail with a spurious unique
constraint violation? I suppose it would be pretty common though given how
updates work.
Yeah, that's the
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
It sucks that patches are posted and no action is taken on them for
months. I agree with that.
This particular patch was originally posted during the 8.1 feature
freeze window (2005-09-29), so it was doomed to a certain amount of
On Tuesday 22 August 2006 16:10, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
It sucks that patches are posted and no action is taken on them for
months. I agree with that.
This particular patch was originally posted during the 8.1 feature
freeze window (2005-09-29), so it was
After a long battle with technology, Lukas Kahwe Smith [EMAIL PROTECTED], an
earthling, wrote:
Markus Schiltknecht wrote:
Marc G. Fournier wrote:
Fixed, sorry for delay ...
Good, thank you. But I've already switched back to IMAP, with
subfolders and automatic filtering. Has the advantage of
Robert Treat [EMAIL PROTECTED] writes:
On Tuesday 22 August 2006 16:10, Tom Lane wrote:
As I see it, we've effectively got a patch that was rejected once,
and Bruce wants to apply it anyway because no replacement has been
forthcoming.
Well, unless someone is going to commit to doing it the
On Thursday 17 August 2006 11:55, Peter Eisentraut wrote:
Tom Lane wrote:
Yeah, that experiment hasn't seemed to work all that well for me
either. Do you have another idea to try, or do you just want to
revert to the old way?
Since almost the first day I hacked on PostgreSQL I have been
Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
On Tuesday 22 August 2006 16:10, Tom Lane wrote:
As I see it, we've effectively got a patch that was rejected once,
and Bruce wants to apply it anyway because no replacement has been
forthcoming.
Well, unless someone is going to
Robert Treat wrote:
On Thursday 17 August 2006 11:55, Peter Eisentraut wrote:
Tom Lane wrote:
Yeah, that experiment hasn't seemed to work all that well for me
either. Do you have another idea to try, or do you just want to
revert to the old way?
Since almost the first day I hacked
I'm curious, do you combine any other lists like that? I've played around
with that idea (for example, I used to combine webmaster emails, pgsql-www,
and -slaves emails but the slaves traffic was too high so I had to split it
back out). As someone subscribed to a good dozen pg lists, I've
Bruce Momjian [EMAIL PROTECTED] writes:
Robert Treat wrote:
... some other tricks people have to make emails more manageable (anyone
combine all pg mail to one folder?)
Yes, all mine are in one folder, and I use elm ME. It is faster than a
GUI email client.
All my PG list mail goes into
On Aug 23, 2006, at 12:15 , Robert Treat wrote:
On Thursday 17 August 2006 11:55, Peter Eisentraut wrote:
Tom Lane wrote:
Yeah, that experiment hasn't seemed to work all that well for me
either. Do you have another idea to try, or do you just want to
revert to the old way?
Since almost
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Robert Treat wrote:
... some other tricks people have to make emails more manageable (anyone
combine all pg mail to one folder?)
Yes, all mine are in one folder, and I use elm ME. It is faster than a
GUI email client.
All my PG
Jim C. Nasby [EMAIL PROTECTED] wrote:
And +1 on Rod's suggestion to make it more aggressive. I always drop the
scale factor to at least 0.2 and 0.1 (though 0.1 and 0.05 don't seem
unreasonable), and typically drop the thresholds to 200 and 100 (though
again, lower is probably warrented).
Joshua D. Drake [EMAIL PROTECTED] writes:
* The schema now uses foreign keys to more accurately reflect a finacial DDL
Addition of foreign key checking will certainly impact performance
significantly.
* The history table now has a primary key that uses a serial
Ditto.
* The respective
74 matches
Mail list logo
