It depends on the settings of the subscriber. In the canonical demo:
ros::Subscriber sub = n.subscribe("chatter", 1000, chatterCallback);
That 1000 isn't just there for fun ;-). That's the the queue size you're setting of messages to keep backed up until it can process them. So if you're using a single threaded executor (which you are if you do ros::spin()) the callback will be called once to process that message, then the second message comes in, and it'll be added to the callback queue to process once the first message is done.
Lets game this out all the way, lets say you have a callback that takes 1 second to process a message and you have a callback queue of size 10, but its getting a topic published at 100hz. That means that the first 10 messages from time t = 0 to t = 0.11 will be queued up or processed (0.01 because the first message is being processed and now we have 10 to fill the queue). After that point, all of the new messages will replace the existing messages in the queue and there will be a bunch of messages thrown out and never correctly processed.
If you set the queue size to 0, then it will have an infinite queue and you'll get lag like you wouldn't believe, in this extreme case, that keeps growing and growing since you throw out no messages.
This is one of several reasons why if you're working with high rate data, a buffer can be a useful thing. This helps make it so that you add new messages to a buffer and then you have a separate thread process that data on a timer so that you can make sure that your callback isn't blocking new data coming in. If you're doing something simple like adding a few numbers or extracting a value, its not a problem. If you're running ICP over the pointclouds and you need to make sure you're not dropping messages, you should use a buffer.
