Re: [PATCHES] Automatic adjustment of bgwriter_lru_maxpages

2007-05-14 Thread daveg
On Mon, May 14, 2007 at 11:19:23PM -0400, Greg Smith wrote: > On Mon, 14 May 2007, Tom Lane wrote: > > >If you can write something like that, why do we need the parameter at all? > > Couple of reasons: > > -As I already mentioned in my last message, I think it's unwise to let the > LRU writes g

Re: [PATCHES] Concurrent psql patch

2007-05-14 Thread daveg
On Mon, May 14, 2007 at 11:55:07AM -0500, Jim C. Nasby wrote: > On Mon, May 14, 2007 at 11:03:52AM -0400, Tom Lane wrote: > > Gregory Stark <[EMAIL PROTECTED]> writes: > > > But these kinds of inconsistent behaviours can be traps for users. It > > > means > > > "\c1" and "\c 1" do different things

Re: [PATCHES] [DOCS] OS/X startup scripts

2007-05-14 Thread Mark Kirkwood
Alvaro Herrera wrote: Mark Kirkwood wrote: Alvaro Herrera wrote: Except that it also includes diffs for generated files, which tend to be huge. To work around that you need to create a list of files to exclude, and the whole thing (which was cumbersome already) starts to get unmanageable. $

Re: [PATCHES] Automatic adjustment of bgwriter_lru_maxpages

2007-05-14 Thread Greg Smith
On Mon, 14 May 2007, Tom Lane wrote: If you can write something like that, why do we need the parameter at all? Couple of reasons: -As I already mentioned in my last message, I think it's unwise to let the LRU writes go completely unbounded. I still think there should be a maximum, and if

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

2007-05-14 Thread Neil Conway
On Fri, 2007-27-04 at 18:59 -0400, Neil Conway wrote: > This patch needs more work. Has a revised version of this patch been submitted? -Neil ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [PATCHES] [DOCS] Autovacuum and XID wraparound

2007-05-14 Thread Neil Conway
On Mon, 2007-14-05 at 16:22 -0400, Bruce Momjian wrote: > I agree with Tom. I don't think the current behavior is a major issue > for users for it to be mentioned more than it already is Are you really suggesting that we shouldn't modify config.sgml to note that "autovacuum = off" does not actual

Re: [PATCHES] [DOCS] OS/X startup scripts

2007-05-14 Thread Alvaro Herrera
Mark Kirkwood wrote: > Alvaro Herrera wrote: > >Except that it also includes diffs for generated files, which tend to be > >huge. To work around that you need to create a list of files to > >exclude, and the whole thing (which was cumbersome already) starts to > >get unmanageable. > > $ make mai

Re: [PATCHES] [HACKERS] Behavior of GENERATED columns per SQL2003

2007-05-14 Thread Bruce Momjian
URL added to TODO item. --- Zoltan Boszormenyi wrote: > Forwarded to -patches because of the attachment. > > Eredeti ?zenet > T?rgy:Re: [HACKERS] Behavior of GENERATED columns per SQL2003 > D?tum:

Re: [PATCHES] [DOCS] OS/X startup scripts

2007-05-14 Thread Mark Kirkwood
Alvaro Herrera wrote: David Fetter wrote: On Mon, May 14, 2007 at 03:31:40PM +1200, Mark Kirkwood wrote: David Fetter wrote: cvs diff works just great until you want to add or remove a file without write permissions to the CVS repository, i.e. when you've checked out as anonymous. I usually

Re: [PATCHES] Updateable cursors patch

2007-05-14 Thread FAST PostgreSQL
Right. I will send an updated patch against the CVS head in the next couple of days. Jaime Casanova wrote: On 4/4/07, FAST PostgreSQL <[EMAIL PROTECTED]> wrote: Attached is a working updateable cursors patch. The core functionality has been implemented and the patch also contains the regressi

Re: [PATCHES] [DOCS] Autovacuum and XID wraparound

2007-05-14 Thread Tom Lane
Alvaro Herrera <[EMAIL PROTECTED]> writes: > I suppose it would be pretty trivial to set the relfrozenxid to > RecentXmin or something during TRUNCATE. I had the idea we were doing that already --- at least I'm pretty sure I remember it being discussed. But I see it's not being done in HEAD.

Re: [PATCHES] [DOCS] Autovacuum and XID wraparound

2007-05-14 Thread Alvaro Herrera
Chris Browne wrote: > Would the following 'maintenance' regimen be truly safe against XID > wraparound: > > - Most tables are being vacuumed regularly, so that >pg_class.relfrozenxid is kept "safe." > > - There are some tables that periodically get TRUNCATEd so that, in >principle, the

Re: [PATCHES] [DOCS] Autovacuum and XID wraparound

2007-05-14 Thread Chris Browne
[EMAIL PROTECTED] (Neil Conway) writes: > On Sun, 2007-13-05 at 22:06 -0400, Tom Lane wrote: >> This fact is already documented in at least three places; do we really >> need two more? > > I think we need to at least modify the documentation for the autovacuum > GUC parameter, which currently state

