On ons, 2011-03-30 at 15:39 -0400, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > On ons, 2011-03-30 at 10:57 -0400, Bruce Momjian wrote:
> > > Also, I am unclear if this is really our bug. At least one of the
> > > systems was on Ubuntu/Debian, and they might both have been, and I know
> > >
On Wed, 2011-03-30 at 16:46 -0400, Robert Haas wrote:
> I don't really
> understand why this is an issue in the first place, though. Surely we
> must be setting the XID counter on the new cluster to match the one on
> the old cluster, and migrating the relfrozenxid and datfrozenxid
> settings, so
On Wed, Mar 30, 2011 at 10:57 AM, Bruce Momjian wrote:
> I think we have three options:
>
> o find if the use of autovacuum_freeze_max_age is safe, or make
> it safe
> o document that autovacuum_naptime always happens before
> autovacuum does anything and set it
Peter Eisentraut wrote:
> On ons, 2011-03-30 at 10:57 -0400, Bruce Momjian wrote:
> > Also, I am unclear if this is really our bug. At least one of the
> > systems was on Ubuntu/Debian, and they might both have been, and I know
> > Debian changes our source code. Where can I find a copy of the di
On ons, 2011-03-30 at 10:57 -0400, Bruce Momjian wrote:
> Also, I am unclear if this is really our bug. At least one of the
> systems was on Ubuntu/Debian, and they might both have been, and I know
> Debian changes our source code. Where can I find a copy of the diffs
> they have made?
http://ba
Alvaro Herrera wrote:
> Excerpts from Jeff Davis's message of mar mar 29 21:27:34 -0300 2011:
> > On Tue, 2011-03-29 at 15:52 -0400, Bruce Momjian wrote:
> > > Does anyone have any other suggestions on how to make sure autovacuum
> > > does not run in freeze mode?
> >
> > Can you run in single use
On Wed, Mar 30, 2011 at 4:56 PM, Heikki Linnakangas
wrote:
>> Attached patch reverts that. Comments?
>
> Looks good, committed.
Thanks!
> We could also improve the error message. If we haven't reached the
> end-of-backup location, we could say something along the lines of:
>
> ERROR: WAL ends be
On 30.03.2011 09:25, Fujii Masao wrote:
On Wed, Mar 30, 2011 at 11:39 AM, Fujii Masao wrote:
On Wed, Mar 30, 2011 at 12:54 AM, Heikki Linnakangas
wrote:
Hmm, why did we change that?
I'm not sure, but I guess that's because I missed the case where crash
recovery starts from the backup :(
On Wed, Mar 30, 2011 at 11:39 AM, Fujii Masao wrote:
> On Wed, Mar 30, 2011 at 12:54 AM, Heikki Linnakangas
> wrote:
>> Hmm, why did we change that?
>
> I'm not sure, but I guess that's because I missed the case where crash
> recovery starts from the backup :(
>
>> It seems like a mistake, the da
On Wed, Mar 30, 2011 at 12:54 AM, Heikki Linnakangas
wrote:
> Hmm, why did we change that?
I'm not sure, but I guess that's because I missed the case where crash
recovery starts from the backup :(
> It seems like a mistake, the database is not
> consistent until you reach the backup stop locatio
On Tue, 2011-03-29 at 21:43 -0300, Alvaro Herrera wrote:
> I think it would be better to have
> some sort of option to disable autovacuum completely which would be used
> only during pg_upgrade.
Sounds reasonable to me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql
Excerpts from Jeff Davis's message of mar mar 29 21:27:34 -0300 2011:
> On Tue, 2011-03-29 at 15:52 -0400, Bruce Momjian wrote:
> > Does anyone have any other suggestions on how to make sure autovacuum
> > does not run in freeze mode?
>
> Can you run in single user mode?
I asked the same thing.
On Tue, 2011-03-29 at 15:52 -0400, Bruce Momjian wrote:
> Does anyone have any other suggestions on how to make sure autovacuum
> does not run in freeze mode?
Can you run in single user mode?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
I have gotten two reports via IRC that months after using 9.0
pg_upgrade, some of the clog files have been removed while there is
still data in the table needing those clog files. These reports came to
me through Rhodiumtoad who analyzed the systems.
Looking at pg_upgrade, I am concerned that som
On 29.03.2011 14:27, Fujii Masao wrote:
On Tue, Mar 29, 2011 at 6:46 PM, hubert depesz lubaczewski
wrote:
Did you use recovery.conf to start standalone PostgreSQL? If not,
recovery doesn't check whether it reaches the recovery ending position
or not. So I guess no problem didn't happen.
no,
hubert depesz lubaczewski wrote:
> it worked. now the slave2 is working as stand alone.
>
> what does it tell us? will any work happening after checkpoint
> break it anyway?
I'm less sure about what will put it into a bad state again than I
was that an immediate checkpoint would put you into
On Tue, Mar 29, 2011 at 6:46 PM, hubert depesz lubaczewski
wrote:
>> Did you use recovery.conf to start standalone PostgreSQL? If not,
>> recovery doesn't check whether it reaches the recovery ending position
>> or not. So I guess no problem didn't happen.
>
> no, i don't use.
>
> hmm .. i am near
On Tue, Mar 29, 2011 at 11:13:07AM +0900, Fujii Masao wrote:
> Yes, it's intentional. In streaming replication, at first the master must
> stream
> a backup history file to the standby in order to let it know the recovery
> ending
> position. But streaming replication doesn't have ability to send
On Tue, Mar 29, 2011 at 11:20:48AM +0900, Fujii Masao wrote:
> On Tue, Mar 29, 2011 at 12:11 AM, hubert depesz lubaczewski
> wrote:
> > On Mon, Mar 28, 2011 at 01:48:13PM +0900, Fujii Masao wrote:
> >> In 9.0, recovery doesn't read a backup history file. That FATAL error
> >> happens
> >> if reco
On Mon, Mar 28, 2011 at 05:29:22PM -0500, Kevin Grittner wrote:
> I have a theory. Can you try it in what would be the failure case,
> but run an explicit a CHECKPOINT on the master, wait for
> pg_controldata to show that checkpoint on the slave, and (as soon as
> you see that) try to trigger the
On Tue, Mar 29, 2011 at 12:11 AM, hubert depesz lubaczewski
wrote:
> On Mon, Mar 28, 2011 at 01:48:13PM +0900, Fujii Masao wrote:
>> In 9.0, recovery doesn't read a backup history file. That FATAL error happens
>> if recovery ends before it reads the WAL record which was generated by
>> pg_stop_ba
On Mon, Mar 28, 2011 at 9:19 PM, hubert depesz lubaczewski
wrote:
> On Mon, Mar 28, 2011 at 01:48:13PM +0900, Fujii Masao wrote:
>> In 9.0, recovery doesn't read a backup history file. That FATAL error happens
>> if recovery ends before it reads the WAL record which was generated by
>> pg_stop_bac
On Mon, Mar 28, 2011 at 05:43:15PM -0500, Kevin Grittner wrote:
> hubert depesz lubaczewski wrote:
>
> > have you seen this mail -
> > http://archives.postgresql.org/pgsql-hackers/2011-03/msg01490.php
>
> One more thing: Am I correct in understanding that you are trying to
> do a PITR-style ba
On Mon, Mar 28, 2011 at 05:29:22PM -0500, Kevin Grittner wrote:
> hubert depesz lubaczewski wrote:
>
> > have you seen this mail -
> > http://archives.postgresql.org/pgsql-hackers/2011-03/msg01490.php
>
> Ah, OK.
>
> I have a theory. Can you try it in what would be the failure case,
> but r
hubert depesz lubaczewski wrote:
> have you seen this mail -
> http://archives.postgresql.org/pgsql-hackers/2011-03/msg01490.php
One more thing: Am I correct in understanding that you are trying to
do a PITR-style backup without using pg_start_backup() and
pg_stop_backup()? If so, why?
-Kev
hubert depesz lubaczewski wrote:
> have you seen this mail -
> http://archives.postgresql.org/pgsql-hackers/2011-03/msg01490.php
Ah, OK.
I have a theory. Can you try it in what would be the failure case,
but run an explicit a CHECKPOINT on the master, wait for
pg_controldata to show that ch
On Mon, Mar 28, 2011 at 04:53:37PM -0500, Kevin Grittner wrote:
> hubert depesz lubaczewski wrote:
> > On Mon, Mar 28, 2011 at 04:24:23PM -0500, Kevin Grittner wrote:
> >> hubert depesz lubaczewski wrote:
> >>
> >>> how come that I can use this backup to make standalone pg, and
> <<< it starts
hubert depesz lubaczewski wrote:
> On Mon, Mar 28, 2011 at 04:24:23PM -0500, Kevin Grittner wrote:
>> hubert depesz lubaczewski wrote:
>>
>>> how come that I can use this backup to make standalone pg, and
<<< it starts without any problem, but when I start it as sr slave,
>>> let it run for som
On Mon, Mar 28, 2011 at 04:24:23PM -0500, Kevin Grittner wrote:
> hubert depesz lubaczewski wrote:
>
> > how come that I can use this backup to make standalone pg, and it
> > starts without any problem, but when I start it as sr slave, let
> > it run for some time, and then promote to standalone
hubert depesz lubaczewski wrote:
> how come that I can use this backup to make standalone pg, and it
> starts without any problem, but when I start it as sr slave, let
> it run for some time, and then promote to standalone, it breaks?
We need more detail to make much of a guess about that.
-
On Mon, Mar 28, 2011 at 01:48:13PM +0900, Fujii Masao wrote:
> In 9.0, recovery doesn't read a backup history file. That FATAL error happens
> if recovery ends before it reads the WAL record which was generated by
> pg_stop_backup(). IOW, recovery gets the recovery ending location from WAL
> record
On Mon, Mar 28, 2011 at 01:48:13PM +0900, Fujii Masao wrote:
> In 9.0, recovery doesn't read a backup history file. That FATAL error happens
> if recovery ends before it reads the WAL record which was generated by
> pg_stop_backup(). IOW, recovery gets the recovery ending location from WAL
> record
On Mon, Mar 28, 2011 at 12:48 AM, Fujii Masao wrote:
> If you want to take hot backup from the standby, you need to do the procedure
> explained in
> http://wiki.postgresql.org/wiki/Incrementally_Updated_Backups
It'd be nice to improve this in 9.2. Relying on users to get this
just right seems b
On Sat, Mar 26, 2011 at 5:31 AM, hubert depesz lubaczewski
wrote:
> I can also setup streaming slave, and it also works, but when I create
> trigger file to promote this slave to master it fails with error:
> 2011-03-24 21:01:58.051 CET @ 9680 LOG: trigger file found:
> /home/depesz/slave2/fini
hi,
So, I hit a strange problem with Streaming Replication, that I cannot explain.
Executive summary:
when using hot backup made on straming replication slave, sometimes
(depending on load) generated backup is created in such a way, that while it
can be brough back as standalone Pg, and it can b
Robert Treat wrote:
> On Mon, Feb 28, 2011 at 3:42 AM, Magnus Hagander wrote:
> > On Mon, Feb 28, 2011 at 06:21, Tom Lane wrote:
> >> Robert Treat writes:
> >>> Did anything ever come of this discussion?
> >>
> >> I think it's a TODO --- nothing done about it as yet, AFAIR.
> >>
> >>> On one of
Thank you! now I understand it...
On Wed, Mar 2, 2011 at 7:35 PM, Tom Lane wrote:
> Marios Vodas writes:
> > I have developed some custom composite and base types in PostgreSQL 9
> which
> > you can find in the code I provide below.
> > I compile my C library using GCC 4.5 under Linux and Visua
Marios Vodas writes:
> I have developed some custom composite and base types in PostgreSQL 9 which
> you can find in the code I provide below.
> I compile my C library using GCC 4.5 under Linux and Visual Studio 2010
> under Windows.
> The problem is when I run this command: *SELECT to_composite(
I have developed some custom composite and base types in PostgreSQL 9 which
you can find in the code I provide below.
I compile my C library using GCC 4.5 under Linux and Visual Studio 2010
under Windows.
The problem is when I run this command: *SELECT to_composite('((1, 2), (3,
4))'::m_segment_ba
On Mon, Feb 28, 2011 at 3:42 AM, Magnus Hagander wrote:
> On Mon, Feb 28, 2011 at 06:21, Tom Lane wrote:
>> Robert Treat writes:
>>> Did anything ever come of this discussion?
>>
>> I think it's a TODO --- nothing done about it as yet, AFAIR.
>>
>>> On one of the databases I
>>> was upgrading, I
On Mon, Feb 28, 2011 at 06:21, Tom Lane wrote:
> Robert Treat writes:
>> Did anything ever come of this discussion?
>
> I think it's a TODO --- nothing done about it as yet, AFAIR.
>
>> On one of the databases I
>> was upgrading, I ran into a similar problem with roles that are set as
>> roles. T
Robert Treat writes:
> Did anything ever come of this discussion?
I think it's a TODO --- nothing done about it as yet, AFAIR.
> On one of the databases I
> was upgrading, I ran into a similar problem with roles that are set as
> roles. The problem seems to stem from pg_dumpall dumping roles in
On Thu, Jan 6, 2011 at 10:08 PM, Bruce Momjian wrote:
> 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 buggin
On 02/03/2011 04:45 PM, Robert Haas wrote:
> Your data modem is probably doing something funky to your network
> stack, but I don't know what.
Are other network services affected as well? In that case, I'd file a
bug against the modem driver software.
Regards
Markus Wanner
--
Sent via pgsql-h
2011/1/31 Jürgen Wolfsgruber :
> Trying to start a telnet-connection, the result was:
>
> telnet 127.0.0.1 5432
> Trying 127.0.0.1...
> telnet: connect to address 127.0.0.1: Operation timed out
> telnet: Unable to connect to remote host
That's just bizarre. How can you get a network timeout over
Hello,
I discussed my problem at www.pg-forum.de with Mr. Scherbaum (ADS) and he
recommended me to inform you about this problem.
I worked on my Mac-Book (Mac OS X 10.6.6) with postgresql database version 9
(postgresql-9.0.1-1-osx.dmg). After installing and connecting my HUAWEI E122
data mode
Tom Lane wrote:
> "Kevin Grittner" writes:
> > Anyone else seeing anything like this on `make world`?
>
> Looks like Bruce didn't bother to test that before committing. Fixed.
Thanks. I built is several times that displayed fine, but I now see
that it throws a warning when built. Thanks for th
"Kevin Grittner" writes:
> Anyone else seeing anything like this on `make world`?
Looks like Bruce didn't bother to test that before committing. Fixed.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
Anyone else seeing anything like this on `make world`?
make[3]: Entering directory
`/home/kgrittn/git/postgresql/kgrittn/doc/src/sgml'
{ \
echo ""; \
echo ""; \
} > version.sgml
"/usr/bin/perl" ./mk_feature_tables.pl YES
../../../src/backend/catalog/sql_feature_package
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
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
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.
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
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 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 straight face.
In the FOREIGN KEY N
On 01/05/2011 11:08 PM, Tom Lane wrote:
If they want to deliberately shoot themselves in the foot by hosing the
login system like that, it's not our job to prevent it. But it's not
our job to try to work around it, either.
I think this is especially true in this cas
Tom Lane wrote:
> Robert Haas writes:
> > 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.
>
> > If adding RESET SES
Robert Haas writes:
> 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.
> If adding RESET SESSION AUTHORIZATION fixes the b
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.
>
> If adding RESET SESSION AUTHORIZATION fixes th
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.
If adding RESET SESSION AUTHORIZATION fixes the bug, I think we should
consid
Florian Pflug wrote:
> Hi
>
> I've just ran into a problem while upgrading from 8.4 to 9.0.
>
> pg_upgrade aborted during the step "Adding support functions to new
> cluster" with "ERROR: permission denied for language c" error.
> Unfortunately, the log didn't include the name of the database wh
On Dec13, 2010, at 16:40 , Tom Lane wrote:
> Florian Pflug writes:
>> On Dec13, 2010, at 00:16 , Robert Haas wrote:
>>> And in fact it strikes me that we might not have much choice about how
>>> to fix this. I think we are not going to retroactively change the
>>> behavior of ALTER DATABASE .. SE
Florian Pflug writes:
> On Dec13, 2010, at 00:16 , Robert Haas wrote:
>> And in fact it strikes me that we might not have much choice about how
>> to fix this. I think we are not going to retroactively change the
>> behavior of ALTER DATABASE .. SET ROLE in a released version, but yet
>> we do, I
On Dec13, 2010, at 00:16 , Robert Haas wrote:
> And in fact it strikes me that we might not have much choice about how
> to fix this. I think we are not going to retroactively change the
> behavior of ALTER DATABASE .. SET ROLE in a released version, but yet
> we do, I think, want to make pg_upgra
On Sun, Dec 12, 2010 at 11:01 AM, Tom Lane wrote:
> This is about like arguing that pg_dump and pg_upgrade should still work
> after you've done "delete from pg_proc;". Superusers are assumed to
> know what they're doing and not break fundamental operations.
No, it isn't like that at all. You'v
On Dec12, 2010, at 17:01 , Tom Lane wrote:
> Florian Pflug writes:
>> pg_upgrade aborted during the step "Adding support functions to new cluster"
>> with "ERROR: permission denied for language c" error. Unfortunately, the
>> log didn't include the name of the database where the error occurred,
Florian Pflug writes:
> pg_upgrade aborted during the step "Adding support functions to new cluster"
> with "ERROR: permission denied for language c" error. Unfortunately, the log
> didn't include the name of the database where the error occurred, so it took
> me a while to figure out that the
Hi
I've just ran into a problem while upgrading from 8.4 to 9.0.
pg_upgrade aborted during the step "Adding support functions to new cluster"
with "ERROR: permission denied for language c" error. Unfortunately, the log
didn't include the name of the database where the error occurred, so it too
Bruce Momjian wrote:
> Win32 buildfarm members are red because of my inet_pton changes. I will
> look into this in the next day, and also improve how we include C files
> from /port for libpq.
OK, I have accomplished both goals with the two attached, applied
patches.
--
Bruce Momjian
Win32 buildfarm members are red because of my inet_pton changes. I will
look into this in the next day, and also improve how we include C files
from /port for libpq.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossi
Lane
Sent: Monday, August 23, 2010 7:06 PM
To: Eric Simon
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Problem Using PQcancel in a Synchronous Query
"Eric Simon" writes:
> Now that I've established some context, here's where I'm at: I've written
>
"Eric Simon" writes:
> Now that I've established some context, here's where I'm at: I've written
> $sth->cancel() for DBD::Pg using PQcancel(), and it works (it returns the
> status 57014: QUERY CANCELED). The problem is that the $sth->execute call
> (which resides between the two alarm() calls a
Hi,
I am using Perl (DBD::Pg) with Postgres. DBD::Pg already fully supports
asynchronous queries, and the canceling of those queries, but I need to
cancel a synchronous query. So to do that, I am trying to write
$sth->cancel() support for DBD::Pg. Here's my example in Perl:
my $aborted
Pei He wrote:
> The extension functions was developed by C++ mixed with C.
> ERROR: incompatible library
> "/home/hepei/bin/Chameleon/lib/libspgist_trie.so": missing magic block
> HINT: Extension libraries are required to use the PG_MODULE_MAGIC macro.
You can use extern "C" blocks for PG_MOD
Hi,
I have some old code for extension functions in Postgres 8.0. And, I
am trying to make it work with Postgres 8.2.
One problem is about the Magic Block.
The extension functions was developed by C++ mixed with C.
The code is like:
extern "C" Datum spgistinsert(PG_FUNCTION_ARGS)
{
...
}
I have
fanng yuan wrote:
> I just do some research on ip address storage and comparing. I
> found pgsql already fixed that issue. I want to get some point from
> your guys about how this work.
I'm not sure what you're looking for, exactly. Does this page help?:
http://www.postgresql.org/docs/8.4/i
Hi Guys:
I just do some research on ip address storage and comparing. I found pgsql
already fixed that issue. I want to get some point from your guys about how
this work. Could you give me some data about that . Also I'm interesting in
pgsql . Could you give me some suggestion about how to hack pgs
> This would guarantee that autovacuum is fired no later than
> autovacuum_naptime after the condition for the run became true.
Of course, this unfortunately not true... The guarantee is 1,5x
autovacuum_naptime. But I'd be happy with it but I agree that's not what
I'd as a user expect from this
> well, my current opinion is that we should spend some nonzero amount
> of thought into figuring out what to do.
I'd suggest to do it like this:
Do autovac_refresh_stats() once per autovacuum_naptime/2 and share the
result among all autovacuum workers.
This would guarantee that autovacuum is
Tom Lane wrote:
> Alvaro Herrera writes:
> > Jakub Ouhrabka wrote:
> >> Was autovacuum requesting to write this 20MB file 650x per minute?
>
> > Yes, exactly.
>
> > Ideally, autovacuum would only request a new copy of the file if the one
> > it got was considerably out of date. Obviously a tent
Alvaro Herrera writes:
> Jakub Ouhrabka wrote:
>> Was autovacuum requesting to write this 20MB file 650x per minute?
> Yes, exactly.
> Ideally, autovacuum would only request a new copy of the file if the one
> it got was considerably out of date. Obviously a tenth of a second is
> not old enoug
Jakub Ouhrabka wrote:
> > Ideally, autovacuum would only request a new copy of the file if the
> > one it got was considerably out of date. Obviously a tenth of a
> > second is not old enough.
>
> I've tried to look at it and found that's already implemented - see
> autovac_refresh_stats(). STATS
> Ideally, autovacuum would only request a new copy of the file if the
> one it got was considerably out of date. Obviously a tenth of a
> second is not old enough.
I've tried to look at it and found that's already implemented - see
autovac_refresh_stats(). STATS_READ_DELAY which is set to 1s.
Jakub Ouhrabka wrote:
> > Maybe you should decrease naptime a bit.
>
> That did the trick, thanks!
>
> > Yes. There were some changes that needed to be done to autovacuum so
> > that it didn't read the stats file too often, but I don't recall if I
> > got around to it.
>
> I looked at the strac
> Maybe you should decrease naptime a bit.
That did the trick, thanks!
> Yes. There were some changes that needed to be done to autovacuum so
> that it didn't read the stats file too often, but I don't recall if I
> got around to it.
I looked at the strace output and there are *writes* to the
Jakub Ouhrabka escreveu:
> These databases are archive databases, so there is no user activity - no
> connected users. But the stats collector generates load - 20-40% of
> modern 2.8GHz core all the time.
>
Did you try to set stats_temp_directory in a RAM based filesystem?
> Any clues what does i
Jakub Ouhrabka wrote:
> > You might want to try setting log_autovacuum_min_duration=0 in the
> > postgresql.conf
>
> Thanks, tried it. There is nothing in the log - the actual
> vacuum/analyze commands are not run (as there is no query activity).
> I suspect that autovacuum is checking each databa
> You might want to try setting log_autovacuum_min_duration=0 in the
> postgresql.conf
Thanks, tried it. There is nothing in the log - the actual
vacuum/analyze commands are not run (as there is no query activity). I
suspect that autovacuum is checking each database if it should run - and
deci
Jakub Ouhrabka wrote:
I've found similar reports but with older versions of postgres:
http://old.nabble.com/100--of-CPU-utilization-postgres-process-tt27302021.html
Those all looked like a FreeBSD issue, doubt it's related to yours.
The pgstat.stat is ~20MB. There are 650 databases, 140GB t
Hi,
sorry for repost but previous message didn't get through. So I'm trying
another list and sending without attachment which I can send privately
upon request (strace output mentioned below).
We've migrated some of our databases to 8.4 cluster (from 8.2 and older
versions).
These database
2010/1/25 Magnus Hagander :
> 2010/1/25 Josh Berkus :
>> On 1/25/10 7:47 AM, Pavel Stehule wrote:
>>> Hello
>>>
>>> I can't to create module on pgfoundry. It is probably access denied
>>> problem. Can somebody help me with this?
>>>
>>> [pa...@nemesis pstcoll]$ cvs -d
>>> :ext:ok...@cvs.pgfoundry.
2010/1/25 Josh Berkus :
> On 1/25/10 7:47 AM, Pavel Stehule wrote:
>> Hello
>>
>> I can't to create module on pgfoundry. It is probably access denied
>> problem. Can somebody help me with this?
>>
>> [pa...@nemesis pstcoll]$ cvs -d
>> :ext:ok...@cvs.pgfoundry.org:/cvsroot/pstcollection import pst
On 1/25/10 7:47 AM, Pavel Stehule wrote:
> Hello
>
> I can't to create module on pgfoundry. It is probably access denied
> problem. Can somebody help me with this?
>
> [pa...@nemesis pstcoll]$ cvs -d
> :ext:ok...@cvs.pgfoundry.org:/cvsroot/pstcollection import pstcoll
> no-vendor initial-releas
Hello
I can't to create module on pgfoundry. It is probably access denied
problem. Can somebody help me with this?
[pa...@nemesis pstcoll]$ cvs -d
:ext:ok...@cvs.pgfoundry.org:/cvsroot/pstcollection import pstcoll
no-vendor initial-release
Password:
Cannot access /cvsroot/pstcollection/CVSROOT
Sergej Galkin writes:
> I realized my own gist index, and now I want to debug it :)
I used Gevel for that:
http://www.sai.msu.su/~megera/wiki/Gevel
Regards,
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgre
201 - 300 of 1070 matches
Mail list logo
