| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | constzl <const_sunny(at)126(dot)com> |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: ran out of space in relation map |
| Date: | 2019-08-24 05:58:22 |
| Message-ID: | 7235.1566626302@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
constzl <const_sunny(at)126(dot)com> writes:
> This means that the number of mapping objects can not be more than MAX_MAPPINGS, which is 62 now.
Yeah ...
> If one day in the future, it does need to be more than 62, then what to do?
Rethink your design? The current system is not close to running
out of those slots, and I can't see any good reason for a large
increase in the number of shared catalogs.
If our backs were against the wall, we could rearrange things
on the assumption that the OIDs of mapped catalogs must fit in
16 bits, which would make room for 80 or so slots without
having to worry about torn writes. We could also be a bit
charier about how many of these catalogs actually need toast
tables ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | constzl | 2019-08-24 06:32:28 | Re:Re: ran out of space in relation map |
| Previous Message | constzl | 2019-08-24 03:48:09 | ran out of space in relation map |