Bruce Momjian wrote:
>
> update pg_log on disk. Another issue is that now that we update the
> transaction status as part of SELECT, pg_log is not the only
We should don't update pg_log for read-only xactions.
> representation of committed status.
>
> Of course, we have to prevent flush of pglog by OS, perhaps by making a
> copy of the last two pages of pg_log before this and remove it after.
> If a backend starts up and sees that pg_log copy file, it puts that in
> place of the current last two pages of pg_log.
Keep two last pg_log pages in shmem, lock them, copy, unlock,
write copy to pg_log.
> Also, for 6.6, I am going to add system table indexes so all cache
> lookups use indexes. I am unsure that shared catalog cache is going to
> do that buffer cache doesn't already do. Perhaps if we just flushed the
> system table cache buffers less frequently, there would be no need for a
> shared system cache.
I would like to see ntuples and npages in pg_class up-to-date.
Now we do fseek for each heap_insert and for each heap_beginscan.
And note that we have to open() system relation files, even
if pages are in buffer pool.
Vadim