Re: [HACKERS] Streaming replication and non-blocking I/O

On Wed, Dec 9, 2009 at 3:58 PM, Heikki Linnakangas wrote: > True. Another idea I had was to introduce a callback that backend libpq > can call when the buffer fills. Walsender would set the callback to > ProcessStreamMsgs(). > > But if everyone is happy with just relying on the OS buffer to not fi

Re: [HACKERS] XLogInsert

On Sun, Sep 13, 2009 at 10:42 PM, Jeff Janes wrote: > > I've attached a patch which removes the iteration over the blocks to be > backed-up from the critical section of XLogInsert.  Now those blocks are > only looped over in one piece of code which both computes the CRC and builds > the linked lis

Re: [HACKERS] Streaming replication and non-blocking I/O

Fujii Masao wrote: > On Tue, Dec 8, 2009 at 11:23 PM, Heikki Linnakangas > wrote: >> If that's deemed not good enough, we could modify just internal_flush() >> so that it uses secure_poll to wait for the possibility to either read >> or write, instead of blocking for just write. Whenever there's i

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

Stephen Frost 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 in the code. > > I've really got to take exc

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

2009/12/9 Bruce Momjian : > 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 that's a horribly bad idea. We have already got a similar issue with ECPG, which clearly sta

Re: [HACKERS] pgbench: new feature allowing to launch shell commands

Michael Paquier wrote: > Please find attached the latest version of the patch, > with the threading bug corrected and the documentation updated as well. Why do you use BUFFER_SIZE-1 for snprintf? snprintf(commandShell, SHELL_COMMAND_SIZE-1, ...) Trailing nulls are also included in the length

Re: [HACKERS] EXPLAIN BUFFERS

Greg Smith wrote: > I just executed that. Note that there are two bits of subjective > tweaking possible to do with this one when it's committed: slimming > down the width of the display, and Euler's suggestion's for rewording. > I linked to both of those messages in the CF app, labeled as

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

David P. Quigley wrote: > On Tue, 2009-12-08 at 15:26 -0500, Robert Haas wrote: > [snip...] >> I can say from experience that this project is very skeptical of >> frameworks that aren't accompanied by at least one, and preferably >> multiple, working implementations. So there is a bit of a chicken

Re: [HACKERS] ProcessUtility_hook

Robert Haas wrote: Since Itagaki Takahiro is now a committer, I sort of assumed he would be committing his own patches. Maybe, but I wasn't going to be the one to suggest that Tom get cut out of the loop after he raised a list of issues with the patch already. I think the situation for EXPLA

Re: [HACKERS] [GENERAL] Installing PL/pgSQL by default

Bruce Momjian writes: > I installed PL/pgSQL by default via initdb with the attached patch. The > only problem is that pg_dump still dumps out the language creation: > CREATE PROCEDURAL LANGUAGE plpgsql; > ALTER PROCEDURAL LANGUAGE plpgsql OWNER TO postgres; > What is odd is that I us

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

On Tue, Dec 8, 2009 at 10:48 PM, Tatsuo Ishii 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 rolling! >

Re: [HACKERS] ProcessUtility_hook

On Tue, Dec 8, 2009 at 10:12 PM, Greg Smith 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 > like all the is

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

> > 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 rolling! Of course I did before he publishes the patches. (I and he

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

Greg Smith writes: > To be clear about which version we're talking about: > http://archives.postgresql.org/message-id/20091130123456.4a03.52131...@oss.ntt.co.jp > > is the candidate for commit that includes the cleanup you've already done. I suppose this is subject to the same auto_explain pr

Re: [HACKERS] [patch] pg_ctl init extension

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) everywhere. Please, look on it and let me know if there is still something what should be changed. That looks much better. There

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

On Tue, Dec 8, 2009 at 10:30 PM, Tatsuo Ishii 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 rev

Re: [HACKERS] EXPLAIN BUFFERS

Euler Taveira de Oliveira wrote: If there is no more objections, I'll flag the patch 'ready for committer' I just executed that. Note that there are two bits of subjective tweaking possible to do with this one when it's committed: slimming down the width of the display, and Euler's suggest

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

> 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 review until January 15th, when the final CommitFest for th

Re: [HACKERS] ProcessUtility_hook

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 like all the issues were sorted out anyway. Euler, you're off the hook

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

