Re: [HACKERS] Reading recovery.conf earlier

On Mon, 2009-12-07 at 13:03 +0900, Fujii Masao wrote: > On Sun, Dec 6, 2009 at 2:49 AM, Simon Riggs wrote: > > Proposal is to split out the couple of lines in > > readRecoveryCommandFile() that set important state and make it read in > > an option block that can be used by caller. It would then be

Re: [HACKERS] Hot standby, recent changes

Simon Riggs wrote: > On Sun, 2009-12-06 at 17:26 -0500, Robert Haas wrote: > >> For what it's worth, this doesn't seem particularly unlikely or >> unusual to me. > > I don't know many people who shutdown both nodes of a highly available > application at the same time. If they did, I wouldn't expe

Re: [HACKERS] Reading recovery.conf earlier

Simon Riggs wrote: > What postgresql.conf already does is read file separately in each > process, so no data passing. No it doesn't. Postmaster reads the file once, and backends inherit the values at fork(). In EXEC_BACKEND case, postmaster writes all the non-default values to a separate file, whi

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

2009/12/7 Itagaki Takahiro : > > Tom Lane 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 presence >> on the CF list should not be taken as evidence that there's consensus >> for it. > > Should we have

Re: [HACKERS] Reading recovery.conf earlier

On Mon, 2009-12-07 at 10:13 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > What postgresql.conf already does is read file separately in each > > process, so no data passing. > > No it doesn't. Postmaster reads the file once, and backends inherit the > values at fork(). In EXEC_BACKEND c

Re: [HACKERS] Hot standby, recent changes

On Mon, 2009-12-07 at 10:02 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Sun, 2009-12-06 at 17:26 -0500, Robert Haas wrote: > > > >> For what it's worth, this doesn't seem particularly unlikely or > >> unusual to me. > > > > I don't know many people who shutdown both nodes of a hi

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

abindra wrote: > Next quarter I am planning to do an Independent Study course > where the main objective would be to allow me to get familiar > with the internals of Postgres by working on a project(s). I > would like to work on something that could possibly be > accepted as a patch. > > This

Re: [HACKERS] Reading recovery.conf earlier

Simon Riggs wrote: > On Mon, 2009-12-07 at 10:13 +0200, Heikki Linnakangas wrote: >> Reading the file separately in each process would cause trouble with >> PGC_POSTMASTER params. All backends must agree on their values. > > Looking at the parameters in recovery.conf I don't believe they would > c

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

Hi, Greg Smith writes: > Robert Haas wrote: >> The main point here for me is that the JSON format is already >> parseable by YAML parsers, and can probably be turned into YAML using >> a very short Perl script - possibly even using a sed script. I think >> that it's overkill to support two forma

Re: [HACKERS] Clearing global statistics

2009/12/7 Greg Smith : > Itagaki Takahiro wrote: > > Greg Smith wrote: > > > > I'm thinking that I should rename this new function > to pg_stat_reset_bgwriter so it's obvious how limited its target is. > > > I don't think it is a good name because we might have another cluster-level > statictics n

Re: [HACKERS] Reading recovery.conf earlier

On Mon, Dec 7, 2009 at 5:28 PM, Simon Riggs wrote: > If you really think that changing the file is a possibility between > processes reading them, then I would just take a full temp copy of the > file, read it in postmaster, read it in startup, then delete temp file. This seems more robust becaus

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

On mån, 2009-12-07 at 17:14 +0900, Hitoshi Harada wrote: > 2009/12/7 Itagaki Takahiro : > > > > Tom Lane 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 presence > >> on the CF list should not be

[HACKERS] New PostgreSQL Committers

On behalf of the core team, I'm pleased to announce that the PostgreSQL Project has expanded it's team of "committers", those people who are able to make direct changes to the PostgreSQL source code respository. As the project is extremely conservative about any changes made to the source code to m

Re: [HACKERS] New PostgreSQL Committers

