Re: [HACKERS] patch for new feature: Buffer Cache Hibernation

Mitsuru IWASAKI wrote: the patch is available at: http://people.freebsd.org/~iwasaki/postgres/buffer-cache-hibernation-postgresql-20110508.patch We can't accept patches just based on a pointer to a web site. Please e-mail this to the mailing list so that it can be considered a submission

Re: [HACKERS] switch UNLOGGED to LOGGED

> On Fri, Apr 22, 2011 at 4:13 AM, Leonardo Francalanci wrote: > >> Maybe you should change xl_act_commit to have a separate list of rels to > >> drop the init fork for (instead of mixing those with the list of files to > >> drop as a whole). > > > > I tried to follow your suggestion, tha

Re: [HACKERS] postgresql.conf error checking strategy

Bruce Momjian writes: > Robert Haas wrote: >> On Wed, Apr 6, 2011 at 5:17 PM, Tom Lane wrote: >>> So I'm thinking we should adopt a strategy that's less likely to result >>> in divergent behavior among different backends. ?The idea I have in mind >>> is to have the first "validation" pass only ch

Re: [HACKERS] patch for new feature: Buffer Cache Hibernation

Hi, folks! > I'll do more testing tomorrow, and hopefully finalize my patch. Done! the patch is available at: http://people.freebsd.org/~iwasaki/postgres/buffer-cache-hibernation-postgresql-20110508.patch I hope this would be committable and the final version. Major changes from the experimen

Re: [HACKERS] pg_upgrade's bindir options could be optional

Peter Eisentraut writes: > On lör, 2011-05-07 at 13:33 -0400, Bruce Momjian wrote: >> Another >> interesting approach would be to assume the /bin directory is ../bin >> from the data directory. That would work for some installs, >> particularly for people moving things around, but again, it is w

Re: [HACKERS] Why not install pgstattuple by default?

Attached patch is a first cut at what moving one contrib module (in this case pg_buffercache) to a new directory structure might look like. The idea is that src/extension could become a place for "first-class" extensions to live. Those are ones community is committed to providing in core, but

Re: [HACKERS] superusers are members of all roles?

Andrew Dunstan wrote: > > > On 04/07/2011 11:01 AM, Tom Lane wrote: > > Andrew Dunstan writes: > >> I thought about that. What I'd like to know is how many people actually > >> want and use and expect the current behaviour. If it's more than a > >> handful (which I seriously doubt) then that's p

Re: [HACKERS] postgresql.conf error checking strategy

Robert Haas wrote: > On Wed, Apr 6, 2011 at 5:17 PM, Tom Lane wrote: > > I just spent a rather confused half hour while testing my GUC > > assign-hook patch, and when I finally figured out what was happening, > > it made me wonder whether we should redesign the behavior a little bit. > > > > The c

Re: [HACKERS] Why not install pgstattuple by default?

On 05/06/2011 04:06 PM, Tom Lane wrote: FWIW, I did move pg_config from -devel to the "main" (really client) postgresql package in Fedora, as of 9.0. That will ensure it's present in either client or server installations. Eventually that packaging will reach RHEL ... We should make sure t

Re: [HACKERS] pg_upgrade's bindir options could be optional

Peter Eisentraut wrote: > On l?r, 2011-05-07 at 13:33 -0400, Bruce Momjian wrote: > > Another > > interesting approach would be to assume the /bin directory is ../bin > > from the data directory. That would work for some installs, > > particularly for people moving things around, but again, it is

Re: [HACKERS] pg_upgrade's bindir options could be optional

Peter Eisentraut wrote: > On fre, 2011-05-06 at 21:54 -0300, Alvaro Herrera wrote: > > Excerpts from Tom Lane's message of vie may 06 17:11:35 -0300 2011: > > > > > As an example, the proposed defaults would be not only wrong, but > > > disastrous in the perfectly-reasonable situation where the us

Re: [HACKERS] Fix for pg_upgrade user flag

On 05/07/2011 06:48 PM, Bruce Momjian wrote: "postgres" is not compiled in. It's whatever user you run initdb under. In particular, in the regression tests, it is probably not "postgres". Thanks. I get confused because the 'postgres' database is hardcoded in, but not the username. Not sure

Re: [HACKERS] Fix for pg_upgrade user flag

Peter Eisentraut wrote: > On l?r, 2011-05-07 at 13:50 -0400, Bruce Momjian wrote: > > I was really wondering if I should be using that hard-coded name, > > rather than allowing the user to supply it. They have to compile in a > > different name, and I assume that name is accessible somewhere. > >

Re: [HACKERS] Fix for pg_upgrade user flag

