global temporary tables
in [PgSql]
|
From: Tom Lane on 26 Apr 2010 16:06 Simon Riggs <simon(a)2ndQuadrant.com> writes: > On Mon, 2010-04-26 at 15:40 -0400, Tom Lane wrote: >> The current definition of Hot Standby is that it's a *read only* >> behavior. Not read mostly. What you are proposing is a rather >> fundamental change in the behavior of HS, and it doesn't seem to me >> that it should be on the head of anybody else to make it work. > That's a dangerous precedent you just set. [ shrug... ] If you have near-term solutions for all the *other* problems that would be involved (like what XID to put into rows you insert in the temp tables) then I might think that what you're asking Robert to do is reasonable. Personally I think non-read-only HS is entirely pie in the sky, and therefore it's not reasonable to saddle unrelated development tasks with an expectation that they should work with a behavior that probably won't ever happen. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 26 Apr 2010 16:18
Tom Lane escribi�: > [ forgot to respond to this part ] > > Robert Haas <robertmhaas(a)gmail.com> writes: > > ... I don't see the problem with DROP. > > Under the proposed design, it's approximately equivalent to dropping a > > table that someone else has truncated. You just wait for the > > necessary lock and then do it. > > And do *what*? You can remove the catalog entries, but how are you > going to make the physical storage of other backends' versions go away? > (To say nothing of making them flush their local buffers for it.) Maybe we could add a sinval message to that effect. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |