Tom Lane wrote:
> Alvaro Herrera writes:
> > Excerpts from Alvaro Herrera's message of vie oct 28 16:47:13 -0300 2011:
> >> BTW we had previous discussions about dropping pg_database's toast
> >> table. Maybe this is a good time to do it, even if there's no risk of
> >> this bug (or the hypotheti
On Fri, Oct 28, 2011 at 3:11 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Alvaro Herrera's message of vie oct 28 16:47:13 -0300 2011:
>>> BTW we had previous discussions about dropping pg_database's toast
>>> table. Maybe this is a good time to do it, even if there's no risk of
Alvaro Herrera writes:
> Excerpts from Alvaro Herrera's message of vie oct 28 16:47:13 -0300 2011:
>> BTW we had previous discussions about dropping pg_database's toast
>> table. Maybe this is a good time to do it, even if there's no risk of
>> this bug (or the hypothetical circularity detoasting
"Kevin Grittner" writes:
> If we made the commit sequence number more generally available,
> incrementing it at the point of visibility change under cover of
> ProcArrayLock, and including the then-current value in a Snapshot
> object when built, would that help with this at all?
No, because we n
Tom Lane wrote:
> The risk factor comes in when we hold a syscache entry across
> transactions; then this guarantee is lost. (In both the original
> example and the pg_proc case above, the second backend is only at
> risk when it starts its transaction after the first one's commit,
> and in bet
Excerpts from Alvaro Herrera's message of vie oct 28 16:47:13 -0300 2011:
> BTW we had previous discussions about dropping pg_database's toast
> table. Maybe this is a good time to do it, even if there's no risk of
> this bug (or the hypothetical circularity detoasting problem) showing up
> ther
Excerpts from Tom Lane's message of vie oct 28 15:37:43 -0300 2011:
> The main concern I had about detoast before caching is the risk of
> circularity, ie, needing detoastable cache entries in order to figure
> out how to detoast. But I think it's probably okay. The current list
> of catalogs w
Robert Haas writes:
> Wait a minute: I'm confused. What's at issue here, at least AIUI, is
> taking a TOAST pointer and fetching the corresponding value. But that
> must involve reading from the TOAST table, and our usual paradigm for
> reading from system catalogs is (1) take AccessShareLock, (
On Tue, Oct 25, 2011 at 11:24 PM, Tom Lane wrote:
> Even given your recent changes to reduce the overhead of checking for
> sinval messages, I'm not sure that it'd be practical to move the sinval
> message processing to just-before-we-look-up-a-cache-entry.
Wait a minute: I'm confused. What's at
On Wed, Oct 26, 2011 at 4:24 AM, Tom Lane wrote:
> Even given your recent changes to reduce the overhead of checking for
> sinval messages, I'm not sure that it'd be practical to move the sinval
> message processing to just-before-we-look-up-a-cache-entry. Right now,
> we do AcceptInvalidationMe
Robert Haas writes:
> On Tue, Oct 25, 2011 at 9:06 PM, Tom Lane wrote:
>> Ordinarily, sending out sinval messages post-commit is okay because we
>> don't release locks until after that, and we suppose that our locks
>> prevent any other transactions from getting to the point of using
>> syscache
On Tue, Oct 25, 2011 at 9:06 PM, Tom Lane wrote:
> What has happened here is that the second ANALYZE has marked itself
> committed in pg_clog and no longer running in the ProcArray, so VACUUM
> feels entitled to remove toast tuples that the ANALYZE deleted. However,
> the ANALYZE has not yet sent
I believe I have reproduced the behavior described by Andrew Hammond in
http://archives.postgresql.org/pgsql-general/2011-10/msg00928.php
This is using the regression database:
1. In session 1, do
set default_statistics_target TO 1;
analyze tenk1;
(We need the large stats targ
13 matches
Mail list logo
