On Wed, 2011-01-05 at 22:05 -0500, Bruce Momjian wrote:
Robert Haas wrote:
On Mon, Dec 13, 2010 at 12:59 AM, Rob Wultsch wult...@gmail.com wrote:
On Sun, Dec 12, 2010 at 7:24 PM, Andrew Dunstan and...@dunslane.net
wrote:
In fact it's possible now to disable FK enforcement, by
On 06.01.2011 00:27, Dimitri Fontaine wrote:
Magnus Hagandermag...@hagander.net writes:
What about pg_streamrecv | gzip …, which has the big advantage of
That's part of what I meant with easier and more useful.
Well…
One thing to keep in mind is that if you do compression in libpq for
On Jan6, 2011, at 04:13 , Bruce Momjian wrote:
Robert Haas wrote:
On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian br...@momjian.us wrote:
I think pg_dumpall would have failed with this setup too, so I don't see
this as a pg_upgrade bug, nor something that I am willing to risk adding
to
On Jan6, 2011, at 05:08 , Tom Lane wrote:
I think an appropriate response would be to prevent ALTER DATABASE SET
ROLE. I really cannot believe that there are any situations where
that's a good idea.
I explained up-thread why, in my situation, doing this *is* a perfectly
good idea. You have
On Wed, Jan 5, 2011 at 23:58, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
* Stefan mentiond it might be useful to put some
posix_fadvise(POSIX_FADV_DONTNEED)
in the process that streams all the files out. Seems useful, as long as
that
doesn't kick them out of the cache *completely*,
2011/1/6 KaiGai Kohei kai...@ak.jp.nec.com:
1. Why is sepgsql the right name for this module, as opposed to, say,
selinux? We don't call the cube module cubepgsql, or the hstore
module hstorepgsql. Maybe there's a reason why this case is
different, but I'm not sure.
In some previous cases
Have a look at
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=ravendt=2011-01-05%2001%3A30%3A12
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=currawongdt=2011-01-06%2002%3A30%3A01
I recall seeing a couple of similar failures in the past few weeks but
can't dredge them up at the
I wrote:
Have a look at
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=ravendt=2011-01-05%2001%3A30%3A12
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=currawongdt=2011-01-06%2002%3A30%3A01
Anybody have any idea what's causing that?
Oh, never mind. The failure mechanism is
Do not know if this mail got lost in between or no one noticed it!
On Thu, 2010-12-23 at 11:05 +0530, Sushant Sinha wrote:
Just a reminder that this patch is discussing how to break url, emails
etc into its components.
On Mon, Oct 4, 2010 at 3:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
On Wed, Jan 5, 2011 at 23:27, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Magnus Hagander mag...@hagander.net writes:
Well, I would guess that if you're streaming the WAL files in parallel
while the base backup is taken, then you're able to have it all without
archiving setup, and the
On Thu, January 6, 2011 12:54, Itagaki Takahiro wrote:
Here is an updated patch for MULTISET functions support.
There seem to be some faulty line-endings in arrays.out that break the arrays
test (on x86_64
Centos 5.4). make, make check were OK after I removed these (3 lines, from
line 1370).
Whilst fooling around with GIN, I have repeatedly observed that doing
make in src/backend/access/gin, followed by make install-bin in
src/backend, fails to rebuild the postgres executable --- it just
installs the existing one. A second execution of make install-bin
does notice that postgres is
On Thu, 2011-01-06 at 09:30 +0900, Hitoshi Harada wrote:
Robert Haas originally began to propose the idea of type
interface to get together three of KNN-GIST, range type and window
frame issue. For KNN-GIST, it was committed by extending pg_amop
without considering others and range type will
On Thu, Jan 6, 2011 at 11:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Whilst fooling around with GIN, I have repeatedly observed that doing
make in src/backend/access/gin, followed by make install-bin in
src/backend, fails to rebuild the postgres executable --- it just
installs the existing one.
On Wed, 2011-01-05 at 12:07 -0800, Jeff Davis wrote:
The current design for range types doesn't ask for add or subtract.
Although it might be interesting to try to use such an interface for
range types, it introduces a lot of complexity and makes it easier to
cause subtle problems (consider
On Thu, Jan 6, 2011 at 12:32 PM, Jeff Davis pg...@j-davis.com wrote:
On Wed, 2011-01-05 at 12:07 -0800, Jeff Davis wrote:
The current design for range types doesn't ask for add or subtract.
Although it might be interesting to try to use such an interface for
range types, it introduces a lot of
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 6, 2011 at 11:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Whilst fooling around with GIN, I have repeatedly observed that doing
make in src/backend/access/gin, followed by make install-bin in
src/backend, fails to rebuild the postgres
Florian Pflug wrote:
On Jan6, 2011, at 04:13 , Bruce Momjian wrote:
Robert Haas wrote:
On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian br...@momjian.us wrote:
I think pg_dumpall would have failed with this setup too, so I don't see
this as a pg_upgrade bug, nor something that I am willing
Robert Haas wrote:
On Wed, Jan 5, 2011 at 11:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Or we could take the approach somebody was just espousing about
Our job is to prevent the user from *accidentally*
shooting themselves in the foot.
I don't see how you can compare those two cases
Peter Eisentraut wrote:
I have often found myself wanting that psql automatically switch between
normal and \x mode depending on the width of the output. Would others
find this useful?
Attached is a crude demo patch. Enable with \pset expanded auto.
It is a TODO:
Add
Greetings,
Looking at discard all, I was a bit suprised that 'DISCARD PLANS;'
doesn't clear out cached stored procedures. To be honest, that's one
of the main reasons I'd see to use it. I thought there had been some
discussion in the archives related to invalidating stored procedure
On Thu, Jan 6, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote:
Well, if everyone who logs in gets the same username, you can easily
conclude that trying to dump/restore the database will cause problems if
you have objects in there that are not owned by that user.
I can't, and neither
Robert Haas wrote:
On Thu, Jan 6, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote:
Well, if everyone who logs in gets the same username, you can easily
conclude that trying to dump/restore the database will cause problems if
you have objects in there that are not owned by that user.
On Thu, Jan 6, 2011 at 3:54 PM, Bruce Momjian br...@momjian.us wrote:
Well, we usually tell people to restore as super-user, particularly
pg_dumpall, but in this case, it is impossible. Certainly pg_upgrade
requires it, which is the root of the problem.
True. Although it's not really
On Thu, Jan 6, 2011 at 3:20 PM, Stephen Frost sfr...@snowman.net wrote:
Greetings,
Looking at discard all, I was a bit suprised that 'DISCARD PLANS;'
doesn't clear out cached stored procedures. To be honest, that's one
of the main reasons I'd see to use it. I thought there had been some
On Thu, Dec 9, 2010 at 2:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Gurjeet Singh singh.gurj...@gmail.com writes:
But I still hold a bias towards renaming the index to match constraint
name
(with a NOTICE), rather than require that the constraint name match the
index name, because the
* Merlin Moncure (mmonc...@gmail.com) wrote:
this is a problem. under what circumstances would you want to discard
them and why? the main problem I see with cached plpgsql plans is
interactions with search_path -- but DISCARD might not be the best way
to attack that problem. There might be
On Thu, Jan 6, 2011 at 4:30 PM, Stephen Frost sfr...@snowman.net wrote:
* Merlin Moncure (mmonc...@gmail.com) wrote:
this is a problem. under what circumstances would you want to discard
them and why? the main problem I see with cached plpgsql plans is
interactions with search_path -- but
* Merlin Moncure (mmonc...@gmail.com) wrote:
this has been discussed a couple of times -- a plausible alternative
might be to adjust the plan caching mechanism to organize the plan
cache around search_path. that way you get a separate plan per
search_path instance.
That would certainly be
On Thu, Jan 6, 2011 at 5:22 PM, Stephen Frost sfr...@snowman.net wrote:
If it's performance vs. correctness, you can guess what I'm going to
vote for, however, in this case, I can't see how either of the other
options would perform better than a discard-like approach. If people
are already
On 05.01.2011 15:54, Magnus Hagander wrote:
Attached is an updated streaming base backup patch, based off the work
that Heikki started.
...
I've implemented a frontend for this in pg_streamrecv, based on the assumption
that we wanted to include this in bin/ for 9.1 - and that it seems like a
On Thu, Jan 6, 2011 at 23:57, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 05.01.2011 15:54, Magnus Hagander wrote:
Attached is an updated streaming base backup patch, based off the work
that Heikki started.
...
I've implemented a frontend for this in pg_streamrecv, based
2011/1/5 Magnus Hagander mag...@hagander.net:
On Wed, Jan 5, 2011 at 22:58, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Magnus Hagander mag...@hagander.net writes:
* Stefan mentiond it might be useful to put some
posix_fadvise(POSIX_FADV_DONTNEED)
in the process that streams all the
On Thu, 2011-01-06 at 13:53 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 6, 2011 at 11:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Whilst fooling around with GIN, I have repeatedly observed that doing
make in src/backend/access/gin, followed by make install-bin
On Wed, 2011-01-05 at 14:54 +0100, Magnus Hagander wrote:
The basic implementation is: Add a new command to the replication mode called
BASE_BACKUP, that will initiate a base backup, stream the contents (in tar
compatible format) of the data directory and all tablespaces, and then end
the
Greetings hackers!
I've renamed the project fsnapshot to pov, PostgreSQL Object Version
control system. :)
I've also created a quite nifty SQL command line based utility to
perform graph/tree sorting algorithms on data in the database, without
the need to export the data to some external
bruce wrote:
Robert Haas wrote:
On Thu, Jan 6, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote:
Well, if everyone who logs in gets the same username, you can easily
conclude that trying to dump/restore the database will cause problems if
you have objects in there that are not
2. The docs contains some references to /usr/local/pgsql/share.. Does
this really mean whatever sharedir you established when you ran
configure, i.e. the output of pg_config --sharedir? I hope so.
Yes, it means the sharedir being configured.
I found the following description at the
2011/1/6 KaiGai Kohei kai...@ak.jp.nec.com:
If we use result of the `pg_config --sharedir` here, how about this
writing style? Or, do we have any other ideas?
I'm not sure - I'll look at your next draft more closely.
The background of this wikipage is that I was persuading people
this
Bruce Momjian br...@momjian.us writes:
We could modify pg_dump to emit RESET AUTHORIZATION in --binary-upgrade
mode. I am unclear if that might cause some other problems though.
I finally figured out what was really bugging me about that proposal:
it's a one-shot hack for fixing one problem
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
We could modify pg_dump to emit RESET AUTHORIZATION in --binary-upgrade
mode. I am unclear if that might cause some other problems though.
I finally figured out what was really bugging me about that proposal:
it's a one-shot hack for
On Wed, Jan 5, 2011 at 02:48, Simon Riggs si...@2ndquadrant.com wrote:
The way I coded it was a new SRF that joins to the existing
pg_stat_activity. So no initdb required, and this can also easily be
included as an external module for 9.0.
Please notice also that my coding of the new SRF does
Em 06-01-2011 21:31, Tom Lane escreveu:
I think I like option #2 better. Comments?
+1.
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Robert Treat wrote:
This is a great use case for user level tracing support. Add a probe
around these bits, and you can capture the information when you need
it.
Sure. I would also like a pony.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training,
Josh Berkus wrote:
Or should it perhaps be a per-table counter in pg_stat_user_tables,
given your statement above?
Or even a timestamp: last_autovacuum_attempt, which would record the
last time autovacuum was tried. If that's fairly recent and you have a
large number of dead rows, you
45 matches
Mail list logo
