Of course the Postgres website lists several community resources which I would encourage you to check out, but given the recent kerfuffle with the freenode irc community I thought it might be good to highlight some additional options. Luckily there are a bunch of them out there, and they are all free to join. The following list is not exhaustive by any means, but these are the regular postgres gatherings that I visit at least occasionally and I think you’ll be able to get something out of as well.
PostgresTeam.Slack.com - Ok, this one is listed on the community page, but since I use slack regularly for work, the Postgres slack team has become my daily driver. The #general channel serves as the primary spot for general Q&A, but there are also topic specific channels like #pgbackrest and #patroni, not to mention general information channels like #postgres-job-offers and #pgsql-commits. So far we’ve had over 10,000 people sign-up for the Postgres slack, and the community continues to grow at a steady pace. If you’ve not used slack before, one of the nice things about it is it has excellent clients for the desktop, through your favorite web browser, and even on mobile; just in case you need to get your postgres fix on the go. (What? I can’t be the only one!)
Stackoverflow - Well, technically https://dba.stackexchange.com, but in any case, your favorite technical question / answer site has a site dedicated to databases. While I have a lot of concerns about the recent purchase, I don't see anything that comes close to an alternative given what it offers. One of the nice things about stackexchange is that it works a little better for long form questions that require more detail and less back-and-forth troubleshooting like you might do on Slack. It also better embraces the asynch nature of the web, which is not to say that you’ll have to wait long, the community there is pretty active and answers can often come in minutes. Oh, if you go now, they are running their annual Developer Survey; if you sign up be sure to represent the Postgres community :-)
The Postgres blogging community is also pretty active, and you can certainly get a lot of good information through posts, and get some questions answered via comments on those topics. While I don’t have a dedicated process for reading Postgres blogs, I find that I do end up coming back to certain ones time and again. If you don’t have a favorite, just keep the Planet Postgres site handy and you'll have the chance to check out many of the most active Postgres bloggers and assemble your own list.
Of course there is always twitter. Best for quick questions and finding out what's new in the world of Postgres, many folks in the community are active and willing to answer (short!) questions on twitter. While there aren’t any official hashtags, I’d recommend following (or tagging) tweets with #postgres or #postgresfriends (or #pghelp if you're optimistic) to get started, and through those you’ll be able to uncover active community members that might also be worth following.
Finally I also want to give a nod to IRC. I’ve been visiting the postgres channel on freenode for nearly 20 years and while the recent changes were a tad depressing the community members on IRC have bailed me out plenty of times, and I'm certainly thankful for thier help over the years. You can read the official migration announcement about the irc team moving to the Libera Chat network, and the Libera Chat folks also have some nice docs on access IRC, whether through a dedicated IRC client or through a web based client (I'm currently trialing this). The primary community channel on IRC is #postgresql, but there are a number of other options; check out the community irc page for more info. If you don’t like Slack for some reason and want to do chat, IRC is still a nice option.
As I mentioned before, this list is certainly not exhaustive. If you don’t like these options, you’re only a google search away from other ones, especially if you are looking for regional or language specific options.
In my experience most of these groups are quite welcoming to new users and happy to answer questions on all sorts of Postgres related topics. Of course, given the distributed nature of the project, and being on the internet in general, you are likely to encounter all different sorts of opinions and folks living in their own world; remember to approach new things with an open mind and find the right fit for you.
]]>select now();
for my actual query, as it's a bit more illustrative.)
```
pagila=# select now(); \g 10
now
2020-11-14 17:37:50.694618-05 (1 row)
pagila=# select now();
now
2020-11-14 17:37:56.045518-05 (1 row)
pagila=# \g
now
2020-11-14 17:37:58.133626-05 (1 row)
pagila=# \g 10
pagila=#
``
My first attempt, without any thought really, was that the right syntax for this was
\g 10. When it didn't work, I stepped through the idea, first verifying my select was good, then verifying
\gworked as expected, and then trying the
\g 10` on it's own. When that didn't work, I double checked the docs and then hit irc to ask if anyone remember that syntax working... of course the answer was no.
If you are wondering, I think I was conflating \g
(which among other things causes psql to either execute the query on the line or re-run the previous query) with \w
which also re-runs the previous query, but takes an argument equal to the number of seconds to delay between each run; so \w 10
will "watch" your query every 10 seconds for eternity.
So, that didn't work, so how to do this easily? Well, the best suggestion from irc was to wrap the query in a quick shell loop, which I admit is a simpel enough way to solve this, but to be honest I wanted an sql level way to handle this. The most obvious solution there was to wrap the query into a DO
script and just loop through 10 times, but even that felt more cumbersome than it should have been, not to mention that would have put all 10 queries in the same transaction context, which probably didn't matter, but wasn't something I wanted to think about.
And that's when \gexec
popped into my head. Ok, it doesn't hurt I had just read the docs; but postgres has such a large feature set that even us old timers forget all the things it can do. For the record, the docs describe \gexec
as so:
Sends the current query buffer to the server, then treats each column of each row of the query's output (if any) as a SQL statement to be executed.
Ok, there's actually more, so go check out the docs, but the main part here was if I could just generate the query enough times, then I could use \gexec
to run it for me. Of course anytime you're dealing with loops at the SQL level, generate_series()
should come to mind, and so marrying the two, you get:
```
pagila=# select 'select now();' from generate_series(1,10) \gexec
now
2020-11-14 17:58:06.963936-05 (1 row)
now
2020-11-14 17:58:06.964205-05 (1 row)
now
2020-11-14 17:58:06.964411-05 (1 row)
now
2020-11-14 17:58:06.96467-05 (1 row)
now
2020-11-14 17:58:06.964953-05 (1 row)
now
2020-11-14 17:58:06.965214-05 (1 row)
now
2020-11-14 17:58:06.96544-05 (1 row)
now
2020-11-14 17:58:06.965713-05 (1 row)
now
2020-11-14 17:58:06.965962-05 (1 row)
now
2020-11-14 17:58:06.966218-05
(1 row)
``
By using
generate_series()` I can generate exactly how many copies of the statement I want (and dynamically substituate in info as needed) and each query will run as it's own statement, all without leaving psql. It's the little things eh?
Note: If you like this post and think \gexec
is going to be a usefel addition for your tool box, you may be equally excited to know that just this week Postgres released a round of security fixes which includes a fix for a nasty exploit involving \gexec
. Yeah, that sucks, but maybe now you'll get some value out of the thing you have to patch. Take what you can get, it's 2020.
Note redux: Thats what I get for not double checking. The security fix was for \gset
, not \gexec
. Apologies for any confusion and/or if you accidentally upgraded your database because of my post.
This release incorporates the following changes:
Note this release drops support for PHP 7.1, and will be the last release to support PHP 7.2.
For more information on phpPgAdmin, check out our project page at https://github.com/phppgadmin/phppgadmin/
You can download the release at: https://github.com/phppgadmin/phppgadmin/releases/tag/REL_7-13-0
For complete details of changes, please see the HISTORY file and/or commit logs. We hope you find this new release helpful!
Package verification codes:
shasum 6.01
This release incorporates the following changes:
Note this new version now requires support for the mbstring module in PHP.
For more information on phpPgAdmin, check out our project page at https://github.com/phppgadmin/phppgadmin/
You can download the release at: https://github.com/phppgadmin/phppgadmin/releases/tag/REL_7-12-1
Special thanks to Jean-Michel Vourgère, who supplied a number of significant patches and updates towards this release. For complete details of changes, please see the HISTORY file and/or commit logs. We hope you find this new release helpful!
]]>Join, or Die
Because the Postgres project has no single owner, the Postgres community has always been a little bit fractured and doesn't always speak with one voice. As users, this means the community can look rather different depending on which vendors you work with, the country you live in, the tooling you use, or the online communities you interact with. Since these different groups aren't always as coordinated as one would hope, initiatives like this can sometimes be harder to push forward, and I think this survey did suffer from that; it only made it out to about 500 people which is a pretty small subset, and you have to keep this in mind before making too large of conclusions about what you see in the data.
Slow and steady growth
39% of respondents have been using Postgres for less than 5 years, with 10% having started within the last 2 years. I've seen surveys from communities where they suddenly catch fire and 50% have used it in less than a year, and 90% less than two years (rhymes with shmocker?) and it becomes really hard for those communities to manage that, so this seems like a positive, and helps confirm that Postgres is growing at a solid pace, but not in a way that is likely to be damaging for the community.
You do what now?
Technical titles are hard, but with more than half of the survey respondents reporting some kind of developer-oriented job title, and 50% saying they work in software companies, it is again a good reminder that Postgres isn't just for DBA's, and that most peoples interactions with the software are coming from non-traditional outlets. I've spent some time coordinating between the Postgres Funds Group and The U.S. PostgreSQL Association this year to ensure a presence at shows like Pycon, Railsconf, and All Things Open, among others, and I hope to see this trend continue into next year.
About those clouds
The answers related to running Postgres on-prem vs the cloud were a bit hard to decipher. We can safely assume about 1/3 of folks are running on fully managed Postgres, but we don't know how many of those people are also manually managing instances as well. (We do both and I expect others do the same depending on the size/scope of their deployment needs). I feel like I could make a hand-wavey argument that at least 15% of overall respondents are AWS customers, which seems like a pretty big number and will for some will probably exacerbate the rumblings that, relative to their code contributions, Amazon is not contributing their fair share. Granted that isn't as surprising as the data on the other cloud providers; Azure/Citus didn't even rank in the poll, which I just have to attribute to a skew based on Timescale's reach, especially since GCP got a hefty 18%, which seems amazing considering how they have managed their Postgres offerings. (I have friends at GCP and I like the platform in general, but Postgres seems like a second class citizen the way they are currently running things)
Those quotes
Oy vey. I'm not sure if Timescale was picking quotes just to stir up some controversy (there are certainly more friendly ones in the raw data), but the quotes about NoSQL are a bit off-putting. This is an area where the community needs to continue improving because we have a reputation for sometimes being "stand-offish". Not in all cases of course, but if you want to find people with strong opinions who are not afraid to speak out, the Postgres community has lots of them. (Perhaps this blog post is a case in point) Anyway, given at least 50% of respondents are using at least one NoSQL system in conjunction with Postgres; and based on modern infrastructure patterns that isn't going to change; we need to learn to focus on helping people where they are, rather than where we think they should be, and being less abrasive about it in general.
All in all, I hope this information will be useful for the community, and I want to thank the Timescale folks for publishing the results (and the raw data), and I hope they will continue to do this and/or work within the community to expand the reach of this survey next year.
]]>