In response to Dave Page : > On behalf of the core team, I'm pleased to announce that the > PostgreSQL Project has expanded it's team of "committers", those > people who are able to make direct changes to the PostgreSQL source > code respository. As the project is extremely conservative about any >

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

On Monday 07 December 2009 02:12:43 Greg Smith wrote: > After getting off to a good start, it looks like this patch is now stuck > waiting for a second review pass from Kevin right now, with no open > items for Andres to correct. Since the only issues on the table seem to > be that of code aesthet

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

Tom Lane writes: > Right, just like every other thing that's pre-installed. If a > particular installation wishes to let individual DB owners control this, > the superuser can drop plpgsql from template1. It's not apparent to me > why we need to allow non-superusers to override the project's dec

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

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > Tallying up the votes on this patch First, I would hope that you don't overlook the author of the patch (me) as an "aye" vote. :) Additionally, if you are going t

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

* 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 because they support arbitrary class instan

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

2009/12/4 Tsutomu Yamada : > Thanks to suggestion. > I send pathces again by another mailer for the archive. > > Sorry to waste resources, below is same content that I send before. Just in case anybody was wondering, I've added myself as a reviewer of this one for next commitfest - I doubt that's

[HACKERS] bug: fuzzystrmatch levenshtein is wrong

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); levenshtein - 1 (1 row) leki_dev=# select levenshtein

[HACKERS] How to cache a non-unique index?

Hi, I have added a catalog table with an index on a non-unique column. I want to cache this non-unique index like other unique indexes in syscache. Is there any way to cache a non-unique index? I just want the index to reside in the memory to speed up the index lookup. Thank you! Wang -- Sent

Re: [HACKERS] EXPLAIN BUFFERS

On Mon, Dec 7, 2009 at 1:28 AM, Itagaki Takahiro 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 ones. I disagree. I object

Re: [HACKERS] bug: fuzzystrmatch levenshtein is wrong

also there is integer overflow: postgres=# select levenshtein('','',1,10,1); levenshtein - -1179869184 (1 row) should we reject arguments greater than,say, 1 ? maximum input length is 255 currently, so the maximum numbers involved would be about 1*255

[HACKERS] some questions in postgresql developping

Hello, 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 for a long time an

Re: [HACKERS] Writeable CTE patch

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 up some of the existing code which u

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

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 complete the > > task. > > Well, I have always thought that it wo

Re: [HACKERS] Reading recovery.conf earlier

On Mon, 2009-12-07 at 19:26 +0900, Fujii Masao wrote: > On Mon, Dec 7, 2009 at 5:28 PM, Simon Riggs wrote: > > If you really think that changing the file is a possibility between > > processes reading them, then I would just take a full temp copy of the > > file, read it in postmaster, read it in

Re: [HACKERS] New PostgreSQL Committers

On Mon, Dec 7, 2009 at 6:49 AM, Dave Page wrote: > On behalf of the core team, I'm pleased to announce that the > PostgreSQL Project has expanded it's team of "committers", those > people who are able to make direct changes to the PostgreSQL source > code respository. As the project is extremely c

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

Dimitri Fontaine writes: > So should the decision to remove plpgsql be on the hosting platform > hands or the hosted database owner? Why not? If they really want to prohibit use of a feature the upstream project has decided should be standard, that's their privilege. The argument against seems t

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 > PostgreSQL Project has expanded it's team of "committers", those > people who are able to make direct changes to the PostgreSQL source > code respository. As the project is ex

Re: [HACKERS] cvs chapters in our docs

2009/11/26 Tom Lane : > Magnus Hagander writes: >> I assume you are fine with the addition of some info about git, but >> what about the removal of those two chapters suggested? > > I agree that we needn't try to cover material that's in the CVS manual. > As somebody mentioned upthread, a sentence

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

On Mon, Dec 7, 2009 at 9:48 AM, Bruce Momjian 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 complet

Re: [HACKERS] cvs chapters in our docs

