On Thu, Feb 28, 2019 at 7:02 PM Thomas Munro wrote:
> The type smgr has only one value 'magnetic disk'. ~15 years ago it
> also had a value 'main memory', and in Berkeley POSTGRES 4.2 there was
> a third value 'sony jukebox'. Back then, all tables had an associated
> block storage manager, and
On Fri, Mar 1, 2019 at 9:11 PM Konstantin Knizhnik
wrote:
> One more thing... From my point of view one of the drawbacks of Postgres
> is that it requires underlaying file system and is not able to work with
> raw partitions.
> It seems to me that bypassing fle system layer can significantly
On 01.03.2019 1:32, Thomas Munro wrote:
On Fri, Mar 1, 2019 at 10:41 AM Shawn Debnath wrote:
On Fri, Mar 01, 2019 at 10:33:06AM +1300, Thomas Munro wrote:
It doesn't make any sense to put things like clog or any other SLRU in
a non-default tablespace though. It's perfectly OK if not all
On Fri, Mar 1, 2019 at 11:31 AM Shawn Debnath wrote:
> On Thu, Feb 28, 2019 at 02:08:49PM -0800, Andres Freund wrote:
> > On 2019-03-01 09:48:33 +1300, Thomas Munro wrote:
> > > On Fri, Mar 1, 2019 at 7:24 AM Andres Freund wrote:
> > > > On 2019-02-28 13:16:02 -0500, Tom Lane wrote:
> > > > >
On Fri, Mar 1, 2019 at 10:41 AM Shawn Debnath wrote:
> On Fri, Mar 01, 2019 at 10:33:06AM +1300, Thomas Munro wrote:
> > It doesn't make any sense to put things like clog or any other SLRU in
> > a non-default tablespace though. It's perfectly OK if not all smgr
> > implementations know how to
Andres Freund writes:
> FWIW, I think while distasteful, I could see us actually using oids,
> just ones that are small enough to fit into 16bit...
If we suppose that all smgrs must be built-in, that's not even much
of a restriction...
regards, tom lane
On 2019-03-01 09:48:33 +1300, Thomas Munro wrote:
> On Fri, Mar 1, 2019 at 7:24 AM Andres Freund wrote:
> > On 2019-02-28 13:16:02 -0500, Tom Lane wrote:
> > > Shawn Debnath writes:
> > > > Another thought: my colleague Anton Shyrabokau suggested potentially
> > > > re-using forknumber to
On Fri, Mar 1, 2019 at 4:09 AM Tom Lane wrote:
> Thomas Munro writes:
> > On Thu, Feb 28, 2019 at 7:37 PM Tom Lane wrote:
> >> Thomas Munro writes:
> >>> Our current thinking is that smgropen() should know how to map a small
> >>> number of special database OIDs to different smgr
On Fri, Mar 1, 2019 at 7:24 AM Andres Freund wrote:
> On 2019-02-28 13:16:02 -0500, Tom Lane wrote:
> > Shawn Debnath writes:
> > > Another thought: my colleague Anton Shyrabokau suggested potentially
> > > re-using forknumber to differentiate smgrs. We are using 32 bits to
> > > map 5 entries
On 2019-02-28 13:16:02 -0500, Tom Lane wrote:
> Shawn Debnath writes:
> > On Thu, Feb 28, 2019 at 10:35:50AM -0500, Robert Haas wrote:
> >> Also, I don't see why we'd need a fake pg_database row in the first
> >> place. IIUC, the OID counter wraps around to FirstNormalObjectId, so
> >> nobody
Shawn Debnath writes:
> On Thu, Feb 28, 2019 at 10:35:50AM -0500, Robert Haas wrote:
>> Also, I don't see why we'd need a fake pg_database row in the first
>> place. IIUC, the OID counter wraps around to FirstNormalObjectId, so
>> nobody should have a database with an OID less than that value.
Hi,
On 2019-02-28 10:02:46 -0800, Shawn Debnath wrote:
> We have scripts under catalog directory that can check to ensure OIDs
> aren't re-used accidentally. However, we still have to define an entry
> in a catalog somewhere and I was proposing creating a new one,
> pg_storage_managers?, to
Robert Haas writes:
> On Thu, Feb 28, 2019 at 1:03 AM Thomas Munro wrote:
>> Nothing seems to break if you remove it (except for some tests using
>> it in an incidental way). See attached.
> FWIW, +1 from me.
To be clear, I'm not objecting to the proposed patch either. I was
just wondering
On Thu, Feb 28, 2019 at 11:06 AM Tom Lane wrote:
> It's certainly possible/likely that we're going to end up needing to
> widen buffer tags to represent the smgr explicitly, because some use
> cases are going to need a real database spec, some are going to need
> a real tablespace spec, and some
Robert Haas writes:
> My first intuition was the same as yours -- that we should use the
> tablespace to decide which smgr is relevant -- but I now think that
> intuition was wrong. Even if you use the tablespace OID to select the
> smgr, it doesn't completely solve the problem you're worried
On Thu, Feb 28, 2019 at 10:09 AM Tom Lane wrote:
> The real reason I'm concerned about this, though, is that for either
> a database or a tablespace, you can *not* get away with having a magic
> OID just hanging in space with no actual catalog row matching it.
> If nothing else, you need an entry
Thomas Munro writes:
> On Thu, Feb 28, 2019 at 7:37 PM Tom Lane wrote:
>> Thomas Munro writes:
>>> Our current thinking is that smgropen() should know how to map a small
>>> number of special database OIDs to different smgr implementations
>> Hmm. Maybe mapping based on tablespaces would be a
On Thu, Feb 28, 2019 at 1:03 AM Thomas Munro wrote:
> The type smgr has only one value 'magnetic disk'. ~15 years ago it
> also had a value 'main memory', and in Berkeley POSTGRES 4.2 there was
> a third value 'sony jukebox'. Back then, all tables had an associated
> block storage manager, and
On Thu, Feb 28, 2019 at 5:37 PM Tom Lane wrote:
> Thomas Munro writes:
> > On Thu, Feb 28, 2019 at 7:08 PM Tom Lane wrote:
> >> I agree that smgrtype as it stands is pretty pointless, but what
> >> will we be using instead to get to those other implementations?
>
> > Our current thinking is
On Thu, Feb 28, 2019 at 7:37 PM Tom Lane wrote:
> Thomas Munro writes:
> > On Thu, Feb 28, 2019 at 7:08 PM Tom Lane wrote:
> >> I agree that smgrtype as it stands is pretty pointless, but what
> >> will we be using instead to get to those other implementations?
>
> > Our current thinking is
Thomas Munro writes:
> On Thu, Feb 28, 2019 at 7:08 PM Tom Lane wrote:
>> I agree that smgrtype as it stands is pretty pointless, but what
>> will we be using instead to get to those other implementations?
> Our current thinking is that smgropen() should know how to map a small
> number of
On Thu, Feb 28, 2019 at 7:08 PM Tom Lane wrote:
> Thomas Munro writes:
> > Motivation: A couple of projects propose to add new smgr
> > implementations alongside md.c in order to use bufmgr.c for more kinds
> > of files, but it seems entirely bogus to extend the unused smgr type
> > to cover
Thomas Munro writes:
> Motivation: A couple of projects propose to add new smgr
> implementations alongside md.c in order to use bufmgr.c for more kinds
> of files, but it seems entirely bogus to extend the unused smgr type
> to cover those.
I agree that smgrtype as it stands is pretty
Hello hackers,
The type smgr has only one value 'magnetic disk'. ~15 years ago it
also had a value 'main memory', and in Berkeley POSTGRES 4.2 there was
a third value 'sony jukebox'. Back then, all tables had an associated
block storage manager, and it was recorded as an attribute relsmgr of
24 matches
Mail list logo
