Re: [HACKERS] bug: fuzzystrmatch levenshtein is wrong

On Tue, Dec 8, 2009 at 4:10 AM, Robert Haas wrote: >> The current behavior of levenshtein(text,text,int,int,int) is wrong. >> Consider: > > Is this the same problem as bug #5098? Yes. Exact same change, plus the shortcut evaluation (for when one of the inputs is empty) was also wrong. I fixed th

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

* Alvaro Herrera: > Florian Weimer escribió: >> * Dimitri Fontaine: >> >> > Well we have JSON and agreed it was a good idea to have it. Now JSON is >> > a subset of YAML and some would prefer another YAML style (me included). >> >> YAML is rather difficult to parse, and most parsers assume a tru

Re: [HACKERS] WAL format

On Tue, Dec 8, 2009 at 10:28 AM, Simon Riggs wrote: > If this was earlier in the release cycle, I'd feel happier. > > 2.5 months before beta is the wrong time to re-design the crash recovery > data format, especially because its only "a bit awkward". We're bound to > break something unforeseen and

Re: [HACKERS] A sniffer for the buffer

Jonas J wrote: I took a look in the code again and made some changes. For the readBuffer im doing now: ReadBuffer(Relation reln, BlockNumber blockNum) fprintf(fp,"r%u\n",(unsigned int) blockNum); //as defined in header, typedef uint32 BlockNumber; and from the write pages: write_buffer(B

Re: [HACKERS] WAL format

Tom Lane wrote: > Heikki Linnakangas writes: >> In particular I wonder why we bother with the page headers. A much >> simpler format would be: > >> - get rid of page headers, except for the header at the beginning of >> each WAL segment >> - get rid of continuation records >> - at the end of WAL

Re: [HACKERS] EXPLAIN BUFFERS

Itagaki Takahiro escreveu: > 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 buffers/blocks. > Nice. Despite of the other opinions, I'm s

Re: [HACKERS] WAL format

Tom Lane wrote: > "Kevin Grittner" writes: >> Heikki Linnakangas wrote: >>> In particular I wonder why we bother with the page headers. > >> Since we re-use the file for a new segment, without overwriting the >> old contents, it seems like we would need to do *something* to >> reliably determin

Re: [HACKERS] questions about concurrency control in Postgresql

2009/12/7 黄晓骋 : > Hello, > > I think in Postgresql, concurrency control acts like this: > > tuple's infomask shows if it is being updated. If it is being updated now, > the latter transaction should reread the tuple and get the newer tuple. > During the progress of getting the newer tuple, it must

