5 ms·

Not sure what you’re talking about wrt. access control, but PostgreSQL replication works just fine for most people, and the lack of in-place upgrades isn’t real

by mikl 4y ago

Not sure what you’re talking about wrt. access control, but PostgreSQL replication works just fine for most people, and the lack of in-place upgrades isn’t really a problem unless you’re working on a massive scale with no downtime tolerance. You run things at an unusual scale, you have unusual problems.

throwaway67743 4y ago
Having to edit a flat file for access control is absurd, perhaps 2 decades ago when it was common sure but everyone figured out how to do it without, also it's not really at that much scale when every other database implementation makes this painless (even Oracle!) Postgres still lacks basically everything that other replication implementations do, if they have to mention log shipping by rsync etc they've already got it wrong. For clarity they only recently figured out "streaming" replication which again, is what everyone else has been doing for years.
- throwaway67743 4y ago
  Annoyingly can't reply to your reply below but: Replication can't (unless it's changed recently) be granted via ddl, and isn't propagated either - but otherwise sure It's not just that though, the general behaviour is counter to how real world deployments work, like for example basically anyone at scale moving away to something else because the admin and operational overhead is way too much
  - deleted 4y ago
    [deleted]
  - pritambaral 4y ago
    > Replication can't (unless it's changed recently) be granted via ddl, and isn't propagated either - but otherwise sure It can, and is, at least as of the five year old (and now unsupported) release 10.
    - throwaway67743 4y ago
      "Client authentication for replication is controlled by a pg_hba.conf record specifying replication in the database field. For example, if the standby is running on host IP 192.168.1.100 and the account name for replication is foo, the administrator can add the following line to the pg_hba.conf file on the primary:" https://www.postgresql.org/docs/current/warm-standby.html#STREAMING-REPLICATION https://www.postgresql.org/docs/current/warm-standby.html#ST...
- mikl 4y ago
  Again, not sure what you’re talking about here. `pg_hba.conf`? Normally you don’t need to modify that regularly (if ever). Normal access control can be done with GRANTs, just like MySQL or Oracle. As for streaming replication, that was added in PostgreSQL 9.0, six major versions ago. Sure, it was late to the party, but it’s not exactly a recent addition.
  - throwaway67743 4y ago
    Ah for some reason I can reply now: Regardless being 2 decades late to the party is unacceptable - it's still not complete and makes real world management a chore, I still admire the purist attitude it has its place but you can't also then claim it's a useful competitor - which is what they do. Unfortunately it's a perl postgres vs the world thing - both are irrelevant.
    - mikl 4y ago
      That they were late to the party doesn’t really matter _now_. It might have mattered five years ago. As for the config, one might argue that reconfiguring replication isn’t a common task, usually something you do when setting up the cluster and never mess with again. I understand that there are pain points running PostgreSQL at massive scale. But 99.9% of projects needing a database never reach that scale. And once they do, they probably need to re-engineer big chunks of the application anyway.
      - throwaway67743 4y ago
        Well this is one aspect - application should not have to care about underlying db topology - if it does then the db is wrong, my main issue tbh is that other databases implement the inevitable like proxying or sharing while postgres leaves it to horrific perl scripts from the last century, it's really not admissable as a production solution
        pritambaral 4y ago
        > while postgres leaves it to horrific perl scripts from the last century Your knowledge of what Postgres supports and how to administrate it seems to be a few years out of date. There's plenty of examples in this thread alone.

by mikl 4y ago

throwaway67743 4y ago

Having to edit a flat file for access control is absurd, perhaps 2 decades ago when it was common sure but everyone figured out how to do it without, also it's not really at that much scale when every other database implementation makes this painless (even Oracle!) Postgres still lacks basically everything that other replication implementations do, if they have to mention log shipping by rsync etc they've already got it wrong. For clarity they only recently figured out "streaming" replication which again, is what everyone else has been doing for years.

throwaway67743 4y ago
Annoyingly can't reply to your reply below but: Replication can't (unless it's changed recently) be granted via ddl, and isn't propagated either - but otherwise sure It's not just that though, the general behaviour is counter to how real world deployments work, like for example basically anyone at scale moving away to something else because the admin and operational overhead is way too much
- deleted 4y ago
  [deleted]
- pritambaral 4y ago
  > Replication can't (unless it's changed recently) be granted via ddl, and isn't propagated either - but otherwise sure It can, and is, at least as of the five year old (and now unsupported) release 10.
  - throwaway67743 4y ago
    "Client authentication for replication is controlled by a pg_hba.conf record specifying replication in the database field. For example, if the standby is running on host IP 192.168.1.100 and the account name for replication is foo, the administrator can add the following line to the pg_hba.conf file on the primary:" https://www.postgresql.org/docs/current/warm-standby.html#STREAMING-REPLICATION https://www.postgresql.org/docs/current/warm-standby.html#ST...
mikl 4y ago
Again, not sure what you’re talking about here. `pg_hba.conf`? Normally you don’t need to modify that regularly (if ever). Normal access control can be done with GRANTs, just like MySQL or Oracle. As for streaming replication, that was added in PostgreSQL 9.0, six major versions ago. Sure, it was late to the party, but it’s not exactly a recent addition.
- throwaway67743 4y ago
  Ah for some reason I can reply now: Regardless being 2 decades late to the party is unacceptable - it's still not complete and makes real world management a chore, I still admire the purist attitude it has its place but you can't also then claim it's a useful competitor - which is what they do. Unfortunately it's a perl postgres vs the world thing - both are irrelevant.
  - mikl 4y ago
    That they were late to the party doesn’t really matter _now_. It might have mattered five years ago. As for the config, one might argue that reconfiguring replication isn’t a common task, usually something you do when setting up the cluster and never mess with again. I understand that there are pain points running PostgreSQL at massive scale. But 99.9% of projects needing a database never reach that scale. And once they do, they probably need to re-engineer big chunks of the application anyway.
    - throwaway67743 4y ago
      Well this is one aspect - application should not have to care about underlying db topology - if it does then the db is wrong, my main issue tbh is that other databases implement the inevitable like proxying or sharing while postgres leaves it to horrific perl scripts from the last century, it's really not admissable as a production solution
      - pritambaral 4y ago
        > while postgres leaves it to horrific perl scripts from the last century Your knowledge of what Postgres supports and how to administrate it seems to be a few years out of date. There's plenty of examples in this thread alone.