Jaime Casanova writes:
> On Tue, Oct 27, 2009 at 6:29 PM, Alvaro Herrera
> wrote:
>> Do you have a vacuum in cron or something like that? Â As Tom says, if it
>> had been autovacuum, it should have been cancelled automatically (else
>> we've got a bug); but something invoking vacuum externally wo
On Tue, Oct 27, 2009 at 6:29 PM, Alvaro Herrera
wrote:
>
> Do you have a vacuum in cron or something like that? As Tom says, if it
> had been autovacuum, it should have been cancelled automatically (else
> we've got a bug); but something invoking vacuum externally wouldn't
> have, so what you des
JC Praud escribió:
> On Wed, Oct 28, 2009 at 12:29 AM, Alvaro Herrera > This bit does not make much sense to me. A transaction waiting will not
> > show up in the log. Were they cancelled? Can you paste an extract from
> > the log?
>
> No, the transactions were not cancelled. All I saw in he
Sorry, I got a bit lost in the thread. BTW, Thanks for all the answers :)
On Wed, Oct 28, 2009 at 12:29 AM, Alvaro Herrera wrote:
> JC Praud escribió:
>
> > - Last night the database locked. pg_log full of messages about insert
> into
> > the mother table waiting for a lock.
>
> This bit does no
On Tue, Oct 27, 2009 at 6:31 PM, Alvaro Herrera
wrote:
> JC Praud escribió:
>
> > So my question are: can the autovacuum daemon perform vacuum full ? Or
> > another internal postgres process ? Could it come from the TRUNCATE I run
> > and canceled 4 days before ?
>
> No. Autovacuum only issues co
JC Praud escribió:
> - Last night the database locked. pg_log full of messages about insert into
> the mother table waiting for a lock.
This bit does not make much sense to me. A transaction waiting will not
show up in the log. Were they cancelled? Can you paste an extract from
the log?
> - A
Greg Smith writes:
> On Tue, 27 Oct 2009, Tom Lane wrote:
>> The issue I can see is that we might never be able to complete any
>> truncation if there's a lot of potentially removable pages and a pretty
>> steady flow of conflicting lock attempts. But that would result in
>> failure to remove
Alvaro Herrera writes:
> Now 40 mins walking those pages to figure out that they need to be
> truncated, I concede that it's too much. Maybe we shouldn't be doing a
> backwards scan; perhaps this breaks the OS readahead and make it even
> slower.
That's very possible, since a backwards scan is g
On Tue, 27 Oct 2009, Tom Lane wrote:
The issue I can see is that we might never be able to complete any
truncation if there's a lot of potentially removable pages and a pretty
steady flow of conflicting lock attempts. But that would result in
failure to remove bloat, not stoppage of conflicti
Greg Smith writes:
> On Tue, 27 Oct 2009, Alvaro Herrera wrote:
>> Now 40 mins walking those pages to figure out that they need to be
>> truncated, I concede that it's too much. Maybe we shouldn't be doing a
>> backwards scan; perhaps this breaks the OS readahead and make it even
>> slower.
> I'
On Tue, 27 Oct 2009, Alvaro Herrera wrote:
Now 40 mins walking those pages to figure out that they need to be
truncated, I concede that it's too much. Maybe we shouldn't be doing a
backwards scan; perhaps this breaks the OS readahead and make it even
slower.
I've watched that take hours befor
Pavel Stehule escribió:
> 2009/10/27 Alvaro Herrera :
> > JC Praud escribió:
> >
> >> So my question are: can the autovacuum daemon perform vacuum full ? Or
> >> another internal postgres process ? Could it come from the TRUNCATE I run
> >> and canceled 4 days before ?
> >
> > No. Autovacuum only
2009/10/27 Alvaro Herrera :
> JC Praud escribió:
>
>> So my question are: can the autovacuum daemon perform vacuum full ? Or
>> another internal postgres process ? Could it come from the TRUNCATE I run
>> and canceled 4 days before ?
>
> No. Autovacuum only issues commands that don't lock tables s
JC Praud escribió:
> So my question are: can the autovacuum daemon perform vacuum full ? Or
> another internal postgres process ? Could it come from the TRUNCATE I run
> and canceled 4 days before ?
No. Autovacuum only issues commands that don't lock tables strongly. I
doubt this has anything t
Hi all,
I've got a weird thing on one of my databases this night:
- I've a monthly partition for storing activity logs defined as this:
- mother log table
- one child partition for each month
- Last friday I dumped the last month partition, and tried to truncate it,
which locked lots of quer
15 matches
Mail list logo