Greg Smith wrote: Takahiro Itagaki wrote: Can I ask the final decision whether the YAML formatter should be applied or rejected? As far as I read the discussion, we can apply it because serveral users want it and we don't have a plan to support extensible formatters in the core. The path I

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

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 review until January 15th, when the final CommitFest for this version start

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

Magnus, > Just in case anybody was wondering, I've added myself as a reviewer of > this one for next commitfest - I doubt that's very surprising :-) > Others are of course more than welcome to chip in! Greg Smith wrote: > There are also a couple of patches that for various reasons have yet to >

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

Takahiro Itagaki wrote: Can I ask the final decision whether the YAML formatter should be applied or rejected? As far as I read the discussion, we can apply it because serveral users want it and we don't have a plan to support extensible formatters in the core. The path I thought made sense a

Re: [HACKERS] bug: fuzzystrmatch levenshtein is wrong

On Tue, Dec 8, 2009 at 9:08 PM, Bruce Momjian 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, or there's so

Re: [HACKERS] [GENERAL] Installing PL/pgSQL by default

Tom Lane wrote: > Andrew Dunstan writes: > > Before we go too far with this, I'd like to know how we will handle the > > problems outlined here: > > > > Hm, I think that's only a problem if we define it to be a problem, > and I

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

David P. Quigley wrote: I understand that PostgreSQL is a fast moving target with a large developer base but so is the Linux Kernel and a similar framework has been working there for years now. It sounds like how you're thinking about this project's development model is inverted from the

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

Can I ask the final decision whether the YAML formatter should be applied or rejected? As far as I read the discussion, we can apply it because serveral users want it and we don't have a plan to support extensible formatters in the core. Greg Smith wrote: > -The patch is small to apply > -Having

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

David P. Quigley wrote: > So I was reading through a set of slides that KaiGai has and he > mentioned a May commitfest link and I looked for the comments related to > his PGACE patches. I've been crawling through the commitfest paces so I > can figure out what the latest version of the pgace patch

Re: [HACKERS] bug: fuzzystrmatch levenshtein is wrong

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, or there's something wrong with > this patch file. The author converted

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: > > leki_dev=# select levenshtein('','a',2,4,5); >  levenshtein > - >           1 > (1 row) > > > leki_dev=# select levenshtein('a','',2,4,5); >  levensht

Re: [HACKERS] Streaming replication, some small issues

On Wed, Dec 9, 2009 at 10:12 AM, Tom Lane wrote: > Fujii Masao writes: >> Thought? Am I missing something? > > This seems terribly overdesigned.  Just emit a warning when you see > the "unlogged op" record and have done. Sounds quite simple. OK, I'll do so. Regards, -- Fujii Masao NIPPON TELE

Re: [HACKERS] Streaming replication and non-blocking I/O

On Tue, Dec 8, 2009 at 11:23 PM, Heikki Linnakangas wrote: > The first question is: do we really need to be prepared for that? The > XLogRecPtr acknowledgment messages the client sends are very small, and > if the client is mindful about not sending them too often - perhaps max > 1 ack per 1 recei

Re: [HACKERS] Streaming replication, some small issues

Fujii Masao writes: > Thought? Am I missing something? This seems terribly overdesigned. Just emit a warning when you see the "unlogged op" record and have done. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Streaming replication, some small issues

On Tue, Dec 8, 2009 at 9:05 PM, Heikki Linnakangas wrote: >> I suspect we should have a WAL record to say "unlogged operation >> performed here" which a standby database would recognize and throw a >> large warning up. > > +1. Seems like a very simple solution. Sounds good. This is not just a pro

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

Robert Haas wrote: > Sorry. I spent a lot of time for both CommitFest 2008-11 and > CommitFest 2009-07 in the hopes of getting something committable, and > I wasn't successful. I'm just at the end of my rope. It seems fairly > clear that Tom isn't going to commit any piece of SE-PostgreSQL at >

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

Robert Haas wrote: > On Tue, Dec 8, 2009 at 10:07 AM, David P. Quigley > 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

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

On Tue, 2009-12-08 at 16:51 -0500, Tom Lane wrote: > Peter Eisentraut writes: > > PGACE wasn't a plugin system. It was an API inside the core code. If > > it had been a plugin system, this would have been much easier, because > > the plugin itself could have been developed independently. > > We

Re: [HACKERS] tsearch parser inefficiency if text includes urls or emails - new version

I wrote: > Perhaps it is some quirk of using 32 bit pointers on the 64 bit > AMD CPU? (I'm looking forward to testing this today on a 64 bit > build on an Intel CPU.) The exact same test on 64 bit OS (SuSE Enterprise Server) on Intel gave very different results. With 10 runs each of 200 iterat

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

Peter Eisentraut writes: > PGACE wasn't a plugin system. It was an API inside the core code. If > it had been a plugin system, this would have been much easier, because > the plugin itself could have been developed independently. Well, it should certainly have used function pointers or somethin

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

On Tue, 2009-12-08 at 15:26 -0500, Robert Haas wrote: [snip...] > > I can say from experience that this project is very skeptical of > frameworks that aren't accompanied by at least one, and preferably > multiple, working implementations. So there is a bit of a chicken and > egg problem here. Wh

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

On Tue, Dec 8, 2009 at 3:24 PM, Stephen Frost 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 in the code. >

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

On mån, 2009-12-07 at 11:45 -0500, Chris Browne wrote: > 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 c

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

On mån, 2009-12-07 at 17:33 +0100, Martijn van Oosterhout wrote: > 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 t

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

On Tue, 2009-12-08 at 15:24 -0500, Stephen Frost 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 in the co

Re: [HACKERS] ECPG patch 2, SQLDA support

On Mon, Nov 16, 2009 at 5:59 AM, Boszormenyi Zoltan wrote: > New version: rebased to current CVS. > This one no longer applies to HEAD, could you update it please? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +593

Re: [HACKERS] [PATCH] dtrace probes for memory manager

--On 8. Dezember 2009 15:51:52 -0500 Greg Smith wrote: Try this instead, which will give you a test where checkpoints have a minimal impact, but lots of memory will be thrown around: pgbench -i -s 10 pgbench -S -c 10 -T 600 Thanks for the input, will try -- Thanks Bernd

Re: [HACKERS] [PATCH] dtrace probes for memory manager

Bernd Helmle wrote: I've tried to benchmark this now on my (fairly slow compared to server hardware) MacBook and see some negative trend for those memory probes in pgbench. Running dozens of rounds with pgbench (scale 150, 10 clients / 1000 transactions) That makes for a 5.5 minute test, which

Re: [HACKERS] [PATCH] dtrace probes for memory manager

--On 13. November 2009 17:16:15 -0500 Robert Haas wrote: Don't think. Benchmark. :-) (If you can measure it at all, it's too much, at least IMHO.) I've tried to benchmark this now on my (fairly slow compared to server hardware) MacBook and see some negative trend for those memory prob

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

On Tue, Dec 8, 2009 at 2:50 PM, David P. Quigley wrote: > On Tue, 2009-12-08 at 14:22 -0500, Robert Haas wrote: >> On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane wrote: >> > Robert Haas writes: >> >> One of the major and fundamental stumbling blocks we've run into is >> >> that every solution we've lo

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

* 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 in the code. I've really got to take exception to this. I've only bee

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

On Tue, 2009-12-08 at 14:22 -0500, Robert Haas wrote: > On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane wrote: > > Robert Haas 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 c

Re: [HACKERS] tsearch parser inefficiency if text includes urls or emails - new version

Tom Lane wrote: > --enable-cassert might have a noticeable performance impact. > We usually try to not have that on when doing performance testing. Right. I turned it on for some initial tests to confirm that we had no assertion failures; then turned it off for the performance testing. I did

Re: [HACKERS] tsearch parser inefficiency if text includes urls or emails - new version

Tom Lane wrote: --enable-cassert might have a noticeable performance impact. We usually try to not have that on when doing performance testing. All covered in the tool's documentation, and it looks like Kevin did the right thing during his tests by checking the pg_config output to confirm th

Re: [HACKERS] More broken links in documentation

2009/12/8 Magnus Hagander : > 2009/12/8 Greg Smith : >> Magnus Hagander wrote: >>> >>> ftp://ftp.sco.com/skunkware >>> Link to "sco skunkware" which supposedly is available there if you >>> don't have the CD, in the installation notes for Unixware and >>> OpenServer. Which it isn't. Suggest we just