Re: [HACKERS] EXPLAIN BUFFERS

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). But it is consistent with people seeing: Seq Scan on foo (cost=0.00..155.00 rows=1000

Re: [HACKERS] EXPLAIN BUFFERS

Robert Haas wrote: > On Mon, Dec 7, 2009 at 11:09 PM, Greg Smith wrote: > > (1) Blocks Shared: (hit=2 read=1641 written=0) Local: (hit=0 read=0 > > written=0) Temp: (read=1443 written=1443) > I could live with the equals signs, but the use of parentheses seems > weird and inconsistent with nor

[HACKERS] questions about concurrency control in Postgresql

Hello, I think in Postgresql, concurrency control acts like this: tuple's infomask shows if it is being updated. If it is being updated now, the latter transaction should reread the tuple and get the newer tuple. During the progress of getting the newer tuple, it must use transaction lock, I mean

Re: [HACKERS] EXPLAIN BUFFERS

On Mon, Dec 7, 2009 at 11:09 PM, Greg Smith wrote: > Robert Haas wrote: > > On Mon, Dec 7, 2009 at 9:58 PM, Itagaki Takahiro > wrote: > > > Obviously I should not hide any information only in the text format. > The new output will be: (in one line) >  Shared Blocks: (hit=2 read=1641 written=0) Lo

Re: [HACKERS] EXPLAIN BUFFERS

Robert Haas wrote: On Mon, Dec 7, 2009 at 9:58 PM, Itagaki Takahiro wrote: Obviously I should not hide any information only in the text format. The new output will be: (in one line) Shared Blocks: (hit=2 read=1641 written=0) Local Blocks: (hit=0 read=0 written=0) Temp Blocks: (read=1443 wr

Re: [HACKERS] A sniffer for the buffer

On Sun, Dec 6, 2009 at 9:04 AM, Greg Smith wrote: > And that won't work at all.  "Buffer" is a structure, not an integer.  You > need to wait until it's been locked, then save the same data as on the read > side (relation and block number) from inside the structure.  You probably > want to hook Fl

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

David P. Quigley wrote: > Not to start a flame war here about access control models but you gave 3 > different examples one of which I don't think has any means to do > anything productive here. You won't be starting a flame war for the same reason some of the community members are so concerned abo

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

On Mon, Dec 7, 2009 at 8:04 PM, Ashish 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 important to find s

Re: [HACKERS] bug: fuzzystrmatch levenshtein is wrong

On Mon, Dec 7, 2009 at 8:33 AM, marcin mank 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 your subscription: http:

Re: [HACKERS] some questions in postgresql developping

2009/12/7 黄晓骋 : > 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 > concurrency control fo

Re: [HACKERS] YAML

Tom Lane wrote: Andrew Dunstan writes: I was in fact prepared to commit this patch, despite some significant misgivings about its wisdom, mainly because it does have such a low impact. But then other people raised objections. I'm not sure how strong those objections are, though. T

Re: [HACKERS] EXPLAIN BUFFERS

On Mon, Dec 7, 2009 at 9:58 PM, Itagaki Takahiro 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 buffers/blocks. > > Euler Taveira d

Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion

On Mon, Dec 7, 2009 at 9:12 PM, Alvaro Herrera wrote: > Tom Lane wrote: >> Simon Riggs 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 changing the name of >> the existing

Re: [HACKERS] EXPLAIN BUFFERS

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 buffers/blocks. Euler Taveira de Oliveira wrote: > Itagaki Takahiro escreveu: > > I think the c

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

KaiGai Kohei escribió: > I could not find the message from David P. Quigley in the list, > although pgsql-hackers@postgresql.org was Cc:'ed. > (something troubled?) Weird. It didn't even made it to the moderator queue for some reason. Perhaps the system dropped it as spam. > So, I'll send it aga

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

I could not find the message from David P. Quigley in the list, although pgsql-hackers@postgresql.org was Cc:'ed. (something troubled?) So, I'll send it again for your information. Original Message Subject: Re: [HACKERS] Adding support for SE-Linux security Date: Mon, 07 Dec 200

Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion

On Mon, 2009-12-07 at 17:41 -0800, Josh Berkus wrote: > Actually, he has a very good point; we're going to get a *lot* of > confusion from the users on this one. I just wish I'd noticed the issue > before. The issue has been mentioned several times, but must have gotten lost among the other email

Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion

On Mon, 2009-12-07 at 23:12 -0300, Alvaro Herrera wrote: > Perhaps > table_exclusion = {on, off, partition} Sounds good to me. > Of course, constraint_exclusion should continue to work as a synonym for > backwards compatibility, but it wouldn't be documented. +1. Regards, Jeff Davis -

Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion

Tom Lane wrote: > Simon Riggs 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 changing the name of > the existing GUC would be a lot less work. However, partition_exclusion >

Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion

On Mon, 07 Dec 2009 20:20:45 -0500 Tom Lane wrote: > Simon Riggs 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 changing the name of > the existing GUC would be a lot less w

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

Robert Haas wrote: > On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian 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

Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion

On 12/7/09 5:17 PM, Tom Lane wrote: > David Fetter writes: >> It's not work you personally would have to do, and the confusion we've >> already bought with this naming scheme is already evident. > > What confusion? The only person complaining is you. Actually, he has a very good point; we're go

Re: [HACKERS] WAL format

On Mon, 2009-12-07 at 21:28 +0200, Heikki Linnakangas wrote: > The changes to ReadRecord in the streaming replication patch feel a > bit awkward, because it has to work around the fact that WAL is > streamed as a stream of bytes, but ReadRecord works one page at a > time. I'd like to replace ReadR

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

Bruce Momjian wrote: > Tom Lane wrote: >> Bruce Momjian writes: >>> Robert Haas wrote: Yes, I think that's the right way to think about it. At a guess, it's two man-months of work to get it in, and ripping it out is likely technically fairly simple but will probably be politically

Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion

Simon Riggs 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 changing the name of the existing GUC would be a lot less work. However, partition_exclusion seems to imply that it *only*

Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion

David Fetter writes: > It's not work you personally would have to do, and the confusion we've > already bought with this naming scheme is already evident. What confusion? The only person complaining is you. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsq

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

Tom Lane wrote: > Robert Haas writes: >> On Mon, Dec 7, 2009 at 9:48 AM, Bruce Momjian wrote: >>> I wonder if we should rephrase this as, "How hard will this feature be >>> to add, and how hard will it be to remove in a few years if we decide we >>> don't want it?" > >> Yes, I think that's the r

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

Hi Robert, Thanks. If I may, what encompasses your area of expertise... BTW Congratulation on becoming a committer! Regards Ashish On Mon, 7 Dec 2009, Robert Haas wrote: On Sun, Dec 6, 2009 at 9:24 PM, wrote: 2. Would someone be willing to be a mentor? It would be nice to be able to get

Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion

On Mon, 2009-12-07 at 13:53 -0800, David Fetter wrote: > We have a very unfortunate naming situation with Jeff Davis's new > feature, namely the shorter name, which is one permutation away from > an existing and entirely unrelated feature: Constraint Exclusion, > which has to do with queries over

Re: [HACKERS] New PostgreSQL Committers

2009/12/8 Kevin Grittner : > Jaime Casanova wrote: >> Dave Page wrote: >>> >>> The new committers are: >>> >>> Robert Haas >>> Simon Riggs >>> Greg Stark >>> ITAGAKI Takahiro >>> >>> Congratulations! >>> >> >> +1 > > Outstanding!  Congratulations, all! +1 Appreciate for their contributions. Co

Re: [HACKERS] bug: json format and auto_explain

Robert Haas writes: > There's an awful lot of layers of function calls happening in > explain.c for no really discernable purpose that I can see. > ExplainOneQuery() calls either ExplainOneUtility() if it has a utility > command or ExplainOneQuery_hook() if that's defined or else it plans > the qu

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

On 12/7/09 4:41 PM, Ashish wrote: > Albe & Joshua, thanks for the advice. I am in the process of deciding > what to work on and am looking at the TODO list. I definitely do not > intend to work in a vacuum :-) I am really excited about this and look > forward to being challenged and learning a lot.

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

Albe & Joshua, thanks for the advice. I am in the process of deciding what to work on and am looking at the TODO list. I definitely do not intend to work in a vacuum :-) I am really excited about this and look forward to being challenged and learning a lot. Regards Ashish On Mon, 7 Dec 2009,

