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.
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
bradley.mcc...@noaa.govwrote:
Well, the issue was corrected by completely rebuilding the database a few
days ago (all the way
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
.
On Fri, Jul 12, 2013 at 11:28 AM, Scott Marlowe scott.marl...@gmail.comwrote:
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 bradley.mcc...@noaa.gov
wrote:
David
, 2013 at 2:25 PM, Scott Marlowe scott.marl...@gmail.comwrote:
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
bradley.mcc...@noaa.govwrote:
The only
for
max_prepared_transactions.
Perplexing.
On Fri, Jul 12, 2013 at 4:35 PM, Scott Marlowe scott.marl...@gmail.comwrote:
So what id
select * from pg_prepared_xacts ;
show?
On Fri, Jul 12, 2013 at 2:30 PM, Bradley McCune
bradley.mcc...@noaa.govwrote:
Scott,
Purely idle. I compared these transactions with our
