Re: [HACKERS] Streaming replication status

Fujii Masao wrote: > On Sat, Jan 9, 2010 at 6:16 AM, Heikki Linnakangas > wrote: >> * If there's no WAL to send, walsender doesn't notice if the client has >> closed connection already. This is the issue Fujii reported already. >> We'll need to add a select() call to the walsender main loop to che

Re: [HACKERS] Streaming replication status

On Sat, Jan 9, 2010 at 10:38 AM, Greg Stark wrote: >> * Need to add comments somewhere to note that ReadRecord depends on the >> fact that a WAL record is always send as whole, never split across two >> messages. > > What happens in the case of the very large records Tom was describing > recently.

Re: [HACKERS] Streaming replication status

On Sat, Jan 9, 2010 at 6:16 AM, Heikki Linnakangas wrote: > I've gone through the patch in detail now. Here's my list of remaining > issues: Great! Thanks a lot! > * If there's no WAL to send, walsender doesn't notice if the client has > closed connection already. This is the issue Fujii reporte

Re: [HACKERS] mailing list archiver chewing patches

Alvaro Herrera wrote: > Andrew Dunstan wrote: > > > > Tim Bunce's recent patch has been mangled apparently by the list > > archives. He sent it as an attachment, and that's how I have it in > > my mailbox, so why isn't it appearing as such in the web archive so > > that it can be nicely downloaded

Re: [HACKERS] 8.5alpha3 hot standby crash report (DatabasePath related?)

On Jan 8, 2010, at 7:36 AM, Simon Riggs wrote: On Fri, 2010-01-08 at 01:26 +, Simon Riggs wrote: I'll test and commit tomorrow, since it's a fairly standalone problem Fix attached, thanks for testing. Works for me and I don't expect it to fail on Solaris, since the root cause of the fai

Re: [HACKERS] mailing list archiver chewing patches

Andrew Dunstan wrote: > > Tim Bunce's recent patch has been mangled apparently by the list > archives. He sent it as an attachment, and that's how I have it in > my mailbox, so why isn't it appearing as such in the web archive so > that it can be nicely downloaded? See >

Re: [HACKERS] Add .gitignore files to CVS?

Tom Lane escribió: > David Fetter writes: > > On Fri, Jan 08, 2010 at 10:35:24PM -0500, Tom Lane wrote: > >> Probably eventually we'll be on git and this will be moot, but that > >> doesn't seem to be ready to happen. > > > What still needs to happen on this? Clearly this would be a post-8.5 > >

Re: [HACKERS] Add .gitignore files to CVS?

David Fetter writes: > On Fri, Jan 08, 2010 at 10:35:24PM -0500, Tom Lane wrote: >> Probably eventually we'll be on git and this will be moot, but that >> doesn't seem to be ready to happen. > What still needs to happen on this? Clearly this would be a post-8.5 > (or whatever the new release num

Re: [HACKERS] Add .gitignore files to CVS?

On Fri, Jan 08, 2010 at 10:35:24PM -0500, Tom Lane wrote: > Probably eventually we'll be on git and this will be moot, but that > doesn't seem to be ready to happen. What still needs to happen on this? Clearly this would be a post-8.5 (or whatever the new release number is) thing, but apart from

Re: [HACKERS] Setting oom_adj on linux?

Alex Hunsaker writes: > Tom, sounds like you got busy with other stuff :) Should I submit a > new patch that uses open and O_WRONLY? No, I was just waiting to see if there were more comments. I can take it from here. regards, tom lane -- Sent via pgsql-hackers mailing

Re: [HACKERS] Setting oom_adj on linux?

On Fri, Jan 8, 2010 at 15:24, Stephen Frost wrote: > There were a few issues, as it turns out, the particularly annoying one > was in the init script which caused upgrades to fail due to sshd not > being restarted, bug report here: Thanks for the pointers! > http://bugs.debian.org/cgi-bin/bugrep

Re: [HACKERS] Feature patch 1 for plperl [PATCH]

On Fri, Jan 8, 2010 at 10:01 AM, Tim Bunce wrote: > I didn't get any significant feedback from the earlier draft so here's > the finished 'feature patch 1' for plperl.  (This builds on my earlier > plperl refactoring patch, and the follow-on ppport.h patch.) > > Significant changes from the first

Re: [HACKERS] Add .gitignore files to CVS?