Re: [HACKERS] tsearch parser inefficiency if text includes urls or emails - new version

Greg Smith writes: > Kevin Grittner wrote: >> Anyway, I'm not sure whether your reply directly answers the point >> I was raising -- peg doesn't do anything with the compiler >> optimization flags under the covers, does it? >> > Not really. It does this: > PGDEBUG="--enable-cassert --enable-deb

Re: [HACKERS] More broken links in documentation

Magnus Hagander wrote: ftp://ftp.ora.com/pub/examples/nutshell/ujip/doc/cjk.inf in charset.sgml, detailed info about some charsets. Do we just remove this? Anybody know if similar info is available elsewhere? Now http://examples.oreilly.com/cjkvinfo/doc/cjk.inf -- Greg Smith2ndQuadrant

Re: [HACKERS] tsearch parser inefficiency if text includes urls or emails - new version

Kevin Grittner wrote: Anyway, I'm not sure whether your reply directly answers the point I was raising -- peg doesn't do anything with the compiler optimization flags under the covers, does it? Not really. It does this: PGDEBUG="--enable-cassert --enable-debug" ./configure --prefix=$PGINST/$

Re: [HACKERS] More broken links in documentation

2009/12/8 Greg Smith : > Magnus Hagander wrote: >> >> ftp://ftp.sco.com/skunkware >> Link to "sco skunkware" which supposedly is available there if you >> don't have the CD, in the installation notes for Unixware and >> OpenServer. Which it isn't. Suggest we just remove this sentence, but >> leave

Re: [HACKERS] More broken links in documentation

2009/12/8 Thom Brown : > 2009/12/8 Magnus Hagander >> >> I wrote a small script to check our SGML, and the following links are >> returning not found in our docs: >> >> ftp://ftp.ora.com/pub/examples/nutshell/ujip/doc/cjk.inf >> in charset.sgml, detailed info about some charsets. Do we just remove

Re: [HACKERS] More broken links in documentation

Magnus Hagander wrote: ftp://ftp.sco.com/skunkware Link to "sco skunkware" which supposedly is available there if you don't have the CD, in the installation notes for Unixware and OpenServer. Which it isn't. Suggest we just remove this sentence, but leave the reference to the CD. This is now

Re: [HACKERS] tsearch parser inefficiency if text includes urls or emails - new version

Hi, On Tuesday 08 December 2009 20:09:22 Greg Smith wrote: > Andres, are using any optimization flags when you're testing? I was testing with and without debug/cassert - and did not get adverse results in both... Unfortunately it looks like I wont get to test today, but only tomorrow morning it

Re: [HACKERS] More broken links in documentation

2009/12/8 Magnus Hagander > I wrote a small script to check our SGML, and the following links are > returning not found in our docs: > > ftp://ftp.ora.com/pub/examples/nutshell/ujip/doc/cjk.inf > in charset.sgml, detailed info about some charsets. Do we just remove > this? Anybody know if similar

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

On 12/8/09 12:36 PM, "Robert Haas" wrote: > On Tue, Dec 8, 2009 at 12:16 PM, Chad Sellers wrote: >> On 12/8/09 11:51 AM, "David P. Quigley" 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 wrote: > On Mon, 2009

Re: [HACKERS] Install chapter broken link

2009/12/7 Greg Smith : > 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 ver

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

On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane wrote: > Robert Haas 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 in the code.  It would be nice >> if it wer

Re: [HACKERS] tsearch parser inefficiency if text includes urls or emails - new version

Greg Smith wrote: > Now that you ask, of course I just spotted a bug in there such > that the documented behavior for the PGDEBUG feature doesn't > actually work. If you were using that to turn off asserts, that > may not have worked as expected. Don't know what you did there > exactly. Fix

[HACKERS] More broken links in documentation

I wrote a small script to check our SGML, and the following links are returning not found in our docs: ftp://ftp.ora.com/pub/examples/nutshell/ujip/doc/cjk.inf in charset.sgml, detailed info about some charsets. Do we just remove this? Anybody know if similar info is available elsewhere? http://d

Re: [HACKERS] tsearch parser inefficiency if text includes urls or emails - new version

