Hi, Alvaro,
Alvaro Herrera wrote:
I am aware that more recent versions 8.x have fixed this problem, I
checked the 7.4 release notes but can't see if any of the fixes made it
into 7.4.
Usually, only critical data loss and security fixes are put into the
minor updates (e. G. 7.4.0 to
Hi Tom,
Thanks for your initial thoughts on this.
On Wed, 2006-09-20 at 20:13 -0400, Tom Lane wrote:
(cut)
You really can't get away with having the identical representation for
CTEs and ordinary sub-selects in the range table. For instance, it
looks like your patch will think that
Strangely, if I try to do a cvs add gram.c, it fails with cvs
add:
`gram.c' added independently by second party I don't know what
this
means. (Why second party and not third party?). Even if I
delete
gram.c. Even if I remove it from .cvsignore.
I think cvs add probably contacts
On 9/22/06, Tom Lane [EMAIL PROTECTED] wrote:
I suggest again that you ought to be running your basic design
past the list sooner rather than later.
We will be posting it as soon as we can.
--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation| fax:
On 22-Sep-06, at 3:58 AM, Markus Schaber wrote:
Hi, Alvaro,
Alvaro Herrera wrote:
I am aware that more recent versions 8.x have fixed this
problem, I
checked the 7.4 release notes but can't see if any of the fixes
made it
into 7.4.
Usually, only critical data loss and security fixes
Dave Cramer wrote:
On 22-Sep-06, at 3:58 AM, Markus Schaber wrote:
Hi, Alvaro,
Alvaro Herrera wrote:
I am aware that more recent versions 8.x have fixed this
problem, I
checked the 7.4 release notes but can't see if any of the fixes
made it
into 7.4.
Usually, only critical
Following the recent discussion on this list and another on pgsql-core,
we have decided that we would like to aim to meet the following schedule
for the release of PostgreSQL 8.3:
April 1st 2007 - Feature freeze
May 1st 2007 - Beta 1 release
June 1st 2007 - Release
This will obviously be a
Mark Cave-Ayland [EMAIL PROTECTED] writes:
The main problem I can see with keeping the CTEs outside the rangetable
is that according to the source, jointree nodes must currently have
RANGETBLREF nodes as leaf nodes; as I understand it, your suggestion of
maintaining the CTEs separately would
Dave Page wrote:
Following the recent discussion on this list and another on pgsql-core,
we have decided that we would like to aim to meet the following schedule
for the release of PostgreSQL 8.3:
April 1st 2007 - Feature freeze
May 1st 2007 - Beta 1 release
June 1st 2007 - Release
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 22 September 2006 15:26
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 8.3 Development Cycle
Sounds fine, but announcing this now is almost certain to reduce the
number of people
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 22 September 2006 15:26
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 8.3 Development Cycle
Sounds fine, but announcing this now is almost certain to
Bruce Momjian wrote:
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 22 September 2006 15:26
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 8.3 Development Cycle
Sounds fine, but announcing this now is almost
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 22 September 2006 15:35
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 8.3 Development Cycle
Err right - if you had said this yesterday when we
discussed the idea I
could have
Magnus Hagander [EMAIL PROTECTED] writes:
That definitely looks weird to me. Unfortunatly, it's way above me wrt
CVS knowledge. I'm just going to have to live with it and remember to
delete that part from my diffs...
The weird thing is that it's not happening for other people. Have you
tried
On Mon, Sep 11, 2006 at 19:05:12 -0400,
Gregory Stark [EMAIL PROTECTED] wrote:
I'm not sure how gmp and the others represent their data but my first guess is
that there's no particular reason the base of the mantissa and exponent have
to be the same as the base the exponent is interpreted
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
An admin who is concerned about this can revoke public access on the
functions for himself ... but should that be the default out-of-the-box
configuration? I feel more comfortable with saying you have to turn
on
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 22 September 2006 15:26
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 8.3 Development Cycle
Sounds fine, but announcing this now is almost certain to reduce the
number of
On 9/22/06, Tom Lane [EMAIL PROTECTED] wrote:
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
An admin who is concerned about this can revoke public access on the
functions for himself ... but should that be the default out-of-the-box
configuration? I feel more
On Thu, 2006-09-21 at 21:45 -0400, Bruce Momjian wrote:
Let me know how it looks.
Very Good
Very last, Minor change thoughts:
* Continuous archiving enhancements
change: Warm Standby enhancements
The improvements to Continuous Archiving
Merlin Moncure [EMAIL PROTECTED] writes:
advisory locks still show up as 'userlock' in the pg_locks view. does
this matter?
I'm disinclined to change that, because it would probably break existing
client-side code for little gain.
regards, tom lane
there are plenty of other potentially nasty things (like
generate_series and the ! operator). why are advisory_locks handled
specially? the way it stands right now is a user with command access
can DoS a server after five minutes of research on the web.
You don't even have to do any
On Sep 22, 2006, at 11:26 , Merlin Moncure wrote:
On 9/22/06, Tom Lane [EMAIL PROTECTED] wrote:
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
An admin who is concerned about this can revoke public access
on the
functions for himself ... but should that be
On Fri, Sep 22, 2006 at 12:03:46PM -0400, AgentM wrote:
On Sep 22, 2006, at 11:26 , Merlin Moncure wrote:
On 9/22/06, Tom Lane [EMAIL PROTECTED] wrote:
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
An admin who is concerned about this can revoke public
Dave Page wrote:
This will obviously be a short development cycle which will allow us to
get some of the features that just missed 8.2 out of the door, as well
as giving us the opportunity to try releasing before the summer (for
those in the northern hemisphere) rather than after.
Joshua's
Bruce, Dave,
This will likely stop people from migrating to 8.2, but so what? It
isn't going to stop new users and existing users in real production
setting will likely wait for 8.3 anyway.
And at this point most production users are only upgrading every 2-3
releases anyway (something which
-Original Message-
From: Tom Dunstan [EMAIL PROTECTED]
To: Dave Page dpage@vale-housing.co.uk
Cc: pgsql-hackers@postgresql.org pgsql-hackers@postgresql.org
Sent: 22/09/06 17:21
Subject: Re: [HACKERS] 8.3 Development Cycle
will other features be considered if
they're ready?
Yes, normal
Tom,
I'm obviously thinking of enums which was ready (for review at least) a
few weeks ago, but has probably bitrotted slightly since then given the
number of patches that have landed in the tree. I intended to brush it
up as soon as the 8.3 tree was open and resubmit it. Will that be a
waste
Tom Dunstan [EMAIL PROTECTED] writes:
Joshua's original mail suggested that only certain features would go in.
Is that still on the cards, or will other features be considered if
they're ready?
You'll note that Dave's mail said no such thing.
There has been some talk of trying to agree on a
On 9/22/06, AgentM [EMAIL PROTECTED] wrote:
I would be more worried about accidental collisions between
applications. The lock ranges will now need to be in their respective
i dont think this argument has merit because the lock is scoped to the
current database. this would only be a problem
On Wed, Sep 13, 2006 at 22:22:12 -0700,
Tom Dunstan [EMAIL PROTECTED] wrote:
That's a worthwhile point. How many patches come from the general
community vs out of the blue? Patches from regulars could probably get a
free pass, which might cut down the review burden substantially.
And how
Tom Dunstan wrote:
Dave Page wrote:
This will obviously be a short development cycle which will allow us to
get some of the features that just missed 8.2 out of the door, as well
as giving us the opportunity to try releasing before the summer (for
those in the northern hemisphere) rather than
Tom Lane wrote:
Matteo Beccati [EMAIL PROTECTED] writes:
Tom Lane ha scritto:
Matteo Beccati [EMAIL PROTECTED] writes:
I cannot see anything bad by using something like that:
if (histogram is large/representative enough)
Well, the question is exactly what is large enough? I feel a bit
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
This is why I suggested we set aside some range of numbers that should
not be used. Doing so would allow adding a better-managed
numbering/naming scheme in the future.
the whole point about advisory locks is that the provided lock space
is
Josh Berkus josh@agliodbs.com writes:
Bruce, Dave,
This will likely stop people from migrating to 8.2, but so what? It
isn't going to stop new users and existing users in real production
setting will likely wait for 8.3 anyway.
And at this point most production users are only upgrading
Good afternoon, dear PostgreSQL developers!
First I want to thank all of you for the great DB Server! It's really
useful, thank you!
Second, here is my question(guys from #postgresql channel advised to write
to dev list):
I want to make a silent install of PostgreSQL version 8.1 using your
On Sep 22, 2006, at 12:46 , Merlin Moncure wrote:
On 9/22/06, AgentM [EMAIL PROTECTED] wrote:
I would be more worried about accidental collisions between
applications. The lock ranges will now need to be in their respective
i dont think this argument has merit because the lock is scoped to
On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote:
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
This is why I suggested we set aside some range of numbers that should
not be used. Doing so would allow adding a better-managed
numbering/naming scheme in the future.
the whole
On Fri, Sep 22, 2006 at 02:16:53PM +0100, Dave Page wrote:
Following the recent discussion on this list and another on
pgsql-core, we have decided that we would like to aim to meet the
following schedule for the release of PostgreSQL 8.3:
April 1st 2007 - Feature freeze
^
We
On Thu, Sep 14, 2006 at 03:41:06 -0700,
Dhanaraj M [EMAIL PROTECTED] wrote:
Is there any utility in postgresql which can do the following?
The utility must update the table whenever there is any change in the
text file.
COPY command helps to do that, though this is not straight forward.
On Fri, Sep 22, 2006 at 11:58:04AM -0500, Bruno Wolff III wrote:
On Wed, Sep 13, 2006 at 22:22:12 -0700,
Tom Dunstan [EMAIL PROTECTED] wrote:
That's a worthwhile point. How many patches come from the general
community vs out of the blue? Patches from regulars could probably get a
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote:
the whole point about advisory locks is that the provided lock space
is unmanaged. for example, in the ISAM system I wrote which hooked
into the acucobol virtual file system
Joachim Wieland [EMAIL PROTECTED] writes:
Appended is a doc patch that removes tables B-4 and B-5 from Appendix B and
integrates information from there into other parts, mostly into section
8.5.3.
Applied with a few minor editorializations.
I still havent gotten a reply to
On Fri, Sep 22, 2006 at 01:21:57PM -0400, Merlin Moncure wrote:
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote:
the whole point about advisory locks is that the provided lock space
is unmanaged. for example, in the ISAM system
Josh Berkus wrote:
I'm obviously thinking of enums which was ready (for review at least) a
few weeks ago, but has probably bitrotted slightly since then given the
number of patches that have landed in the tree. I intended to brush it
up as soon as the 8.3 tree was open and resubmit it. Will that
Josh Berkus wrote:
Tom,
I'm obviously thinking of enums which was ready (for review at least) a
few weeks ago, but has probably bitrotted slightly since then given the
number of patches that have landed in the tree. I intended to brush it
up as soon as the 8.3 tree was open and resubmit it.
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
I'm not asking for a defined solution to how to support multiple
different users of locks within the same database. I just want us to set
aside (as in, recommend they not be used) some set of numbers so that in
the future we could recommend a
Tom Lane wrote:
Tom Dunstan [EMAIL PROTECTED] writes:
Joshua's original mail suggested that only certain features would go in.
Is that still on the cards, or will other features be considered if
they're ready?
You'll note that Dave's mail said no such thing.
No, but it did explicitly
Merlin Moncure [EMAIL PROTECTED] writes:
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
This is why I suggested we set aside some range of numbers that should
not be used. Doing so would allow adding a better-managed
numbering/naming scheme in the future.
the whole point about advisory
On Fri, Sep 22, 2006 at 01:42:48PM -0400, Merlin Moncure wrote:
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
I'm not asking for a defined solution to how to support multiple
different users of locks within the same database. I just want us to set
aside (as in, recommend they not be used)
I thought folks might be interested in this... note in particular the
comment about linux.
Begin forwarded message:
From: Greg 'groggy' Lehey [EMAIL PROTECTED]
Date: June 26, 2006 11:34:12 PM EDT
To: leo huang [EMAIL PROTECTED]
Cc: freebsd-performance@freebsd.org
Subject: Re: Is the fsync()
On 9/22/06, Tom Lane [EMAIL PROTECTED] wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
This is why I suggested we set aside some range of numbers that should
not be used. Doing so would allow adding a better-managed
numbering/naming scheme in
When initdb is given an invalid (possibly mistyped) locale name, it just
prints a warning and proceeds with the default locale from the
environment. Someone already wondered about this before:
/* should we exit here? */
if (!ret)
fprintf(stderr, _(%s: invalid locale name
Great, all added.
---
Simon Riggs wrote:
On Thu, 2006-09-21 at 21:45 -0400, Bruce Momjian wrote:
Let me know how it looks.
Very Good
Very last, Minor change thoughts:
* Continuous archiving
On Sep 22, 2006, at 14:11 , Jim C. Nasby wrote:
On Fri, Sep 22, 2006 at 01:21:57PM -0400, Merlin Moncure wrote:
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote:
the whole point about advisory locks is that the provided lock
On Thu, Sep 21, 2006 at 03:05:36PM -0500, Jim C. Nasby wrote:
Regardless, I think we should include a section of major new
projects/developments from pgFoundry, because they ultimately make
PostgreSQL a more useful database. Maybe this list should only be in the
I like that. New enhancement
Jim C. Nasby wrote:
On Fri, Sep 22, 2006 at 11:58:04AM -0500, Bruno Wolff III wrote:
On Wed, Sep 13, 2006 at 22:22:12 -0700,
Tom Dunstan [EMAIL PROTECTED] wrote:
That's a worthwhile point. How many patches come from the general
community vs out of the blue? Patches from regulars could
Good afternoon, dear PostgreSQL developers!
First I want to thank all of you for the great DB Server!
It's really useful, thank you!
Second, here is my question(guys from #postgresql channel
advised to write to dev list):
I want to make a silent install of PostgreSQL version 8.1
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
advisory locks still show up as 'userlock' in the pg_locks view. does
this matter?
I'm disinclined to change that, because it would probably break existing
client-side code for little gain.
I think clarity suggests we should make
Bruce Momjian wrote:
I created a major features list for 8.2 and put it into CVS. Instead of
going into detail (meaning the item would not appear in the Changes
section below, I just highlighted some of the big stuff, and was
purposely vague about the details, so people just have an overview of
On Fri, Sep 22, 2006 at 01:52:02PM -0400, Jim Nasby wrote:
I thought folks might be interested in this... note in particular the
comment about linux.
...
From: Greg 'groggy' Lehey [EMAIL PROTECTED]
Date: June 26, 2006 11:34:12 PM EDT
To: leo huang [EMAIL PROTECTED]
Cc:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm disinclined to change that, because it would probably break existing
client-side code for little gain.
I think clarity suggests we should make the heading match the feature,
i.e call it advisory rather than userlock. We changed
Jim C. Nasby [EMAIL PROTECTED] writes:
Ahh, ok, I didn't realize that the total lock space was larger than
what's being exposed today. That means we can easily add that stuff in
the future and not break anything, which is all I was looking for.
Yeah --- in particular, we can always add more
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
An admin who is concerned about this can revoke public access on the
functions for himself ... but should that be the default out-of-the-box
configuration? I feel more
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm disinclined to change that, because it would probably break existing
client-side code for little gain.
I think clarity suggests we should make the heading match the feature,
i.e call it advisory rather than
[EMAIL PROTECTED] writes:
I don't believe that fsync() on Linux syncs the whole file system
either.
Indeed. I'd disregard this as coming from someone who knows much
less than he thinks.
(The most likely explanation for his results, I expect, is that FreeBSD
is trying to fsync and the disk
On Sep 22, 2006, at 15:00 , [EMAIL PROTECTED] wrote:
On Fri, Sep 22, 2006 at 01:52:02PM -0400, Jim Nasby wrote:
I thought folks might be interested in this... note in particular the
comment about linux.
...
From: Greg 'groggy' Lehey [EMAIL PROTECTED]
Date: June 26, 2006 11:34:12 PM EDT
To:
Peter Eisentraut [EMAIL PROTECTED] writes:
When initdb is given an invalid (possibly mistyped) locale name, it just
prints a warning and proceeds with the default locale from the
environment. Someone already wondered about this before:
/* should we exit here? */
if (!ret)
AgentM [EMAIL PROTECTED] writes:
If I want to use these locks, it seems I will have to hard-code some
offset into each app or hash the schema name and use that as an
offset :( In any case, I can't imagine the wtf? nightmares an
accidental collision would induce.
That depends entirely on
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
(b) we put up that pgfoundry module so that there would be a backward
compatible solution. Won't be very backward compatible if the locks
look different in pg_locks.
But is anyone going to know what userlocks is in 1-2 years? We have
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
(b) we put up that pgfoundry module so that there would be a backward
compatible solution. Won't be very backward compatible if the locks
look different in pg_locks.
But is anyone going to know what userlocks is
On 9/22/06, AgentM [EMAIL PROTECTED] wrote:
Except you can put tables (and pretty much all your other objects)
in a
schema, one that's presumably named after your application. That
greatly
removes the odds of conficts.
Indeed. In our development environment, we store development,
Bruce Momjian [EMAIL PROTECTED] writes:
I don't see the column rename as an
API change issue.
How can you possibly claim it's not an API change?
If you're insistent on this, my recommendation would be to add a new
LOCKTAG value for advisory locks instead of re-using LOCKTAG_USERLOCK.
This
Tom,
Pretty sure. :) Why the oops? They haven't been mentioned in some PR
material or something have they?
No, I'd just been confused and thought the patch was submitted before
feature freeze.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of
Andrew Sullivan wrote:
On Thu, Sep 21, 2006 at 03:05:36PM -0500, Jim C. Nasby wrote:
Regardless, I think we should include a section of major new
projects/developments from pgFoundry, because they ultimately make
PostgreSQL a more useful database. Maybe this list should only be in the
I like
On 2006-09-22, Jim Nasby [EMAIL PROTECTED] wrote:
I thought folks might be interested in this... note in particular the
comment about linux.
I don't believe that either person in that discussion knows what they are
really talking about.
fsync() on FreeBSD does, as is required, force any
On 9/22/06, Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I don't see the column rename as an
API change issue.
How can you possibly claim it's not an API change?
i dunno, i agree with bruce here. we are just changing the output of
pg_locks a bit reflecting the
Merlin Moncure wrote:
On 9/22/06, Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I don't see the column rename as an
API change issue.
How can you possibly claim it's not an API change?
i dunno, i agree with bruce here. we are just changing the output
Bruce Momjian [EMAIL PROTECTED] writes:
I guess it is a compatibility change, but weighing compatibility against
clarity, I am leaning toward clarity. I assume it is this line that
would be changed:
_(user lock [%u,%u,%u,%u]),
You assume wrong ... that has nothing to do with what
Jie Zhang wrote:
Hi Heikki and all,
I just sent the latest bitmap index patch to the list. I am not sure if
there is any size limit for this mailing list. If you have received my
previous email, please let me know.
Hi Jie,
I know I said I was going to get testing on this months ago but I've
FYI, I am traveling to Oxford, England next week, Monday to Friday, to
meet with Simon and Heikki. My Internet connectivity will be irregular.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
On Friday 22 September 2006 12:40, Tom Lane wrote:
Tom Dunstan [EMAIL PROTECTED] writes:
Joshua's original mail suggested that only certain features would go in.
Is that still on the cards, or will other features be considered if
they're ready?
You'll note that Dave's mail said no such
Robert Treat wrote:
On Friday 22 September 2006 12:40, Tom Lane wrote:
Tom Dunstan [EMAIL PROTECTED] writes:
Joshua's original mail suggested that only certain features would go in.
Is that still on the cards, or will other features be considered if
they're ready?
You'll note that
Bruce Momjian [EMAIL PROTECTED] writes:
Agreed, but my guess is that we are going to introduce shorter varlena
headers for 8.3. It will hard to reject an optimization like that, and
that will probably change the disk format for most columns.
Well, several of the proposals that have been made
Just a short note that the first Beta is now available on
ftp.postgresql.org, and, shortly, on the mirrors ...
This isn't a full announce, which will be on Monday ... but please run a
few tests, make sure everything looks okay ...
Marc G. Fournier Hub.Org Networking Services
84 matches
Mail list logo
