On Fri, Aug 6, 2010 at 2:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Aug 6, 2010 at 1:14 PM, Tom Lane <tgl@sss.pgh.pa.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.
Hey, if you have an idea... I'd love to get rid of it, too, but I
don't see how to do it.
> 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.
Well, I wouldn't expect anyone to use an exclusive lock for readers
without a good reason, but you still have n backends that each have to
read, presumably, about O(n) messages, so eventually that's going to
start to pinch.
Do you think it's worth worrying about the reduction in the number of
possible SI message types?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company