Hi,
I'm talking about our own massively bloated toast table - described in
an earlier post - that I think I can replicate. I didn't mean to
steal your thread, but the problem seems very similar, and we're using
9.1. I don't know a lot about Postgres internals, but to me it smells
like a bug of s
David,
I'm sorry, but I'm not sure that I follow how this is pertinent to this
particular thread. Are you proposing a way to replicate the scenario we
experienced of our massively bloated TOAST table? If so, I'm not entirely
sure that's doable given that the source of the issue was never clear.
Thanks, Scott. Currently, it's a bit difficult due to resources for a
complete copy of the database to be useful. I won't get into the details,
but it just wasn't an option at the time. With that said, I'm definitely
making it a major concern of ours for such future issues, so post mortem
and su
Hi,
I think I could write a script to do something similar to what is
happening if anyone is interested. I'd want some direction as to the
best way to handle this though: it'd be easier for me to script it as
Rails code because that's what the app is. Perhaps from that we can
get the generated S
It's always a good idea to keep a copy of the database for a post mortem if
possible. If you've found a bug, it's nice to find and fix it. If you were
suffering from an operational failure of some sort, then it helps to figure
that out too.
On Fri, Jul 12, 2013 at 2:42 PM, Bradley McCune wrote:
Well, the issue was corrected by completely rebuilding the database a few
days ago (all the way to reinitializing the database directory). With that
said, I did check that table at the time, and I received an empty result
set from such a SELECT statement. The same goes for
max_prepared_transactio
So what id
select * from pg_prepared_xacts ;
show?
On Fri, Jul 12, 2013 at 2:30 PM, Bradley McCune wrote:
> Scott,
>
> Purely idle. I compared these transactions with our other "healthy"
> databases, and they checked out.
>
>
> On Fri, Jul 12, 2013 at 4:25 PM, Scott Marlowe wrote:
>
>> Prepared
Scott,
Purely idle. I compared these transactions with our other "healthy"
databases, and they checked out.
On Fri, Jul 12, 2013 at 4:25 PM, Scott Marlowe wrote:
> Prepared transactions that are sitting still do the same thing, and show
> no connections.
>
>
> On Fri, Jul 12, 2013 at 2:25 PM,
Prepared transactions that are sitting still do the same thing, and show no
connections.
On Fri, Jul 12, 2013 at 2:25 PM, Scott Marlowe wrote:
> Idle in Transaction? Or plain Idle? Idle in Transaction stops vacuum from
> reclaiming space and is indicative of a broken application.
>
>
> On Fri, J
Idle in Transaction? Or plain Idle? Idle in Transaction stops vacuum from
reclaiming space and is indicative of a broken application.
On Fri, Jul 12, 2013 at 9:39 AM, Bradley McCune wrote:
> The only transactions present were "" for current_query. I even
> stopped the remote services, restarted
The only transactions present were "" for current_query. I even
stopped the remote services, restarted the PostgreSQL server (assumingly,
there should be no transactions occurring now), and performed another
VACUUM FULL followed by REINDEX due to known fullvac index bloat in pre-9
pgsql version.
Did you have a long running trasnaction? Especially a prepared
transaction, blocking the vacuum from reclaiming the space?
On Fri, Jul 12, 2013 at 8:10 AM, Bradley McCune wrote:
> David,
>
> (As a preface, I have already gone forward with completely rebuilding the
> database which seems to have f
David,
(As a preface, I have already gone forward with completely rebuilding the
database which seems to have finally fixed the problem. Rebuilding the
table itself had no effect, and I couldn't wait much longer to move
forward.)
Yes, this seems similar, however, the key difference being that VA
Hi,
I have a very similar problem... details below.
On Wed, Jul 3, 2013 at 5:19 PM, Paul Tilles wrote:
> Recently, I've had a PostgreSQL 8.2.11 server upgraded to 8.4 in order to
> take advantage of autovacuum features. This server exists in a very closed
> environment (isolated network, limited
14 matches
Mail list logo
