Postgres can scale up to as many processors as you want to install, and your OS can handle/manage effectively. You can install Postgres on a 128 core machine (or even a machine with 128 physical processors) and it will work fine. It may even work better than on a 64 core machine if the OS scheduler can handle that many cores.

Postgres has been shown to scale linearly up to 64 cores (with caveats: We're talking about read performance, in a specific configuration (disk, RAM, OS, etc.) -- Robert Haas has a blog article with a nice graph which I've reproduced below:

What's important about this graph?

The relationship is linear (or nearly so) as long as the Number of Clients is less than or equal to the Number of Cores, and then begins what looks to be roughly a log-linear decrease in performance as you have more client connections than you do cores to run Postgres backends on because the backends start fighting for the CPU (load average goes above 1.0, etc...).

While it has only been demonstrated for up to 64 cores, you can generalize that you can keep adding cores (and clients) and keep improving performance, up to the limit of some other subsystem (disk, memory, network) where processes are no longer having CPU contention problems but are instead waiting on something else.

(Haas also has another article where they proved linear scalability to 32 cores which has some great reference material on scalability in general -- highly recommended background reading!)

No it's a very precise statistic. A "logical processor" is a core. And a core is just that, it doesn't matter how they're spread over physical processors.

And if you're dealing with a machine with more cores than the supported number, this shouldn't be an issue with PostgreSQL. Each connection is inherently single-threaded* so whatever number of cores you have is what's going to limit the efficiency and efficacy of concurrent connections.

Needless to say this also means you should put your money in faster cores than quantity of cores unless you want to cluster things in a more complicated method.

_{* 2017 Update: Some queries (or subqueries) may be executed in parallel.}

Others have clarified that a logical processor generally refers to a CPU core, but I do want to comment on the statement that it doesn't matter how cores are spread over CPUs.

You can have caches on the CPU die that are shared among cores or that are dedicated to single or subgroups of cores. For example, one common config is dedicated L1 cache and shared L2 cache. In this instance, the scalability of a single dual core CPU can differ from two single core CPUs.

These scalability affects continue into main memory, with NUMA machines exhibiting different behavior than non-NUMA.

I point these out only because the OP is discussing questions of scalability, whose answers are generally more nuanced than "program X can use Y CPU cores".

In this case, they mean multiple processors with fewer cores... Some of the talk is future-proofing. Some is marketing-speak.