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 kno
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, Serv
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:
http://www.postgresql.org/mailpref/pgsq
On Wed, Jan 5, 2011 at 02:48, Simon Riggs 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 not have the O^2
Tom Lane wrote:
> Bruce Momjian 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 o
Bruce Momjian 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 that could arise
2011/1/6 KaiGai Kohei :
> 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 feature being worthful,
>>> 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 descri
bruce wrote:
> Robert Haas wrote:
> > On Thu, Jan 6, 2011 at 1:59 PM, Bruce Momjian 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
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 applicat
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
On Thu, 2011-01-06 at 13:53 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Jan 6, 2011 at 11:57 AM, Tom Lane 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
2011/1/5 Magnus Hagander :
> On Wed, Jan 5, 2011 at 22:58, Dimitri Fontaine wrote:
>> Magnus Hagander writes:
>>> * 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
>>> d
On Thu, Jan 6, 2011 at 23:57, Heikki Linnakangas
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 on the
>> assumption
>>
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
reas
On Thu, Jan 6, 2011 at 5:22 PM, Stephen Frost 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 using 'discar
* 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 4:30 PM, Stephen Frost 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 DISCARD might n
* 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 b
On Thu, Dec 9, 2010 at 2:48 PM, Tom Lane wrote:
> Gurjeet Singh 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 constraint name is optional and when i
On Thu, Jan 6, 2011 at 3:20 PM, Stephen Frost 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
> discussion
On Thu, Jan 6, 2011 at 3:54 PM, Bruce Momjian 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 impossible, it just r
Robert Haas wrote:
> On Thu, Jan 6, 2011 at 1:59 PM, Bruce Momjian 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'
On Thu, Jan 6, 2011 at 1:59 PM, Bruce Momjian 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 could Florian.
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
pl
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 auto-exp
Robert Haas wrote:
> On Wed, Jan 5, 2011 at 11:08 PM, Tom Lane 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 with a st
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 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 r
Robert Haas writes:
> On Thu, Jan 6, 2011 at 11:57 AM, Tom Lane 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 t
On Thu, Jan 6, 2011 at 12:32 PM, Jeff Davis 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 complexity
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 11:57 AM, Tom Lane 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. A second
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 wil
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
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).
On Wed, Jan 5, 2011 at 23:27, Dimitri Fontaine wrote:
> Magnus Hagander 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 server could still recycling them.
>
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 wrote:
> [ sorry for no
I wrote:
> Have a look at
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=raven&dt=2011-01-05%2001%3A30%3A12
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=currawong&dt=2011-01-06%2002%3A30%3A01
> Anybody have any idea what's causing that?
Oh, never mind. The failure mechanism
Have a look at
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=raven&dt=2011-01-05%2001%3A30%3A12
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=currawong&dt=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 m
2011/1/6 KaiGai Kohei :
>> 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 when SELin
On Wed, Jan 5, 2011 at 23:58, Dimitri Fontaine 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*, for other back
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 Jan6, 2011, at 04:13 , Bruce Momjian wrote:
> Robert Haas wrote:
>> On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian 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 pg_upgrade.
>
On 06.01.2011 00:27, Dimitri Fontaine wrote:
Magnus Hagander 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 the
transfer, and
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 wrote:
> > > On Sun, Dec 12, 2010 at 7:24 PM, Andrew Dunstan
> > > wrote:
> > >> In fact it's possible now to disable FK enforcement, by disabling the
> > >> triggers. I
45 matches
Mail list logo
