Re: [HACKERS] Block-level CRC checks

2009-12-01 Thread Robert Haas
On Tue, Dec 1, 2009 at 8:30 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Bruce Momjian wrote: What might be interesting is to report CRC mismatches if the database was shut down cleanly previously;  I think in those cases we shouldn't have torn pages. Unfortunately

Re: [HACKERS] CommitFest status/management

2009-12-01 Thread Robert Haas
On Tue, Dec 1, 2009 at 8:27 AM, Andrew Dunstan and...@dunslane.net wrote: Bruce Momjian wrote: It would also like to clarify the use case for this a little bit more.  Is this just to track patches which committers are in the process of committing (or have committed)?  Or would a committer

Re: [HACKERS] CommitFest status/management

2009-12-01 Thread Robert Haas
On Tue, Dec 1, 2009 at 9:42 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: If we went with Bruce's interpretation, we could have a committer field that only appears when the status is Claimed by Committer or Committed and the contents of that field could

Re: [HACKERS] Block-level CRC checks

2009-12-01 Thread Robert Haas
On Tue, Dec 1, 2009 at 9:40 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Even if rescanning every page in the cluster was feasible from a performance point-of-view, it would make the CRC checking a lot less useful. It's not hard to imagine that when a hardware glitch

Re: [HACKERS] [PATCH] Windows x64

2009-12-01 Thread Robert Haas
On Tue, Dec 1, 2009 at 6:25 AM, Tsutomu Yamada tsut...@sraoss.co.jp wrote: Hello. The following patches support Windows x64. 1) use intptr_t for Datum and pointer macros. (to support Windows LLP64)   almost the same as that post before.  

Re: [HACKERS] Fwd: psql+krb5

2009-12-01 Thread Robert Haas
2009/11/30 rahimeh khodadadi rahimeh.khodad...@gmail.com: -- Forwarded message -- From: rahimeh khodadadi rahimeh.khodad...@gmail.com Date: 2009/11/29 Subject: Re: psql+krb5 To: Denis Feklushkin denis.feklush...@gmail.com Please review the guidelines for reporting a

Re: [HACKERS] Block-level CRC checks

2009-12-01 Thread Robert Haas
On Tue, Dec 1, 2009 at 10:35 AM, Simon Riggs si...@2ndquadrant.com wrote: On Tue, 2009-12-01 at 16:40 +0200, Heikki Linnakangas wrote: It's not hard to imagine that when a hardware glitch happens causing corruption, it also causes the system to crash. Recalculating the CRCs after crash would

Re: [GENERAL] [HACKERS] Fwd: psql+krb5

