Re: Commits 8de72b and 5457a1 (COPY FREEZE)

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Commits 8de72b and 5457a1 (COPY FREEZE)
Дата
Msg-id 1354816613.11983.1.camel@jdavis
обсуждение исходный текст
Ответ на Re: Commits 8de72b and 5457a1 (COPY FREEZE)  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Commits 8de72b and 5457a1 (COPY FREEZE)
Список pgsql-hackers
On Thu, 2012-12-06 at 11:55 -0500, Stephen Frost wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
> When I last recall this discussion (likely in some bar in Europe), the
> problem was also that an independent session would be able to:
> 
> a) see that the table exists (due to SnapshotNow being used for lookups)
> b) see rows in the table
> 
> Part 'a' is something which I think would be good to fix (but hard),
> and it sounds like this patch might make part 'b' happen, which I think
> makes the part 'a' problem worse.  I'm guessing this isn't a problem for
> the TRUNCATE case because the second session would still be looking at
> the pre-TRUNCATE files on disk, right?  Is that reference to exactly
> which files on disk to look at being used to address the CREATE problem
> too..?

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).

So, yes, it's like TRUNCATE in that regard.

Regards,Jeff Davis




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Fix for pg_upgrade status display
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Functional dependency in GROUP BY through JOINs