This is no doubt a very basic quiesting, but I have not been able to find any clear information to answer it…
If I use a windon with size 640x480 pixels to create a context, then that results in a render buffer size 640x480, right?
If I now resize my window to say 1024x768 then what? Will the render buffer automatically resize so it now generates 1024x768 pixels in a render pass, or is it still the original size?
It seems quite evident (from visua inspection) to me that the resize results in more pixels being rendered, but since this is not the default behavior in DX, I feel in need of confirmation for my observations.
Whenever I resize my window, the underlying backbuffer also resizes, resulting in some deallocation and allocation of memory on the graphics card?
Thanks in advance for any concrete info related to this 
At least 640x480 pixels yes (not bytes).
How many bytes there are per pixel avg depends on things such as your AA mode, what buffers/attachments you’ve requested as part of your framebuffer, and internal GPU/driver details. The driver may allocate more pixels than your window res to make internal computations easier, suppress some reallocs when windows are resized, etc.
If I now resize my window to say 1024x768 then what? Will the render buffer automatically resize so it now generates 1024x768 pixels in a render pass, or is it still the original size?
The former, except that it merely resizes the underlying framebuffer to at least 1024x768. When you say you resize your window, you are resizing the framebuffer underlying the window too.
Note that to take advantage of those extra pixels, you actually have to issue a new glViewport command, when you sense that the window has been resized, so that your render passes actually draw to those extra pixels.
Whenever I resize my window, the underlying backbuffer also resizes, resulting in some deallocation and allocation of memory on the graphics card?
Should, yes.
You can use NVX_gpu_memory_info (or ATI_meminfo probably) to put some actual numbers on your question. That’s one of the cool things about these extensions. You can see how much memory is “lopped off the top” of GPU memory when you create a framebuffer of a specific configuration, so you know how much space is left for textures, VBOs, and such, which reduces of the chance of “trashing” GPU memory.
Thanks for the confirmation. That was what I needed to be sure I was going the right direction.