On Thu, Jul 07, 2011 at 09:30:47PM -0400, Robert Haas wrote:
> On Thu, Jul 7, 2011 at 3:54 PM, Noah Misch wrote:
> > Yes. DDL-DDL concurrency is a much smaller practical concern, but it is a
> > quality-of-implementation hole.
>
> Agreed, although I'm not too pleased about the fact that this doe
On Thu, Jul 7, 2011 at 3:54 PM, Noah Misch wrote:
> Yes. DDL-DDL concurrency is a much smaller practical concern, but it is a
> quality-of-implementation hole.
Agreed, although I'm not too pleased about the fact that this doesn't
fix nextval(). That seems like a fairly significant hole (but one
On Thu, Jul 07, 2011 at 11:43:30AM -0400, Robert Haas wrote:
> On Wed, Jul 6, 2011 at 10:44 PM, Noah Misch wrote:
> > Attached. I made the counter 64 bits wide, handled the nothing-found case
> > per
> > your idea, and improved a few comments cosmetically. I have not attempted
> > to
> > impro
On Wed, Jul 6, 2011 at 10:44 PM, Noah Misch wrote:
> Attached. I made the counter 64 bits wide, handled the nothing-found case per
> your idea, and improved a few comments cosmetically. I have not attempted to
> improve the search_path interposition case. We can recommend the workaround
> above
On Wed, Jul 06, 2011 at 08:35:55PM -0400, Robert Haas wrote:
> On Wed, Jul 6, 2011 at 6:32 PM, Noah Misch wrote:
> > While a mere "LOCK bar.x" is sufficient to get a clean cutover with respect
> > to
> > parsing, it fails to invalidate plans. To really cover all bases, you need
> > some no-op ac
On Wed, Jul 6, 2011 at 6:32 PM, Noah Misch wrote:
>> Maybe this is a stupid idea, but what about changing the logic so
>> that, if we get back InvalidOid, we AcceptInvalidationMessages() and
>> retry if the counter has advanced? ISTM that might cover the example
>> you mentioned in your last post
On Wed, Jul 06, 2011 at 03:06:40PM -0400, Robert Haas wrote:
> On Sun, Jun 19, 2011 at 11:42 PM, Noah Misch wrote:
> > On Sun, Jun 19, 2011 at 11:44:35PM +0100, Greg Stark wrote:
> >> So I was the victim assigned to review this patch.
> >
> > Thanks for doing so.
>
> This discussion seems to have
On Sun, Jun 19, 2011 at 11:42 PM, Noah Misch wrote:
> On Sun, Jun 19, 2011 at 11:44:35PM +0100, Greg Stark wrote:
>> So I was the victim assigned to review this patch.
>
> Thanks for doing so.
This discussion seems to have died off. Let's see if we can drive
this forward to some conclusion.
I t
Hi Greg,
On Sun, Jun 19, 2011 at 11:44:35PM +0100, Greg Stark wrote:
> So I was the victim assigned to review this patch.
Thanks for doing so.
> The code is pretty much impeccable as usual from Noah. But I have
> questions about the semantics of it.
>
> Firstly this bit makes me wonder:
>
> +
So I was the victim assigned to review this patch.
The code is pretty much impeccable as usual from Noah. But I have
questions about the semantics of it.
Firstly this bit makes me wonder:
+ /* Not-found is always final. */
+ if (!OidIsValid(relOid1))
+
On Mon, Jun 13, 2011 at 4:04 PM, Noah Misch wrote:
> On Mon, Jun 13, 2011 at 08:21:05AM -0400, Robert Haas wrote:
>> On Mon, Jun 13, 2011 at 1:12 AM, Noah Misch wrote:
>> > This probably would not replace a backend-local counter of processed
>> > messages
>> > for RangeVarLockRelid()'s purposes.
On Mon, Jun 13, 2011 at 08:21:05AM -0400, Robert Haas wrote:
> On Mon, Jun 13, 2011 at 1:12 AM, Noah Misch wrote:
> > This probably would not replace a backend-local counter of processed
> > messages
> > for RangeVarLockRelid()'s purposes. ?It's quite possibly a good way to
> > reduce
> > SInval
On Mon, Jun 13, 2011 at 1:12 AM, Noah Misch wrote:
> That might be a start, but it's not a complete replacement for the global
> counter. AcceptInvalidationMessages() is actually called in
> LockRelationOid(),
> but the comparison needs to happen a level up in RangeVarLockRelid(). So, we
> woul
On Sun, Jun 12, 2011 at 10:56:41PM -0400, Robert Haas wrote:
> On Sun, Jun 12, 2011 at 9:23 PM, Noah Misch wrote:
> >> I haven't reviewed
> >> your patch in detail, but is there a way we can encapsulate the
> >> knowledge of the invalidation system down inside the sinval machinery,
> >> rather tha
On Sun, Jun 12, 2011 at 9:23 PM, Noah Misch wrote:
>> I haven't reviewed
>> your patch in detail, but is there a way we can encapsulate the
>> knowledge of the invalidation system down inside the sinval machinery,
>> rather than letting the heap code have to know directly about the
>> counter? Pe
On Sun, Jun 12, 2011 at 06:20:53PM -0400, Robert Haas wrote:
> On Sun, Jun 12, 2011 at 3:18 PM, Noah Misch wrote:
> > Indeed, the original patch slowed it by about 50%. ?I improved the patch,
> > adding a global SharedInvalidMessageCounter to increment as we process
> > messages. ?If this counter
On Sun, Jun 12, 2011 at 3:18 PM, Noah Misch wrote:
> Indeed, the original patch slowed it by about 50%. I improved the patch,
> adding a global SharedInvalidMessageCounter to increment as we process
> messages. If this counter does not change between the RangeVarGetRelid() call
> and the post-lo
17 matches
Mail list logo