Re: [HACKERS] YAML

Andrew Dunstan writes: > I was in fact prepared to commit this patch, despite some significant > misgivings about its wisdom, mainly because it does have such a low > impact. But then other people raised objections. I'm not sure how strong > those objections are, though. The "lite" version pos

Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion

On Mon, Dec 07, 2009 at 07:11:56PM -0500, Tom Lane wrote: > David Fetter writes: > > We have a very unfortunate naming situation with Jeff Davis's new > > feature, namely the shorter name, which is one permutation away > > from an existing and entirely unrelated feature: Constraint > > Exclusion,

Re: [HACKERS] Reading recovery.conf earlier

On Mon, 2009-12-07 at 19:21 -0500, Tom Lane wrote: > Simon Riggs writes: > > On Mon, 2009-12-07 at 19:07 +0200, Heikki Linnakangas wrote: > >> Why not just follow the example of postresql.conf? > > > Much better idea. > > Rather than reinventing all the infrastructure associated with GUCs, > may

Re: [HACKERS] Reading recovery.conf earlier

Simon Riggs writes: > On Mon, 2009-12-07 at 19:07 +0200, Heikki Linnakangas wrote: >> Why not just follow the example of postresql.conf? > Much better idea. Rather than reinventing all the infrastructure associated with GUCs, maybe we should just make the recovery parameters *be* GUCs. At least

Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion

David Fetter writes: > We have a very unfortunate naming situation with Jeff Davis's new > feature, namely the shorter name, which is one permutation away from > an existing and entirely unrelated feature: Constraint Exclusion, > which has to do with queries over partitioned tables and like > enti

Re: [HACKERS] YAML

Josh Berkus wrote: Not everything is sanely convertible into some sort of plugin. A plugin mechanism for this would be FAR more trouble that it is worth, IMNSHO. We are massively over-egging this pudding (as a culinary blogger you should appreciate this analogy). OK, then let's just acc

Re: [HACKERS] DTrace compiler warnings

--On 14. November 2009 15:25:25 +0100 Zdenek Kotala wrote: Hmm, const is also problem on solaris. dtrace generates probe.h file and eats const. It generates following noise on solaris build: "postgres.c", line 554: warning: argument #1 is incompatible with prototype: prototype: poi

Re: [HACKERS] [patch] executor and slru dtrace probes

--On 13. November 2009 23:29:41 +0100 Zdenek Kotala wrote: t contains two DTrace probe groups. One is related to monitoring SLRU and second is about executor nodes. I merged it with the head. Original end of mail thread is here: http://archives.postgresql.org/pgsql-hackers/2009-04/msg001

Re: [HACKERS] Reading recovery.conf earlier

On Mon, 2009-12-07 at 19:07 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > How does this sound? > > > > At startup we will delete recovery.conf.running, if it exists. > > At startup recovery.conf will be copied to recovery.conf.running, which > > will be the file read by any additional

Re: [HACKERS] bug: json format and auto_explain

On Mon, Dec 7, 2009 at 11:07 AM, Tom Lane wrote: > Itagaki Takahiro writes: >> Tom Lane wrote: >>> Looks like auto_explain is under the illusion that it need not call >>> ExplainBeginOutput/ExplainEndOutput. > >> Explain{Begin/End}Output are static functions, so we cannot call them >> from an ex

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

On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian 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 back in unless we

Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion

David Fetter wrote: Folks, We have a very unfortunate naming situation with Jeff Davis's new feature, namely the shorter name, which is one permutation away from an existing and entirely unrelated feature: Constraint Exclusion, which has to do with queries over partitioned tables and like entiti

Re: [HACKERS] Writeable CTE patch

Marko Tiikkaja escribió: > Tom Lane wrote: > >The only thing that I'd be comfortable with is > >copying the snap and modifying the copy. > > I don't see an easy way to do that with the current code; > CopySnapshot() is static and PushUpdatedSnapshot() seems to be a bit > of a pain since it messes

[HACKERS] Exclusion Constraint vs. Constraint Exclusion

Folks, We have a very unfortunate naming situation with Jeff Davis's new feature, namely the shorter name, which is one permutation away from an existing and entirely unrelated feature: Constraint Exclusion, which has to do with queries over partitioned tables and like entities. Renaming it, whic

Re: [HACKERS] YAML

> Not everything is sanely convertible into some sort of plugin. A plugin > mechanism for this would be FAR more trouble that it is worth, IMNSHO. > > We are massively over-egging this pudding (as a culinary blogger you > should appreciate this analogy). OK, then let's just accept it. It's smal

Re: [HACKERS] Install chapter broken link

Magnus Hagander wrote: Our instalation chapter (15.2) has a link to http://developer.postgresql.org/~petere/bsd-gettext/ to get gettext on "other systems". this link is broken. Can somebody provide a proper one, or should we remove it? Goals of his version described at http://archives.postgre

Re: [HACKERS] WAL format

Alvaro Herrera writes: > Heikki Linnakangas wrote: >> - at the end of WAL segment, when there's not enough space to write the >> next WAL record, always write an XLOG SWITCH record to fill the rest of >> the segment. > What happens if a record is larger than a WAL segment? For example, > what if

Re: [HACKERS] WAL format