2009-12-01 Thread Robert Haas
On Tue, Dec 1, 2009 at 11:26 AM, Scott Marlowe scott.marl...@gmail.com wrote: Except that he posted a month ago and got no answers... Gee, I wonder why. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Re: [COMMITTERS] pgsql: Rewrite GEQO`s gimme_tree function so that it always finds a

2009-12-01 Thread Robert Haas
On Tue, Dec 1, 2009 at 11:39 AM, Greg Sabino Mullane g...@turnstep.com wrote: Playing around with this a bit, I was easily able to get 2-second planing times on 15 table join, 6-second planning times on a 16 table join and 30-second planning times on a 17 table join.  This makes it hard to

Re: [HACKERS] Block-level CRC checks

2009-12-01 Thread Robert Haas
On Tue, Dec 1, 2009 at 1:02 PM, Joshua D. Drake j...@commandprompt.com wrote: The hard core reality is this. *IF* it is one of the goals of this project to insure that the software can be safely, effectively, and responsibly operated in a manner that is acceptable to C* level people in a

Re: [HACKERS] Block-level CRC checks

2009-12-01 Thread Robert Haas
On Tue, Dec 1, 2009 at 2:06 PM, Aidan Van Dyk ai...@highrise.ca wrote: Well, *I* think if we're ever going to have really reliable in-place upgrades that we can expect to function release after release, we're going to need to be able to read in old version pages, and convert them to current

Re: [HACKERS] Block-level CRC checks

2009-12-01 Thread Robert Haas
On Tue, Dec 1, 2009 at 3:04 PM, Greg Stark gsst...@mit.edu wrote: I find that hard to understand. I believe the consensus is that an on-demand page-level migration statregy like Aidan described is precisely the plan when it's necessary to handle page format changes. There were no page format

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

2009-12-01 Thread Robert Haas
On Tue, Dec 1, 2009 at 5:15 PM, Greg Stark gsst...@mit.edu wrote: On Tue, Dec 1, 2009 at 9:58 PM, decibel deci...@decibel.org wrote: What happened to the work that was being done to allow a page to be upgraded on the fly when it was read in from disk? There were no page level changes between

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

2009-12-01 Thread Robert Haas
On Tue, Dec 1, 2009 at 9:31 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Tue, Dec 1, 2009 at 5:15 PM, Greg Stark gsst...@mit.edu wrote: On Tue, Dec 1, 2009 at 9:58 PM, decibel deci...@decibel.org wrote: What happened to the work that was being done to allow a page

Re: [HACKERS] [PATCH] bugfix for int2vectorin

2009-12-01 Thread Robert Haas
On Tue, Dec 1, 2009 at 10:38 PM, Tom Lane t...@sss.pgh.pa.us wrote: Caleb Welton cwel...@greenplum.com writes: I believe the int2vectorin function should handle invalid input more cleanly. Why bother?  Under what circumstances would users (or anyone at all) be putting data into an int2vector?

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

2009-12-01 Thread Robert Haas
On Tue, Dec 1, 2009 at 10:34 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: Well, there were quite a number of open issues relating to page conversion: ? ? ? ?o ?Do we write the old version or just convert on read? ? ? ? ?o ?How do we write pages that get larger

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

2009-12-01 Thread Robert Haas
On Tue, Dec 1, 2009 at 10:45 PM, Greg Smith g...@2ndquadrant.com wrote: Robert Haas wrote: If the pre-upgrade utility is something that has to be run while the database is off-line, then it defeats the point of an in-place upgrade.  If it can be run while the database is up, I fear

Re: [HACKERS] operator exclusion constraints

2009-12-01 Thread Robert Haas
On Fri, Nov 27, 2009 at 10:18 PM, Jeff Davis pg...@j-davis.com wrote: On Thu, 2009-11-26 at 01:33 -0800, Jeff Davis wrote: Remaining issues:  * represent operator IDs in catalog, rather than strategy numbers Done, attached.  * if someone thinks it's an issue, support search strategies that

Re: [HACKERS] operator exclusion constraints

2009-12-02 Thread Robert Haas
On Wed, Dec 2, 2009 at 12:18 AM, Jeff Davis pg...@j-davis.com wrote: On Tue, 2009-12-01 at 23:19 -0500, Robert Haas wrote: For parity with unique constraints, I think that the message: operator exclusion constraint violation detected: %s should be changed to: conflicting key value violates

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

2009-12-02 Thread Robert Haas
On Tue, Dec 1, 2009 at 11:45 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: The key issue, as I think Heikki identified at the time, is to figure out how you're eventually going to get rid of the old pages. ?He proposed running a pre-upgrade utility on each page to reserve

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

2009-12-02 Thread Robert Haas
On Wed, Dec 2, 2009 at 11:08 AM, Simon Riggs si...@2ndquadrant.com wrote: On Wed, 2009-12-02 at 10:48 -0500, Robert Haas wrote: Well, that's sort of a circular argument.  If you're going to reserve space with a pre-upgrade utility, you're going to need to put the pre-upgrade utility

Re: [CORE] [HACKERS] EOL for 7.4?

2009-12-02 Thread Robert Haas
On Wed, Dec 2, 2009 at 12:22 PM, Greg Sabino Mullane g...@turnstep.com wrote: Mark wrote: Doesn't mean that packagers have to make new packages ... I personally think new packages shouldn't be made for anything older then *maybe* 3 releases (8.2, 8.3 and 8.4), but even that I think tends to be

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

2009-12-02 Thread Robert Haas
On Wed, Dec 2, 2009 at 1:08 PM, Greg Smith g...@2ndquadrant.com wrote: Robert Haas wrote: The problem I'm referring to is that there is no guarantee that you would be able predict how much space to reserve.  In a case like CRCs, it may be as simple as 4 bytes.  But what if, say, we switch

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

2009-12-02 Thread Robert Haas
On Wed, Dec 2, 2009 at 1:56 PM, Greg Smith g...@2ndquadrant.com wrote: Robert Haas wrote: Some additional catalog support was suggested to mark what the pre-upgrade utility had processed.   I'm sure I could find the messages about again if I had to. And that's a perfectly sensible solution

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

2009-12-02 Thread Robert Haas
On Wed, Dec 2, 2009 at 2:27 PM, Greg Smith g...@2ndquadrant.com wrote: Robert Haas wrote: On Wed, Dec 2, 2009 at 1:56 PM, Greg Smith g...@2ndquadrant.com wrote: There's no reason the associated catalog support had to ship with the old version.  You can always modify the catalog after initdb

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

2009-12-02 Thread Robert Haas
On Wed, Dec 2, 2009 at 3:48 PM, Tom Lane t...@sss.pgh.pa.us wrote: Greg Stark gsst...@mit.edu writes: This whole discussion is based on assumptions which do not match my recollection of the old discussion. I would suggest people go back and read the emails but it's clear at least some people

Re: [HACKERS] Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a

2009-12-02 Thread Robert Haas
On Wed, Dec 2, 2009 at 5:08 PM, Greg Sabino Mullane g...@turnstep.com wrote: What about 14? Could we at least raise it to 14? 1/2 :) I doubt we can raise it at all without lying to ourselves about the likely results of so doing.  The GEQO planning times are in the low double digits of

Re: [HACKERS] set the cost of an aggregate function

2009-12-02 Thread Robert Haas
On Mon, Nov 30, 2009 at 11:53 AM, Jaime Casanova jcasa...@systemguards.com.ec wrote: 2009/11/30 Jaime Casanova jcasa...@systemguards.com.ec: Hi, why we can't do $subject? it could have any benefit on the planner? seems like while we can set the cost of the state transition function, that

Re: [HACKERS] CommitFest status/management

2009-12-02 Thread Robert Haas
On Tue, Dec 1, 2009 at 9:43 AM, Robert Haas robertmh...@gmail.com wrote: On Tue, Dec 1, 2009 at 9:42 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: If we went with Bruce's interpretation, we could have a committer field that only appears when the status

Re: [HACKERS] Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a

2009-12-02 Thread Robert Haas
On Wed, Dec 2, 2009 at 9:55 PM, Tom Lane t...@sss.pgh.pa.us wrote: One other thing I'm noticing about the current implementation is that it seems to spend an entirely excessive amount of brain power considering the best order in which to execute cross-joins.  If I do X, A JOIN B ON Pab JOIN C

Re: [HACKERS] Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a

2009-12-02 Thread Robert Haas
On Wed, Dec 2, 2009 at 10:32 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Not sure what you mean.  There's already a special-case code path for cross joins; but I think it's probably considering a lot of silly paths.  Is there a case where it makes sense

Re: [HACKERS] patch - per-tablespace random_page_cost/seq_page_cost

2009-12-03 Thread Robert Haas
On Sat, Nov 28, 2009 at 9:54 PM, David Rowley dgrow...@gmail.com wrote: Robert Haas Wrote: Hmm.  I'm not able to reliably detect a performance difference between unpatched CVS HEAD (er... git master branch) and same with spcoptions- v2.patch applied.  I figured that if there were going

Re: [HACKERS] [PATCH] Largeobject Access Controls (r2432)

2009-12-03 Thread Robert Haas
On Thu, Dec 3, 2009 at 12:49 PM, Jaime Casanova jcasa...@systemguards.com.ec wrote: This manual will be specific for 8.5 so i think all mentions to the version should be removed Not sure I agree on this point. We have similar mentions elsewhere. ...Robert -- Sent via pgsql-hackers mailing

Re: [HACKERS] [PATCH] Largeobject Access Controls (r2432)

2009-12-03 Thread Robert Haas
On Thu, Dec 3, 2009 at 1:23 PM, Greg Smith g...@2ndquadrant.com wrote: Robert Haas wrote: On Thu, Dec 3, 2009 at 12:49 PM, Jaime Casanova jcasa...@systemguards.com.ec wrote: This manual will be specific for 8.5 so i think all mentions to the version should be removed Not sure I agree

Re: [HACKERS] [PATCH] Largeobject Access Controls (r2432)

2009-12-03 Thread Robert Haas
On Thu, Dec 3, 2009 at 2:25 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Thu, Dec 3, 2009 at 1:23 PM, Greg Smith g...@2ndquadrant.com wrote: In this particular example, it's bad form because it's even possible that 8.5 will actually be 9.0.  You don't

Re: [HACKERS] [PATCH] Largeobject Access Controls (r2432)

2009-12-03 Thread Robert Haas
On Thu, Dec 3, 2009 at 3:33 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: I agree that search and replace isn't that hard, but I don't find the proposed construction awkward, and we have various uses of it in the docs already.  Actually the COPY one

Re: [HACKERS] operator exclusion constraints

2009-12-03 Thread Robert Haas
On Thu, Dec 3, 2009 at 7:42 PM, Jeff Davis pg...@j-davis.com wrote: On Thu, 2009-12-03 at 19:00 -0500, Tom Lane wrote: I'm starting to go through this patch now.  I thought the consensus was to refer to them as just exclusion constraints?  I'm not seeing that the word operator really adds

Re: [HACKERS] Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a

2009-12-03 Thread Robert Haas
On Wed, Dec 2, 2009 at 10:53 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Well, when I was testing, I believe I observed that an n-way join with 1 cross join was slower to plan than an n-way join with no cross joins.  ISTM that it should actually be faster

Re: [HACKERS] Block-level CRC checks

2009-12-04 Thread Robert Haas
On Fri, Dec 4, 2009 at 9:48 AM, Alvaro Herrera alvhe...@commandprompt.com wrote: Heikki Linnakangas escribió: Simon Riggs wrote: On Fri, 2009-12-04 at 09:52 -0300, Alvaro Herrera wrote: BTW with VACUUM FULL removed I assume we're going to get rid of HEAP_MOVED_IN and HEAP_MOVED_OFF too,

Re: [HACKERS] operator exclusion constraints

2009-12-04 Thread Robert Haas
On Dec 4, 2009, at 11:35 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Thu, Dec 3, 2009 at 7:42 PM, Jeff Davis pg...@j-davis.com wrote: On Thu, 2009-12-03 at 19:00 -0500, Tom Lane wrote: I'm starting to go through this patch now. I thought the consensus

Re: [HACKERS] First feature patch for plperl - draft [PATCH]

2009-12-04 Thread Robert Haas
On Fri, Dec 4, 2009 at 1:51 PM, Tom Lane t...@sss.pgh.pa.us wrote: David E. Wheeler da...@kineticode.com writes: On Dec 4, 2009, at 10:36 AM, Tom Lane wrote: I vote a big no on this. That's fine. It's relatively simple for an admin to create a Perl module that does everything she wants,

Re: [HACKERS] First feature patch for plperl - draft [PATCH]

2009-12-04 Thread Robert Haas
On Fri, Dec 4, 2009 at 2:05 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: So, do we look for another way to provide the functionality besides having a GUC, or is the functionality itself bad? I don't think we want random Perl code running inside

Re: [HACKERS] Block-level CRC checks

2009-12-04 Thread Robert Haas
On Fri, Dec 4, 2009 at 2:04 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Fri, Dec 4, 2009 at 9:48 AM, Alvaro Herrera alvhe...@commandprompt.com wrote: Heikki Linnakangas escribi?: Simon Riggs wrote: On Fri, 2009-12-04 at 09:52 -0300, Alvaro Herrera wrote: BTW

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-04 Thread Robert Haas
On Wed, Dec 2, 2009 at 4:24 PM, Tom Lane t...@sss.pgh.pa.us wrote: Ron Mayer rm...@cheapcomplexdevices.com writes: Tom Lane wrote: Hmm.  So the argument for it is let's make a machine-readable format more human-readable?  I'm not getting the point.  People should look at the regular text

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-04 Thread Robert Haas
On Fri, Dec 4, 2009 at 7:42 PM, Josh Berkus j...@agliodbs.com wrote: On top of that, if you did want YAML for easier readability, what aspect of the output is more readable in YAML than it is in text format?  The only answer I can think of is that you like having each data element on a

Re: [HACKERS] Adding support for SE-Linux security

2009-12-04 Thread Robert Haas
On Thu, Dec 3, 2009 at 5:23 PM, Josh Berkus j...@agliodbs.com wrote: In words of one syllable: I do not care at all whether the NSA would use Postgres, if they're not willing to come and help us build it. There's several 2-syllable words there.  ;-)  If we tried to build it without their

Re: [HACKERS] Adding support for SE-Linux security

2009-12-05 Thread Robert Haas
On Sat, Dec 5, 2009 at 12:14 AM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: Actually, we tried that already, in a previous iteration of this discussion.  Someone actually materialized and commented on a few things.  The problem, as I remember it, was that they didn't know much

Re: [HACKERS] Cancelling idle in transaction state

2009-12-05 Thread Robert Haas
On Sat, Dec 5, 2009 at 8:13 PM, James Pye li...@jwp.name wrote: I think the answer here is that the server should *not* report the cancellation. Rather, it should mark the transaction as failed and let the client eventually sync its state on subsequent requests that will result in

Re: [HACKERS] Cancelling idle in transaction state

2009-12-05 Thread Robert Haas
On Sat, Dec 5, 2009 at 10:15 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: I think this line of thinking is on the right track.  The server should certainly not send back an immediate ERROR response, because that will definitely confuse the client.  Of course

Re: [HACKERS] Cancelling idle in transaction state

2009-12-06 Thread Robert Haas
On Dec 6, 2009, at 2:58 AM, Simon Riggs si...@2ndquadrant.com wrote: On Sat, 2009-12-05 at 18:13 -0700, James Pye wrote: On Dec 5, 2009, at 12:25 PM, Simon Riggs wrote: ... I'm not volunteering here, but having worked with the protocol, I do have a suggestion: Thanks. Looks like good

Re: [HACKERS] Hot standby, recent changes

2009-12-06 Thread Robert Haas
On Sun, Dec 6, 2009 at 3:06 PM, Simon Riggs si...@2ndquadrant.com wrote: On Sun, 2009-12-06 at 20:32 +0200, Heikki Linnakangas wrote: Simon Riggs wrote: On Sun, 2009-12-06 at 12:32 +0200, Heikki Linnakangas wrote: 4. Need to handle the case where master is started up with

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-06 Thread Robert Haas
On Sun, Dec 6, 2009 at 8:34 PM, Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp wrote: Josh Berkus j...@agliodbs.com wrote: Having compared the JSON and YAML output formats, I think having YAML as a 2nd human-readable format might be valuable, even though it adds nothing to

Re: [HACKERS] Adding support for SE-Linux security

2009-12-06 Thread Robert Haas
On Sat, Dec 5, 2009 at 8:18 AM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: I offered to review it. ?I was going to mostly review the parts that impacted our existing code, and I wasn't going to be able to do a thorough job of the SE-Linux-specific files. Review it and commit

Re: [HACKERS] EXPLAIN BUFFERS

2009-12-07 Thread Robert Haas
On Mon, Dec 7, 2009 at 1:28 AM, Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp wrote: (ii) format: why does text output format have less counters than the other ones? That's because lines will be too long for text format. I think the three values in it are the most important and useful

Re: [HACKERS] Adding support for SE-Linux security

2009-12-07 Thread Robert Haas
On Mon, Dec 7, 2009 at 9:48 AM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: This is no harder than many of the other seemingly crazy things I have done, e.g. Win32 port, client library threading. ?If this is a feature we should have, I will get it done or get others to help me

Re: [HACKERS] new CommitFest states (was: YAML)

2009-12-07 Thread Robert Haas
On Mon, Dec 7, 2009 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote: Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes: Tom Lane t...@sss.pgh.pa.us wrote: It was written and submitted by one person who did not bother to ask first whether anyone else thought it was worthwhile.  So its

Re: [HACKERS] Need a mentor, and a project.

2009-12-07 Thread Robert Haas
On Sun, Dec 6, 2009 at 9:24 PM, abin...@u.washington.edu wrote: 2. Would someone be willing to be a mentor? It would be nice to be able to get some guidance on a one-to-one basis. I might be willing to do this, but if you pick a project that is outside my area of knowledge then I might not be

Re: [HACKERS] bug: json format and auto_explain

2009-12-07 Thread Robert Haas
On Mon, Dec 7, 2009 at 10:42 AM, Alvaro Herrera alvhe...@commandprompt.com wrote: Tom Lane wrote: Euler Taveira de Oliveira eu...@timbira.com writes: While testing the EXPLAIN BUFFERS patch I found a bug. I'm too tired to provide a fix right now but if someone can take it I will appreciate.

Re: [HACKERS] Adding support for SE-Linux security

2009-12-07 Thread Robert Haas
On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian br...@momjian.us wrote: As Alvaro mentioned, the original patch used ACE but it added too much code so the community requested its removal from the patch.  It could be re-added if we have a need. Well, there's no point in putting that framework

Re: [HACKERS] bug: json format and auto_explain

2009-12-07 Thread Robert Haas
On Mon, Dec 7, 2009 at 11:07 AM, Tom Lane t...@sss.pgh.pa.us wrote: Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes: Tom Lane t...@sss.pgh.pa.us wrote: Looks like auto_explain is under the illusion that it need not call ExplainBeginOutput/ExplainEndOutput. Explain{Begin/End}Output are

Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion

2009-12-07 Thread Robert Haas
On Mon, Dec 7, 2009 at 9:12 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: If we do need to do this, perhaps we should change the older parameter to be partition_exclusion. Yeah, if we do want to do something about this then

Re: [HACKERS] EXPLAIN BUFFERS

2009-12-07 Thread Robert Haas
On Mon, Dec 7, 2009 at 9:58 PM, Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp wrote: Here is an updated patch per discussion.  * Counters are accumulative. They contain I/Os by child nodes.  * Text format shows all counters.  * Add shared_ prefix to variables representing shared

Re: [HACKERS] some questions in postgresql developping

2009-12-07 Thread Robert Haas
2009/12/7 黄晓骋 huangxcl...@gmail.com: I’m a student from Nankai University in China. Now I and my team do a project which aims to integrate XML to Postgresql. What I do is to complete the function of XML Update. Now I’m researching in concurrency control. I have read the code about the

Re: [HACKERS] bug: fuzzystrmatch levenshtein is wrong

2009-12-07 Thread Robert Haas
On Mon, Dec 7, 2009 at 8:33 AM, marcin mank marcin.m...@gmail.com wrote: The current behavior of levenshtein(text,text,int,int,int) is wrong. Consider: Is this the same problem as bug #5098? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Need a mentor, and a project.

2009-12-07 Thread Robert Haas
On Mon, Dec 7, 2009 at 8:04 PM, Ashish abin...@u.washington.edu wrote: Hi Robert, Thanks. If I may, what encompasses your area of expertise... BTW Congratulation on becoming a committer! Thanks. As others have said, it's probably best to pick a project first, or at least an area. It's more

Re: [HACKERS] EXPLAIN BUFFERS

2009-12-07 Thread Robert Haas
On Mon, Dec 7, 2009 at 11:09 PM, Greg Smith g...@2ndquadrant.com wrote: Robert Haas wrote: On Mon, Dec 7, 2009 at 9:58 PM, Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp wrote: Obviously I should not hide any information only in the text format. The new output will be: (in one line

Re: [HACKERS] EXPLAIN BUFFERS

2009-12-08 Thread Robert Haas
On Dec 8, 2009, at 12:05 AM, Greg Smith g...@2ndquadrant.com wrote: Robert Haas wrote: I could live with the equals signs, but the use of parentheses seems weird and inconsistent with normal english usage (which permits parentheses as a means of making parenthetical comments

Re: [HACKERS] YAML

2009-12-08 Thread Robert Haas
On Tue, Dec 8, 2009 at 9:13 AM, Andrew Dunstan and...@dunslane.net wrote: Well, if we're going to commit this, as now appears likely, we should have some language lawyers go over our code for both YAML and JSON with a fine tooth comb to make sure what we are producing is strictly According To

Re: [HACKERS] Adding support for SE-Linux security

2009-12-08 Thread Robert Haas
On Tue, Dec 8, 2009 at 10:07 AM, David P. Quigley dpqu...@tycho.nsa.gov wrote: I'd be willing to take a look at the framework and see if it really is SELinux centric. If it is we can figure out if there is a way to accomodate something like SMACK and FMAC. I'd like to hear from someone with

Re: [HACKERS] Adding support for SE-Linux security

2009-12-08 Thread Robert Haas
On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley dpqu...@tycho.nsa.gov wrote: On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote: On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian br...@momjian.us wrote: As Alvaro mentioned, the original patch used ACE but it added too much code so

Re: [HACKERS] Adding support for SE-Linux security

2009-12-08 Thread Robert Haas
On Tue, Dec 8, 2009 at 12:16 PM, Chad Sellers csell...@tresys.com wrote: On 12/8/09 11:51 AM, David P. Quigley dpqu...@tycho.nsa.gov wrote: On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote: On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley dpqu...@tycho.nsa.gov wrote: On Mon, 2009-12-07

Re: [HACKERS] Adding support for SE-Linux security

2009-12-08 Thread Robert Haas
On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: One of the major and fundamental stumbling blocks we've run into is that every solution we've looked at so far seems to involve adding SE-Linux-specific checks in many places

Re: [HACKERS] Adding support for SE-Linux security

2009-12-08 Thread Robert Haas
On Tue, Dec 8, 2009 at 2:50 PM, David P. Quigley dpqu...@tycho.nsa.gov wrote: On Tue, 2009-12-08 at 14:22 -0500, Robert Haas wrote: On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: One of the major and fundamental stumbling blocks

Re: [HACKERS] Adding support for SE-Linux security

2009-12-08 Thread Robert Haas
On Tue, Dec 8, 2009 at 3:24 PM, Stephen Frost sfr...@snowman.net wrote: * Robert Haas (robertmh...@gmail.com) wrote: One of the major and fundamental stumbling blocks we've run into is that every solution we've looked at so far seems to involve adding SE-Linux-specific checks in many places

Re: [HACKERS] bug: fuzzystrmatch levenshtein is wrong

2009-12-08 Thread Robert Haas
On Mon, Dec 7, 2009 at 8:33 AM, marcin mank marcin.m...@gmail.com wrote: The current behavior of levenshtein(text,text,int,int,int) is wrong. Consider: leki_dev=# select levenshtein('','a',2,4,5);  levenshtein -           1 (1 row) leki_dev=# select levenshtein('a','',2,4,5);

Re: [HACKERS] bug: fuzzystrmatch levenshtein is wrong

2009-12-08 Thread Robert Haas
On Tue, Dec 8, 2009 at 9:08 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: patch attached. I cannot get this patch to apply for anything.  All 4 hunks fail, both on HEAD and on the the pre-8.4-pgindent version of fuzzystrmatch.c. Either I'm doing something wrong here

Re: [HACKERS] [PATCH] Windows x64 [repost]

2009-12-08 Thread Robert Haas
On Tue, Dec 8, 2009 at 10:30 PM, Tatsuo Ishii is...@postgresql.org wrote: Tatsuo Ishii wrote: Now that Greg is going to close the Nov Commit Festa, I think he is requesting initial reviews for the patches. While Magnus might take a look anyway, in general we'll all be taking a break from

Re: [HACKERS] ProcessUtility_hook

2009-12-08 Thread Robert Haas
On Tue, Dec 8, 2009 at 10:12 PM, Greg Smith g...@2ndquadrant.com wrote: It looks like the last round of issues on this patch only came from Tom's concerns, so I'm not sure if anyone but Tom (or a similarly picky alternate committer) is going to find anything else in a re-review.  It looks to me

Re: [HACKERS] [PATCH] Windows x64 [repost]

2009-12-08 Thread Robert Haas
On Tue, Dec 8, 2009 at 10:48 PM, Tatsuo Ishii is...@postgresql.org wrote: Ok. Your suggestion is very helpfull. In general Tsutomu will wait for feedbacks come in, probably until Jan 15th. Of course there's also no rule that you couldn't review these sooner - that might help get the ball

Re: [HACKERS] Adding support for SE-Linux security

2009-12-09 Thread Robert Haas
On Wed, Dec 9, 2009 at 1:44 AM, Magnus Hagander mag...@hagander.net wrote: 2009/12/9 Bruce Momjian br...@momjian.us: I frankly think the patch should be thought of as the SE-Linux-specific directory files, which KaiGai can maintain, and the other parts, which I think I can handle. I think

Re: [HACKERS] EXPLAIN BUFFERS

2009-12-09 Thread Robert Haas
On Wed, Dec 9, 2009 at 12:36 AM, Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp wrote: Note that the patch also removes buffer counters from log_statement_stats, but we only have brief descriptions about the options. Our documentation say nothing about buffer counters, so I didn't modify those

Re: [HACKERS] [patch] pg_ctl init extension

2009-12-09 Thread Robert Haas
On Dec 9, 2009, at 8:32 AM, Zdenek Kotala zdenek.kot...@sun.com wrote: Greg Smith píše v út 08. 12. 2009 v 22:44 -0500: Zdenek Kotala wrote: thanks for your useful comments. I attached new doc patch version. I removed example changes and add link to create database cluster (I hope)

Re: [HACKERS] explain output infelicity in psql

2009-12-09 Thread Robert Haas
On Wed, Dec 9, 2009 at 2:37 PM, Andrew Dunstan and...@dunslane.net wrote: I have just noticed while checking the EXPLAIN YAML patch that the non-text explain formats are output as a single line with embedded line feeds, while the text format is delivered as a set of text records, one per line.

Re: [HACKERS] Adding support for SE-Linux security

2009-12-09 Thread Robert Haas
On Wed, Dec 9, 2009 at 5:38 PM, Bruce Momjian br...@momjian.us wrote: If you want to avoid all good reasons for this features and are looking for reasons why this patch is a bad idea, I am sure you can find them. You seem to be suggesting that our reactions are pure obstructionism, or that they

Re: [HACKERS] bug: fuzzystrmatch levenshtein is wrong

2009-12-09 Thread Robert Haas
On Tue, Dec 8, 2009 at 9:45 PM, Robert Haas robertmh...@gmail.com wrote: On Tue, Dec 8, 2009 at 9:08 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: patch attached. I cannot get this patch to apply for anything.  All 4 hunks fail, both on HEAD and on the the pre-8.4-pgindent

Re: [HACKERS] ProcessUtility_hook

2009-12-09 Thread Robert Haas
Why does this patch #ifdef out the _PG_fini code in pg_stat_statements? Where you check for INSERT, UPDATE, and DELETE return codes in pgss_ProcessUtility, I think this deserves a comment explaining that these could occur as a result of EXECUTE. It wasn't obvious to me, anyway. It seems to me

Re: [HACKERS] ProcessUtility_hook

2009-12-09 Thread Robert Haas
On Wed, Dec 9, 2009 at 9:33 PM, Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp wrote: Robert Haas robertmh...@gmail.com wrote: Why does this patch #ifdef out the _PG_fini code in pg_stat_statements? That's because _PG_fini is never called in current releases. We could remove it completely

Re: [HACKERS] bug: fuzzystrmatch levenshtein is wrong

2009-12-09 Thread Robert Haas
On Wed, Dec 9, 2009 at 9:00 PM, Robert Haas robertmh...@gmail.com wrote: On Tue, Dec 8, 2009 at 9:45 PM, Robert Haas robertmh...@gmail.com wrote: On Tue, Dec 8, 2009 at 9:08 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: patch attached. I cannot get this patch to apply

Re: [HACKERS] ProcessUtility_hook

2009-12-09 Thread Robert Haas
On Wed, Dec 9, 2009 at 10:14 PM, Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp wrote: I'm confused by the we cannot retrieve the number of rows for SELECT part.  Can you clarify that? Ah, I meant the SELECT was EXECUTE of SELECT. If I use internal structure names, the explanation will be:

Re: [HACKERS] EXPLAIN BUFFERS

2009-12-10 Thread Robert Haas
On Thu, Dec 10, 2009 at 9:03 AM, Euler Taveira de Oliveira eu...@timbira.com wrote: Robert Haas escreveu: I'm not sure whether this is a good idea or not.  Let me read the patch.  I'm not sure an EXPLAIN option is really an adequate substitute for log_statement_stats - the latter will let you

Re: [HACKERS] explain output infelicity in psql

2009-12-10 Thread Robert Haas
On Wed, Dec 9, 2009 at 6:41 PM, Andrew Dunstan and...@dunslane.net wrote: Oh, dear.  I think that line continuation syntax was recently added - subsequent to the machine-readable EXPLAIN patch.  The reason why it's coded to emit everything as a single row is because that will be most

Re: [HACKERS] EXPLAIN BUFFERS

2009-12-10 Thread Robert Haas
On Thu, Dec 10, 2009 at 10:44 AM, Tom Lane t...@sss.pgh.pa.us wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Takahiro Itagaki escribió: Blocks: (shared hit=96 read=1544 written=0) (local hit=0 read=0 written=0) (temp read=0 written=0) Maybe I missed part of this discussion, but it

Re: [HACKERS] EXPLAIN BUFFERS

2009-12-10 Thread Robert Haas
On Thu, Dec 10, 2009 at 10:52 AM, Greg Smith g...@2ndquadrant.com wrote: Robert Haas wrote: I don't think IO is a terrible name for an option but I like BUFFERS better.  I don't think the BUFFERS/BLOCKS confusion is too bad, but perhaps we could use BUFFERS in both places. I don't know how

Re: [HACKERS] EXPLAIN BUFFERS

2009-12-10 Thread Robert Haas
On Thu, Dec 10, 2009 at 10:50 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Thu, Dec 10, 2009 at 9:03 AM, Euler Taveira de Oliveira eu...@timbira.com wrote: Why? If you want this information for all of your queries, you can always set

Re: [HACKERS] explain output infelicity in psql

2009-12-10 Thread Robert Haas
On Thu, Dec 10, 2009 at 11:44 AM, Ron Mayer rm...@cheapcomplexdevices.com wrote: Alvaro Herrera wrote: Robert Haas escribió: On first blush, I'm inclined to suggest that the addition of + signs to mark continuation lines is a misfeature. EXPLAIN is a special case.  IMHO it should be dealt

Re: [HACKERS] explain output infelicity in psql

2009-12-10 Thread Robert Haas
On Thu, Dec 10, 2009 at 12:43 PM, Andrew Dunstan and...@dunslane.net wrote: Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: Yeah, I'm thinking we should probably suppress output of format.nl_right (no matter what the format) where there is only one column. (This is even uglier

Re: [HACKERS] Adding support for SE-Linux security

2009-12-10 Thread Robert Haas
On Wed, Dec 9, 2009 at 10:43 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Wed, Dec 9, 2009 at 5:38 PM, Bruce Momjian br...@momjian.us wrote: If you want to avoid all good reasons for this features and are looking for reasons why this patch is a bad idea, I am sure you can

Re: [HACKERS] Adding support for SE-Linux security

2009-12-10 Thread Robert Haas
On Thu, Dec 10, 2009 at 5:08 PM, Tom Lane t...@sss.pgh.pa.us wrote: If I thought that Bruce could go off in a corner and make this happen and it would create no demands on anybody but him and KaiGai-san, I would say fine, if that's where you want to spend your time, go for it.  But even to

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-10 Thread Robert Haas
On Thu, Dec 10, 2009 at 8:39 PM, Andrew Dunstan and...@dunslane.net wrote: OK, I've committed the YAML stuff, so who is working on the auto-explain bug? Robert? I'd like that fixed before I add in the query text to auto-explain output. I'm going to propose fixing this in what seems to me to be

Re: [HACKERS] explain output infelicity in psql

2009-12-10 Thread Robert Haas
On Thu, Dec 10, 2009 at 8:11 PM, Bruce Momjian br...@momjian.us wrote: Andrew Dunstan wrote: Tom Lane wrote: regression=# select E'xxx\nxx\n'     as a, 1 as b;                           a          

<    1   2   3   4   5   6   7   8   9   10   >