Tom Lane escribió:
> [ forgot to respond to this part ]
>
> Robert Haas 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 i
Simon Riggs 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 b
On Mon, Apr 26, 2010 at 3:30 PM, Simon Riggs wrote:
> On Sun, 2010-04-25 at 11:35 -0400, Robert Haas wrote:
>
>> And I don't
>> think you can even get that far, because I don't think too many people
>> here are going to say that we shouldn't add global temporary tables
>> unless we can also make t
On Mon, 2010-04-26 at 15:40 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Sun, 2010-04-25 at 11:35 -0400, Robert Haas wrote:
> >> And I don't
> >> think you can even get that far, because I don't think too many people
> >> here are going to say that we shouldn't add global temporary tables
>
Simon Riggs writes:
> On Sun, 2010-04-25 at 11:35 -0400, Robert Haas wrote:
>> And I don't
>> think you can even get that far, because I don't think too many people
>> here are going to say that we shouldn't add global temporary tables
>> unless we can also make them work with Hot Standby.
> The
On Sun, 2010-04-25 at 11:35 -0400, Robert Haas wrote:
> And I don't
> think you can even get that far, because I don't think too many people
> here are going to say that we shouldn't add global temporary tables
> unless we can also make them work with Hot Standby.
The policy round here for some t
On Sun, Apr 25, 2010 at 5:29 PM, Josh Berkus wrote:
> Robert,
>
>> (1). What I *think* it is supposed to mean is that the table is a
>> permanent object which is "globally" visible - that is, it's part of
>> some non-temp schema like public or $user and it's column definitions
>> etc. are visible
Josh Berkus wrote:
Robert,
(1). What I *think* it is supposed to mean is that the table is a
permanent object which is "globally" visible - that is, it's part of
some non-temp schema like public or $user and it's column definitions
etc. are visible to all backends - and it's not automaticall
Robert,
(1). What I *think* it is supposed to mean is that the table is a
permanent object which is "globally" visible - that is, it's part of
some non-temp schema like public or $user and it's column definitions
etc. are visible to all backends - and it's not automatically removed
on commit, b
Jim Nasby writes:
> On Apr 24, 2010, at 10:02 PM, Tom Lane wrote:
>> Yeah. I think we also use RelFileNode as a hash tag in places, and
>> so adding a bool to it would be problematic for a couple of reasons:
>> possibly uninitialized pad bytes, and uselessly incorporating more bytes
>> into the h
On Apr 24, 2010, at 10:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> Pushing it into the RelFileNode has some advantages in terms of being
>> able to get at the information from everywhere, but one thing that
>> makes me think that's probably not a good decision is that we somtimes
>> WAL-log re
On Sun, Apr 25, 2010 at 8:57 AM, Simon Riggs wrote:
>> I don't think that quite works, because the standby might assign a
>> relfilenode number for a global temp table and then the master might
>> subsequently assign the same relfilenode number to a regular table.
>> We might be able to make that
On Sun, 2010-04-25 at 06:50 -0400, Robert Haas wrote:
> On Sun, Apr 25, 2010 at 3:49 AM, Simon Riggs wrote:
> > On Sat, 2010-04-24 at 19:01 -0400, Robert Haas wrote:
> >
> >> There is one major problem, though: assigning a
> >> scratch relfilenode to the temporary table requires generating an OID,
On Sat, Apr 24, 2010 at 11:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> Pushing it into the RelFileNode has some advantages in terms of being
>> able to get at the information from everywhere, but one thing that
>> makes me think that's probably not a good decision is that we somtimes
>> WAL-l
On Sun, Apr 25, 2010 at 3:49 AM, Simon Riggs wrote:
> On Sat, 2010-04-24 at 19:01 -0400, Robert Haas wrote:
>
>> There is one major problem, though: assigning a
>> scratch relfilenode to the temporary table requires generating an OID,
>> which we currently have no way to allow on the standby.
>
>
On Sat, 2010-04-24 at 19:01 -0400, Robert Haas wrote:
> There is one major problem, though: assigning a
> scratch relfilenode to the temporary table requires generating an OID,
> which we currently have no way to allow on the standby.
Why not have an unlogged counter, which resets each system sta
Robert Haas writes:
> Pushing it into the RelFileNode has some advantages in terms of being
> able to get at the information from everywhere, but one thing that
> makes me think that's probably not a good decision is that we somtimes
> WAL-log relfilenodes. And WAL-logging the value of the isTemp
On Sat, Apr 24, 2010 at 10:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> Oh, maybe I do see. If we pass it to smgropen() and stash it in the
>> SMgrRelation, we don't have to keep supplying it later on, maybe?
>
> Right. I'm unsure whether we should push it into the RelFileNode
> struct itsel
Robert Haas writes:
> Oh, maybe I do see. If we pass it to smgropen() and stash it in the
> SMgrRelation, we don't have to keep supplying it later on, maybe?
Right. I'm unsure whether we should push it into the RelFileNode
struct itself, but even having it in SMgrRelation ought to cut out
a few
On Sat, Apr 24, 2010 at 9:59 PM, Robert Haas wrote:
> On Sat, Apr 24, 2010 at 9:37 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Unfortunately, I don't see much alternative to making smgr know
>>> something about the temp-ness of the relation, though I'm hoping to
>>> keep the smgr surgery to a
On Sat, Apr 24, 2010 at 9:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> Unfortunately, I don't see much alternative to making smgr know
>> something about the temp-ness of the relation, though I'm hoping to
>> keep the smgr surgery to an absolute minimum. Maybe what we could do
>> is incorpora
On Apr 24, 2010, at 8:14 PM, Robert Haas wrote:
>> One possibility: rename the existing pg_stats to pg_stats_permanent. Create
>> a global temporary table called pg_stats_temporary. pg_stats becomes a union
>> of the two. I know the backend wouldn't be able to use the view, but
>> hopefully acce
Robert Haas writes:
> Unfortunately, I don't see much alternative to making smgr know
> something about the temp-ness of the relation, though I'm hoping to
> keep the smgr surgery to an absolute minimum. Maybe what we could do
> is incorporate the backend ID or PID into the file name when the
> r
On Sat, Apr 24, 2010 at 8:47 PM, Jim Nasby wrote:
> On Apr 24, 2010, at 12:31 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> At least AIUI, the use case for this feature is that you want to avoid
>>> creating "the same" temporary table over and over again.
>>
>> The context that I've seen it come
On Apr 24, 2010, at 12:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> At least AIUI, the use case for this feature is that you want to avoid
>> creating "the same" temporary table over and over again.
>
> The context that I've seen it come up in is that people don't want to
> clutter their funct
On Sat, Apr 24, 2010 at 6:29 PM, Simon Riggs wrote:
> On Fri, 2010-04-23 at 22:52 -0400, Robert Haas wrote:
>> Thoughts?
>
> Only a requirement: that we design this in a way that will allow temp
> tables to be used during Hot Standby. I make not other comment.
For so long as local temporary table
On Sat, Apr 24, 2010 at 3:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... Why would the
>> end-of-session processing need the catalog entries? It seems like
>> whatever backend-local data structure we're using to record the
>> relfilenode mappings would be sufficent to nuke the backend stor
On Fri, 2010-04-23 at 22:52 -0400, Robert Haas wrote:
> Thoughts?
Only a requirement: that we design this in a way that will allow temp
tables to be used during Hot Standby. I make not other comment.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-
Robert Haas writes:
> ... Why would the
> end-of-session processing need the catalog entries? It seems like
> whatever backend-local data structure we're using to record the
> relfilenode mappings would be sufficent to nuke the backend storage,
> and what else needs doing?
Well, if you're inten
On Sat, Apr 24, 2010 at 1:38 PM, Tom Lane wrote:
> [ forgot to respond to this part ]
>
> Robert Haas 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
>> ne
>
> For a first cut, I had thought about ignoring the problem. Now, that
> may sound stupid, because now if two different backends have very
> different distributions of data in the table and both do an ANALYZE,
> one set of statistics will clobber the other set of statistics. On
> the flip side,
On Sat, Apr 24, 2010 at 1:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> At least AIUI, the use case for this feature is that you want to avoid
>> creating "the same" temporary table over and over again.
>
> The context that I've seen it come up in is that people don't want to
> clutter their fu
[ forgot to respond to this part ]
Robert Haas 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 remov
Robert Haas writes:
> At least AIUI, the use case for this feature is that you want to avoid
> creating "the same" temporary table over and over again.
The context that I've seen it come up in is that people don't want to
clutter their functions with create-it-if-it-doesn't-exist logic,
which you
On Sat, Apr 24, 2010 at 12:11 PM, Tom Lane wrote:
> "Greg Sabino Mullane" writes:
>>> surprised to find my clone unaffected? If it modifies both, how do we
>>> avoid complete havoc if the original has since been modified (perhaps
>>> incompatibly, perhaps not) by some other backend doing its own
"Greg Sabino Mullane" writes:
>> surprised to find my clone unaffected? If it modifies both, how do we
>> avoid complete havoc if the original has since been modified (perhaps
>> incompatibly, perhaps not) by some other backend doing its own ALTER
>> TABLE?
> Since this is such a thorny problem,
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>...
> surprised to find my clone unaffected? If it modifies both, how do we
> avoid complete havoc if the original has since been modified (perhaps
> incompatibly, perhaps not) by some other backend doing its own ALTER
> TABLE?
Since this is
2010/4/24 Robert Haas :
> A couple of recent threads made got me thinking again about the idea
> of global temporary tables. There seem to be two principal issues:
>
> 1. What is a global temporary table?
>
> 2. How could we implement that?
>
> Despite rereading the "idea: global temp tables" thre
On Fri, Apr 23, 2010 at 11:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 23, 2010 at 11:11 PM, Tom Lane wrote:
>>> I also kind of wonder what is supposed to happen if someone DROPs or
>>> ALTERs the temp table definition ...
>
>> ...not so much. Here you REALLY want a DROP attempt
Robert Haas writes:
> On Fri, Apr 23, 2010 at 11:11 PM, Tom Lane wrote:
>> I also kind of wonder what is supposed to happen if someone DROPs or
>> ALTERs the temp table definition ...
> ...not so much. Here you REALLY want a DROP attempt to acquire an
> AccessExclusiveLock that will conflict wi
On Fri, Apr 23, 2010 at 11:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> A couple of recent threads made got me thinking again about the idea
>> of global temporary tables. There seem to be two principal issues:
>
>> 1. What is a global temporary table?
>
>> 2. How could we implement that?
>
>
Robert Haas writes:
> A couple of recent threads made got me thinking again about the idea
> of global temporary tables. There seem to be two principal issues:
> 1. What is a global temporary table?
> 2. How could we implement that?
> Despite rereading the "idea: global temp tables" thread fro
42 matches
Mail list logo