On Monday 07 December 2009 21:44:37 Tom Lane wrote: > "Kevin Grittner" writes: > > Heikki Linnakangas wrote: > >> In particular I wonder why we bother with the page headers. > > > > Since we re-use the file for a new segment, without overwriting the > > old contents, it seems like we would need t

Re: [HACKERS] WAL format

"Kevin Grittner" writes: > Heikki Linnakangas wrote: >> In particular I wonder why we bother with the page headers. > Since we re-use the file for a new segment, without overwriting the > old contents, it seems like we would need to do *something* to > reliably determine when we've hit the end

Re: [HACKERS] Build sizes vs docs

Magnus Hagander writes: > Came cross this when updating the cvs fix. We declare size requirements as: >Also check that you have sufficient disk space. You will need about >65 MB for the source tree during compilation and about MB for >the installation directory. An empty database clus

Re: [HACKERS] WAL format

Heikki Linnakangas writes: > In particular I wonder why we bother with the page headers. A much > simpler format would be: > - get rid of page headers, except for the header at the beginning of > each WAL segment > - get rid of continuation records > - at the end of WAL segment, when there's not

Re: [HACKERS] WAL format

Heikki Linnakangas wrote: > - at the end of WAL segment, when there's not enough space to write the > next WAL record, always write an XLOG SWITCH record to fill the rest of > the segment. What happens if a record is larger than a WAL segment? For example, what if I insert a 16 MB+ datum into a

Re: [HACKERS] WAL format

Heikki Linnakangas wrote: > In particular I wonder why we bother with the page headers. Since we re-use the file for a new segment, without overwriting the old contents, it seems like we would need to do *something* to reliably determine when we've hit the end of a segment and have moved into

[HACKERS] Install chapter broken link

Our instalation chapter (15.2) has a link to http://developer.postgresql.org/~petere/bsd-gettext/ to get gettext on "other systems". this link is broken. Can somebody provide a proper one, or should we remove it? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.c

[HACKERS] Build sizes vs docs

Came cross this when updating the cvs fix. We declare size requirements as: Also check that you have sufficient disk space. You will need about 65 MB for the source tree during compilation and about MB for the installation directory. An empty database cluster takes about 25 MB; databa

[HACKERS] WAL format

While looking at the streaming replication patch, I can't help but wonder why our WAL format is so complicated. WAL is divided into WAL segments, each 16 MB by default. Each WAL segment is divided into pages, 8k by default. At the beginning of each WAL page, there's a page header, but the header a

Re: [HACKERS] YAML

Josh Berkus wrote: What it's sounding like is that we ought to have a plug-in (both for postmaster and for psql) which allows the calling of an external library to parse explain output. Then people could covert XML/JSON into whatever they wanted. It would be kinder to just reject the YAML pat

Re: [HACKERS] YAML

Josh Berkus wrote: All, What it's sounding like is that we ought to have a plug-in (both for postmaster and for psql) which allows the calling of an external library to parse explain output. Then people could covert XML/JSON into whatever they wanted. Not everything is sanely convertib

[HACKERS] What happened to pl/proxy and FDW?

Marko, Asko, hackers: I thought the idea was that we were going to add PL/proxy to 8.5, with support for the foriegn data wrapper syntax? What happened to that? --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.

Re: [HACKERS] YAML

All, What it's sounding like is that we ought to have a plug-in (both for postmaster and for psql) which allows the calling of an external library to parse explain output. Then people could covert XML/JSON into whatever they wanted. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-

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

On Dec 7, 2009, at 9:52 AM, Alvaro Herrera wrote: >> Tallying up the votes on this patch, we have Tom Lane, Andrew Dunstan, >> Josh Drake, and myself arguing against including this in core, and >> Josh Berkus and Itagaki Takahiro arguing for it. Ron Mayer seemed >> somewhat in favor of it in his

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

Tom Lane wrote: > Bruce Momjian writes: > > Robert Haas wrote: > >> Yes, I think that's the right way to think about it. At a guess, it's > >> two man-months of work to get it in, and ripping it out is likely > >> technically fairly simple but will probably be politically impossible. > > > I fig

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

