Christopher Browne cbbro...@gmail.com 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
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 br...@momjian.ushttp://momjian.us
On Sat, Apr 23, 2011 at 9:46 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Tue, Apr 19, 2011 at 9:47 PM, Robert Haas robertmh...@gmail.com 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.
On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian br...@momjian.us 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.
On Sat, May 7, 2011 at 8:54 AM, Dimitri Fontaine dimi...@2ndquadrant.fr 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
On Sat, May 7, 2011 at 9:50 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian br...@momjian.us 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
On Sat, May 7, 2011 at 3:32 AM, Mitsuru IWASAKI iwas...@jp.freebsd.org 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...
On Fri, 06 May 2011 20:06:04 -, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas wrote:
On Sat, May 7, 2011 at 9:50 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian br...@momjian.us wrote:
The attached, applied patch checks that the pg_upgrade user specified is
a super-user. ?It also reports the error message when
Greg Stark gsst...@mit.edu writes:
On Fri, May 6, 2011 at 11:32 PM, Greg Smith g...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com writes:
On Fri, May 6, 2011 at 10:25 PM, Robert Haas robertmh...@gmail.com 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
nitpick
That
On 6 May 2011 15:00, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan pe...@2ndquadrant.com writes:
On 5 May 2011 21:05, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com 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
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 of
Dne 7.5.2011 04:02, Robert Haas napsal(a):
2011/4/30 Tomas Vondra t...@fuzzy.cz:
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
Peter Geoghegan pe...@2ndquadrant.com 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
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 new
Bruce Momjian br...@momjian.us 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
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
stewardship board
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
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 1, 2011 at 5:48 PM, Bruce Momjian br...@momjian.us 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
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 of people.
On 7 May 2011 18:07, Tom Lane t...@sss.pgh.pa.us 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
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
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 in
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's
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 ~/.emacs,
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 time
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 installation
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 something
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
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 host-triplet-pg_config is
also built for use with external modules?
I'm not adverse to submit a
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]
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 the
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:
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-obvious
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
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.
http://archives.postgresql.org/pgsql-hackers/2011-05/msg00275.php
cheers
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 unusable by a
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.
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 why
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 user has
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 worth
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
Robert Haas wrote:
On Wed, Apr 6, 2011 at 5:17 PM, Tom Lane t...@sss.pgh.pa.us 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.
Andrew Dunstan wrote:
On 04/07/2011 11:01 AM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net 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
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
Peter Eisentraut pete...@gmx.net 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,
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
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
On Wed, Apr 6, 2011 at 5:17 PM, Tom Lane t...@sss.pgh.pa.us 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
51 matches
Mail list logo