Robert Haas writes: > Tom's stated position was that the only way this was going to happen > is if it regularly annoyed someone with access to the core repository. > I am, and I do. Yeah. I don't see the harm in it if Robert (or some other git user) will contract to maintain them. I know that

Re: [HACKERS] [COMMITTERS] pgsql: Tidy up and refactor plperl.c.

Robert Haas writes: > On Fri, Jan 8, 2010 at 10:25 PM, Tom Lane wrote: >> [ squint... ]  I thought we'd decided that wasn't a good idea? > http://archives.postgresql.org/pgsql-hackers/2009-11/msg01941.php OK, I'd forgotten that ... regards, tom lane -- Sent via pgsql-

Re: [HACKERS] [COMMITTERS] pgsql: Tidy up and refactor plperl.c.

On Fri, Jan 8, 2010 at 10:25 PM, Tom Lane wrote: > aduns...@postgresql.org (Andrew Dunstan) writes: >> - Changed MULTIPLICITY check from runtime to compiletime. >>     No loads the large Config module. > > [ squint... ]  I thought we'd decided that wasn't a good idea? > What happens if the libperl

Re: [HACKERS] Add .gitignore files to CVS?

On Fri, Jan 8, 2010 at 9:21 PM, Euler Taveira de Oliveira wrote: > Robert Haas escreveu: >> I would be willing to maintain .gitignore files, under the agreement >> that if I should fail or cease to do so, and no one else wants to take >> over, then they all get removed.   Would that be acceptable?

Re: [HACKERS] [COMMITTERS] pgsql: Tidy up and refactor plperl.c.

aduns...@postgresql.org (Andrew Dunstan) writes: > - Changed MULTIPLICITY check from runtime to compiletime. > No loads the large Config module. [ squint... ] I thought we'd decided that wasn't a good idea? What happens if the libperl we load at runtime doesn't match what we saw in the header