Bruce Momjian writes: > Robert Haas wrote: >> Yes, I think that's the right way to think about it. At a guess, it's >> two man-months of work to get it in, and ripping it out is likely >> technically fairly simple but will probably be politically impossible. > I figure if there is sufficient usa

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

Martijn van Oosterhout escribió: > On Mon, Dec 07, 2009 at 01:09:59PM -0300, Alvaro Herrera wrote: > > This is how the code was developed initially -- the patch was called > > PGACE and SELinux was but the first implementation on top of it. > > I find it astonishing that after SE-PgSQL was implem

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

On Mon, 2009-12-07 at 14:52 -0300, Alvaro Herrera wrote: > Robert Haas escribió: > > > Tallying up the votes on this patch, we have Tom Lane, Andrew Dunstan, > > Josh Drake, and myself arguing against including this in core, and > > Josh Berkus and Itagaki Takahiro arguing for it. Ron Mayer seeme

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

Robert Haas wrote: > > Agreed. ?SE-Linux support might expand our user base and give us > > additional credibility, or it might be a feature that few people use --- > > and I don't think anyone knows the outcome. > > > > I wonder if we should rephrase this as, "How hard will this feature be > > to

Re: [HACKERS] Block-level CRC checks

On Fri, Dec 4, 2009 at 10:47 PM, Chuck McDevitt wrote: > A curiosity question regarding torn pages:  How does this work on file > systems that don't write in-place, but instead always do copy-on-write? > > My example would be Sun's ZFS file system (In Solaris & BSD).  Because of its > "snapshot

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

Robert Haas escribió: > Tallying up the votes on this patch, we have Tom Lane, Andrew Dunstan, > Josh Drake, and myself arguing against including this in core, and > Josh Berkus and Itagaki Takahiro arguing for it. Ron Mayer seemed > somewhat in favor of it in his message on-list but sent a messa

Re: [HACKERS] operator exclusion constraints

On Mon, 2009-12-07 at 00:26 -0500, Tom Lane wrote: > Jeff Davis writes: > > [ exclusion constraint patch ] > > Applied after quite a lot of editorialization. For future reference, > here is a summary of what I did: Thank you for the suggestions, and the other constructive criticism during devel

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

Florian Weimer escribió: > * Dimitri Fontaine: > > > Well we have JSON and agreed it was a good idea to have it. Now JSON is > > a subset of YAML and some would prefer another YAML style (me included). > > YAML is rather difficult to parse, and most parsers assume a trusted > document source beca

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

Chris Browne writes: > I feel about the same way about this as I did about the adding of > "native Windows" support; I'm a bit concerned that this could be a > destabilizing influence. I was wrong back then; the Windows support > hasn't had the ill effects I was concerned it might have. That's a

Re: [HACKERS] Reading recovery.conf earlier

Simon Riggs wrote: > How does this sound? > > At startup we will delete recovery.conf.running, if it exists. > At startup recovery.conf will be copied to recovery.conf.running, which > will be the file read by any additional processes that read > recovery.conf during this execution. The permission

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

t...@sss.pgh.pa.us (Tom Lane) writes: > Robert Haas writes: >> On Mon, Dec 7, 2009 at 9:48 AM, Bruce Momjian wrote: >>> I wonder if we should rephrase this as, "How hard will this feature be >>> to add, and how hard will it be to remove in a few years if we decide we >>> don't want it?" > >> Yes,

Re: [HACKERS] New PostgreSQL Committers

dp...@pgadmin.org (Dave Page) writes: > Congratulations! +1 Congratulations, indeed, to this worthy set of developers! -- output = reverse("moc.liamg" "@" "enworbbc") http://linuxfinances.info/info/multiplexor.html "Power tends to corrupt and absolute power corrupts absolutely." -- First Bar

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

Martijn van Oosterhout writes: > I find it astonishing that after SE-PgSQL was implemented on top of a > pluggable system (PGACE) and this system was removed at request of the > "community" [1] that at this late phase people are suggesting it needs > to be added back again. Havn't the goalposts be

