On Tue, Jun 7, 2011 at 2:57 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > Seems like you're trying to fix the problem directly, which as you > say, has problems. > > At some point we resolve from a word mentioned in the FROM clause to a > relfilenode. > > Surely somewhere there we can notice its unlogged before we end up > down in the guts of smgr?
Probably. I guess the question is whether we want this to fail in (a) the parser, (b) the planner, or (c) the executor. I'm not quite sure what is best, but if I had to guess I would have picked (c) in preference to (b) in preference to (a), and you seem to be proposing (a). Having parserOpenTable() or transformSelectStmt() or some such place barf doesn't feel right - it's not the job of those functions to decide whether the query can actually be executed at the moment, just whether it's well-formed. Failing in the planner seems better, but it seems like a crude hack to have estimate_rel_size() be the place that bails out just because that's where we happen to call smgrnblocks(). Also, it seems like we oughtn't error out if someone wants to, say, PREPARE a query while running in HS mode and then wait until after the server is promoted to EXECUTE it, which won't work if we fail in the planner. So that led me to the approach I took in the patch I posted last night: tweak estimate_rel_size() just enough so it doesn't fail, and then fail for real inside the executor. This is not to say I'm not open to other ideas, but just to give a brief history of how I ended up where I am. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
