On 13/09/10 05:49, Robert Haas wrote:
On Mon, Sep 6, 2010 at 10:55 PM, Robert Haasrobertmh...@gmail.com wrote:
3. With respect to unlogged tables, the major obstacle seems to be
figuring out a way for these to get automatically truncated at startup
time. As with temporary table cleanup in
On Mon, Sep 13, 2010 at 5:24 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The LSNs on all pages in an unlogged relation should be zero, and
XLogFlush() will do nothing. That's what we rely on at the moment for pages
that are not WAL-logged for some reason, I don't think you
On Mon, Sep 6, 2010 at 7:55 PM, Robert Haas robertmh...@gmail.com wrote:
3. With respect to unlogged tables, the major obstacle seems to be
figuring out a way for these to get automatically truncated at startup
time.
(please forgive what is probably a stupid question)
By truncate do mean
On Mon, Sep 13, 2010 at 9:06 PM, Rob Wultsch wult...@gmail.com wrote:
On Mon, Sep 6, 2010 at 7:55 PM, Robert Haas robertmh...@gmail.com wrote:
3. With respect to unlogged tables, the major obstacle seems to be
figuring out a way for these to get automatically truncated at startup
time.
On Mon, Sep 6, 2010 at 10:55 PM, Robert Haas robertmh...@gmail.com wrote:
3. With respect to unlogged tables, the major obstacle seems to be
figuring out a way for these to get automatically truncated at startup
time. As with temporary table cleanup in general, the problem here is
that you
I haven't had a chance to do a great deal of work on this project, but
I'm hoping to get back to it at some point and, in the meantime,
thought that it might be useful to circulate a few thoughts I've had
so far.
1. As common architecture for both features, I think that it might
make sense to
