On Thu, Nov 01, 2018 at 07:06:32PM -0400, Stephen Frost wrote:
> No, we don't currently track that information but it's an interesting
> idea, at least imv.
What would be the use case for it? What you are looking for here is
gathering information about all pages in a relation and just aggregate
which one has the newest LSN, which you can do at SQL level using
pageinspect to grab all the page LSNs, then use pg_control_checkpoint()
with the LSN of the last checkpoint to know if a table has been written
as such. I agree that there could be cheaper solutions than that, but
it is hard if the use cases in need of such a thing balance with the
extra maintenance involved by a new feature when there are already tools
allowing one to do that.
> Seems like a pretty useful use-case. I had been thinking for a while,
> based on a comment made be someone else (Vik Fearing..), that we should
> have a way to turn an unlogged table into an 'init table' or similar-
> that is, just copy the data from the main fork into the init fork and
> then fsync it, then the data is there on restart.
That's interesting. We already have all the facilities to be able to
handle properly init forks, and the code code better in making sure that
WAL-logging of init forks happens when it should.
> Having a way to say 'this data has been fsyncd' is a pretty interesting
> idea though. I wonder how hard it'd be to make that work.
That's however not much different from a "CREATE TABLE save_data AS
SELECT * FROM unlogged_table" happening at some point in time?
--
Michael