Kevin Grittner wrote: After running a series of tests with --enable-cassert to confirm that nothing squawked, I disabled that before doing any performance testing. Going from memory, I used --enable-debug --with-libxml and --prefix. I didn't explicitly use or disable any compiler optimizations.

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

Robert Haas 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 in the code. It would be nice > if it were possible to use the exist permissions-checking functi

Re: [HACKERS] Sought after architectures for the PostgreSQL buildfarm?

On Tue, Dec 08, 2009 at 10:51:01AM -0500, Andrew Dunstan wrote: > Peter St. Onge wrote privately: > > > >With the local server room renovations, there may be some older > >equipment being retired. Are there any architectures that you > >would like to see added to the buildfarm? > > > Hackers, > >

Re: [HACKERS] Sought after architectures for the PostgreSQL buildfarm?

I might be able to help with: Sparc PA-Risc (HP-UX) IA64 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -Original Message- From: pgsql-hackers-ow...@post

Re: [HACKERS] Sought after architectures for the PostgreSQL buildfarm?

On 12/8/09 7:51 AM, Andrew Dunstan wrote: > > > Peter St. Onge wrote privately: >> >> With the local server room renovations, there may be some older >> equipment being retired. Are there any architectures that you would >> like to see added to the buildfarm? Got any Sparc machines? We're likel

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

On Tue, Dec 8, 2009 at 12:16 PM, Chad Sellers wrote: > On 12/8/09 11:51 AM, "David P. Quigley" 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 >>> wrote: On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote: > On Mo

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

On 12/8/09 11:51 AM, "David P. Quigley" 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 >> wrote: >>> On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote: On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian wrote: > As Alva

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

On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote: > On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley > wrote: > > On Mon, 2009-12-07 at 17:57 -0500, 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 ad

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

On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley wrote: > On Mon, 2009-12-07 at 17:57 -0500, 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 fro

Re: [HACKERS] tsearch parser inefficiency if text includes urls or emails - new version

Andres Freund wrote: > Did you test that with a optimized build? After running a series of tests with --enable-cassert to confirm that nothing squawked, I disabled that before doing any performance testing. Going from memory, I used --enable-debug --with-libxml and --prefix. I didn't explici

Re: [HACKERS] tsearch parser inefficiency if text includes urls or emails - new version

On Tuesday 08 December 2009 17:15:36 Kevin Grittner wrote: > Andres Freund wrote: > > Could you show your testcase? Will hopefully look into this later. > > I dont see why it could get slower? > I don't either. The best I can tell, following the pointer from > orig to any of its elements seems t

Re: [HACKERS] tsearch parser inefficiency if text includes urls or emails - new version

Andres Freund wrote: > Could you show your testcase? OK. I was going to try to check other platforms first, and package up the information better, but here goes. I created 1 lines with random IP-based URLs for a test. The first few lines are: create table t1 (c1 int not null primary

Re: [HACKERS] Sought after architectures for the PostgreSQL buildfarm?

Andrew Dunstan writes: > Peter St. Onge wrote privately: >> With the local server room renovations, there may be some older >> equipment being retired. Are there any architectures that you would >> like to see added to the buildfarm? > Any nominations? Sure, what's being offered? I've noticed

Re: [HACKERS] YAML

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > If the spec is in flux, that seems like More Than Sufficient reason > to reject the patch for the time being. It can be resubmitted when > it's no longer shooting at a moving target. Saying that it is in flux is a bit of a stretch. Even if i

Re: [HACKERS] Sought after architectures for the PostgreSQL buildfarm?

Peter St. Onge wrote privately: With the local server room renovations, there may be some older equipment being retired. Are there any architectures that you would like to see added to the buildfarm? Hackers, Any nominations? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] YAML

Robert Haas writes: > +1. I'm a little concerned about the bit about the YAML specification > changing, too, but at least if we can ensure that we're compliant with > the spec that is current at the time the code goes in we have a leg to > stand on. If the spec is in flux, that seems like More T

Re: [HACKERS] tsearch parser inefficiency if text includes urls or emails - new version

On Tuesday 08 December 2009 16:23:11 Kevin Grittner wrote: > I wrote: > > Frankly, I'd be amazed if there was a performance regression, > > OK, I'm amazed. While it apparently helps some cases dramatically > (Andres had a case where run time was reduced by 93.2%), I found a > pretty routine case

