"John D. Burger" <john@xxxxxxxxx> writes: > Someone talked about the postmaster having to be "at arms' length" > from the actual tables. But I was looking at the postmaster code, > and it seems to fork a new backend as soon as select indicates > there's a new request, without checking authorization or anything > first. So why can't the new backend query the user table as normal? > Even if shared buffers are trashed, that'll only take down the new > backend, not the original postmaster, right? Well, the current design is that the postmaster has a copy of the flat file in memory, which is inherited by backends across the fork(), and so they can query it at small cost. For the normal situation where the list of users isn't changing very rapidly, this is probably faster than your suggestion would be. The issue to make it work like you suggest is that there's not presently any way to query tables until *after* you have selected and connected to a particular database. So you'd still need a flat file representing pg_database, plus it's unclear how you'd implement some of pg_hba.conf's options like "samegroup". Since the tables you need to touch are all shared, it's conceivable that this could be hacked around, but it seems awfully messy. Another consideration is that this'd significantly increase the amount of work done before validating that the connection request is authorized, thus perhaps making it easier to mount a DOS attack on the postmaster (though admittedly a blackhat with access to the postmaster port can probably cause trouble anyway just from the "fork bomb" effect). regards, tom lane
