Re: including backend ID in relpath of temp rels - updated patch

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Aug 6, 2010 at 1:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Really? Surely that should be illegal during normal operation. We
>> might be doing such during crash recovery, but we don't need to
>> broadcast sinval messages then.

> autovacuum.c does it when we start to worry about XID wraparound, but
> you can also do it from any normal backend. Just "DROP TABLE
> pg_temp_2.foo" or whatever and away you go.

Mph. I'm still not convinced that the sinval message needs to carry
backendid. But maybe the first-cut solution should just be to squeeze
the id into the padding area. You should be able to get up to 65535
allowed backends, not 32k --- or perhaps use different message type IDs
for local and global backendid, so that all 65536 bitpatterns are
allowed for a non-global backendid.

> Well, presumably we'd just represent it as a 1-byte field followed by
> a 2-byte field, and do a bit of math. But I don't really see the
> point. The whole architecture of a shared invalidation queue is
> fundamentally non-scalable because it's a broadcast medium.

Sure, it tops out somewhere, but 32K is way too close to configurations
we know work well enough in the field (I've seen multiple reports of
people using a couple thousand backends). In any case, sinval readers
don't block each other in the current implementation, so I'm really
dubious that there's any inherent scalability limitation there. I'll
hold still for 64K but I think it might be better to go for 2^24.

regards, tom lane