Dropping -general.
On Sep 14, 2006, at 5:33 PM, Steve Crawford wrote:
I would like the ability to absolutely set parameters/settings in psql
so that our psql scripts could generate predictable output absent a
known or controllable initial state. Original discussion at bottom of
message.
One alt
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> In short, our design is based on many of the pg_upgrade concepts but
> rewritten in C... if you have any blatant faults in pg_upgrade, that's
> the best place to start discussion.
Well, actually, there's a reason why pg_upgrade isn't in the CVS tree
On 9/21/06, Josh Berkus wrote:
OK ... can we re-name the project, please, though? It's going to be
hard for employees of other companies to contribute to the "EnterpriseDB
Migrator". Maybe "PGMigrator" with EnterpriseDB leading off the
discription?
I can't personally make that call but I'l
Jonah,
We certainly want it to be a community effort, we're just cleaning up
the design right now. The code itself will be posted as-is for anyone
to break, patch, and enhance.
Even if the design is the only thing the community latches onto,
improves, and drives into a new working pg_upgrade,
We would help if we do it in an open pgfoundry project.
Bizgres?
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Josh Berkus [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 21, 2006 11:08 PM Eastern Standard Time
To: Jonah H. Harris
Cc: pgsql-hackers@postgr
On 9/21/06, Josh Berkus wrote:
Ooops, didn't mean to start a which-hunt.
Not you're fault :)
So I think the thing to decide is whether this is EDB freeware or a real
community OSS effort. I think that we'll be happy to have either, but
right now it's in some grey area.
We certainly want i
Jonah,
I don't think I've seen anyone actually propose a design and state
they were going to work on it (at least until 8.3)... so it's funny
that I'm trying to follow the new, "keep the community informed"
policy and yet everyone is still not happy enough.
Ooops, didn't mean to start a which-
Jonah H. Harris wrote:
On 9/21/06, Tom Lane <[EMAIL PROTECTED]> wrote:
I see more and more people falling into the trap of doing a lot of work
*before* showing their ideas to the community. This is an excellent
plan if what you are hoping to accomplish is to waste a lot of work.
Otherwise, you'
On 9/21/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
You know, if I could post the Mammoth Replicator code for comment,
I'd do it as soon as possible, design flaws and coding bugs included.
It's easy to say something on the contrary when you know you can't
back it up to begin with.
Before eve
On 9/21/06, Tom Lane <[EMAIL PROTECTED]> wrote:
I see more and more people falling into the trap of doing a lot of work
*before* showing their ideas to the community. This is an excellent
plan if what you are hoping to accomplish is to waste a lot of work.
Otherwise, you'll do a lot better to ge
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
what is below.
Let
On Thu, 21 Sep 2006, Tom Lane wrote:
We've seen reports occasionally of how the system reports that
max_fsm_pages needs to be increased to at least X, and then when the DBA
does so, it complains that some larger amount is needed --- one recent
report is here:
http://archives.postgresql.org/pgsql
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Doesn't creating many temp tables in a transaction do the same thing?
>
> True, but it's a tad harder/less likely that you'd accidentally cause
> a problem that way.
Then why not use a GUC (that only an administrator can set) to cont
Jonah H. Harris wrote:
> On 9/21/06, Josh Berkus wrote:
> >So, are you saying that you already have code?
>
> Yes.
>
> >If not, care to open up the process? We have others interested in
> >contributing.
>
> We'll be opening it in the next few weeks. A large majority of it is
> working but we
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> On 9/21/06, Josh Berkus wrote:
>> If not, care to open up the process? We have others interested in
>> contributing.
> We'll be opening it in the next few weeks. A large majority of it is
> working but we want to solidify the design and current is
Markus Schaber wrote:
> Hi, Dave,
>
> Dave Cramer 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
> m
Simon Riggs wrote:
>
> SQL:2003 Analytical functions (Sergey, Tom, Neil)
>
> All statistical aggregate functions defined by SQL:2003 are now
> supported and user-defined aggregates now can take multiple columns as
> inputs.
>
Could this be a good starting point for SQL:2003 Window functions
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Josh Berkus wrote:
>> Bruce,
>>
>> What happened to PL/pgSQL debugging? Did it die?
>
> The debuggers is going to be on pgfoundry, if it isn't there already.
> The idea is that it would be loadable for 8.2, work out all the bugs,
> and perhaps included
Josh Berkus wrote:
> Bruce, All:
>
> > The debuggers is going to be on pgfoundry, if it isn't there already.
> > The idea is that it would be loadable for 8.2, work out all the bugs,
> > and perhaps included in 8.3.
> >
>
> So, should I take this off the press list for 8.2 and save it for 8.3,
Tom Lane wrote:
Well, we're not supporting dynamically linked objects in a static build ;-)
It's at least theoretically possible that you could link selected PL
objects into a static backend build, but no one is particularly
interested in expending effort on it. There don't seem to be any
pla
On 9/21/06, Josh Berkus wrote:
So, are you saying that you already have code?
Yes.
If not, care to open up the process? We have others interested in
contributing.
We'll be opening it in the next few weeks. A large majority of it is
working but we want to solidify the design and current i
Jonah,
> We're currently working on the design docs and a beta. Denis, Faiz,
> and/or Ahsan will post here when it's posted. You should expect some
> activity in this area in the next two weeks or so.
So, are you saying that you already have code?
If not, care to open up the process? We have
On 9/20/06, Josh Berkus wrote:
Supposedly someone from EnterpriseDB is working on this as well;
where are you?
Josh,
We're currently working on the design docs and a beta. Denis, Faiz,
and/or Ahsan will post here when it's posted. You should expect some
activity in this area in the next two
Tom Lane wrote:
> In fact, maybe vacuum should just throw a WARNING when it
> finds a single rel with more than MaxFSMPages pages with useful free
> space?
I fully agree with this. This (in particular, how many useful free
pages a rel has) is information a good DBA can make very good use of,
and
On Thu, Sep 21, 2006 at 11:24:53AM -0400, Bruce Momjian wrote:
> Josh Berkus wrote:
> > Bruce,
> >
> > What happened to PL/pgSQL debugging? Did it die?
>
> The debuggers is going to be on pgfoundry, if it isn't there already.
> The idea is that it would be loadable for 8.2, work out all the bug
Tom Lane wrote:
I think it's reasonable for vacuumlazy.c to track at most MaxFSMPages
pages as it's doing now --- but it should keep a separate count of the
total number of pages with at least threshold amount of free space, and
pass that as a separate argument to RecordRelationFreeSpace. This w
Hi, Tom,
Tom Lane wrote:
> I think it's reasonable for vacuumlazy.c to track at most MaxFSMPages
> pages as it's doing now --- but it should keep a separate count of the
> total number of pages with at least threshold amount of free space, and
> pass that as a separate argument to RecordRelationF
Hi, Dave,
Dave Cramer 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 7.4.13). So
Bruce, All:
The debuggers is going to be on pgfoundry, if it isn't there already.
The idea is that it would be loadable for 8.2, work out all the bugs,
and perhaps included in 8.3.
So, should I take this off the press list for 8.2 and save it for 8.3,
when the feature will be actually usefu
We've seen reports occasionally of how the system reports that
max_fsm_pages needs to be increased to at least X, and then when the DBA
does so, it complains that some larger amount is needed --- one recent
report is here:
http://archives.postgresql.org/pgsql-admin/2006-06/msg00176.php
I finally g
Martijn van Oosterhout wrote:
On Wed, Sep 20, 2006 at 10:56:08AM -0700, Mark Dilger wrote:
If the system chooses cast chains based on a breadth-first search, then the
existing int2 -> int8 cast would be chosen over an int2 -> int4 -> int8
chain, or an int2 -> int3 -> int4 -> int8 chain, or in f
Jeremy Drake <[EMAIL PROTECTED]> writes:
> I put together a patch which adds a regression test for large objects,
> hopefully attached to this message. I would like some critique of it, to
> see if I have gone about it the right way. Also I would be happy to hear
> any additional tests which shou
Simon Riggs wrote:
> On Wed, 2006-09-20 at 20:43 -0300, Tom Lane wrote:
> > Log Message:
> > ---
> > Add documentation for new in-core advisory lock functions. Merlin Moncure
> >
> > Modified Files:
> > --
> > pgsql/doc/src/sgml:
> > func.sgml (r1.338 -> r1.339)
>
Simon Riggs <[EMAIL PROTECTED]> writes:
> The release notes don't mention that the advisory locks feature has been
> added either.
I think Bruce only has the notes synced up to about a week ago ...
regards, tom lane
---(end of broadcast)---
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
> Sent: 21 September 2006 16:25
> To: Josh Berkus
> Cc: pgsql-hackers@postgresql.org; Simon Riggs
> Subject: Re: [HACKERS] Release Notes: Major Changes in 8.2
>
> Josh Berkus wrote:
>
OK, I will work it.
---
Simon Riggs wrote:
> On Wed, 2006-09-20 at 23:22 -0400, Bruce Momjian wrote:
>
> > Usually the major items just jump out of the release list. In this
> > case, nothing really jumped out, and I felt
Josh Berkus wrote:
> Bruce,
>
> What happened to PL/pgSQL debugging? Did it die?
The debuggers is going to be on pgfoundry, if it isn't there already.
The idea is that it would be loadable for 8.2, work out all the bugs,
and perhaps included in 8.3.
--
Bruce Momjian [EMAIL PROTECTED]
En
* 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 this potentially-dangerous feature" tha
Am Donnerstag, 21. September 2006 16:02 schrieb Tom Lane:
> There don't seem to be any
> platforms anymore on which --disable-shared is actually important.
> (Should we just get rid of it?)
IIRC, I added it in the past to test for static-only platforms like QNX. I
don't know if we plan to suppor
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Another question is, what should cmin and cmax system columns return?
If we're going to fool with these, I'd like to renew the suggestion I
made awhile back that none of the system columns should have explicit
entries in pg_attribute, but rather the
Le jeudi 21 septembre 2006 01:52, Tom Lane a écrit :
> Or we could try to do something about limiting the number of such locks
> that can be granted, but that seems nontrivial to tackle at such a late
> stage of the devel cycle.
>
> Thoughts?
What about reserving some amount of shared_buffers out
Tom Lane wrote:
It's at least theoretically possible that you could link selected PL
objects into a static backend build, but no one is particularly
interested in expending effort on it. There don't seem to be any
platforms anymore on which --disable-shared is actually important.
(Should we just
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Doesn't creating many temp tables in a transaction do the same thing?
True, but it's a tad harder/less likely that you'd accidentally cause
a problem that way.
I'm not sure if I'm crying wolf or whether there's a serious issue.
Certainly, if you have SQ
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.
Did they ?
Dave
---(end of broadcast)---
TIP 6: explain analyze is your friend
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> Because createlang relies on *dynamic* loading.
> So that is working as designed.
> I interpret that as 'static builds for the database
> server are not supported'. Ok by me.
Well, we're not supporting dynamically linked obje
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> We could also limit the size of the hash table, which takes up most of
> the memory, and only keep the latest phantom cids there. Presumably, if
> current command id is 1000, you're not likely to set cmax to 500 on any
> tuple in that transaction
On Wed, 2006-09-20 at 20:43 -0300, Tom Lane wrote:
> Log Message:
> ---
> Add documentation for new in-core advisory lock functions. Merlin Moncure
>
> Modified Files:
> --
> pgsql/doc/src/sgml:
> func.sgml (r1.338 -> r1.339)
>
> (http://developer.postgres
Another question is, what should cmin and cmax system columns return? If
we overlay cmin and cmax, cmin and cmax on-disk will always be the same
value. And with phantom cids, it wouldn't be meaningful outside the
inserting/deleting transaction.
The options that I can think of are:
1. Only ret
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
A big question is, do we need to implement spilling to disk?
My thought is no, at least not in the first cut ... this is something
that can be added later if it proves critical, and right at the moment
my guess is that it n
> True, but running several dozen instances on a single machine will
> require a lot more memory (or, conversely, each individual database gets
> a lot less memory to use).
>
> Of course, this is all hand-waving right now... it'd be interesting to
> see which approach was actually better.
I'm run
On Wed, 2006-09-20 at 23:22 -0400, Bruce Momjian wrote:
> Usually the major items just jump out of the release list. In this
> case, nothing really jumped out, and I felt if I listed sereral, it was
> going to look weak because they were not big things, so I figured I
> would just go with the "br
On Wed, Sep 20, 2006 at 10:56:08AM -0700, Mark Dilger wrote:
> If the system chooses cast chains based on a breadth-first search, then the
> existing int2 -> int8 cast would be chosen over an int2 -> int4 -> int8
> chain, or an int2 -> int3 -> int4 -> int8 chain, or in fact any chain at
> all, b
52 matches
Mail list logo