On Mon, Dec 07, 2009 at 04:08:28PM +0100, Magnus Hagander wrote: > 2009/11/26 Tom Lane : > > Magnus Hagander writes: > >> I assume you are fine with the addition of some info about git, but > >> what about the removal of those two chapters suggested? > > > > I agree that we needn't try to cover ma

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

On Mon, Dec 07, 2009 at 09:53:32AM +0100, Albe Laurenz wrote: > abindra wrote: > > Next quarter I am planning to do an Independent Study course > > where the main objective would be to allow me to get familiar > > with the internals of Postgres by working on a project(s). I > > would like to wor

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

Itagaki Takahiro writes: > Tom Lane 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 presence >> on the CF list should not be taken as evidence that there's consensus >> for it. > Should we have "Needs

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

Greg Smith wrote: > After getting off to a good start, it looks like this patch is now > stuck waiting for a second review pass from Kevin right now, with > no open items for Andres to correct. Since the only issues on the > table seem to be that of code aesthetics and long-term planning > for

Re: [HACKERS] How to cache a non-unique index?

Xin Wang writes: > I have added a catalog table with an index on a non-unique column. I > want to cache this non-unique index like other unique indexes in > syscache. Is there any way to cache a non-unique index? No, not with syscache. regards, tom lane -- Sent via pgsq

Re: [HACKERS] bug: json format and auto_explain

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 > > ExplainJSONLineEnding() doesn't expect es->grouping_stack list as a null > >

Re: [HACKERS] cvs chapters in our docs

Magnus Hagander writes: > I would also like to propose that we actually backpatch this. At least > the addition of the git documentation and the update of the CVS > documentation. So we get this info out there. We don't normally > backpatch things like this though, so comments on that? The sort o

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

Robert Haas wrote: > Bruce Momjian wrote: >> Personally, I think AppArmor is a saner security system: >> >> http://www.novell.com/linux/security/apparmor/selinux_comparison.html > Agreed. > I'd like to see us be able to support it. One of the things that > I think would be worth looking i

Re: [HACKERS] cvs chapters in our docs

2009/12/7 Tom Lane : > Magnus Hagander writes: >> I would also like to propose that we actually backpatch this. At least >> the addition of the git documentation and the update of the CVS >> documentation. So we get this info out there. We don't normally >> backpatch things like this though, so co

Re: [HACKERS] New PostgreSQL Committers

On Mon, Dec 7, 2009 at 5:49 AM, Dave Page wrote: > > The new committers are: > > Robert Haas > Simon Riggs > Greg Stark > ITAGAKI Takahiro > > Congratulations! > +1 -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59

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

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 right way to think about i

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

Tom Lane writes: > Why not? If they really want to prohibit use of a feature the upstream > project has decided should be standard, that's their privilege. Well, I guess they could also automate their database creation to fix the privileges and assign the ownership of the language to the owner o

Re: [HACKERS] cvs chapters in our docs

Magnus Hagander escribió: > 2009/12/7 Tom Lane : > > Magnus Hagander writes: > >> I would also like to propose that we actually backpatch this. At least > >> the addition of the git documentation and the update of the CVS > >> documentation. So we get this info out there. We don't normally > >> ba

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

On Mon, Dec 7, 2009 at 10:20 AM, Tom Lane wrote: > Itagaki Takahiro writes: >> Tom Lane 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 presence >>> on the CF list should not be taken as evidence tha

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

Dimitri Fontaine wrote: If the problem is supporting 2 formats in core rather than 3, what about replacing the current JSON support with the YAML one? 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

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.

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] 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] 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

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

[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] 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

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] [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] 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] 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 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] 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] 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] 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] 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

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] 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

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] 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] 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

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] 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] 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] 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

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] 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

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] 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] 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-

[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

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

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

[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

[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] 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

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

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 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] 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

"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] 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

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] 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] 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

[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] 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

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] 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] 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] 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] [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] 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

  1   2   >