On Tue, Jul 5, 2011 at 12:03 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> Well, as long as we can verify that OLDSERXID_MAX_PAGE has the
>> same value for BLCKSZ=8K before and after this patch, I don't see
>> any real downside to applying it. If, hypothetically, it's buggy,
>> it's only g
Robert Haas wrote:
> Well, as long as we can verify that OLDSERXID_MAX_PAGE has the
> same value for BLCKSZ=8K before and after this patch, I don't see
> any real downside to applying it. If, hypothetically, it's buggy,
> it's only going to break things for non-default block sizes which
> are,
On Tue, Jul 5, 2011 at 10:51 AM, Kevin Grittner
wrote:
>> Is this still an open item?
>
> Yes, although I'm not clear on whether people feel it is one which
> needs to be fixed for 9.1 or left for 9.2.
>
> On a build with a BLCKSZ less than 8KB we would not get a warning
> before problems occurred
Robert Haas wrote:
> On Sun, Jun 19, 2011 at 7:17 PM, Kevin Grittner
> wrote:
>> Heikki Linnakangas wrote:
>>
>>> * The oldserxid code is broken for non-default BLCKSZ.
>>> o The warning will come either too early or too late
>>> o There is no safeguard against actually wrapping around the
>>> S
On Sun, Jun 19, 2011 at 7:17 PM, Kevin Grittner
wrote:
> Heikki Linnakangas wrote:
>
>> * The oldserxid code is broken for non-default BLCKSZ.
>> o The warning will come either too early or too late
>> o There is no safeguard against actually wrapping around the
>> SLRU, just the warning
>> o I'm
Heikki Linnakangas wrote:
> * The oldserxid code is broken for non-default BLCKSZ.
> o The warning will come either too early or too late
> o There is no safeguard against actually wrapping around the
> SLRU, just the warning
> o I'm suspicious of the OldSerXidPagePrecedesLogically() logic
> with
On 15.06.2011 19:10, Kevin Grittner wrote:
There is one issue you raised in this post:
http://archives.postgresql.org/message-id/4def3194.6030...@enterprisedb.com
Robert questioned whether it should be 9.1 material here:
http://archives.postgresql.org/message-id/BANLkTint2i2fHDTdr=Xq3K=yrxegov
On 15.06.2011 19:10, Kevin Grittner wrote:
There is an unnecessary include of predicate.h in nbtree.c we should
delete. That seems safe enough.
...
It seems like it might be a good idea to apply pgindent formating to
the latest SSI changes, to minimize conflict on back-patching any
bug fixes. I
"Kevin Grittner" wrote:
> Unless I'm missing something, the only remaining changes needed
> are for documentation (as mentioned in previous posts).
I just found notes that we also need regression tests for the
SSI/DDL combination and a comment in lazy_truncate_heap.
At any rate, not anything
Heikki Linnakangas wrote:
>> There may be some places this can be checked which haven't yet
>> been identified and touched.
>
> Yeah - in 9.2.
No argument here. I'm all for stabilizing and getting the thing out
-- I think we've established that performance is good for many
workloads as it st
On 10.06.2011 18:05, Kevin Grittner wrote:
Heikki Linnakangas wrote:
* Is the SXACT_FLAG_ROLLED_BACK flag necessary? It's only set in
ReleasePredicateLocks() for a fleeting moment while the
function releases all conflicts and locks held by the
transaction, and finally the sxact stru
On 12.06.2011 17:59, Kevin Grittner wrote:
Heikki Linnakangas wrote:
On 10.06.2011 18:05, Kevin Grittner wrote:
Heikki Linnakangas wrote:
o There is no safeguard against actually wrapping around the
SLRU, just the warning
Any thoughts on what we should do instead? If someone holds open a
tra
> Heikki Linnakangas wrote:
> On 10.06.2011 18:05, Kevin Grittner wrote:
>> Heikki Linnakangas wrote:
>>> o There is no safeguard against actually wrapping around the
>>> SLRU, just the warning
>>
>> Any thoughts on what we should do instead? If someone holds open a
>> transaction long enough to b
On Sat, Jun 11, 2011 at 01:38:31PM -0500, Kevin Grittner wrote:
> I'm not concerned about references covered by
> SerializableXactHashLock. I am more concerned about some of the
> tests for whether the (MySerializableXact == InvalidSerializableXact)
> checks and any other tests not covered by that
> Dan Ports wrote:
> On Fri, Jun 10, 2011 at 09:43:58PM +0300, Heikki Linnakangas wrote:
>>> Do checks such as that argue for keeping the volatile flag, or do
>>> you think we can drop it if we make those changes? (That would
>>> also allow dropping a number of casts which exist just to avoid
>>
On Fri, Jun 10, 2011 at 09:43:58PM +0300, Heikki Linnakangas wrote:
> > Do checks such as that argue for keeping the volatile flag, or do
> > you think we can drop it if we make those changes? (That would also
> > allow dropping a number of casts which exist just to avoid
> > warnings.)
>
> I bel
On 10.06.2011 18:05, Kevin Grittner wrote:
Heikki Linnakangas wrote:
o There is no safeguard against actually wrapping around the
SLRU, just the warning
Any thoughts on what we should do instead? If someone holds open a
transaction long enough to burn through a billion transaction
Heikki Linnakangas wrote:
> Here's a bunch of small issues that I spotted:
Thanks for going over it again. It is encouraging that you didn't
spot any *big* issues.
> * The oldserxid code is broken for non-default BLCKSZ.
>o The warning will come either too early or too late
Good point
It makes wonders to take a couple of months break from looking at a
piece of code, and then review it in detail again. It's like a whole new
pair of eyes :-).
Here's a bunch of small issues that I spotted:
* The oldserxid code is broken for non-default BLCKSZ.
o The warning will come either
19 matches
Mail list logo