Kevin Grittner wrote: > > Bruce Momjian wrote: > > Tom Lane wrote: > >> Bruce Momjian writes: > >>> One question I have is why we even bother to allow the database > >>> username to be specified? Shouldn't we just hard-code that to > >>> 'postgres'? > >> > >> Only if you want to render pg_upgrade

Re: [HACKERS] Why not install pgstattuple by default?

On 05/07/2011 05:26 PM, Peter Eisentraut wrote: On lör, 2011-05-07 at 17:16 -0400, Andrew Dunstan wrote: pg_config is useful quite apart from its use in building things, as was discussed upthread. Link please. cheers and

Re: [HACKERS] GSoC 2011 - New phpPgAdmin Plugin Architecture

Robert, >>  A copy of my proposal can be found at >> [http://fit.faccat.br/~leonardo/gsoc_proposal.html]. But I will put a >> copy of this in another place. So, what would be better? Put on the >> PostgreSQL Wiki [http://http://wiki.postgresql.org/wiki] or the >> phpPgAdmin website [http://phppg

Re: [HACKERS] Why not install pgstattuple by default?

On lör, 2011-05-07 at 17:06 -0400, Greg Smith wrote: > The repmgr program we distribute has the same problem, so I've been > getting first-hand reports of just how many people are likely to run > into this recently. You have to install postgresql-devel with RPM and > on Debian, the very non-obvi

Re: [HACKERS] Why not install pgstattuple by default?

On lör, 2011-05-07 at 17:16 -0400, Andrew Dunstan wrote: > pg_config is useful quite apart from its use in building things, as was > discussed upthread. Link please. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresq

Re: [HACKERS] Prefered Types

On fre, 2011-05-06 at 18:38 -0300, Alvaro Herrera wrote: > I remember that one of the problems put forth against this idea was > that stuff like int2+int2 which currently returns int2 would have to > be changed to return int4, otherwise it risks overflow which it > currently doesn't (not because th

Re: [HACKERS] Why not install pgstattuple by default?

On 05/07/2011 04:43 PM, Peter Eisentraut wrote: On lör, 2011-05-07 at 17:35 -0300, Euler Taveira de Oliveira wrote: Em 07-05-2011 13:42, Peter Eisentraut escreveu: Do you need pg_config to install extensions? No. But we need it to build other extensions. But for that you need the -dev[el]

Re: [HACKERS] (Better) support for cross compiled external modules

On mån, 2011-05-02 at 14:41 +, Johann 'Myrkraverk' Oskarsson wrote: > Is it possible to add support for cross compiled PGXS modules to the > build system? > > That is, when PG is cross compiled, a -pg_config is > also built for use with external modules? > > I'm not adverse to submit a patch

Re: [HACKERS] Why not install pgstattuple by default?

On 05/07/2011 12:42 PM, Peter Eisentraut wrote: On fre, 2011-05-06 at 14:32 -0400, Greg Smith wrote: Given the other improvements in being able to build extensions in 9.1, we really should push packagers to move pg_config from the PostgreSQL development package into the main one starting in

Re: [HACKERS] pg_upgrade's bindir options could be optional

On lör, 2011-05-07 at 13:33 -0400, Bruce Momjian wrote: > Another > interesting approach would be to assume the /bin directory is ../bin > from the data directory. That would work for some installs, > particularly for people moving things around, but again, it is worth > trying to default somethin

Re: [HACKERS] pg_upgrade's bindir options could be optional

On fre, 2011-05-06 at 21:54 -0300, Alvaro Herrera wrote: > Excerpts from Tom Lane's message of vie may 06 17:11:35 -0300 2011: > > > As an example, the proposed defaults would be not only wrong, but > > disastrous in the perfectly-reasonable situation where the user has > > moved the old installat

Re: [HACKERS] Re: [pgsql-advocacy] New Canadian nonprofit for trademark, postgresql.org domain, etc.

Chris, > Not totally Idle thought: it would be nice if the "holding > corporation" doesn't need a bank account, as they impose burdens of > fees (not huge, but not providing us notable value), and more > importantly, impose administrative burdens. Our banks like to impose > holds on accounts any t

Re: [HACKERS] psql describe.c cleanup

On lör, 2011-05-07 at 15:40 -0400, Josh Kupershmidt wrote: > And while I'm griping about describe.c, is it just me or is the source > code indentation in that file totally screwy? I'm using emacs and I've > loaded the snippet for pgsql-c-mode from > ./src/tools/editors/emacs.samples into my ~/.emac

Re: [HACKERS] Fix for pg_upgrade user flag

On lör, 2011-05-07 at 13:50 -0400, Bruce Momjian wrote: > I was really wondering if I should be using that hard-coded name, > rather than allowing the user to supply it. They have to compile in a > different name, and I assume that name is accessible somewhere. "postgres" is not compiled in. It'

Re: [HACKERS] Why not install pgstattuple by default?

On lör, 2011-05-07 at 17:35 -0300, Euler Taveira de Oliveira wrote: > Em 07-05-2011 13:42, Peter Eisentraut escreveu: > > Do you need pg_config to install extensions? > > > No. But we need it to build other extensions. But for that you need the -dev[el] package anyway, so there would be no point i

Re: [HACKERS] Why not install pgstattuple by default?

Em 07-05-2011 13:42, Peter Eisentraut escreveu: Do you need pg_config to install extensions? No. But we need it to build other extensions. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent

Re: [HACKERS] Process wakeups when idle and power consumption

On 7 May 2011 18:07, Tom Lane wrote: > The aspect of this that *is* relevant is that if you haven't > deliberately defeated the interlock (and thereby put your data at risk), > you won't be able to start a new postmaster until all the old > shmem-attached children are gone.  And that's why having

Re: [HACKERS] Fix for pg_upgrade user flag

> Bruce Momjian wrote: > Tom Lane wrote: >> Bruce Momjian writes: >>> One question I have is why we even bother to allow the database >>> username to be specified? Shouldn't we just hard-code that to >>> 'postgres'? >> >> Only if you want to render pg_upgrade unusable by a significant >> fraction

Re: [HACKERS] Bug in autovacuum.c?

Tom Lane wrote: > Robert Haas writes: > > On Fri, Apr 1, 2011 at 5:48 PM, Bruce Momjian wrote: > >> Agreed it is not worth it but I think we should at least C comment > >> something. ? I think at a minimum we should set it to > >> FirstNormalTransactionId. > > > I think you should leave it well

Re: [HACKERS] Re: [pgsql-advocacy] New Canadian nonprofit for trademark, postgresql.org domain, etc.

I quite agree with Peter's comments. Keeping this corporation as simple to manage as possible is a considerably valuable feature. If we find we need an "activity corporation," it won't be all that difficult to found that, and it's worth noting that *that* organization would need to have a substan

[HACKERS] Re: [pgsql-advocacy] New Canadian nonprofit for trademark, postgresql.org domain, etc.

On fre, 2011-05-06 at 21:53 +0200, Cédric Villemain wrote: > > If someone gets motivated to build up Canadian community activity, > the > > membership of the NPO could be expanded in the future, and new board > > members could be elected. Otherwise, the nonprofit could run under > a > > stewardshi

Re: [HACKERS] Fix for pg_upgrade user flag

Tom Lane wrote: > Bruce Momjian writes: > > One question I have is why we even bother to allow the database username > > to be specified? Shouldn't we just hard-code that to 'postgres'? > > Only if you want to render pg_upgrade unusable by a significant fraction > of people. "postgres" is not t

Re: [HACKERS] Fix for pg_upgrade user flag

Bruce Momjian writes: > One question I have is why we even bother to allow the database username > to be specified? Shouldn't we just hard-code that to 'postgres'? Only if you want to render pg_upgrade unusable by a significant fraction of people. "postgres" is not the hard wired name of the bo

Re: [HACKERS] pg_upgrade's bindir options could be optional

Alvaro Herrera wrote: > Excerpts from Tom Lane's message of vie may 06 17:11:35 -0300 2011: > > > As an example, the proposed defaults would be not only wrong, but > > disastrous in the perfectly-reasonable situation where the user has > > moved the old installation aside and then installed the ne

Re: [HACKERS] Process wakeups when idle and power consumption

Peter Geoghegan writes: > Perhaps I'm missing the point here, but I don't think that I have to > make an argument for why it might be acceptable to have two archivers > running at once, or two of any other auxiliary process. Let's assume > that it's completely unacceptable. It may still be worth w

Re: [HACKERS] a bit more precise MaxOffsetNumber

Dne 7.5.2011 04:02, Robert Haas napsal(a): > 2011/4/30 Tomas Vondra : >> I've been digging in the sources, and I've noticed the MaxOffsetNumber >> is defined (in storage/off.h) like this >> >> (BLCKSZ / sizeof(ItemIdData)) >> >> I guess it might be made a bit more precise by subtracting the header

Re: [HACKERS] Why not install pgstattuple by default?

On fre, 2011-05-06 at 14:32 -0400, Greg Smith wrote: > Given the other improvements in being able to build extensions in 9.1, > we really should push packagers to move pg_config from the PostgreSQL > development package into the main one starting in that version. I've > gotten bit by this plenty

Re: [HACKERS] Backpatching of "Teach the regular expression functions to do case-insensitive matching"

Robert Haas writes: > On the flip side, the risk of it flat-out blowing up seems pretty > small. For someone to invent their own version of wchar_t that uses > something other than Unicode code points would be pretty much pure > masochism, wouldn't it? Well, no, that's not clear. The C standard

Re: [HACKERS] Process wakeups when idle and power consumption

On 6 May 2011 15:00, Tom Lane wrote: > Peter Geoghegan writes: >> On 5 May 2011 21:05, Tom Lane wrote: >>> The major problem I'm aware of for getting rid of periodic wakeups is >>> the need for child processes to notice when the postmaster has died >>> unexpectedly. > >> Could you please expand

Re: [HACKERS] switch UNLOGGED to LOGGED

Robert Haas writes: > On Fri, May 6, 2011 at 10:25 PM, Robert Haas wrote: >> ERROR:  constraints on permanent tables may reference only permanent tables >> HINT:  constraint %s > Argh, hit send too soon. > HINT: constraint %s references table %s That looks like a DETAIL, not a HINT. Also see

Re: [HACKERS] Why not install pgstattuple by default?

Greg Stark writes: > On Fri, May 6, 2011 at 11:32 PM, Greg Smith wrote: >> I use pgstattuple, pageinspect, pg_freespacemap, and pg_buffercache >> regularly enough that I wish they were more common.  Throw in pgrowlocks and >> you've got the whole group Robert put into the debug set.  It makes me

Re: [HACKERS] Fix for pg_upgrade user flag

Robert Haas wrote: > On Sat, May 7, 2011 at 9:50 AM, Robert Haas wrote: > > On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian wrote: > >> The attached, applied patch checks that the pg_upgrade user specified is > >> a super-user. ?It also reports the error message when the post-pg_ctl > >> connection

Re: [HACKERS] Why not install pgstattuple by default?

On Fri, 06 May 2011 20:06:04 -, Tom Lane wrote: Bundling pg_config into a -libs package is probably not going to happen, at least not on Red Hat systems, because it would create multilib issues (ie, you're supposed to be able to install 32-bit and 64-bit libraries concurrently, but there's

Re: [HACKERS] patch for new feature: Buffer Cache Hibernation

On Sat, May 7, 2011 at 3:32 AM, Mitsuru IWASAKI wrote: > I have one more day for working on this, but I may give up... I think this is an interesting line of inquiry, but if you were hoping to get something committable in a couple of days, you had unrealistic expectations... -- Robert Haas Ente

Re: [HACKERS] Fix for pg_upgrade user flag

On Sat, May 7, 2011 at 9:50 AM, Robert Haas wrote: > On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian wrote: >> The attached, applied patch checks that the pg_upgrade user specified is >> a super-user.  It also reports the error message when the post-pg_ctl >> connection fails. >> >> This was prompt

Re: [HACKERS] Why not install pgstattuple by default?

On Sat, May 7, 2011 at 8:54 AM, Dimitri Fontaine wrote: > We've been talking about renaming contrib for a long time, but that will > not cut it.  Classifying it and agreeing to maintain some parts of it > the same way we maintain the core is what's asked here.  Is there a will > to go there? I'm

Re: [HACKERS] Fix for pg_upgrade user flag

On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian wrote: > The attached, applied patch checks that the pg_upgrade user specified is > a super-user.  It also reports the error message when the post-pg_ctl > connection fails. > > This was prompted by a private bug report from EnterpriseDB. It strikes m

Re: [HACKERS] time-delayed standbys

On Sat, Apr 23, 2011 at 9:46 PM, Jaime Casanova wrote: > On Tue, Apr 19, 2011 at 9:47 PM, Robert Haas wrote: >> >> That is, a standby configured such that replay lags a prescribed >> amount of time behind the master. >> >> This seemed easy to implement, so I did.  Patch (for 9.2, obviously) >> a

[HACKERS] Fix for pg_upgrade user flag

The attached, applied patch checks that the pg_upgrade user specified is a super-user. It also reports the error message when the post-pg_ctl connection fails. This was prompted by a private bug report from EnterpriseDB. -- Bruce Momjian http://momjian.us EnterpriseDB

Re: [HACKERS] Why not install pgstattuple by default?

Christopher Browne writes: > I don't expect the extension system to help with any of this, since if > "production folk" try to install minimal sets of packages, they're > liable to consciously exclude extension support. The "improvement" > would come from drawing contrib a bit closer to core, and