Jeff, * Jeff Davis (pg...@j-davis.com) wrote: > That isn't a problem, because the other session won't see the tuple in > pg_class until the creating transaction commits, at which point the rows > have committed, too (because this would only kick in when the rows are > loaded in the same transaction as the CREATE).
See, that's what I originally thought but was corrected on it at one point (by Tom, iirc). I just did a simple test against 9.2.1 using serializable mode. In this mode, if you do something like this: session a --------- begin; session b --------- begin; create table q (a integer); insert into q values (1); commit; select * from q; You'll get an empty table. That's not great, but it's life- once something is in pg_class, all sessions can see it because the table lookups are done using SnapshotNow and aren't truely transactional, but at least you can't see any rows in the table because the individual rows are marked with the transaction ID which created them and we can't see them in our transaction that started before the table was created. It sounds like, with this patch/change, this behavior would change. Now, I'm not necessairly against this, but it's clearly something different than what we had before and might be an issue for some. If, in the general case, we're actually 'ok' with this, I'd ask why we don't simply do it by default..? If we're *not* 'ok' with it, perhaps we shouldn't be doing it at all... If we fix the bigger issue (which, as I understand it from various discussions with Tom and Robert, is very difficult), then this whole problem goes away entirely. I always figured/expected that to be how we'd fix this, not just punt on the issue and tell the user "sure, you can do this, hope you know what you're doing...". Thanks, Stephen
signature.asc
Description: Digital signature