Re: [HACKERS] strange segfault with 8.3.8

Filip Rembiałkowski wrote: Dec 7 07:24:45 nsXX kernel: postgres[22481]: segfault at 7fda5e1d5000 ip 7fda604553c3 sp 7fffe41faf28 error 4 in libc-2.9.so [7fda603d1000+168000] Dec 7 07:24:45 nsXX kernel: grsec: From XX.YY.ZZ.51: Segmentation fault occurred a

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

Greg Smith wrote: > That's a step backwards. By providing JSON format, we've also satisfied > people who want YAML. Ripping out JSON would mean we *only* support > YAML. There are far many more JSON parsers than YAML parsers, which is > why I thought the current code committed was good enough.

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

Robert Haas wrote: On a related note, Greg Smith requested a state called "Discussing Review", which would logically follow "Needs Review" and precede "Waiting for Author"/"Ready for Committer"/"Returned with Feedback". I'm not altogether convinced of the value of that state, but I'm not altogeth

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

On Mon, Dec 07, 2009 at 01:09:59PM -0300, Alvaro Herrera wrote: > > Given the extreme patience and diligence exhibited by KaiGai, I > > hesitate to say this, but it seems to me that this would be > > critically important for the long term success of this feature. I > > have no idea how much work i

Re: [HACKERS] New PostgreSQL Committers

Jaime Casanova wrote: > Dave Page wrote: >> >> The new committers are: >> >> Robert Haas >> Simon Riggs >> Greg Stark >> ITAGAKI Takahiro >> >> Congratulations! >> > > +1 Outstanding! Congratulations, all! -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To mak

Re: [HACKERS] [patch] pg_ctl init extension

Greg, thanks for your useful comments. I attached new doc patch version. I removed example changes and add link to create database cluster (I hope) everywhere. Please, look on it and let me know if there is still something what should be changed. Thanks Zdenek Greg Smith píše v ne 06.

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

KaiGai Kohei wrote: > Apart from SELinux, it is quite natural to apply any access > controls on binary data. If we could not have any valid access > controls, users will not want to store their sensitive > information, such as confidential PDF files, as a large object. Absolutely. The histori

Re: [HACKERS] EXPLAIN BUFFERS

Itagaki Takahiro escreveu: > I think the current output is enough and useful in normal use. > We can use XML or JSON format for more details. > I don't think it is a good idea to have different information in different formats. I'm with Robert; *don't* do that. If you want to suppress the other on

[HACKERS] strange segfault with 8.3.8

hello, from kernel log: Dec 7 07:24:45 nsXX kernel: postgres[22481]: segfault at 7fda5e1d5000 ip 7fda604553c3 sp 7fffe41faf28 error 4 in libc-2.9.so [7fda603d1000+168000] Dec 7 07:24:45 nsXX kernel: grsec: From XX.YY.ZZ.51: Segmentation fault occurred at 7fda5e1d5000 in /usr

Re: [HACKERS] bug: json format and auto_explain

On Mon, Dec 7, 2009 at 10:42 AM, Alvaro Herrera wrote: > Tom Lane wrote: >> Euler Taveira de Oliveira 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. It >> > seems >> > ExplainJSONLine

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

Kevin Grittner escribió: > > I'd like to see us be able to support it. One of the things that > > I think would be worth looking into is whether there is a way to > > make this pluggable, so that selinux and apparmor and trusted > > solaris and so on could make use of the same framework > > Giv

Re: [HACKERS] bug: json format and auto_explain

Itagaki Takahiro writes: > Tom Lane wrote: >> Looks like auto_explain is under the illusion that it need not call >> ExplainBeginOutput/ExplainEndOutput. > Explain{Begin/End}Output are static functions, so we cannot call them > from an external contrib module. Instead, I'll suggest to call them

Re: [HACKERS] bug: json format and auto_explain

Alvaro Herrera escreveu: > Fortunately the author of auto_explain can now commit the fix by himself ... > Kudos, BTW :-) > Congratulations! -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your su

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

On Sun, Dec 6, 2009 at 9:24 PM, 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 able to help as much.

  1   2   >