Re: [HACKERS] tsearch parser inefficiency if text includes urls or emails - new version

I wrote: > Frankly, I'd be amazed if there was a performance regression, OK, I'm amazed. While it apparently helps some cases dramatically (Andres had a case where run time was reduced by 93.2%), I found a pretty routine case where run time was increased by 3.1%. I tweaked the code and got th

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

On Tue, Dec 8, 2009 at 10:07 AM, David P. Quigley 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 more extensive exper

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

On Mon, 2009-12-07 at 22:25 -0500, Greg Smith wrote: > 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

Re: [HACKERS] A sniffer for the buffer

Greg Smith wrote: > Jonas J wrote: > >P.S.: I'm using PostgreSQL 8.1.4 to run with TPCC-UVA benchmarks tests... > Ah. PostgreSQL 8.1 is significantly slower than the current > versions, and you're not going to get as much help with issues > related to the source code as if you're using a newer on

Re: [HACKERS] New PostgreSQL Committers

On Mon, Dec 07, 2009 at 10:49:13AM +, Dave Page wrote: > On behalf of the core team, I'm pleased to announce that the > > Congratulations! > +1 Congrats to you all, and thanks for the contributions, both past and future. As an aside, this sort of thing is one of the best signs to an external

Re: [HACKERS] A sniffer for the buffer

Thanks for the answers. I will change it for PostgreSQL 8.4 and try to use DBT-2. But, I'm not quite sure if DTrace will give me the workload that I want. Since, i want to trace the Workload that is above the Buffer Layer. With workload I mean two fields (operation: read/write and Block Number). T

[HACKERS] Streaming replication and non-blocking I/O

I find the backend libpq changes related to non-blocking I/O quite complex. Can we find a simpler solution? The problem we're trying to solve is that while the walsender backend sends a lot of WAL records to the client, the client can send a lot of messages to the backend. If volume of the message

Re: [HACKERS] YAML

On Tue, Dec 8, 2009 at 9:13 AM, Andrew Dunstan 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 > Hoyle. +1. I'm

Re: [HACKERS] YAML

Tim Bunce wrote: I've no contribution to the main topic, but I'd like to point out that the "JSON is a subset of YAML" meme is not without controversy: http://search.cpan.org/~mlehmann/JSON-XS-2.26/XS.pm#JSON_and_YAML It may not be relevant in your use-case, but I thought it worth a mentio

Re: [HACKERS] YAML

On Mon, Dec 07, 2009 at 07:07:13PM -0500, Andrew Dunstan wrote: > > > 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 cul

Re: [HACKERS] questions about concurrency control in Postgresql

2009/12/8 黄晓骋 : > From the above, I think the tuple lock is unnecessary, because it uses > transaction lock. > > Besides, tuple lock is unlocked after the tuple is updated but not after the > transaction commits. I mean it's not 2PL. It's a two step process. An update marks the tuple locked. Anoth

Re: [HACKERS] Streaming replication, some small issues

Greg Stark wrote: > On Tue, Dec 8, 2009 at 8:30 AM, Heikki Linnakangas > wrote: >> - It's possible to shut down master, change max_wal_senders to 0, >> restart and do an operation like CLUSTER which then skips WAL-logging. >> Then shutdown, change max_wal_senders back to non-zero. All this while >

Re: [HACKERS] Streaming replication, some small issues

On Tue, Dec 8, 2009 at 8:30 AM, Heikki Linnakangas wrote: > - It's possible to shut down master, change max_wal_senders to 0, > restart and do an operation like CLUSTER which then skips WAL-logging. > Then shutdown, change max_wal_senders back to non-zero. All this while > the standby is running.

Re: [HACKERS] Streaming replication, some small issues

On Tue, Dec 8, 2009 at 5:30 PM, Heikki Linnakangas wrote: > A couple of small issues spotted while reviewing the streaming > replication patch: Thanks for the review! > - Because sentPtr is initialized to zeros, GetOldestWALSendPointer will > return zero before a just-launched WAL sender has sen

Re: [HACKERS] EXPLAIN BUFFERS

On Dec 8, 2009, at 12:05 AM, Greg Smith 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). But it is consistent with people see

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

Dne 8.12.09 00:27, Bernd Helmle napsal(a): --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://archive

  1   2   >