Anyone? I'd like some feedback before moving on to do the seq scan + sort in
those
CLUSTER cases where use_index_scan returns false...
- Messaggio originale -
Da: Leonardo F m_li...@yahoo.it
A: pgsql-hackers@postgresql.org
Inviato: Mer 20 gennaio 2010, 18:48:00
Oggetto: Re:
(2010/01/21 16:52), Takahiro Itagaki wrote:
KaiGai Koheikai...@ak.jp.nec.com wrote:
This patch renamed the hasBlobs() by getBlobs(), and changed its
purpose. It registers DO_BLOBS, DO_BLOB_COMMENTS and DO_BLOB_ACLS
for each large objects owners, if necessary.
This patch adds
Leonardo F m_li...@yahoo.it wrote:
Anyone? I'd like some feedback before moving on to do the seq scan + sort in
those
CLUSTER cases where use_index_scan returns false...
+1 for CLUSTER using sort.
I have a couple of comments for the current implementation:
* Do we need to disable
Heikki Linnakangas wrote:
It's a good question if that still makes sense with Hot Standby. Perhaps
we should redefine smart shutdown in standby mode to shut down as soon
as all read-only connections have died.
I've advocated in the past that an escalating shutdown procedure would
be
Il 21/01/2010 03:33, Jaime Casanova ha scritto:
On Wed, Jan 20, 2010 at 9:32 PM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Wed, Jan 20, 2010 at 6:20 PM, Sergey E. Koposovm...@sai.msu.ru wrote:
Hello hackers,
I've recently hit the message WARNING: pgstat wait timeout with PG
Deadlock bug was prevented by stop-gap measure in December commit.
Full resolution patch attached for Startup process waits on buffer pins.
Startup process sets SIGALRM when waiting on a buffer pin. If woken by
alarm we send SIGUSR1 to all backends requesting that they check to see
if they are
On Thu, 2010-01-21 at 18:01 +0900, Hiroyuki Yamada wrote:
I think the patch has two problems.
* disable_standby_sig_alarm() does not clear standby_timeout_active flag
when it succeeds in disabling the alarm.
Ah, thanks.
* Assertion check in HoldingBufferPinThatDelaysRecovery() can
On Thu, Jan 21, 2010 at 3:06 AM, Jeff Davis pg...@j-davis.com wrote:
Here's the problem as I see it:
You are writing a lot of true facts but I miss to find a real
problem... What exactly do you see as a problem?
The only time you are writing problem is in this paragraph:
However, there's
In an attempt to pre-empt the normally drawn-out discussions about
what the next version of PostgreSQL will be numbered. the core team
have discussed the issue and following a lenghty debate lasting
literally a few minutes decided that the next release shall be
Wait for it
9.0.
--
Dave
On Wed, Jan 20, 2010 at 15:36, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jan 20, 2010 at 4:27 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Magnus Hagander wrote:
On Wed, Jan 20, 2010 at 09:52, Magnus Hagander mag...@hagander.net wrote:
On Tue, Jan 19, 2010 at
On Thu, 2010-01-21 at 18:01 +0900, Hiroyuki Yamada wrote:
Deadlock bug was prevented by stop-gap measure in December commit.
Full resolution patch attached for Startup process waits on buffer pins.
Startup process sets SIGALRM when waiting on a buffer pin. If woken by
alarm we send SIGUSR1
On Tue, Jan 19, 2010 at 21:07, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
I wrote:
Perhaps it is as simple, though, as using the client's time
instead of the CVS server's time -- that's one of the things I've
seen cause problems for this sort of thing using CVS before.
I got a brief
Wait for it
9.0.
Yeah!!!
--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
%s is too gigantic of an industry to bend to the whims of reality
--
Sent via pgsql-hackers mailing list
On Wednesday 20 January 2010 17:59:36 Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
I realize its way too late in the cycle for that, but why dont we start
using some library for easy cross platform atomic ops?
(1) there probably isn't one that does exactly what we want, works
On 21/01/10 09:37, Dave Page wrote:
In an attempt to pre-empt the normally drawn-out discussions about
what the next version of PostgreSQL will be numbered. the core team
have discussed the issue and following a lenghty debate lasting
literally a few minutes decided that the next release shall
On Thu, Jan 21, 2010 at 10:36 AM, Richard Huxton d...@archonet.com wrote:
You don't have a code-name. All the cool kids have code-names for their
projects.
There - that should distract everyone from actual release-related work for
the next week or so :-)
Nicely done Sir :-)
--
Dave Page
KaiGai Kohei kai...@ak.jp.nec.com wrote:
I'm not sure whether we need to make groups for each owner of large objects.
If I remember right, the primary issue was separating routines for dump
BLOB ACLS from routines for BLOB COMMENTS, right? Why did you make the
change?
When
2010/1/21 Dave Page dp...@pgadmin.org
In an attempt to pre-empt the normally drawn-out discussions about
what the next version of PostgreSQL will be numbered. the core team
have discussed the issue and following a lenghty debate lasting
literally a few minutes decided that the next release
On Thu, Jan 21, 2010 at 10:54 AM, Thom Brown thombr...@gmail.com wrote:
I feel sorry for 8.5 now. It had such high hopes of becoming a proper
version.
Yeah, well - it'll be remembered. I still find occasional references
to PostgreSQL 7.5 in the pgAdmin code.
So, does this mean the next
one idea could be to actually prepare a query using SPI for select * from
table order by cols and then peek inside to see which plan was generated.
perhaps you could do this using the existing planner hook.
you might have to watch out for the user's rules or planner hooks (though I
don't think
* Do we need to disable sort-path for tables clustered on a gist index?
Yes; as I said in a previous mail, only plain btree indexes (that is, not
custom expression indexes) would have that option (at least in a first
version...)
* I'd prefer to separate cost calculation routines from
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
9.0.
You don't have a code-name. All the cool kids have code-names
for their projects.
I've got one: Postgres
Better yet, how about we bite the bullet and make the name change
official. Seems like a major version bump is the right time
to
On Thu, 2010-01-21 at 12:26 +, Greg Sabino Mullane wrote:
Better yet, how about we bite the bullet and make the name change
official. Seems like a major version bump is the right time
to do it.
I thought we ended up that thread already?
--
Devrim GÜNDÜZ, RHCE
Command Prompt -
On Thu, Jan 21, 2010 at 12:26 PM, Greg Sabino Mullane g...@turnstep.com wrote:
I've got one: Postgres
Better yet, how about we bite the bullet and make the name change
official. Seems like a major version bump is the right time
to do it.
Please don't start that again. It was distracting
Heikki Linnakangas wrote:
Magnus Hagander wrote:
2010/1/17 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
We could replace the blocking PQexec() calls with PQsendQuery(), and use
the emulated version of select() to wait.
Hmm. That would at least theoretically work, but aren't there
Hi,
If the primary has a connected standby, the WAL files required for
the standby cannot be deleted. So if it has fallen too far behind
for some reasons, a disk full failure might occur on the primary.
This is one of the problems that should be fixed for v9.0.
We can cope with that case by
On Thu, Jan 21, 2010 at 1:48 AM, Josh Berkus j...@agliodbs.com wrote:
Huh? *Archived* segments aren't supposed to get deleted, at least not
by any automatic Postgres action. It would be up to the DBA how long
he wants to keep them around.
OK. The docs indicated that the segments needed to
* Dave Page (dp...@pgadmin.org) wrote:
Wait for it
9.0.
Sure, tell us now, after we've all already had to submit our 8.5-related
talks for PGCon... ;)
Thanks!
Stephen
signature.asc
Description: Digital signature
On Thu, Jan 21, 2010 at 2:07 PM, Stephen Frost sfr...@snowman.net wrote:
* Dave Page (dp...@pgadmin.org) wrote:
Wait for it
9.0.
Sure, tell us now, after we've all already had to submit our 8.5-related
talks for PGCon... ;)
What's 8.5?
--
Dave Page
EnterpriseDB UK:
Fujii Masao wrote:
If the primary has a connected standby, the WAL files required for
the standby cannot be deleted. So if it has fallen too far behind
for some reasons, a disk full failure might occur on the primary.
This is one of the problems that should be fixed for v9.0.
We can cope
2010/1/21 Boszormenyi Zoltan z...@cybertec.at:
Tom Lane írta:
Robert Haas robertmh...@gmail.com writes:
I think that it is a very bad idea to implement this feature in a way
that is not 100% portable.
Agreed, this is not acceptable. If there were no possible way to
implement the feature
On Thu, Jan 21, 2010 at 12:57 AM, Alex Hunsaker bada...@gmail.com wrote:
Seems to me a comment about the above might be nice. Something like
/* Things after here are should always be default null */ in
pg_attribute.h ?
Well... that wouldn't actually be a correct summary, so no. The point
is
Hi,
Robert Haas írta:
2010/1/21 Boszormenyi Zoltan z...@cybertec.at:
Tom Lane írta:
Robert Haas robertmh...@gmail.com writes:
I think that it is a very bad idea to implement this feature in a way
that is not 100% portable.
Agreed, this is not acceptable. If
On tor, 2010-01-21 at 10:36 +, Richard Huxton wrote:
9.0.
You don't have a code-name. All the cool kids have code-names for
their projects.
The One That Worked
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Peter Eisentraut wrote:
On tor, 2010-01-21 at 10:36 +, Richard Huxton wrote:
9.0.
You don't have a code-name. All the cool kids have code-names for
their projects.
The One That Worked
Bullwinkle (This time for sure!)
cheers
andrew
--
Sent via pgsql-hackers
Magnus Hagander mag...@hagander.net writes:
On Tue, Jan 19, 2010 at 21:07, Kevin Grittner
Reality check: does the frequency of lost CVS commits within git
seem consistent with this theory?
Well, supposedly all our servers are synced with NTP. I know the main
cvs server is, and the git server
On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I'd like to proceed by committing an initial patch which changes the
Escaping Strings for Inclusion in SQL
On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
Thanks. So it means that this patch will considered for 9.1.
Yeah, I think that's best.
I would like a mini-review on the change I made in the latest
patch by introducing the validator function. Is it enough
to check
Andrew Dunstan and...@dunslane.net wrote:
Bullwinkle (This time for sure!)
LOL
But that trick never works...
http://www.youtube.com/watch?v=e7mmrF-4rUE
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Thu, Jan 21, 2010 at 07:30, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 21, 2010 at 12:57 AM, Alex Hunsaker bada...@gmail.com wrote:
Seems to me a comment about the above might be nice. Something like
/* Things after here are should always be default null */ in
pg_attribute.h ?
9.0.
You don't have a code-name. All the cool kids have code-names for their
projects.
Black Dog
yup, I'm a zeppelin fan :)
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
* I'd prefer to separate cost calculation routines from create_index_path()
and cost_sort(), rather than using a dummy planner.
Don't go that way. The cost functions have enough dependencies on
low-level planner functionality that
Greg Stark gsst...@mit.edu wrote:
What would be useful is a tool which given a list of standby
databases and list of base backup images can apply a set of policy
rules to determine which base backups and archived logs to delete.
The policy might look something like keep one base backup per
one idea could be to actually prepare a query using SPI for select * from
table order by cols and then peek inside
to see which plan was generated.
I like that!!!
Here's a first attempt, it looks like it's working...
(I still have to skip non-btree indexes and expression indexes, plus
add a
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
I would like a mini-review on the change I made in the latest
patch by introducing the validator function. Is it enough
to check for
(source == PGC_S_DEFAULT || source ==
On Thu, Jan 21, 2010 at 10:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
I would like a mini-review on the change I made in the latest
patch by introducing the validator function.
Tom Lane t...@sss.pgh.pa.us wrote:
I have noticed that CVS operations (at least from the user's
viewpoint) work in local time. So even if the clocks are synced,
a different TZ setting could conceivably lead to issues.
Hmmm... If that were the issue I would think we'd've seen the
problem
Leonardo F m_li...@yahoo.it writes:
one idea could be to actually prepare a query using SPI for select * from
table order by cols and then peek inside
to see which plan was generated.
I like that!!!
Here's a first attempt, it looks like it's working...
(I still have to skip non-btree
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 21, 2010 at 10:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Why is this a good idea at all? I can easily see somebody feeling that
he'd like autovacuums to fail rather than block on locks for a long
time, for example.
What I can see
Tom Lane írta:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
I would like a mini-review on the change I made in the latest
patch by introducing the validator function. Is it enough
to check for
(source ==
By the time you make this actually work in all cases, it's probably
going to be more of a mess than the other way;
I meant to add only ASC/DESC; I would leave all other cases
(non-btrees, custom expression btrees) to use the old index-scan method.
not to mention that it
doesn't work *at
Boszormenyi Zoltan z...@cybertec.at writes:
You expressed stability concerns coming from this patch.
Were these concerns because of locks timing out making
things fragile or because of general feelings about introducing
such a patch at the end of the release cycle? I was thinking
about the
Leonardo F m_li...@yahoo.it writes:
By the time you make this actually work in all cases, it's probably
going to be more of a mess than the other way;
I meant to add only ASC/DESC; I would leave all other cases
(non-btrees, custom expression btrees) to use the old index-scan method.
That
Magnus Hagander mag...@hagander.net writes:
So the list really isn't very long. I think it's perfectly possible to
clear it off before the release. Because we still only want to change
after the release, or are you saying once those are fixed, we can
change even if we happen to be in beta at
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Better yet, how about we bite the bullet and make the name change
official. Seems like a major version bump is the right time
to do it.
I thought we ended up that thread already?
Well, the thread may have ended, but the problem remains.
Greg Sabino Mullane g...@turnstep.com wrote:
many people are loathe to see the discussion come up again,
but as long as the project is saddled with its ugly and
unweildy official name, it has a large problem.
I don't particularly like the official stance on pronouncing it, but
other than
2010/1/21 Robert Haas robertmh...@gmail.com:
On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I'd like to proceed by committing an initial patch which changes
2010/1/21 Greg Sabino Mullane g...@turnstep.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Better yet, how about we bite the bullet and make the name change
official. Seems like a major version bump is the right time
to do it.
I thought we ended up that thread already?
Well,
I meant to add only ASC/DESC; I would leave all other cases
(non-btrees, custom expression btrees) to use the old index-scan method.
That hardly seems acceptable.
Well I brought up that in an earlier post:
Leonardo F m_li...@yahoo.it writes:
I hoped that since people mostly (95%?) use plain btree indexes,
a patch that helped CLUSTER with using such indexes would be fine
(at least at first...). I guess that a patch that deals with all other types
of
indexes would be way more complicated (not at
On Thu, Jan 21, 2010 at 11:59 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Better yet, how about we bite the bullet and make the name change
official. Seems like a major version bump is the right time
to do it.
I thought we ended up that thread already?
Well, the thread may have ended,
On Thu, 2010-01-21 at 10:14 +0100, Joachim Wieland wrote:
On Thu, Jan 21, 2010 at 3:06 AM, Jeff Davis pg...@j-davis.com wrote:
Here's the problem as I see it:
You are writing a lot of true facts but I miss to find a real
problem... What exactly do you see as a problem?
I worded that in a
On Thu, Jan 21, 2010 at 11:57 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/1/21 Robert Haas robertmh...@gmail.com:
On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas
On Jan 21, 2010, at 9:19 AM, Robert Haas wrote:
As far as I can see, there is absolutely zero reason to care about
whether the product is called Postgres or PostgreSQL.
How about simply Post? Or just SQL? ;-P
If it were
called WeGrindUpTheBonesOfSmallChildrenSQL, maybe a change would be
On Jan 19, 2010, at 9:26 PM, Andrew Dunstan wrote:
The first thing I think we need to do is move the GUC processing code out of
_PG_init() and into plperl_init_interp(), protected by a flag to make sure
it's only called successfully once. I'm trying to work out a neat way to put
the value
Hey -hackers,
Enclosed is a patch adding a 'regschema' OID type. I'm really just
hoping to get this out there, don't worry about committing it at this
point. This is something that I've always wanted in the field (yes,
I'm lazy). Many thanks to RhodiumToad for pointers about the
* David Christensen:
Currently, a session will look like the following:
machack:machack:5485=# show tables;
See:
\d
or \? for general help with psql commands
machack:machack:5485=#
Said formatting looks like it could use some improvement, open to
suggestions, but
On Jan 21, 2010, at 9:46 AM, David Christensen wrote:
It uses the same quoting mechanism as regclass, and I've tested against some
odd schema names such as fooschema; I updated the docs as I was able, but
am not familiar enough with the regression tests to add those yet. I hope to
address
2010/1/21 Robert Haas robertmh...@gmail.com:
On Thu, Jan 21, 2010 at 11:57 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2010/1/21 Robert Haas robertmh...@gmail.com:
On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane
David Christensen da...@endpoint.com writes:
Enclosed is a patch adding a 'regschema' OID type.
What in the world is the point of that? The regfoo types are for things
that have schema-qualified names.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Jan 21, 2010, at 11:48 AM, Florian Weimer wrote:
* David Christensen:
Currently, a session will look like the following:
machack:machack:5485=# show tables;
See:
\d
or \? for general help with psql commands
machack:machack:5485=#
Said formatting looks like it could
David E. Wheeler da...@kineticode.com writes:
OOh, /me likey! This would save me a ton of code in pgTAP (about half its
queries have to join to pg_namespace to get schema names).
Schema names of what? It sounds to me like you're failing to use the
existing regfoo types in appropriate places
2010/1/21 David Christensen da...@endpoint.com:
On Jan 21, 2010, at 11:48 AM, Florian Weimer wrote:
* David Christensen:
Currently, a session will look like the following:
machack:machack:5485=# show tables;
See:
\d
or \? for general help with psql commands
On Jan 21, 2010, at 9:57 AM, Tom Lane wrote:
Schema names of what? It sounds to me like you're failing to use the
existing regfoo types in appropriate places ...
The names of schemas in which to find functions, tables, views, triggers, etc.
etc. I have lots of stuff like this:
On Jan 21, 2010, at 11:56 AM, Tom Lane wrote:
David Christensen da...@endpoint.com writes:
Enclosed is a patch adding a 'regschema' OID type.
What in the world is the point of that? The regfoo types are for
things
that have schema-qualified names.
Perhaps the naming is a bit
David Christensen da...@endpoint.com writes:
Should the error messages between the SHOW cases and the others be
consistent (ERROR: unsupported command or similar)? It's worth
noting that this is only in the psql client, but we could simulate the
ereport output from the server.
No. Not
On Jan 21, 2010, at 12:02 PM, Tom Lane wrote:
David Christensen da...@endpoint.com writes:
Should the error messages between the SHOW cases and the others be
consistent (ERROR: unsupported command or similar)? It's worth
noting that this is only in the psql client, but we could simulate
David E. Wheeler da...@kineticode.com writes:
The names of schemas in which to find functions, tables, views, triggers,
etc. etc. I have lots of stuff like this:
SELECT true
FROM pg_catalog.pg_namespace n
JOIN pg_catalog.pg_class c ON n.oid = c.relnamespace
On Jan 21, 2010, at 10:06 AM, Tom Lane wrote:
Well, without a context that explains *why* you're doing that, it's hard
to consider what a better solution would look like. Personally I
usually prefer solutions involving WHERE oid = 'foo.bar'::regclass,
because that scales easily to either
Well, the expression cases would be more likely to cost more if
implemented as a sort, but that doesn't mean that a sort couldn't be a
win. Besides, even if you blow off the expression case, what about
nulls first/last, nondefault opclasses, etc?
Ok, let's split the problem in 2 parts:
a)
On Thu, Jan 21, 2010 at 1:28 PM, Leonardo F m_li...@yahoo.it wrote:
Well, the expression cases would be more likely to cost more if
implemented as a sort, but that doesn't mean that a sort couldn't be a
win. Besides, even if you blow off the expression case, what about
nulls first/last,
On Thu, Jan 21, 2010 at 12:53 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
add to state structure field like lexer_error. This field will be
checked before execution
it could be ugly for metacommands, there will be lot of new checks :(
Eh? The only places where we should need new tests
On Mon, Jan 18, 2010 at 3:55 AM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Robert Haas robertmh...@gmail.com wrote:
A couple of preliminary comments on this:
Thanks.
The attached is rebased on HEAD, with additional documentation.
1. If we're thinking that this syntax should
2010/1/21 Robert Haas robertmh...@gmail.com:
On Thu, Jan 21, 2010 at 12:53 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
add to state structure field like lexer_error. This field will be
checked before execution
it could be ugly for metacommands, there will be lot of new checks :(
Eh?
Le 15/01/2010 18:53, Guillaume Lelarge a écrit :
Le 08/01/2010 23:22, Guillaume Lelarge a écrit :
Le 07/01/2010 19:13, Robert Haas a écrit :
On Thu, Jan 7, 2010 at 10:33 AM, Guillaume Lelarge
guilla...@lelarge.info wrote:
Le 04/01/2010 22:36, Guillaume Lelarge a écrit :
Le 29/12/2009 14:12,
Hello
After upgrading to 8.3.9 and moving some our PostgreSQL clusters to a
new server yesterday, we have experienced a strange thing this past night.
All PITR backup history files created when running a PITR base backup on
all PostgreSQL clusters running in this new server (at different hours
On 21 Jan 2010, at 09:37, Dave Page wrote:
In an attempt to pre-empt the normally drawn-out discussions about
what the next version of PostgreSQL will be numbered. the core team
have discussed the issue and following a lenghty debate lasting
literally a few minutes decided that the next
Grzegorz Jaskiewicz wrote:
On 21 Jan 2010, at 09:37, Dave Page wrote:
In an attempt to pre-empt the normally drawn-out discussions about
what the next version of PostgreSQL will be numbered. the core team
have discussed the issue and following a lenghty debate lasting
literally a few minutes
Here is a small patch that changes the error message
duplicate key value violates unique constraint %s
into
duplicate key value violates primary key %s
when the constraint is in fact a primary key.
Comments?
PS: Yes, this would need a handful of regression test updates if
accepted.
On Thu, 2010-01-21 at 21:26 +0100, Stefan Kaltenbrunner wrote:
http://www.postgresql.org/docs/current/static/release-6-5.html
That was another great release IMHO.
--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://www.CommandPrompt.com
devrim~gunduz.org, devrim~PostgreSQL.org,
On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut pete...@gmx.net wrote:
Here is a small patch that changes the error message
duplicate key value violates unique constraint %s
into
duplicate key value violates primary key %s
when the constraint is in fact a primary key.
Comments?
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut pete...@gmx.net wrote:
Here is a small patch that changes the error message
duplicate key value violates unique constraint %s
into
duplicate key value violates primary key %s
when the
Rafael Martinez r.m.guerr...@usit.uio.no writes:
After upgrading to 8.3.9 and moving some our PostgreSQL clusters to a
new server yesterday, we have experienced a strange thing this past night.
All PITR backup history files created when running a PITR base backup on
all PostgreSQL clusters
On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut pete...@gmx.net wrote:
Here is a small patch that changes the error message
duplicate key value violates unique constraint %s
into
On tor, 2010-01-21 at 15:47 -0500, Robert Haas wrote:
On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut pete...@gmx.net wrote:
Here is a small patch that changes the error message
duplicate key value violates unique constraint %s
into
duplicate key value violates primary key
Peter Eisentraut pete...@gmx.net writes:
On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote:
This patch fails to cover all cases (index build being the obvious
omission, but I think there might be other paths as well where the
information is not so readily available).
This is the user-visible
Tom Lane wrote:
Rafael Martinez r.m.guerr...@usit.uio.no writes:
All PITR backup history files created when running a PITR base backup on
all PostgreSQL clusters running in this new server (at different hours
during the night) got an identical 2nd part file name.
24
Rafael Martinez r.m.guerr...@usit.uio.no writes:
Tom Lane wrote:
I think this is normal behavior now, if you have an unloaded server.
pg_start_backup now forces a segment switch, so if nothing much else is
happening it's quite likely that the recorded start point will be the
beginning of the
On tor, 2010-01-21 at 16:29 -0500, Tom Lane wrote:
regression=# alter table foo add primary key (f1);
NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index foo_pkey
for table foo
ERROR: could not create unique index foo_pkey
DETAIL: Key (f1)=(1) is duplicated.
He he, that one
On Thu, Jan 21, 2010 at 4:24 PM, Peter Eisentraut pete...@gmx.net wrote:
Why bother?
Because unique constraints and primary keys are different things and it
would be slightly less confusing that way.
I don't really see why it would be any less confusing. You could
argue that someone might
1 - 100 of 136 matches
Mail list logo
