"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Thu, Jun 12, 2003 at 06:23:12PM -0400, Tom Lane wrote:
>>> Even stuff like
>>> drop and rename should be protected by versioning, no?
>>
>> No. System-catalog changes are always READ COMMITTED mode.
> Yeah, so the catalog changes shouldn't be visi
On Mon, Jun 16, 2003 at 01:17:38 -0500,
"Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
>
> Yeah, so the catalog changes shouldn't be visible to anyone until after
> the ALTER is complete, right? Even if a transaction is set to read
> uncommitted, I assume it will always read only committed data from
On Thu, Jun 12, 2003 at 06:23:12PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Is there any ALTER that would require blocking selects?
>
> DROP INDEX, for certain.
Sure, but that's usually trivially fast.
> > Even stuff like
> > drop and rename should be protected by
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Is there any ALTER that would require blocking selects?
DROP INDEX, for certain.
> Even stuff like
> drop and rename should be protected by versioning, no?
No. System-catalog changes are always READ COMMITTED mode.
regards, t
On Wed, Jun 11, 2003 at 03:19:14PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Is it really necessary to block reads on a table that is affected by
> > adding a foreign key constraint?
>
> It's trickier than you seem to think. The command is adding an index,
> which at
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Is it really necessary to block reads on a table that is affected by
> adding a foreign key constraint?
It's trickier than you seem to think. The command is adding an index,
which at some point is going to affect plans for SELECTs on the table.
It migh
Is it really necessary to block reads on a table that is affected by
adding a foreign key constraint? I can see why you wouldn't want UPDATES
or INSERTS on the child table or DELETEs on the parent, but select
should be fine on both tables, no?
--
Jim C. Nasby (aka Decibel!)[EMA
