Re: [HACKERS] [Pgbuildfarm-members] time to play ...
buen viaje :-) On 6/29/07, David Fetter <[EMAIL PROTECTED]> wrote: On Fri, Jun 29, 2007 at 11:25:31AM -0400, Andrew Dunstan wrote: > > For anyone who cares ... > > I will be on vacation in Spain for the next two weeks, and only Bon voyage! :) Cheers, D > sporadically in electronic contact. > > cheers > > andrew > ___ > Pgbuildfarm-members mailing list > [EMAIL PROTECTED] > http://pgfoundry.org/mailman/listinfo/pgbuildfarm-members -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! Consider donating to PostgreSQL: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- Guido Barosio --- http://www.globant.com [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] block size
Chaps: I am currently after the block size being used by major rdbm's and how do they take advantage of it. (ie, postgresql does interacts basically in two ways, by WAL'ing, and by the update activity, block size 8192) While I am googling this, hints will be apreciated. Thanks in advance, -- Guido Barosio --- http://www.globant.com [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Lack of urgency in 8.3 reviewing
What about a mentoring schema in order to push up the gap that represents catching up with cases like the one Andrew posted? By the way, being a patch reviewer doesn't represents also to be able to find out potential problems in the code, which may have nothing to do with the patch functionality? g.- On 5/16/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: Andrew Dunstan wrote: > > > Bruce Momjian wrote: > > In talking to people who are assigned to review patches or could review > > patches, I often get the reply, "Oh, yea, I need to do that". > > > > Folks, we are six weeks into feature freeze and have made slim progress > > on getting patches reviewed and applied. As I stated earlier, we are > > now looking at August/September for beta, but that might be pushed back > > even later if we don't get more progress. > > > > It seems there is a lot of reliance on Tom to get the patches applied, > > but I don't think that is fair or reasonable. I think we need more > > urgency on the part of everyone to make faster progress. Patch > > reviewers and committers need to take more initiative to get things done > > rather than wait for some external force to prompt them. > > > > > > I at least feel uncomfortable about reviewing code that deals with areas > I have not touched much, and where I feel the author probably knows a > lot more than me. The chance of my catching errors/problems in such a > case is much lower. Yep, that is part of our problem, but even items people have already said they _can_ review have shown little progress. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- Guido Barosio --- http://www.globant.com [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Lack of urgency in 8.3 reviewing
Bruce, where can I take a look at the patch list in order to find out if I can be of some help? Regards, g.- On 5/16/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: In talking to people who are assigned to review patches or could review patches, I often get the reply, "Oh, yea, I need to do that". Folks, we are six weeks into feature freeze and have made slim progress on getting patches reviewed and applied. As I stated earlier, we are now looking at August/September for beta, but that might be pushed back even later if we don't get more progress. It seems there is a lot of reliance on Tom to get the patches applied, but I don't think that is fair or reasonable. I think we need more urgency on the part of everyone to make faster progress. Patch reviewers and committers need to take more initiative to get things done rather than wait for some external force to prompt them. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Guido Barosio --- http://www.globant.com [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] question for serial types with CHECK conditions
Thanks for your reply Michael.
My point was to step on the asumption that the implicit "serial"
call for a type represents the fact that the sequence will start
allways in the same place, unless inmediatelly after your "create
table" you plan to modify that, which makes no sense when we go back
to what the CREATE SEQUENCE represents for the case.
For what I saw, straight foward what I did is wrong, but the server
allowed me to proceed. So yes, my fault, but with a bit of help,
right?
After all I am just being boggus on a silly point. The range of
potential DBA's which may come to this situation is pretty small for
further discussions :)
Best wishes,
g.-
On 4/28/07, Michael Glaesemann <[EMAIL PROTECTED]> wrote:
On Apr 28, 2007, at 10:30 , Guido Barosio wrote:
> Now, my question is: Shouldn't postgresql avoid the creation of the
> table while a serial type contains a check condition?
My question to you is why should it? "a" SERIAL is a shorthand for
creating an INTEGER column "a", a sequence ("a_seq") with a
dependency, and DEFAULT nextval(a_seq). There may be a valid reason
someone wants to put additional constraints on the column, and I'm
not sure why the server should second guess the DBA in this case. If
the CHECK constraint isn't what you want, then don't include it: and
in this case the server helpfully gave you an error which let you
know that the CHECK constraint was not doing what you expected.
Also, the server doesn't have the smarts to look into the CHECK
constraint and decide if it makes sense in your case. For example,
perhaps you want to have CHECK (a > 0), which won't really do
anything for a default sequence. However, if the sequence is changed,
it may return negative integers, which you may not want, so in some
cases, CHECK (a > 0) may be a valid constraint *in your case*.
The crux of the issue is that there may be valid reasons to have a
CHECK constraint on a INTEGER (SERIAL) column, and the server is not
(and will probably never be) smart enough to know your particular
business rules without you telling it specifically.
Does this help clarify the situation?
Michael Glaesemann
grzm seespotcode net
--
Guido Barosio
---
http://www.globant.com
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[HACKERS] question for serial types with CHECK conditions
Hey ya,
Found a behaviour that caught my attention. While it's not a real
problem, and definetely not serious, I realize that it may be good to
write about it, cause I couldn't find previous posts on the matter.
Basically, I am preparing a presentation for an install party, and
while I was checking the documentation for certain bullets I arrived
to the CHECK stuff.
Therefore, I went into my psql and threw the following, without
paying too much attention:
CREATE TABLE checksss (a serial CHECK (a > 1 and a < 10), b varchar);
followed by a :
INSERT INTO checksss (b) values ('asdf');
Obviously, postgresql replied with a big : "new row ...violates
check constraint ..."
Now, my question is: Shouldn't postgresql avoid the creation of the
table while a serial type contains a check condition? A serial type
represents a sequence, but is not the same as creating the sequence
per se, with special conditions from start.
I may be radically wrong, and this is probably the case, but I
couldn't resist and choose to ask.
Kind regards,
--
Guido Barosio
---
http://www.globant.com
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] Companies Contributing to Open Source
"Companies often bring fresh prespective, ideas, and testing infrastucture to a project." "prespective" || "perspective" ? g.- On 12/21/06, Kevin Grittner <[EMAIL PROTECTED]> wrote: >>> On Tue, Dec 19, 2006 at 6:13 PM, in message <[EMAIL PROTECTED]>, Bruce Momjian <[EMAIL PROTECTED]> wrote: > if the company dies, the community keeps going (as it did after Great > Bridge, without a hickup), but if the community dies, the company dies > too. This statement seems to ignore organizations for which PostgreSQL is an implementation detail in their current environment. While we appreciate PostgreSQL and are likely to try to make an occasional contribution, where it seems to be mutually beneficial, the Wisconsin State Courts would survive the collapse of the PostgreSQL community. While I can only guess at the reasons you may have put the slant you did on the document, I think it really should reflect the patient assistance the community provides to those who read the developers FAQ and make a good faith effort to comply with what is outlined there. The cooperative, professional, and helpful demeanor of the members of this community is something which should balanced against the community's need to act as a gatekeeper on submissions. I have recent experience as a first time employee contributor. When we hit a bump in our initial use of PostgreSQL because of the non-standard character string literals, you were gracious in accepting our quick patch as being possibly of some value in the implementation of the related TODO item. You were then helpful in our effort to do a proper implementation of the TODO item which fixes it. I see that the patch I submitted was improved by someone before it made the release, which is great. This illustrates how the process can work. I informed management of the problem, and presented the options -- we could do our own little hack that we then had to maintain and apply as the versions moved along, or we could try to do fix which the community would accept and have that feature "just work" for us for all subsequent releases. The latter was a little more time up front, but resulted in a better quality product for us, and less work in the long term. It was also presumably of some benefit to the community, which has indirect benefit to our organization. Nobody here wants to switch database products again soon, so if we can solve our problem in a way that helps the product gain momentum, all the better. I ran a consulting business for decades, and I know that there is a great variation in the attitudes among managers. Many are quite reasonable. I'm reminded of a meeting early in my career with a businessman who owned and operated half a dozen successful businesses in a variety of areas. He proposed a deal that I was on the verge of accepting, albeit somewhat reluctantly. He stopped me and told me that he hoped to continue to do business with me, so any deal we made had to benefit and work for both of us or it was no good at all; if I was uncomfortable with something in the proposal, we should talk it out. That's the core of what we're trying to say in this document, isn't it? The rest is an executive overview of the developer FAQ? I can't help feeling that even with the revisions so far it could have a more positive "spin". -Kevin ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- Guido Barosio --- http://www.globant.com [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Upgrading a database dump/restore
Well, there is a TODO item ( somewhere only we know ...).
Administration
* Allow major upgrades without dump/reload, perhaps using pg_upgrade
http://momjian.postgresql.org/cgi-bin/pgtodo?pg_upgrade
pg_upgrade resists itself to be born, but that discussion seems to
seed *certain* fundamentals for a future upgrade tool. It reached
pgfoundry, at least the name :)
g.-
On 10/5/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Mark Woodward" <[EMAIL PROTECTED]> writes:
> Not to cause any arguments, but this is sort a standard discussion that
> gets brought up periodically and I was wondering if there has been any
> "softening" of the attitudes against an "in place" upgrade, or movement to
> not having to dump and restore for upgrades.
Whenever someone actually writes a pg_upgrade, we'll institute a policy
to restrict changes it can't handle. But until we have a credible
upgrade tool it's pointless to make any such restriction. ("Credible"
means "able to handle system catalog restructurings", IMHO --- without
that, you'd not have any improvement over the current rules for minor
releases.)
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
--
Guido Barosio
---
http://www.globant.com
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] scripts/common.c minor memory leak
A good spot :)
Sorry for being no{isy}{vice}{wbie}, but what does it means "found by
coverity" ?
g.-
On 10/3/06, Martijn van Oosterhout wrote:
Just a minor thing. In yesno_prompt(), the value is resp is allocated
memory that is never freed.
File: src/bin/scripts/common.c
Line: 218
Not terribly important though, it's not used in critical utilities, but
it's used often.
Found by coverity.
--
Martijn van Oosterhout http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to
litigate.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFFItO3IB7bNG8LQkwRAk2bAKCB3AKuon35YAMOEjixN7P9HQeoBgCeOWpF
5/GvkeMtRwlncGBP9MG2qXw=
=FBVw
-END PGP SIGNATURE-
--
Guido Barosio
---
http://www.globant.com
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] contrib uninstall scripts need some love
Let me know if you need an extra pair of eyes. G.- On 9/10/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote: Tom Lane wrote: > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: >> Tom Lane wrote: >>> Seems like this area needs more attention ... anyone want to work on it? > >> I'll take it. How long do I have? > > Since it's contrib, I don't think we need to hold you to being done > before beta1. But the sooner the better of course. O.k., I will start working through it and report at the end of the week. Joshua D. Drake > > regards, tom lane > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Guido Barosio --- http://www.globant.com [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Did this work in earlier version of Postgres?
Which is actually a float8 :) CREATE TABLE public.test ( junk double precision, ); alter table public.test add column foo float8; Table "public.test" Column | Type | +--+-- junk | double precision | punk | double precision | Regards, Guido Barosio On 3/23/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote: > Tony Caduto wrote: > > I could have swore that this worked in earlier releases of Postgresql > > i.e. 7.4. > > > > CREATE TABLE public.test > > ( > > junk double NOT NULL, > > CONSTRAINT junk_pkey PRIMARY KEY (junk) > > )WITHOUT OIDS; > > There has never been a type named double in PostgreSQL. The type name > mandated by the SQL standard is double precision, and PostgreSQL > supports that. > > -- > Peter Eisentraut > http://developer.postgresql.org/~petere/ > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to [EMAIL PROTECTED] so that your >message can get through to the mailing list cleanly > -- Guido Barosio --- ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [ADMIN] How to VACUUM this table? "998994633 estimated total rows"
So this presents the fact that pg_stattuple should prevent and guess [taking a sample?] that a table needs an urgent lookup instead of ending the scan and presenting real numbers?g.- On 2/13/06, Chris Browne <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] (Guido Barosio) writes:> quote: " If you are quite sure it has few if any dead tuples, it might be> something to try to avoid VACUUMing except as needed to evade the 2^31 > transaction limit..."> You may use the pg_stattuple software, included in the /contrib . This will show you the current scenery, and whether you shall clean or not dead tuples.The trouble with pg_stattuple() is that running it is virtually as expensive as running the vacuum. For a bit table, you pay all the I/Ocost, and any costs of the super-long-running-transaction and don'teven get any cleanup for that cost.--let name="cbbrowne" and tld=" cbbrowne.com" in name ^ "@" ^ tld;;http://cbbrowne.com/info/lsf.htmlPhilosophy is a game with objectives and no rules. Mathematics is a game with rules and no objectives.---(end of broadcast)---TIP 4: Have you searched our list archives? http://archives.postgresql.org-- /"\ ASCII Ribbon Campaign .\ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail ./ \ -
