4 ms·

Ok but postgres is the wrong choice for everything - never ever have I seen a database so out of touch with actual database requirements. Working replication -

Ok but postgres is the wrong choice for everything - never ever have I seen a database so out of touch with actual database requirements. Working replication - barely and still awful 2 decades after MySQL In place upgrades - nope Access control that doesn't require root access to filesystem - nope The list goes on... Disclosure: I do postgres in production for 10000s of machines in like 49 countries, I understand how databases work and have been doing this for 20 odd years, it's a bad choice because postgres is written by purists, not people who deal with it in the real world.

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.
pritambaral 4y ago
Funny you say that, because I got the same feeling from MySQL. I mean, dropping data, ignoring constraints, all done silently. A database that cannot keep my data safe is just not a database.
- throwaway67743 4y ago
  Ah yes, the old MySQL sucks argument based entirely on a bug fixed a decade ago
  - pritambaral 4y ago
    I'm not trying to pick a fight with you. Nor am I trying to say "MySQL sucks". I'm commiserating with you, or at least trying to, at your level. You're the one bursting in here shouting "Postgres sucks!" "based entirely" on a lack of features added more than "a decade ago". You have your choices, we have ours. You'd rather have the convenience of features, even at the risk of losing your data; we'd rather have the peace of mind of knowing our data is safe, and build features that don't exist out of whatever else we have, however we can. It's not always about what bugs or features exist or don't exist now. It's also about the nature of a project and how it's developed, and how it's going to evolve or otherwise behave in the future. After all, we're talking about databases here; we trust our data to them.

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.

pritambaral 4y ago

Funny you say that, because I got the same feeling from MySQL. I mean, dropping data, ignoring constraints, all done silently. A database that cannot keep my data safe is just not a database.

throwaway67743 4y ago
Ah yes, the old MySQL sucks argument based entirely on a bug fixed a decade ago
- pritambaral 4y ago
  I'm not trying to pick a fight with you. Nor am I trying to say "MySQL sucks". I'm commiserating with you, or at least trying to, at your level. You're the one bursting in here shouting "Postgres sucks!" "based entirely" on a lack of features added more than "a decade ago". You have your choices, we have ours. You'd rather have the convenience of features, even at the risk of losing your data; we'd rather have the peace of mind of knowing our data is safe, and build features that don't exist out of whatever else we have, however we can. It's not always about what bugs or features exist or don't exist now. It's also about the nature of a project and how it's developed, and how it's going to evolve or otherwise behave in the future. After all, we're talking about databases here; we trust our data to them.