Re: [GENERAL] GCC error while trying to install 9.4 via brew on MAC OS
Jimmy Jack wrote: > I sent the message, it is pending review due its size… meanwhile there is the > cache part I rejected it -- it contained 400kB of gcc output plus a second copy of the same thing in HTML format. I have no desire to pointlessly cause 3 GB of outgoing traffic in our mailing list server, when Tom just quoted the ~10 lines that matter. All that has been discovered about compression is now a forgotten art, it seems. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PSQL/pgAdmin - Column Completion
On Wed, Dec 31, 2014, at 12:01 PM, dvlsg wrote: > Yeah, I think that would be problematic. All other sql query > applications I've used in the past with autocomplete seem to parse the > entire query and find table references for autocompletion based on the > whole query, whereas psql seems to typically base autocomplete off of > the current cursor location and strings behind it without any > lookaheads (as far as I can tell -- I only took a brief look, and it's > been a long time since I've had to write C code). > > I suppose what I would really be looking for is something like the > vastly simplified query below, where pressing Ctrl+Space after each > "a." would provide a list of columns only for the table alias. > > SELECT a.Column1, a.Column2, a.Column3 FROM > public.a_table_for_querying a > > It looks like that would take a fairly significant bit of > work/overhaul to make the autocomplete parser look at the entire query > to find a list of used tables, and then find the list of available > columns based on that, if I'm reading the code correctly. > > I agree with that last sentiment, though -- I don't think a list of > every column from every table would be very helpful. Just ran across pgcli which does you what you want from the command line: https://github.com/amjith/pgcli > > > > Dave Lesage *Club **Speed, Inc.* *Software Engineer* 4740 Green River > Road, Suite #308 Corona, CA 92880 > > Email: [hidden email] 24 Hour Support: (877) 751-3200 International > Support: (951) 817-7073 > > This e-mail is covered by the Electronic Communications Privacy Act, > 18 USC §§ 2510-2521 and is legally privileged. This communication and > any accompanying document(s) are confidential and privileged. They are > intended for the sole use of the addressee. If you receive this > transmission in error, you are advised that any disclosure, copying, > distribution, or the taking of any action in reliance upon the > communication is strictly prohibited. If you have received this > communication in error, please contact Club Speed, Inc. at (877) > 751-3200. > > > View this message in context: Re: PSQL/pgAdmin - Column Completion[1] > Sent from the PostgreSQL - general mailing list archive[2] at Nabble.com. Links: 1. http://postgresql.nabble.com/PSQL-pgAdmin-Column-Completion-tp5832573p5832578.html 2. http://postgresql.nabble.com/PostgreSQL-general-f1843780.html -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PSQL/pgAdmin - Column Completion
That looks perfect. I'll look into it, and pass the link along to the pgAdmin developers. I did bring up the suggestion to Dave Page who was kind enough to take the auto complete request under consideration for the future when they get to later stages of the product. -- View this message in context: http://postgresql.nabble.com/PSQL-pgAdmin-Column-Completion-tp5832573p5833448.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] How to monitor locks (max_pred_locks_per_transaction)?
Andrey Lizenko wrote: > does max_locks_per_transaction limit all others modes of locks by > the same way? In the sense that the count of all other locks must be less than max_locks_per_transaction * max_connections, yes. Most other locks do not persist past the end of transactions or the closing of connections (advisory locks and locks related to prepared transactions being edge-case exceptions). No other types of locks have the granularity promotion -- most other locks showing in sp_locks are on relations or transactions. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] How to analyze a slowdown in 9.3.5?
I'm running 9.3.5 on a virtual machine with 5 cores and 24 GB of memory. Disk is on a SAN. I have a task that runs weekly that processes possibly as many as 120 months worth of data, one month at a time. Since moving to 9.3.5 (from 8.2!!) the average time for a month has been 3 minutes or less. However, when this job ran this Tuesday, it ran fine for a number of months, but then started slowing down dramatically, 300 minutes for one month and then 167 minutes for the next. I stopped and restarted postgresql, the next block also ran really slow (157 minutes.) I then rebooted the server and the remaining blocks ran at the usual fast speed again, so restarting postgresql didn't fix the problem but rebooting the server did. Looking at the logs, I see queries with a function call that would normally take no more than 100-200 milliseconds, usually far less, that were taking 100 seconds or longer. This function gets called thousands of times for each month, so that appears to be one source of the slowdown. I don't suspect a memory leak in the calling program (in php), because since moving to this server in December this weekly task has run several times over the same range of months, making pretty much the same function calls each time. I also ran the entire range several times during testing. One change made to the server since the previous week's run was that I moved up to the latest Centos kernel (Linux version 3.10.0-123.13.2.el7.x86_64). As far as I can tell, the other virtual servers weren't being slowed down, so I don't suspect problems with the virtual server or the SAN. If this happens again, what sorts of settings in postgresq.conf or other tools should I be using to try to track down what's causing this? -- Mike Nolan -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] unexpected PQresultStatus: 8 with simple logical replication
Hi all, I'm trying to learn about how to subscribe to events in a logical replication slot. I'm finding that the documentation is sparse and mostly focused on binary WAL replication. I'd like to get a toy example working where I can see changes in my terminal. I'm able to create a replication slot, but trying to start it results in the error in the subject of my email: psql "dbname=postgres replication=database user=postgres" -c "CREATE_REPLICATION_SLOT foobar LOGICAL test_decoding" slot_name | consistent_point | snapshot_name | output_plugin ---+--+---+--- foobar| 0/D9C59A60 | 127E-1| test_decoding (1 row) psql "dbname=postgres user=postgres" -c "SELECT slot_name, plugin, restart_lsn FROM pg_replication_slots" slot_name |plugin | restart_lsn ---+---+- foobar| test_decoding | 0/D9C59A28 (1 row) psql "dbname=postgres replication=database user=postgres" -c "START_REPLICATION SLOT foobar LOGICAL 0/D9C59A28" unexpected PQresultStatus: 8 Advice? Many thanks, Brent
Re: [GENERAL] How to analyze a slowdown in 9.3.5?
On 9.1.2015 23:14, Michael Nolan wrote: > I'm running 9.3.5 on a virtual machine with 5 cores and 24 GB of > memory. Disk is on a SAN. > > I have a task that runs weekly that processes possibly as many as > 120 months worth of data, one month at a time. Since moving to 9.3.5 > (from 8.2!!) the average time for a month has been 3 minutes or less. Congrats to migrating to a supported version! Please, comparison of the configuration used on 8.2 and 9.3.5 would be helpful (i.e. how you've updated the config on the new version?). > However, when this job ran this Tuesday, it ran fine for a number of > months, but then started slowing down dramatically, 300 minutes for > one month and then 167 minutes for the next. I stopped and restarted > postgresql, the next block also ran really slow (157 minutes.) I > then rebooted the server and the remaining blocks ran at the usual > fast speed again, so restarting postgresql didn't fix the problem > but rebooting the server did. What amounts of data are we talking about? Gigabytes? Tens of gigabytes? > > Looking at the logs, I see queries with a function call that would > normally take no more than 100-200 milliseconds, usually far less, > that were taking 100 seconds or longer. This function gets called > thousands of times for each month, so that appears to be one source > of the slowdown. But why are the functions taking so much longer? Are they eating CPU, I/O or are generally waiting for something (e.g. locks)? > > I don't suspect a memory leak in the calling program (in php), > because since moving to this server in December this weekly task has > run several times over the same range of months, making pretty much > the same function calls each time. I also ran the entire range > several times during testing. > > One change made to the server since the previous week's run was that > I moved up to the latest Centos kernel (Linux version > 3.10.0-123.13.2.el7.x86_64). And what was the previous kernel version? However, if it worked fine after rebooting the server, it may not be a kernel issue (unless it somehow depends on uptime). Is there something in the /var/log/messages? > As far as I can tell, the other virtual servers weren't being slowed > down, so I don't suspect problems with the virtual server or the SAN. > > If this happens again, what sorts of settings in postgresq.conf or > other tools should I be using to try to track down what's causing > this? Well, we don't know what the function is doing, so it'd be nice to get some basic description first. Is it querying the database? Is it inserting or updating large amounts of data? Or is it something more complex? Aside from that, some basic system stats would be really helpful, so that we can identify the bottleneck (is that a CPU, I/O, locking, ...). A few lines from these commands should give us some basic idea: iostat -x -k 5 vmstat -w 5 regards -- Tomas Vondrahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
