Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> No, it isn't. Please add a TODO item about it:
> * Prevent long-lived temp tables from causing frozen-Xid advancement
> starvation
> >>
> > Jeff Amiel wrote:
> >> Can somebody explain this one to me? because of our aud
Alvaro Herrera <[EMAIL PROTECTED]> writes:
No, it isn't. Please add a TODO item about it:
* Prevent long-lived temp tables from causing frozen-Xid advancement
starvation
>>
> Jeff Amiel wrote:
>> Can somebody explain this one to me? because of our auditing technique, we
>> have m
Jeff Amiel wrote:
>
> Bruce Momjian wrote:
>>>
>>> No, it isn't. Please add a TODO item about it:
>>> * Prevent long-lived temp tables from causing frozen-Xid advancement
>>>starvation
>
> Can somebody explain this one to me? because of our auditing technique, we
> have many LONG lived temp
Bruce Momjian wrote:
No, it isn't. Please add a TODO item about it:
* Prevent long-lived temp tables from causing frozen-Xid advancement
starvation
Can somebody explain this one to me? because of our auditing technique,
we have many LONG lived temp tables.(one per pooled
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > Is this item closed?
>
> No, it isn't. Please add a TODO item about it:
> * Prevent long-lived temp tables from causing frozen-Xid advancement
>starvation
Thanks. Added to TODO.
--
Bruce Momjian <[EMAIL PROTECTED]>http://mo
Andrew Hammond wrote:
> On 9/13/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> > Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > > >
> > > > Is this item closed?
> > >
> > > No, it isn't. Please add a TODO item about it:
> > > * Prevent long-lived temp tables from causing frozen-Xid adva
On 9/13/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > >
> > > Is this item closed?
> >
> > No, it isn't. Please add a TODO item about it:
> > * Prevent long-lived temp tables from causing frozen-Xid advancement
> >starvation
>
> Sorry, I d
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > Is this item closed?
>
> No, it isn't. Please add a TODO item about it:
> * Prevent long-lived temp tables from causing frozen-Xid advancement
>starvation
Sorry, I don't understand this. Can you give me more text? Thanks.
--
Bruce
Bruce Momjian wrote:
>
> Is this item closed?
No, it isn't. Please add a TODO item about it:
* Prevent long-lived temp tables from causing frozen-Xid advancement
starvation
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prom
Is this item closed?
---
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> Yeah, we had better investigate some way to clean them up. It was never
> > >> obv
Bruce McAlister wrote:
> Denis Gasparin wrote:
> > RESET SESSION command is available only in 8.2 branch, isn't it?
> > I tried to issue the command in a 8.1 server and the answer was: ERROR:
> > unrecognized configuration parameter "session"
>
> I had a look in our configuration and there is a
Denis Gasparin wrote:
> Martijn van Oosterhout ha scritto:
>> On Thu, Jun 28, 2007 at 11:12:19AM +0100, Bruce McAlister wrote:
>>
>>> I just want to verify that I understand you correctly here, do you mean
>>> that the temporary table is created by specific sql, for example, create
>>> temp tabl
Martijn van Oosterhout ha scritto:
> On Thu, Jun 28, 2007 at 11:12:19AM +0100, Bruce McAlister wrote:
>
>> I just want to verify that I understand you correctly here, do you mean
>> that the temporary table is created by specific sql, for example, create
>> temp table, then perform some actions
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Oh, I was just thinking in way for Bruce to get out of his current
> situation.
Oh, for that a manual "drop table" as superuser should work fine.
regards, tom lane
---(end of broadcast)--
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Yeah, we had better investigate some way to clean them up. It was never
> >> obvious before that it mattered to get rid of orphan temp tables, but I
> >> guess it does.
>
> > Would it be enough to delete the tup
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Yeah, we had better investigate some way to clean them up. It was never
>> obvious before that it mattered to get rid of orphan temp tables, but I
>> guess it does.
> Would it be enough to delete the tuple from pg_class?
No, you nee
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Well, it certainly seems like this shouldn't be happening. Maybe the
> > table belonged to a session that crashed, but the pg_class entry has not
> > been cleaned up -- possibly because that backend has not connected to
> > that part
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Well, it certainly seems like this shouldn't be happening. Maybe the
> table belonged to a session that crashed, but the pg_class entry has not
> been cleaned up -- possibly because that backend has not connected to
> that particular database.
Hm --- a
Bruce, please make sure to keep the list copied on replies. I think
there is an important bug here and I don't want it to get lost just
because I lose track of it. I'm also crossposting to pgsql-hackers.
Bruce McAlister wrote:
> okidoki, I tried this:
>
> blueface-crm=# select relname, nspnam
Alvaro Herrera wrote:
> > Bruce McAlister wrote:
> >
>> >> Alvaro Herrera wrote:
>> >>
>>> >>> Bruce McAlister wrote:
>>> >>>
Martijn van Oosterhout wrote:
> > All the values here look OK, except one:
> >
> > On Thu, Jun 28, 2007 at 07:50:36AM +0100, Bruc
Alvaro Herrera wrote:
> Bruce McAlister wrote:
>> Martijn van Oosterhout wrote:
>>> All the values here look OK, except one:
>>>
>>> On Thu, Jun 28, 2007 at 07:50:36AM +0100, Bruce McAlister wrote:
blueface-crm=# select oid, relfrozenxid from pg_class where relkind in
('r', 't');
Bruce McAlister wrote:
> Martijn van Oosterhout wrote:
> > All the values here look OK, except one:
> >
> > On Thu, Jun 28, 2007 at 07:50:36AM +0100, Bruce McAlister wrote:
> >> blueface-crm=# select oid, relfrozenxid from pg_class where relkind in
> >> ('r', 't');
> >>oid | relfrozenxid
> >
On Thu, Jun 28, 2007 at 11:12:19AM +0100, Bruce McAlister wrote:
> I just want to verify that I understand you correctly here, do you mean
> that the temporary table is created by specific sql, for example, create
> temp table, then perform some actions on that temp table, then, either
> you remove
Bruce McAlister wrote:
> Excuse my PGSQL ignorance, I'm new to PostgreSQL, and waiting for these
> PGSQL books to become available:
>
> http://www.network-theory.co.uk/newtitles.html
I'm pretty sure you'll find those are just bound copies of
http://www.postgresql.org/docs/8.2/interactive/index.ht
Alban Hertroys wrote:
> Bruce McAlister wrote:
>> Which brings me onto a possibly related question. I've noticed that in
>> this particular database, that there are temporary tables that are
>> created. I'm not 100% sure how/why these temporary tables are being
>> created, but I do assume that it m
Bruce McAlister wrote:
> Which brings me onto a possibly related question. I've noticed that in
> this particular database, that there are temporary tables that are
> created. I'm not 100% sure how/why these temporary tables are being
> created, but I do assume that it must be by some sort of SQL q
Martijn van Oosterhout wrote:
> All the values here look OK, except one:
>
> On Thu, Jun 28, 2007 at 07:50:36AM +0100, Bruce McAlister wrote:
>> blueface-crm=# select oid, relfrozenxid from pg_class where relkind in
>> ('r', 't');
>>oid | relfrozenxid
>> -+--
>> 2570051
All the values here look OK, except one:
On Thu, Jun 28, 2007 at 07:50:36AM +0100, Bruce McAlister wrote:
> blueface-crm=# select oid, relfrozenxid from pg_class where relkind in
> ('r', 't');
>oid | relfrozenxid
> -+--
> 2570051 | 2947120794
Whatever this table is, t
Bruce McAlister wrote:
> I will run with DEBUG2 for a while and see if my output looks anything
> like this :)
I've been running in DEBUG2 mode for a couple days now and I can see the
extra information being logged into the log file, but it looks like the
autovacuum is not actually starting, it d
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
>>> How much is the age decremented by on a vacuum run then?
>> It should be decremented to the vacuum_freeze_min_age. However, I'm
>> running some experiments with your settings and apparently it's not
>> working as it should.
>
Okay, if it's dec
Alvaro Herrera wrote:
> Bruce McAlister wrote:
>> Alvaro Herrera wrote:
>>> Bruce McAlister wrote:
>>>
>>> Ok now this is interesting:
>>>
select datname, age(datfrozenxid) from pg_database;
datname |age
-+---
blueface-crm
Alvaro Herrera wrote:
> > How much is the age decremented by on a vacuum run then?
>
> It should be decremented to the vacuum_freeze_min_age. However, I'm
> running some experiments with your settings and apparently it's not
> working as it should.
Nah, false alarm, it's working as expected for
Bruce McAlister wrote:
> Alvaro Herrera wrote:
> > Bruce McAlister wrote:
> >
> > Ok now this is interesting:
> >
> >> select datname, age(datfrozenxid) from pg_database;
> >> datname |age
> >> -+---
> >> blueface-crm| 441746613
>
Alvaro Herrera wrote:
> Bruce McAlister wrote:
>
> Ok now this is interesting:
>
>> select datname, age(datfrozenxid) from pg_database;
>> datname |age
>> -+---
>> blueface-crm| 441746613
>
> Note this value is 440 million, and yo
Bruce McAlister wrote:
Ok now this is interesting:
> select datname, age(datfrozenxid) from pg_database;
> datname |age
> -+---
> blueface-crm| 441746613
Note this value is 440 million, and you said in your original report that
>
Alvaro Herrera wrote:
> Bruce McAlister wrote:
>
>> I have just checked the pg_stat_all_tables in the pg_catalog schema and
>> I can see the index scans etc table values incrementing. The data in the
>> tables seems to be updating. Just an FYI, I've enabled manual vacuum
>> analyze runs on the blu
Bruce McAlister wrote:
> I have just checked the pg_stat_all_tables in the pg_catalog schema and
> I can see the index scans etc table values incrementing. The data in the
> tables seems to be updating. Just an FYI, I've enabled manual vacuum
> analyze runs on the blueface-service database up unti
Alvaro Herrera wrote:
> Bruce McAlister wrote:
>> Hi All,
>>
>> I have enabled autovacuum in our PostgreSQL cluster of databases. What I
>> have noticed is that the autovacuum process keeps selecting the same
>> database to perform autovacuums on and does not select any of the others
>> within the
Bruce McAlister wrote:
> Hi All,
>
> I have enabled autovacuum in our PostgreSQL cluster of databases. What I
> have noticed is that the autovacuum process keeps selecting the same
> database to perform autovacuums on and does not select any of the others
> within the cluster. Is this normal behav
Hi All,
I have enabled autovacuum in our PostgreSQL cluster of databases. What I
have noticed is that the autovacuum process keeps selecting the same
database to perform autovacuums on and does not select any of the others
within the cluster. Is this normal behaviour or do I need to do
something m
40 matches
Mail list logo
