Alvaro Herrera <[EMAIL PROTECTED]> writes:
>>> Right. This is expected. VACUUM cannot remove them because the
>>> serializable transaction might still want to see those rows.
> Joseph S wrote:
>> The serializable transaction *can't* see those rows, they were created
>> and obsoleted after the
> Alvaro Herrera wrote:
> >Joseph S wrote:
> >>I realize this thread is old, but I just conducted an experiment with pg
> >>8.0.10 and a transaction with a SERIALIZABLE isolation level does
> >>prevent VACUUM from reclaiming rows that were created and then obsoleted
> >> in a subsequent transact
The serializable transaction *can't* see those rows, they were created
and obsoleted after the start of the transaction. The point of make the
transaction serializable in the first place was to allow VACUUM to
reclaim those rows.
Alvaro Herrera wrote:
Joseph S wrote:
I realize this thread i
Joseph S wrote:
> I realize this thread is old, but I just conducted an experiment with pg
> 8.0.10 and a transaction with a SERIALIZABLE isolation level does
> prevent VACUUM from reclaiming rows that were created and then obsoleted
> in a subsequent transaction.
Right. This is expected. VA
I realize this thread is old, but I just conducted an experiment with pg
8.0.10 and a transaction with a SERIALIZABLE isolation level does
prevent VACUUM from reclaiming rows that were created and then obsoleted
in a subsequent transaction.
Martijn van Oosterhout wrote:
On Thu, Oct 19, 2006
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/19/06 15:22, Martijn van Oosterhout wrote:
> On Thu, Oct 19, 2006 at 04:18:50PM -0400, Joseph Shraibman wrote:
>> I'm running postgres 8.0.8. I have a table that is updated very
>> rapidly, so I vacuum it every 10 minutes. The problem is that
Joseph S writes:
> But if the tuple in question was created and then deleted after the
> transaction, the transaction should still not need to see it.
No, because it might have taken a snapshot during the interval where the
tuple was good.
regards, tom lane
But if the tuple in question was created and then deleted after the
transaction, the transaction should still not need to see it.
Martijn van Oosterhout wrote:
On Thu, Oct 19, 2006 at 04:25:09PM -0400, Joseph S wrote:
The problem is that the "old" transaction can see effects of later
started t
On Thu, Oct 19, 2006 at 04:25:09PM -0400, Joseph S wrote:
> >The problem is that the "old" transaction can see effects of later
> >started transactions, so VACUUM can't delete the later stuff either...
>
> How can it see effects of transactions that started after it?
Check the documentation for t
Martijn van Oosterhout wrote:
Sure, don't keep transactions open for so long. Is there a particular
reason you do that?
Because I have a leak somewhere? Even if the transaction isn't that old
it will still cause me some table bloat in the meantime.
The problem is that the "old" transaction
On Thu, Oct 19, 2006 at 04:18:50PM -0400, Joseph Shraibman wrote:
> I'm running postgres 8.0.8. I have a table that is updated very
> rapidly, so I vacuum it every 10 minutes. The problem is that I
> sometimes have transactions that hang out for a long time without doing
> anything. These tra
I'm running postgres 8.0.8. I have a table that is updated very
rapidly, so I vacuum it every 10 minutes. The problem is that I
sometimes have transactions that hang out for a long time without doing
anything. These transactions are preventing VACUUM from cleaning up
tuples that were created
12 matches
Mail list logo