Re: [PATCHES] [DOCS] Autovacuum and XID wraparound

2007-05-14 Thread Bruce Momjian
David Fetter wrote: > On Sun, May 13, 2007 at 10:06:40PM -0400, Tom Lane wrote: > > David Fetter <[EMAIL PROTECTED]> writes: > > > Per Neil Conway, here's some doc patches re: the autovacuum > > > daemon's behavior. Should this be back-patched to 8.2x? > > > > This fact is already documented in a

Re: [PATCHES] [DOCS] OS/X startup scripts

2007-05-14 Thread Alvaro Herrera
David Fetter wrote: > On Mon, May 14, 2007 at 03:31:40PM +1200, Mark Kirkwood wrote: > > David Fetter wrote: > > >cvs diff works just great until you want to add or remove a file > > >without write permissions to the CVS repository, i.e. when you've > > >checked out as anonymous. > > > > > > > I u

Re: [PATCHES] On patching without write access to CVS

2007-05-14 Thread Andrew Hammond
On May 14, 12:57 am, [EMAIL PROTECTED] (Peter Eisentraut) wrote: > Am Montag, 14. Mai 2007 03:56 schrieb David Fetter: > > > +For those things which CVS does not do > > +by itself, such as letting you create patches without write access, s/such as letting you create patches/specifically cr

Re: [PATCHES] Concurrent psql patch

2007-05-14 Thread Jim C. Nasby
On Mon, May 14, 2007 at 06:26:42PM +0100, Gregory Stark wrote: > > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > > Since this command will be getting used very frequently by anyone using > > concurrent connections interactively, it'd be nice if it was lower-case. > > It looks like that limits us

Re: [PATCHES] [DOCS] OS/X startup scripts

2007-05-14 Thread David Fetter
On Mon, May 14, 2007 at 03:31:40PM +1200, Mark Kirkwood wrote: > David Fetter wrote: > >cvs diff works just great until you want to add or remove a file > >without write permissions to the CVS repository, i.e. when you've > >checked out as anonymous. > > > > I usually saved an untouched version of

Re: [PATCHES] Concurrent psql patch

2007-05-14 Thread Gregory Stark
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > Since this command will be getting used very frequently by anyone using > concurrent connections interactively, it'd be nice if it was lower-case. > It looks like that limits us to j, k, m, n, v, and y. In unix this idea > is about jobs, what about us

Re: [PATCHES] [GENERAL] dropping role w/dependent objects

2007-05-14 Thread Alvaro Herrera
Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Sample output to the client (note: in this test, MAX_REPORTED_DEPS is > > set to 10). > > ... > > foo=# drop user foo; > > ERROR: role "foo" cannot be dropped because some objects depend on it > > DETAIL: owner of tablespace foo > >

Re: [PATCHES] Concurrent psql patch

2007-05-14 Thread Jim C. Nasby
On Mon, May 14, 2007 at 11:03:52AM -0400, Tom Lane wrote: > Gregory Stark <[EMAIL PROTECTED]> writes: > > But these kinds of inconsistent behaviours can be traps for users. It means > > "\c1" and "\c 1" do different things even though "\cpostgres" and \c > > postgres" > > do the same thing. And it

Re: [PATCHES] Have vacuum emit a warning when it runs out of maintenance_work_mem

2007-05-14 Thread Tom Lane
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Jim C. Nasby wrote: >> If nothing else, it would likely be >> worth special-casing an entire page being dead, which is a common case >> for queue tables. That could be done by making an entry in the page >> number array with a special offset value.

Re: [PATCHES] Have vacuum emit a warning when it runs out of maintenance_work_mem

2007-05-14 Thread Heikki Linnakangas
Jim C. Nasby wrote: Did someone come up with a bitmap compression scheme for on-disk bitmap indexes that would help out here? Some form of compression could make a big difference in mostly-dead pages. Yes, there's a pretty nice compression scheme there, but the requirement for random access m

Re: [PATCHES] Concurrent psql patch

2007-05-14 Thread Jim C. Nasby
On Mon, May 14, 2007 at 12:51:39PM +0100, Gregory Stark wrote: > "Tom Lane" <[EMAIL PROTECTED]> writes: > > > Gregory Stark <[EMAIL PROTECTED]> writes: > >> So would you prefer \g& as Jim Nasby suggested? I hadn't even considered > >> that > >> previously since I'm not accustomed to using \g but

Re: [PATCHES] Have vacuum emit a warning when it runs out of maintenance_work_mem

2007-05-14 Thread Jim C. Nasby
Did someone come up with a bitmap compression scheme for on-disk bitmap indexes that would help out here? Some form of compression could make a big difference in mostly-dead pages. If nothing else, it would likely be worth special-casing an entire page being dead, which is a common case for queue t

Re: [PATCHES] Concurrent psql patch

