On 4/26/06 5:42 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Yeah, this is probably the best workaround for now. I think we should
> look at making it fully concurrent-safe per upthread comments, but that
> won't be happening in existing release branches.
I changed the index build script such tha
On Wed, Apr 26, 2006 at 07:13:08PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > What about not updating if the tuplecount is within X percent? Would
> > that be safe enough to back-port?
>
> Even if you got agreement that it was a good idea (I don't think so
> myself), i
On 4/26/06 5:34 PM, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> Try running a first index build by itself and then running them in
> parallel. Hopefully once pg_class has an exact tuple count the
> conflicting update won't happen. If you actually have an exact tuple
> count you could also try upda
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> What about not updating if the tuplecount is within X percent? Would
> that be safe enough to back-port?
Even if you got agreement that it was a good idea (I don't think so
myself), it wouldn't help Wes, at least not for values of X smaller
than 100. P
On Wed, Apr 26, 2006 at 06:42:53PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Try running a first index build by itself and then running them in
> > parallel.
>
> Yeah, this is probably the best workaround for now. I think we should
> look at making it fully concurren
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Try running a first index build by itself and then running them in
> parallel.
Yeah, this is probably the best workaround for now. I think we should
look at making it fully concurrent-safe per upthread comments, but that
won't be happening in existing
On Wed, Apr 26, 2006 at 05:24:27PM -0500, Wes wrote:
> On 4/25/06 12:24 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
>
> > I'm inclined to think that the right solution is to fix UpdateStats and
> > setRelhasindex so that they don't use simple_heap_update, but call
> > heap_update directly and cope w
On 4/25/06 12:24 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> I'm inclined to think that the right solution is to fix UpdateStats and
> setRelhasindex so that they don't use simple_heap_update, but call
> heap_update directly and cope with HeapTupleUpdated (by looping around
> and trying the update
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Hannu Krosing wrote:
>> Would this take effect even inside a single command ? in other words, if
>> it were possible that an index appeared in middle of a big update, would
>> the tuples updated after the index becomes visible be also added to the
>> ind
Hannu Krosing wrote:
> Ühel kenal päeval, T, 2006-04-25 kell 13:58, kirjutas Tom Lane:
> > Martijn van Oosterhout writes:
> > > I think the basic problem is that DDL can't really work within a
> > > transaction. If I do an ALTER TABLE, some of these changes need to show
> > > up to concurrent tran
Ühel kenal päeval, T, 2006-04-25 kell 13:58, kirjutas Tom Lane:
> Martijn van Oosterhout writes:
> > I think the basic problem is that DDL can't really work within a
> > transaction. If I do an ALTER TABLE, some of these changes need to show
> > up to concurrent transactions (maybe creating a uniq
Martijn van Oosterhout writes:
> I think the basic problem is that DDL can't really work within a
> transaction. If I do an ALTER TABLE, some of these changes need to show
> up to concurrent transactions (maybe creating a unique index?).
The point is that DDL can't be MVCC. If for instance you a
On Tue, Apr 25, 2006 at 12:25:35PM -0500, Jim C. Nasby wrote:
> Is there anything in comments/docs/list archives about why catalog
> access uses a bunch of 'magic' instead of treating catalog tables the
> same as every other table? I realize that ultimately you have to
> bootstrap somehow (kinda ha
On Tue, Apr 25, 2006 at 12:48:04PM -0400, Alvaro Herrera wrote:
> I'm late to this thread, but maybe we can make the process of storing
> the new data in pg_class take a lock using LockObject() or something
> like that to serialize the access to the pg_class row. The idea would
> be that this lock
14 matches
Mail list logo