[HACKERS] Build farm tweaks

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > I mentioned earlier that buildfarm member jaguar (that's the one that > builds with CLOBBER_CACHE_ALWAYS) was showing suspicious intermittent > failures. Tom, this brings up another question: is there any flag, environment, forced resource li

Re: [HACKERS] Initial refactoring of plperl.c - updated

Tim Bunce wrote: I see you've not commited it yet, so to help out I've attached a new diff, over the current CVS head, with two minor changes: - Removed the test, as noted above. - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. I have committed this with minor edits. That s

Re: [HACKERS] Testing plperl<->plperlu interaction

Tom Lane wrote: Andrew Dunstan writes: Tom Lane wrote: Also, some commentary connecting this test to plperl.c's support for two interpreters would be a good thing. ITYM in the .sql file(s)? No, the test in the makefile is what seems to need a comment. It doesn't

Re: [HACKERS] Testing plperl<->plperlu interaction

Andrew Dunstan writes: > Tom Lane wrote: >> Also, some commentary connecting this test to plperl.c's support for >> two interpreters would be a good thing. > ITYM in the .sql file(s)? No, the test in the makefile is what seems to need a comment. It doesn't have to be much. I was thinking somet

Re: [HACKERS] Add .gitignore files to CVS?

Robert Haas escreveu: > I would be willing to maintain .gitignore files, under the agreement > that if I should fail or cease to do so, and no one else wants to take > over, then they all get removed. Would that be acceptable? > -1. I tend to agree with Tom and Peter. Why don't you use vpath bui

Re: [HACKERS] Testing plperl<->plperlu interaction

Tom Lane wrote: Hm ... I wonder how badly this fails if perl isn't present? Before you say that that won't matter, consider "make clean" etc. The makefile does have to parse. It might be sufficient to wrap this test in an "ifneq ($(PERL),)" or similar. OK, can do that. Also, some comme

Re: [HACKERS] We need to rethink relation cache entry rebuild

Greg Stark writes: > How old is this problem? It doesn't sound like a backpatchable fix... Presumably it goes back to 8.0. I was planning to defer thinking about whether to back-patch it until we had a working fix and could see how big a change it really is. regards, tom

Re: [HACKERS] damage control mode

On Fri, Jan 8, 2010 at 7:48 PM, Peter Eisentraut wrote: > On fre, 2010-01-08 at 10:02 +0100, Dimitri Fontaine wrote: >> Now, I'll second Greg Smith and Tom here, in that I think we need to >> run >> the last commitfest as usual, knowing that the outcome of the >> commitfest >> for any given patch

Re: [HACKERS] We need to rethink relation cache entry rebuild

On Sat, Jan 9, 2010 at 1:01 AM, Tom Lane wrote: > Comments? > How old is this problem? It doesn't sound like a backpatchable fix... -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hack

Re: [HACKERS] Streaming replication status

On Fri, Jan 8, 2010 at 9:16 PM, Heikki Linnakangas wrote: > * We still have a related issue, though: if standby is configured to > archive to the same location as master (as it always is on my laptop, > where I use the postgresql.conf of the master unmodified in the server), > right after failove

Re: [HACKERS] Testing plperl<->plperlu interaction

Andrew Dunstan writes: > OK, here is a patch that provides for running regression tests for > plperlu alone and plperl/plperlu interaction, skipping the latter if > it's not supported on the platform, using the test Tim has suggested. > ! ifeq ($(shell $(PERL) -V:usemultiplicity), usemultiplici

Re: [HACKERS] synchronized snapshots

On Fri, Jan 8, 2010 at 7:36 PM, Joachim Wieland wrote: >  * If all four pg_synchronize_snapshot_taken() calls return true and the > If we must have a timeout I think you should throw an error if the timeout expires. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

[HACKERS] We need to rethink relation cache entry rebuild

I mentioned earlier that buildfarm member jaguar (that's the one that builds with CLOBBER_CACHE_ALWAYS) was showing suspicious intermittent failures. There's another one today: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguar&dt=2010-01-08%2004:00:02 and I also managed to reproduce a

Re: [HACKERS] damage control mode

On fre, 2010-01-08 at 10:02 +0100, Dimitri Fontaine wrote: > Now, I'll second Greg Smith and Tom here, in that I think we need to > run > the last commitfest as usual, knowing that the outcome of the > commitfest > for any given patch is not "it made it" but "we reviewed it". It's > still > right f

Re: [HACKERS] Testing plperl<->plperlu interaction

Tim Bunce wrote: Or perhaps put the tests that require multiplicity into a plperl_multi.sql file and add logic to the GNUmakefile to add that file to REGRESS if "perl -V:usemultiplicity" returns "usemultiplicity='define';" OK, here is a patch that provides for running regression tests f

[HACKERS] mailing list archiver chewing patches

Tim Bunce's recent patch has been mangled apparently by the list archives. He sent it as an attachment, and that's how I have it in my mailbox, so why isn't it appearing as such in the web archive so that it can be nicely downloaded? See

Re: [HACKERS] git help

Kevin Grittner wrote: What would the normal workflows be to: rebase the postgresql.git clone and the serializable branch on the server? rebase my working copy on my desktop from the serializable branch on the server? The way you asked this suggests you've chewed on someone's advanced

Re: [HACKERS] Serializable Isolation without blocking

Again, a somewhat tardy post from a question found in review. Markus Wanner wrote: >> I suppose these more persistent write locks should >> be kept out of the DEFAULT lock method, too > > I fail to understand that part. What's the DEFAULT lock method? With some adjustment of line wrappin

Re: [HACKERS] Setting oom_adj on linux?

Stephen Frost writes: > The other issue was with a Debian-specific patch which was applied to > OpenSSH which basically just created noise in the log file, bug report > here: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487325 Hmm, that's pretty interesting, specifically this: : After som

Re: [HACKERS] Setting oom_adj on linux?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Alex Hunsaker writes: > > Sure this was openssh? I just looked through the entire cvs history > > for opensshp and found 0 references to 'oom' let alone 'oom_adj'. > > Maybe something distro specific? > > FWIW, I see no evidence that sshd on Fedora does an

Re: [HACKERS] Application name patch - v3

Le 07/01/2010 19:13, Robert Haas a écrit : > On Thu, Jan 7, 2010 at 10:33 AM, Guillaume Lelarge > wrote: >> Le 04/01/2010 22:36, Guillaume Lelarge a écrit : >>> Le 29/12/2009 14:12, Guillaume Lelarge a écrit : Le 29/12/2009 00:03, Guillaume Lelarge a écrit : > Le 28/12/2009 22:59, Tom Lan

Re: [HACKERS] Streaming replication status

On 1/8/10 1:16 PM, Heikki Linnakangas wrote: > * A standby that connects to master, initiates streaming, and then sits > idle without stalls recycling of old WAL files in the master. That will > eventually lead to a full disk in master. Do we need some kind of a > emergency valve on that? WARNING:

[HACKERS] NOT NULL violation and error-message

Hi all, when trying to insert/update a NOT NULL column with a null-values (in this case the "created"-column), we get this error: ERROR: null value in column "created" violates not-null constraint Using JDBC this error-message is what appears in the SQLException.getMessage() which makes it impo

Re: [HACKERS] Serializable implementation

Robert Haas wrote: > I think anything you decide about how to invoke the different > isolation levels will be easy to change later to meet whatever the > consensus of the community is at that time. I wouldn't spend any > time or energy on it now. For purposes of your prototype patch, > using R

Re: [HACKERS] Listen / Notify - what to do when the queue is full

On Fri, Jan 8, 2010 at 4:10 PM, Tom Lane wrote: > Merlin Moncure writes: >> On Fri, Jan 8, 2010 at 1:24 PM, Tom Lane wrote: >>> No, he meant ASCII.  Otherwise we're going to have to deal with encoding >>> conversion issues. > >> That seems pretty awkward...instead of forcing an ancient, useless

Re: [HACKERS] Serializable Isolation without blocking

Nicolas Barbier wrote: > AFAICS, detecting a "rw" dependency where the read executes after > the write is rather easy: the writer has created a row version > that is not visible to the reader's snapshot. Therefore, any time > a reader reads a non-last version of a row, there is a rw > dependency

Re: [HACKERS] Listen / Notify - what to do when the queue is full

Merlin Moncure writes: > On Fri, Jan 8, 2010 at 1:24 PM, Tom Lane wrote: >> No, he meant ASCII.  Otherwise we're going to have to deal with encoding >> conversion issues. > That seems pretty awkward...instead of forcing an ancient, useless to > 90% of the world encoding, why not send bytea You

Re: [HACKERS] Listen / Notify - what to do when the queue is full

conversion problems in some circumstances - what about bytea (or why _do_ we have to limit this to something?). I agree with bytea. Zero conversions and the most flexible. Payload encoding/format should be decided by the user. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo

Re: [HACKERS] damage control mode

Robert Haas wrote: > On Fri, Jan 8, 2010 at 1:38 PM, Bruce Momjian wrote: > > Robert Haas wrote: > >> >> We discussed doing this at the very beginning of 8.4 release cycle > >> >> and, the more I think about it, the more I think it's not fair not to > >> >> go ahead and do it. ?Otherwise, we're re

Re: [HACKERS] Serializable Isolation without blocking

2010/1/8 Markus Wanner : > SIREAD atop predicate locking serves detecting vulnerable edges (I hope > I'm using that term correctly here) between newly inserted tuples and > reads, right? I was trying to figure if it would make sense to use > predicate locking (instead of table or row level locking

Re: [HACKERS] damage control mode

> Presuming enough reviewers (which should be the case this time given the > expectation that submitters also review), the suggested pacing here now > has every patch passing through a round of review and potentially one > update within ten days. If we *don't* have enough reviewers, though, I t

Re: [HACKERS] damage control mode

Jeff, > Aside: I'll take this alarm as a very strong hint that I shouldn't push > the "range types" any more until the next development cycle. > Particularly because Tom is one of the people with opinions about it, so > I don't want to distract him from features submitted several commitfests > ago

Re: [HACKERS] Setting oom_adj on linux?

On Fri, Jan 8, 2010 at 12:45, Tom Lane wrote: > Alex Hunsaker writes: >> Sure this was openssh? I just looked through the entire cvs history >> for opensshp and found 0 references to 'oom' let alone 'oom_adj'. >> Maybe something distro specific? > > FWIW, I see no evidence that sshd on Fedora doe

Re: [HACKERS] Listen / Notify - what to do when the queue is full

Andrew Chernow wrote: conversion problems in some circumstances - what about bytea (or why _do_ we have to limit this to something?). I agree with bytea. Zero conversions and the most flexible. Payload encoding/format should be decided by the user. yeah that is exactly why I think they t

Re: [HACKERS] Listen / Notify - what to do when the queue is full

On Fri, Jan 8, 2010 at 1:24 PM, Tom Lane wrote: > Merlin Moncure writes: >> On Fri, Jan 8, 2010 at 7:48 AM, Joachim Wieland wrote: >>> - do we need to limit the payload to pure ASCII ? I think yes, we need >>> to. I also think we need to reject other payloads with elog(ERROR...). > >> Just notic

Re: [HACKERS] Setting oom_adj on linux?

Alex Hunsaker writes: > Sure this was openssh? I just looked through the entire cvs history > for opensshp and found 0 references to 'oom' let alone 'oom_adj'. > Maybe something distro specific? FWIW, I see no evidence that sshd on Fedora does anything to change its oom score --- the oom_adj file

[HACKERS] synchronized snapshots

The attached patch implements the idea of Heikki / Simon published in http://archives.postgresql.org/pgsql-hackers/2009-11/msg00271.php Since nobody objected to the idea in general, I have implemented it. As this is not currently used anywhere it doesn't give immediate benefit, it is however a p

Re: [HACKERS] Setting oom_adj on linux?

On Fri, Jan 8, 2010 at 10:24, Stephen Frost wrote: > As I recall, oom_adj wasn't visible in the container because you > explicitly set what proc entries processes can have access to when using > VServers, and OpenSSH didn't handle that cleanly.  Guess what I'm just > saying is "don't just assume e

Re: [HACKERS] Streaming replication and postmaster signaling

David Fetter wrote: > On Thu, Jan 07, 2010 at 03:32:28PM -0500, Tom Lane wrote: > > [ shrug... ] To me, HS+SR is actual replication, which would > > justify tagging this release 9.0. With only one of them, it's 8.5. > > I understand that there are power users who would find HS alone to > > be tr

Re: [HACKERS] damage control mode

On Fri, Jan 8, 2010 at 1:38 PM, Bruce Momjian wrote: > Robert Haas wrote: >> >> We discussed doing this at the very beginning of 8.4 release cycle >> >> and, the more I think about it, the more I think it's not fair not to >> >> go ahead and do it. ?Otherwise, we're rewarding people for ignoring a

Re: [HACKERS] damage control mode

Robert Haas wrote: > >> We discussed doing this at the very beginning of 8.4 release cycle > >> and, the more I think about it, the more I think it's not fair not to > >> go ahead and do it. ?Otherwise, we're rewarding people for ignoring a > >> guideline that was discussed, and punishing (1) the p

Re: [HACKERS] Serializable Isolation without blocking

Markus Wanner wrote: > I don't remember reading about predicate locking in the paper I > read. Either he didn't cover that in his first implementation > (based on page level locking), or I've simply re-used that part of > my in-brain-memory. If you read the first paper but not the second, all

Re: [HACKERS] damage control mode

On Fri, Jan 8, 2010 at 1:29 PM, Bruce Momjian wrote: > Robert Haas wrote: >> On Fri, Jan 8, 2010 at 1:07 PM, Bruce Momjian wrote: >> > Robert Haas wrote: >> >> > You can't move from commitfest to beta until all _known_ bugs are >> >> > fixed/addressed, and you can't move from beta to RC using the

Re: [HACKERS] Feature patch 1 for plperl [PATCH]

On Jan 8, 2010, at 7:01 AM, Tim Bunce wrote: > I didn't get any significant feedback from the earlier draft so here's > the finished 'feature patch 1' for plperl. (This builds on my earlier > plperl refactoring patch, and the follow-on ppport.h patch.) > > Significant changes from the first draf

Re: [HACKERS] damage control mode

Robert Haas wrote: > On Fri, Jan 8, 2010 at 1:07 PM, Bruce Momjian wrote: > > Robert Haas wrote: > >> > You can't move from commitfest to beta until all _known_ bugs are > >> > fixed/addressed, and you can't move from beta to RC using the same > >> > criteria. > >> > >> Hmm. ?For 8.4, I don't thin

Re: [HACKERS] damage control mode

On Fri, Jan 8, 2010 at 1:07 PM, Bruce Momjian wrote: > Robert Haas wrote: >> > You can't move from commitfest to beta until all _known_ bugs are >> > fixed/addressed, and you can't move from beta to RC using the same >> > criteria. >> >> Hmm.  For 8.4, I don't think we actually fixed "all" known b

Re: [HACKERS] Listen / Notify - what to do when the queue is full

Merlin Moncure writes: > On Fri, Jan 8, 2010 at 7:48 AM, Joachim Wieland wrote: >> - do we need to limit the payload to pure ASCII ? I think yes, we need >> to. I also think we need to reject other payloads with elog(ERROR...). > Just noticed this...don't you mean UTF8? Are we going to force no

Re: [HACKERS] Listen / Notify - what to do when the queue is full

Merlin Moncure wrote: On Fri, Jan 8, 2010 at 7:48 AM, Joachim Wieland wrote: - do we need to limit the payload to pure ASCII ? I think yes, we need to. I also think we need to reject other payloads with elog(ERROR...). Just noticed this...don't you mean UTF8? Are we going to force non Englis

Re: [HACKERS] Listen / Notify - what to do when the queue is full

On Fri, Jan 8, 2010 at 7:48 AM, Joachim Wieland wrote: > - do we need to limit the payload to pure ASCII ? I think yes, we need > to. I also think we need to reject other payloads with elog(ERROR...). Just noticed this...don't you mean UTF8? Are we going to force non English speaking users to se

Re: [HACKERS] RFC: PostgreSQL Add-On Network

Magnus Hagander wrote: On Fri, Jan 8, 2010 at 18:48, Dave Page wrote: 2010/1/8 Magnus Hagander : On Fri, Jan 8, 2010 at 18:44, Dave Page wrote: The current set of active mirrors can always be found at http://www.postgresql.org/mirrors.xml, so you can build URLs on the mirror network using th

Re: [HACKERS] damage control mode

On Friday 08 January 2010 19:07:16 Bruce Momjian wrote: > > I think so, too, but I'm actually afraid that if we don't start making > > some tough decisions soon it's going to be even later than that. I'm > > dismayed by the number of people who seem to think that the current > > schedule is not al

Re: [HACKERS] RFC: PostgreSQL Add-On Network

On Jan 8, 2010, at 10:08 AM, Magnus Hagander wrote: > That, or implement that "send me to a random mirror" feature. Or > maybe the "send me to a random close mirror if available, or a random > global if not" feature. :-) > > Either way, there's definitely room for some improvement there, but > l

Re: [HACKERS] RFC: PostgreSQL Add-On Network

On Fri, Jan 8, 2010 at 18:48, Dave Page wrote: > 2010/1/8 Magnus Hagander : >> On Fri, Jan 8, 2010 at 18:44, Dave Page wrote: >>> The current set of active mirrors can always be found at >>> http://www.postgresql.org/mirrors.xml, so you can build URLs on the >>> mirror network using the protocol,

Re: [HACKERS] damage control mode

Robert Haas wrote: > > You can't move from commitfest to beta until all _known_ bugs are > > fixed/addressed, and you can't move from beta to RC using the same > > criteria. > > Hmm. For 8.4, I don't think we actually fixed "all" known bugs - I > think we made a decision about which ones had to b

Re: [HACKERS] RFC: PostgreSQL Add-On Network

On Fri, Jan 8, 2010 at 18:55, David E. Wheeler wrote: > On Jan 8, 2010, at 9:38 AM, Magnus Hagander wrote: > >> Is there a particular reason not to use the existing mirroring network >> to distribute the files? If not, then I suggest using them should be >> part of the design. > > No, as long as P

Re: [HACKERS] Serializable Isolation without blocking

Hi, Kevin Grittner wrote: > I had this flagged as needing a response, but it fell through the > cracks yesterday. Apologies for the delayed response. No problem. > Markus Wanner wrote: > When the Cahill paper talks about predicate locking, it *is* talking > about what to lock with SIREAD locks

Re: [HACKERS] RFC: PostgreSQL Add-On Network

On Jan 8, 2010, at 9:59 AM, Dave Page wrote: > Either can be arranged. For StackBuilder, we created a pgFoundry > project, so files can just be uploaded there by authorised users, from > where they get replicated back onto the mirror network. > > Which leads us neatly back to the GForge URL threa

Re: [HACKERS] git help (was: Serializable Isolation without blocking)

On Fri, Jan 8, 2010 at 11:22 AM, Kevin Grittner wrote: > Magnus Hagander wrote: >> On Thu, Jan 7, 2010 at 19:08, Kevin Grittner > >>> Robert's advice being the last (and only) offered on the topic, >>> I'm taking the silence as agreement and have dropped the request >>> for a "serializable" repos

Re: [HACKERS] RFC: PostgreSQL Add-On Network

On Fri, Jan 8, 2010 at 5:55 PM, David E. Wheeler wrote: > On Jan 8, 2010, at 9:38 AM, Magnus Hagander wrote: > >> Is there a particular reason not to use the existing mirroring network >> to distribute the files? If not, then I suggest using them should be >> part of the design. > > No, as long as

Re: [HACKERS] Setting oom_adj on linux?

Robert Haas writes: > There could well be moving parts if the user wants to adjust the value > being written to oom_adj, and can't because it's compiled in. I don't > see why we can't just add a GUC for this and be done with it. The number of users who will want to do that might be different fro

Re: [HACKERS] RFC: PostgreSQL Add-On Network

On Jan 8, 2010, at 9:38 AM, Magnus Hagander wrote: > Is there a particular reason not to use the existing mirroring network > to distribute the files? If not, then I suggest using them should be > part of the design. No, as long as PAUS can drop uploaded distributions onto the master FTP server,

Re: [HACKERS] RFC: PostgreSQL Add-On Network

On Jan 8, 2010, at 9:24 AM, Dave Page wrote: > If that is the goal of your project then I withdraw my previous > comments, which were written on the belief that you were proposing a > generic distribution/build/installation system for PostgreSQL users. It is a generic distribution and installatio

Re: [HACKERS] true serializability and predicate locking

Greg Stark wrote: > Well we disagree with whether we have any reasonable plan for > adding the more fine-grained locks. We probably agree on that, too. Perhaps it's that I think we can develop one within a few months and you don't? > AFAICT we have either a) add something clean and abstract

Re: [HACKERS] RFC: PostgreSQL Add-On Network

2010/1/8 Magnus Hagander : > On Fri, Jan 8, 2010 at 18:44, Dave Page wrote: >> The current set of active mirrors can always be found at >> http://www.postgresql.org/mirrors.xml, so you can build URLs on the >> mirror network using the protocol, host, port and path from the mirror >> list, and then

Re: [HACKERS] RFC: PostgreSQL Add-On Network

On Fri, Jan 8, 2010 at 18:44, Dave Page wrote: > On Fri, Jan 8, 2010 at 5:38 PM, Magnus Hagander wrote: >> On Thu, Jan 7, 2010 at 21:07, David E. Wheeler wrote: >>> Hackers, >>> >>> I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL >>> extensions. I've tried to closely follow the

Re: [HACKERS] Setting oom_adj on linux?

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> I don't want to go to the trouble of creating (and documenting) a >> configure option for this. Much less a GUC ;-) > Requiring a custom build to disable it would be horrible, in my view. BTW, maybe you're confused about the inte

Re: [HACKERS] RFC: PostgreSQL Add-On Network

On Fri, Jan 8, 2010 at 5:38 PM, Magnus Hagander wrote: > On Thu, Jan 7, 2010 at 21:07, David E. Wheeler wrote: >> Hackers, >> >> I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL extensions. >> I've tried to closely follow the [CPAN philosophy][] to come up with a plan >> that re

Re: [HACKERS] RFC: PostgreSQL Add-On Network

On Thu, Jan 7, 2010 at 21:07, David E. Wheeler wrote: > Hackers, > > I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL extensions. > I've tried to closely follow the [CPAN philosophy][] to come up with a plan > that requires a minimum-work implementation that builds on the existin

Re: [HACKERS] Setting oom_adj on linux?

On Fri, Jan 8, 2010 at 12:24 PM, Tom Lane wrote: > Stephen Frost writes: >> * Tom Lane (t...@sss.pgh.pa.us) wrote: >>> I don't want to go to the trouble of creating (and documenting) a >>> configure option for this.  Much less a GUC ;-) > >> Requiring a custom build to disable it would be horribl

Re: [HACKERS] RFC: PostgreSQL Add-On Network

On Fri, Jan 8, 2010 at 5:13 PM, David E. Wheeler wrote: > Please let the Windows thread die now. PGAN doesn't ignore Windows; it > ignores installer development. > yeah, I think there are two quite separable projects here. It's quite possible that once the binary installer people have a source p

Re: [HACKERS] Setting oom_adj on linux?

Tom Lane wrote: I don't want to go to the trouble of creating (and documenting) a configure option for this. Much less a GUC ;-) What I suggest is that we do something like #ifdef LINUX_OOM_ADJ ... fprintf(oom, "%d\n", LINUX_OOM_ADJ); ... #endif Then,

Re: [HACKERS] Add .gitignore files to CVS?

On Thu, Jan 7, 2010 at 5:45 PM, Tom Lane wrote: > Peter Eisentraut writes: >> On tor, 2010-01-07 at 22:16 +, Tim Bunce wrote: >>> Is there any reason not to add .gitignore files into the repository? > >> I already find the .cvsignore files to be useless and an annoyance to >> keep up to date

Re: [HACKERS] damage control mode

On Fri, Jan 8, 2010 at 11:44 AM, Bruce Momjian wrote: > Robert Haas wrote: >> On Thu, Jan 7, 2010 at 9:11 PM, Andrew Dunstan wrote: >> > This strikes me as quite premature. Heiki just said he expects to have SR >> > committed next week. >> >> Getting it committed is not what I'm worried about.  W

Re: [HACKERS] true serializability and predicate locking

On Fri, Jan 8, 2010 at 5:13 PM, Kevin Grittner wrote: >> From what I understand your first cut will just take full-table >> "locks" anyways so it won't matter what type of plan is used at >> all. > > Right.  And it would be totally premature to try to test any > optimizations at that phase, which

Re: [HACKERS] Setting oom_adj on linux?

Alex, * Alex Hunsaker (bada...@gmail.com) wrote: > As long as the VM/container you are running under wont kill postmaster > for trying to access proc-- the patch I posted should work fine. It > just ignores any error (I assumed you might be running in a chroot > without proc or some such). As I

Re: [HACKERS] Setting oom_adj on linux?

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> I don't want to go to the trouble of creating (and documenting) a >> configure option for this. Much less a GUC ;-) > Requiring a custom build to disable it would be horrible, in my view. > Or, at best, just means that the package

Re: [HACKERS] RFC: PostgreSQL Add-On Network

On Fri, Jan 8, 2010 at 5:13 PM, David E. Wheeler wrote: > This whole bit about Windows is a red herring. Perhaps I should not have > phrased it the way I did WRT Windows. So I'm going to change it to: > >> The PGAN client will make no other assumptions about how to build and >> install extensio

Re: [HACKERS] Add .gitignore files to CVS?

On Friday 08 January 2010 17:38:15 Alex Hunsaker wrote: > On Fri, Jan 8, 2010 at 02:03, Magnus Hagander wrote: > > You can always create your own branch with just the .gitignore files > > and merge that into whatever you're working on :) > > The only thing annoying about that is if you generate d

Re: [HACKERS] damage control mode

On Jan 8, 2010, at 1:02 AM, Dimitri Fontaine wrote: > Now, I'll second Greg Smith and Tom here, in that I think we need to run > the last commitfest as usual, knowing that the outcome of the commitfest > for any given patch is not "it made it" but "we reviewed it". It's still > right for the proje

Re: [HACKERS] damage control mode

* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote: > It also seems to call into question the wisdom of annual releases. > If we had a two-year cycle which had three times as much in it, > would that be an improvement, or not? At the moment, my vote would be "how 'bout we discuss this post-8.5?

Re: [HACKERS] RFC: PostgreSQL Add-On Network

On Jan 8, 2010, at 1:35 AM, Dave Page wrote: > I am saying that if the design won't ever work without requiring > painful dependency installation that users will likely not want to > bother with, then it is fundamentally broken. Better to write one > system that can _eventually_ work everywhere, t

Re: [HACKERS] true serializability and predicate locking

Greg Stark wrote: > My comment was in relation to the idea of representing the costs > in the planner. I was a) saying you had to see how the > implementation went before you try to come up with how to > represent the costs and then b) speculating (hypocritically:) that > you might have the dire

Re: [HACKERS] Setting oom_adj on linux?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Alex Hunsaker writes: > > On Fri, Jan 8, 2010 at 07:27, Tom Lane wrote: > >> Then, somebody who wants the feature would build with, say, > >>        -DLINUX_OOM_ADJ=0 > >> or another value if they want that. > > > Here is a stab at that. > > Anybody have

  1   2   >