2007-05-14 Thread Tom Lane
Gregory Stark <[EMAIL PROTECTED]> writes: > But these kinds of inconsistent behaviours can be traps for users. It means > "\c1" and "\c 1" do different things even though "\cpostgres" and \c postgres" > do the same thing. And it means "\c1" might connect to a database named "1" > today but switch s

Re: [PATCHES] Concurrent psql patch

2007-05-14 Thread Gregory Stark
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > Would \c# limit us to 9 concurrent connections? Might want > > \cs[witch] [session] Hm, we kind of have a choice with \c#. Either we treat it as part of the command in which case the way to connect to an integer-named database is to include a space. W

Re: [PATCHES] Automatic adjustment of bgwriter_lru_maxpages

2007-05-14 Thread Greg Smith
On Mon, 14 May 2007, Heikki Linnakangas wrote: If it's safe to set it high, let's default it to infinity. The maximum right now is 1000, and that would be a reasonable new default. You really don't to write more than 1000 per interval anyway without taking a break for checkpoints; the more w

Re: [PATCHES] Automatic adjustment of bgwriter_lru_maxpages

2007-05-14 Thread Tom Lane
Greg Smith <[EMAIL PROTECTED]> writes: > Since the whole background writer setup is kind of complicated, the other > thing I was working on is writing a guide on how to use the new > pg_stat_bgwriter information to figure out if you need to increase > bgwriter_[all|lru]_pages (and the other para

Re: [PATCHES] [DOCS] OS/X startup scripts

2007-05-14 Thread Greg Smith
On Mon, 14 May 2007, Gregory Stark wrote: Personally I find CVS so terribly slow for large trees like Postgres that it's essential to use rsync to maintain a local CVS repository. That makes 'cvs diff' remarkably fast. Having recently tried to get this to work right and not quite nailed it do

Re: [PATCHES] Automatic adjustment of bgwriter_lru_maxpages

2007-05-14 Thread Heikki Linnakangas
Greg Smith wrote: On Mon, 14 May 2007, ITAGAKI Takahiro wrote: BTW, your patch will cut LRU writes short, but will not encourage to do more works. So should set more aggressive values to bgwriter_lru_percent and bgwriter_lru_maxpages as defaults? Setting a bigger default maximum is one poss

Re: [PATCHES] Automatic adjustment of bgwriter_lru_maxpages

2007-05-14 Thread Greg Smith
On Mon, 14 May 2007, ITAGAKI Takahiro wrote: BTW, your patch will cut LRU writes short, but will not encourage to do more works. So should set more aggressive values to bgwriter_lru_percent and bgwriter_lru_maxpages as defaults? Setting a bigger default maximum is one possibility I was thinkin

Re: [PATCHES] [DOCS] OS/X startup scripts

2007-05-14 Thread Andrew Dunstan
Heikki Linnakangas wrote: You need write-access to add files, even on anonymouse server. We often get patches with new files as separate attachments because of that. This is the part that cvsutils fakes for you (by hacking the local cvs metadata files) so you don't need write access.

Re: [PATCHES] Concurrent psql patch

2007-05-14 Thread Gregory Stark
"Tom Lane" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: >> So would you prefer \g& as Jim Nasby suggested? I hadn't even considered that >> previously since I'm not accustomed to using \g but it does seem kind of >> pretty. I normally use ; but I suppose there's nothing

Re: [PATCHES] [DOCS] OS/X startup scripts

2007-05-14 Thread Gregory Stark
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes: > You need write-access to add files, even on anonymouse server. We often get > patches with new files as separate attachments because of that. Oh quite right. I had forgotten but that was the original reason I switched to using rsync. The alternat

Re: [PATCHES] [DOCS] OS/X startup scripts

2007-05-14 Thread Heikki Linnakangas
Gregory Stark wrote: "Tom Lane" <[EMAIL PROTECTED]> writes: David Fetter <[EMAIL PROTECTED]> writes: I haven't included the customary diffs. This points me to some of the many deficiencies of CVS, namely that I would need write access in order to have it create a diff, Strange, it works fine

Re: [PATCHES] [DOCS] OS/X startup scripts

2007-05-14 Thread Gregory Stark
"Tom Lane" <[EMAIL PROTECTED]> writes: > David Fetter <[EMAIL PROTECTED]> writes: >> I haven't included the customary diffs. This points me to some of the >> many deficiencies of CVS, namely that I would need write access in >> order to have it create a diff, > > Strange, it works fine for everyo

Re: [PATCHES] Automatic adjustment of bgwriter_lru_maxpages

2007-05-14 Thread ITAGAKI Takahiro
Greg Smith <[EMAIL PROTECTED]> wrote: > The first patch (buf-alloc-stats) takes the two most interesting pieces of > data the original patch collected, the number of buffers allocated > recently and the number that the clients wrote out, and ties all that into > the new stats structure. > The

Re: [PATCHES] On patching without write access to CVS

2007-05-14 Thread Peter Eisentraut
Am Montag, 14. Mai 2007 03:56 schrieb David Fetter: > +For those things which CVS does not do > +by itself, such as letting you create patches without write access, I don't think that is accurate. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(e