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
> A: pgsql-hackers@postgresql.org
> Inviato: Mer 20 gennaio 2010, 18:48:00
> Oggetto: Re: [HACKERS] About "O
(2010/01/21 16:52), Takahiro Itagaki wrote:
>
> KaiGai Kohei 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 DumpableObjectType D
Leonardo F 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 sort-path for tables
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 helpful
Il 21/01/2010 03:33, Jaime Casanova ha scritto:
On Wed, Jan 20, 2010 at 9:32 PM, Jaime Casanova
wrote:
On Wed, Jan 20, 2010 at 6:20 PM, Sergey E. Koposov wrote:
Hello hackers,
I've recently hit the message "WARNING: pgstat wait timeout" with PG 8.4.2.
i see the same yesterday when initdb
>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
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() ca
On Thu, Jan 21, 2010 at 3:06 AM, Jeff Davis 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 still a problem in
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 wrote:
> On Wed, Jan 20, 2010 at 4:27 AM, Heikki Linnakangas
> wrote:
>> Magnus Hagander wrote:
>>> On Wed, Jan 20, 2010 at 09:52, Magnus Hagander wrote:
On Tue, Jan 19, 2010 at 16:59, Robert Haas wrote:
> On Tue, Jan 19, 2010 at 10:44 AM, Mag
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 s
On Tue, Jan 19, 2010 at 21:07, Kevin Grittner
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 consult with a Rub
> 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 (pgsql-ha
On Wednesday 20 January 2010 17:59:36 Tom Lane wrote:
> Andres Freund 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
> everywhere,
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 be
On Thu, Jan 21, 2010 at 10:36 AM, Richard Huxton 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
EnterpriseDB
KaiGai Kohei 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 --use-set-session-aut
2010/1/21 Dave Page
> 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
>
>
On Thu, Jan 21, 2010 at 10:54 AM, Thom Brown 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 alpha/beta will be na
one idea could be to actually prepare a query using SPI for "select * from
table order by " 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 refer
> * 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 create_i
-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 ti
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 - http://ww
On Thu, Jan 21, 2010 at 12:26 PM, Greg Sabino Mullane 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 enough last t
Heikki Linnakangas wrote:
> Magnus Hagander wrote:
>> 2010/1/17 Heikki Linnakangas :
>>> 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 still
>> places we may en
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 caref
On Thu, Jan 21, 2010 at 1:48 AM, Josh Berkus 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 be kept ar
* 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 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: http://www.enterprisedb.c
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 co
2010/1/21 Boszormenyi Zoltan :
> Tom Lane írta:
>> Robert Haas 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 portably, we *might* cons
On Thu, Jan 21, 2010 at 12:57 AM, Alex Hunsaker 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 that variable-l
Hi,
Robert Haas írta:
> 2010/1/21 Boszormenyi Zoltan :
>
>> Tom Lane írta:
>>
>>> Robert Haas 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 p
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:
http://w
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 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 is, but it g
On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas wrote:
> On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> I'd like to proceed by committing an initial patch which changes the
>>> "Escaping Strings for Inclusion in SQL Commands" to use a
>>> with one per function (as we
On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan 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 for
> (so
Andrew Dunstan 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:
http://www.postgresql.org/mailpref/
On Thu, Jan 21, 2010 at 07:30, Robert Haas wrote:
> On Thu, Jan 21, 2010 at 12:57 AM, Alex Hunsaker 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
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 s
Takahiro Itagaki 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 making them be standalone would
Greg Stark 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
> week go
>one idea could be to actually prepare a query using SPI for "select * from
>table order by " 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 AS
Robert Haas writes:
> On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan 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 == PGC_S_SESSION)
>> to ensure on
On Thu, Jan 21, 2010 at 10:59 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan 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 ==
Tom Lane 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 more often. From
Leonardo F writes:
>> one idea could be to actually prepare a query using SPI for "select * from
>> table order by " 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 ex
Robert Haas writes:
> On Thu, Jan 21, 2010 at 10:59 AM, Tom Lane 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 happening is someone setting this GUC i
Tom Lane írta:
> Robert Haas writes:
>
>> On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan 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 || sourc
> 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 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 former, hence
Leonardo F 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 hardly seems
Magnus Hagander 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 the time?
When a
-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 rema
"Greg Sabino Mullane" 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 that I see no p
2010/1/21 Robert Haas :
> On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas wrote:
>> On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane wrote:
>>> Robert Haas writes:
I'd like to proceed by committing an initial patch which changes the
"Escaping Strings for Inclusion in SQL Commands" to use a
2010/1/21 Greg Sabino Mullane :
>
> -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:
http://old.nabble.com/Re%3A-About-%22Our-CLUSTER-implementation-is-pessimal%2
Leonardo F 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 the "plann
On Thu, Jan 21, 2010 at 11:59 AM, Pavel Stehule 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, but
On Thu, 2010-01-21 at 10:14 +0100, Joachim Wieland wrote:
> On Thu, Jan 21, 2010 at 3:06 AM, Jeff Davis 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 confusing way
On Thu, Jan 21, 2010 at 11:57 AM, Pavel Stehule wrote:
> 2010/1/21 Robert Haas :
>> On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas wrote:
>>> On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane wrote:
Robert Haas writes:
> I'd like to proceed by committing an initial patch which changes the
>
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 wou
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 val
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
necess
* 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
> suggest
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 "foo""schema"; I updated the docs as I was able, but
> am not familiar enough with the regression tests to add those yet. I hope to
>
2010/1/21 Robert Haas :
> On Thu, Jan 21, 2010 at 11:57 AM, Pavel Stehule
> wrote:
>> 2010/1/21 Robert Haas :
>>> On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas wrote:
On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'd like to proceed by committing an ini
David Christensen 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 (pgsql-hackers@postgresql.o
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 use
"David E. Wheeler" 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 :
>
> 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
>>> ma
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:
SELE
On Jan 21, 2010, at 11:56 AM, Tom Lane wrote:
David Christensen 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 disingenuous, and I'm not ti
David Christensen 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 unless you w
On Jan 21, 2010, at 12:02 PM, Tom Lane wrote:
David Christensen 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
"David E. Wheeler" 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
> WHERE c.
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:
On Thu, Jan 21, 2010 at 1:28 PM, Leonardo F 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, nondefault opc
On Thu, Jan 21, 2010 at 12:53 PM, Pavel Stehule 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 are the places
that che
On Mon, Jan 18, 2010 at 3:55 AM, Takahiro Itagaki
wrote:
> Robert Haas 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 eventually result in
>> inserts (and updates?)
2010/1/21 Robert Haas :
> On Thu, Jan 21, 2010 at 12:53 PM, Pavel Stehule
> 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 nee
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
>>> wrote:
Le 04/01/2010 22:36, Guillaume Lelarge a écrit :
> Le 29/12/2009 14:12, Guill
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
du
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 r
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 de
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
accepte
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, devrim.gunduz~li
On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut 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 writes:
> On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut 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
Rafael Martinez 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 running in this new ser
On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut wrote:
> >> Here is a small patch that changes the error message
> >>
> >> duplicate key value violates unique constraint "%s"
> >>
> >> into
> >>
> >> duplicate key
On tor, 2010-01-21 at 15:47 -0500, Robert Haas wrote:
> On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut 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 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 error m
Tom Lane wrote:
> Rafael Martinez 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 digits>.0020.backup e.g.00
Rafael Martinez 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 WAL segment (plu
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,
On Thu, Jan 21, 2010 at 4:24 PM, Peter Eisentraut 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 not know that
1 - 100 of 136 matches
Mail list logo
