Hi All,
Here is a revised patch based on our earlier discussion. I implemented
Robert's idea of tracking the vacuum generation number in the line
pointer itself. For LP_DEAD line pointers, the lp_off/lp_len is unused
(and always set to 0 for heap tuples). We use those 30 bits to store
the generati
Robert Haas writes:
> On Fri, Aug 19, 2011 at 2:13 PM, Tom Lane wrote:
>> 1. Robert was speculating the other day about wanting to be able to
>> snoop the inval traffic. Right now, callbacks can only snoop a fairly
>> small subset of it.
> Is that true? It appears to me that the events that ar
On Fri, Aug 19, 2011 at 2:13 PM, Tom Lane wrote:
> Currently, we have two types of callbacks that can be registered to get
> control when an invalidation message is received: syscache callbacks and
> relcache callbacks. It strikes me that we might be better advised to
> unify these into a single
On Sun, Aug 21, 2011 at 12:10 AM, Gokulakannan Somasundaram
wrote:
> Consider the TPC-C benchmark. Currently on a four core box, Oracle does
> 29 transactions per minute. Say we are doing something around half of
> this. So a page should get quickly filled. If a vacuum runs and the
> transacti
In common cases of snapshot use we run GetSnapshotData() into a
statically allocated snapshot, then immediately copy the static struct
into a dynamically allocated copy.
The static allocation was designed to remove the overhead of dynamic
allocation, but then we do it anyway.
The snapmgr code doe
Kohei KaiGai writes:
> The current implementation set the current user as owner of the new schema.
> The default permission check of schema allows owner to create several kinds
> of underlying objects.
>
> In the result, we may consider a scenario that a user without permissions to
> create new ob
2011/8/21 Dimitri Fontaine :
> Kohei KaiGai writes:
>> However, it allows users to create a new schema with his ownership,
>> even if current user does not have permission to create a new schema.
> [...]
>> It seems to me that we should inject permission checks here like as
>> CreateSchemaCommand(
Kohei KaiGai writes:
> However, it allows users to create a new schema with his ownership,
> even if current user does not have permission to create a new schema.
[...]
> It seems to me that we should inject permission checks here like as
> CreateSchemaCommand() doing.
It seems to me the code has
>
> a) First, my understanding of checkpoint is that it flushes all the pages,
> that got changed below a particular LSN. If we are not having a LSN in the
> visibility map, how we will be sure, that a visibility map page is getting
> flushed/not?
>
Please ignore this statement. I confused betwee
>> The all_visible_cleared flag is included in the WAL record of the insert
(or update or delete). Partial page writes are not a problem, because we
>> always fetch the VM page and clear the bit, regardless of the LSN on the
VM page.
Two things
a) First, my understanding of checkpoint is that it
On 21.08.2011 07:41, Gokulakannan Somasundaram wrote:
On Sat, Aug 20, 2011 at 4:57 AM, Gokulakannan Somasundaram
wrote:
by your argument, if WALInserLock is held for 't' seconds, you should
definitely be holding visibility map lock for more than time frame 't'.
Nope, that's not how it work
On 21.08.2011 07:10, Gokulakannan Somasundaram wrote:
d) In addition, currently there is no WAL Logging, while the bit is
cleared,
which would not be the case in future and hence the exclusive lock held
on
the visibility map is going to be held for a longer time.
This is false and has been
12 matches
Mail list logo
