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
Attachment:
signature.asc
Description: PGP signature
