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
ql version.
On Fri, Jul 12, 2013 at 11:28 AM, Scott Marlowe wrote:
> 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,
> >
&
, 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, Jul 12, 2013 at 9:39 AM, Bradley McCune
>> wrote:
&g
max_prepared_transactions.
Perplexing.
On Fri, Jul 12, 2013 at 4:35 PM, Scott Marlowe wrote:
> 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
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.
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 da
