Re: [GENERAL] postgresql-9.5.3 compilation on Solaris SPARC
On Sat, May 21, 2016 at 1:04 AM, Tom Lane wrote: > Venkata Balaji N writes: > > "make" command is generating the following error while compiling > > postgresql-9.5.3 on Solaris SPARC. > > > Undefined first referenced > > symbol in file > > atomic_cas_64 port/atomics.o > > atomic_cas_32 port/atomics.o > > Hmm. Do you get any warnings about references to those functions earlier > in the build? > I do not see any such similar warnings earlier in the build. src/include/port/atomics/generic-sunpro.h cites these references > as authority for believing that those functions exist in Solaris: Yes, i could see the references mentioned in the above file. > >http://www.unix.com/man-page/opensolaris/3c/atomic_cas/ >http://docs.oracle.com/cd/E23824_01/html/821-1465/atomic-cas-3c.html > > I see that the first of those mentions it's for SunOS 5.11 whereas your > machine says it's 5.10 ... is it possible the functions were new in 5.11? > I am not 100% sure. By the error, what i understand is that for some reason PostgreSQL version 9.5.x is expecting the SunOS version to be more recent than 5.10. We would need to compile PostgreSQL-9.5.3 to upgrade our customer's production environments. We did not have problems compiling earlier versions of PostgreSQL. Regards, Venkata B N Fujitsu Australia
Re: [GENERAL] Thoughts on "Love Your Database"
> On May 20, 2016, at 1:43 PM, Guyren Howe wrote: > > On May 20, 2016, at 13:38 , Pierre Chevalier Géologue > wrote: >> >> Le 04/05/2016 18:29, Szymon Lipiński a écrit : >>> On the other hand, when I was trying to store all my logic in a >>> database, there was just one thing that made me hate it. Testing. >>> Testing the procedures inside the database was not easy, not funny, and >>> too much time consuming. >> >> Yes, very good point. > > Are there any best practices or tricks to make this easier? In-database unit tests help. pgTap is a decent framework for building that sort of test-suite in a way that'll play nice with reporting and CI tools. http://pgtap.org Cheers, Steve -- 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] PQcancel may hang in the recv call
On Thu, 2016-05-19 at 15:32 -0400, Tom Lane wrote: > Peter Juhasz writes: > > > > We've found a situation where canceling a query may cause the > > client to > > hang, possibly indefinitely. This can happen if the network > > connection > > fails in a specific way. > > ... > > However, if the network fails in a way that the connection appears > > to > > have been established but subsequent packages are dropped silently, > > this recv() call will block. > Hmm. I would expect the recv to eventually fail based on TCP > timeouts, > but I agree that that would be much longer than you'd typically wish > to wait. > In case the connection goes through, the recv call does return after 60 seconds (on linux, where I'm trying this). The problem is that in our home-grown framework we'd want to use cancel to bail out of queries that have already run for too long. So at that point we've already waited long enough, we don't want to wait even more. The situation is even worse in an asynchronous, event-driven application: in that case we must not block at all. Yet, with the problem I've described, cancellation blocks just like in the synchronous case, rendering the entire application unresponsive for that period. (It's actually even worse than that, because DBD::Pg's support for asynchronous operation is half-finished at best: their pg_cancel function wants to read back the confirmation of the cancellation with PQgetResult, which blocks indefinitely if the network connection has failed in the way I've described.) > > > > Is this known? > I do not recall anyone ever reporting something similar --- and that > code > has been like that for a long time. I did forget to mention that I've observed this behavior with Postgresql 9.5.3 and 9.4.8, but I don't think the actual version matters much, because as you say, that part of the code has not changed recently. I find it strange that nobody has reported similar problems, though - everyone else has perfect network connections that never drop packets, never introduce random delays? > > > > > Is this a bug? > I wouldn't call it that exactly. There might be an opportunity for > improvement here, but it's not very clear what. Just introducing a > timeout would likely create more problems than it fixes, considering > the > evident rarity of the problem. In our framework we had to resort to this: but we mark the connection as unreliable, unusable if even cancellation times out. The point is that the application must remain responsive, and even in case of a complete network failure (between the app server and the database) we must be able to signal this state to the user. Best regards, Péter Juhász PS. and now for something completely different: the menu on http://yum. postgresql.org/ seems to be broken, the last two items are wrapped around into a second line. -- 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] Thoughts on "Love Your Database"
Interesting conversation. While reading it, I sort of regret the times when a single guy was in charge of the whole thing, and managed to simply make it work, using all possible tools he had. "Informaticien" was the generic term, in French. Every single part of the big thing he built (hardware on server and clients' sides, database, network, client programs, server programs, etc.) may not be perfect (often from far), but the whole thing was running smoothly, and he knew perfectly what to fix when something was happening. Yes, it took a multipurpose fellow to do that, neither a "SQL-only" fellow, nor a "C-what-else" guy. It also reminds me of a paper I read once, where it was carefully explained why scientists hated databases. But that's another subject. Le 04/05/2016 21:22, Will McCormick a écrit : Yeah but your already paying for a developer ... À+ Pierre -- Pierre Chevalier PChGEI: Pierre Chevalier Géologue Et Informaticien Partenaire DALIBO Mesté Duran 32100 Condom Tél+fax :09 75 27 45 62 06 37 80 33 64 Émail : pierrechevaliergeolCHEZfree.fr icq# : 10432285 jabber: pierre.chevalier1...@jabber.fr http://pierremariechevalier.free.fr/pierre_chevalier_geologue -- 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] Thoughts on "Love Your Database"
On May 20, 2016, at 13:38 , Pierre Chevalier Géologue wrote: > > Le 04/05/2016 18:29, Szymon Lipiński a écrit : >> On the other hand, when I was trying to store all my logic in a >> database, there was just one thing that made me hate it. Testing. >> Testing the procedures inside the database was not easy, not funny, and >> too much time consuming. > > Yes, very good point. Are there any best practices or tricks to make this easier? -- 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] Thoughts on "Love Your Database"
Le 04/05/2016 18:29, Szymon Lipiński a écrit : On the other hand, when I was trying to store all my logic in a database, there was just one thing that made me hate it. Testing. Testing the procedures inside the database was not easy, not funny, and too much time consuming. Yes, very good point. À+ Pierre -- Pierre Chevalier PChGEI: Pierre Chevalier Géologue Et Informaticien Partenaire DALIBO Mesté Duran 32100 Condom Tél+fax :09 75 27 45 62 06 37 80 33 64 Émail : pierrechevaliergeolCHEZfree.fr icq# : 10432285 jabber: pierre.chevalier1...@jabber.fr http://pierremariechevalier.free.fr/pierre_chevalier_geologue -- 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] PostgreSql Doubts
On Fri, 20 May 2016 09:19:08 -0500, John McKown wrote: >I don't know much about FireBird. I (not a lawyer) think it has a very good >license. One interesting thing is that it says that it can run as a >"server", like PostgreSQL, or "embedded", like SQLite. But I can't really >figure out how the "embedded" is actually "embedded". Firebird is available as a DLL on Windows and Linux. http://www.firebirdsql.org/file/documentation/reference_manuals/user_manuals/html/ufb-cs-embedded.html George -- 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] No warnings or errors after same sequential revoke
Alex Ignatov writes: > Why we have no warnings or errors about that we have no such grant > after first revoke? Yes, that's intentional. There's no warning about granting twice in a row, either. regards, tom lane -- 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] Debugging a backend stuck consuming CPU
On Thu, May 19, 2016 at 05:52:26PM -0400, Tom Lane wrote: > "k...@rice.edu" writes: > > The stack trace just appeared to be what I would expect while a 'DISCARD > > ALL' > > command was being run: > > > #0 0x0073bc7c in MemoryContextSetParent () > > #1 0x0073bde3 in MemoryContextDelete () > > #2 0x0054e3a9 in DropAllPreparedStatements () > > #3 0x005365f3 in DiscardCommand () > > Hmm, what it seems from these traces is that you've got a whole heck of > a lot of prepared statements. > > > The backend does have a very large memory footprint (12GB). > > Um. > > The most likely explanation is that you are hitting O(N^2) behavior as > a consequence of MemoryContextSetParent being O(N) in the number of > sibling contexts of the context to be deleted. We fixed that for 9.6 > (commit 25c539233044c235e97fd7c9dc600fb5f08fe065) but there's no easy > solution in older branches, short of not using so many prepared > statements. I'm a bit surprised that you could have gotten up to 12GB > worth of prepared statements in an application that sends DISCARD ALL > periodically. > > regards, tom lane > Hi, The DISCARD ALL is only sent by pgbouncer at the end of the processing. The actual process builds up a cache to be used later whose size is proportional to the number of items. The initial run is large, but the regular runs are much smaller and cleanup quickly. I was more concerned with incorrect behavior leading to DB corruption. Thank you for your suggestions and assistance. Regards, Ken -- 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] postgresql-9.5.3 compilation on Solaris SPARC
On Fri, May 20, 2016 at 11:04 AM, Tom Lane wrote: > src/include/port/atomics/generic-sunpro.h cites these references > as authority for believing that those functions exist in Solaris: > >http://www.unix.com/man-page/opensolaris/3c/atomic_cas/ >http://docs.oracle.com/cd/E23824_01/html/821-1465/atomic-cas-3c.html > > I see that the first of those mentions it's for SunOS 5.11 whereas your > machine says it's 5.10 ... is it possible the functions were new in 5.11? Those two are listed in SunOS 5.10 man pages: http://www.unix.com/man-page/sunos/3c/atomic_cas/ -- Michael -- 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] postgresql-9.5.3 compilation on Solaris SPARC
Venkata Balaji N writes: > "make" command is generating the following error while compiling > postgresql-9.5.3 on Solaris SPARC. > Undefined first referenced > symbol in file > atomic_cas_64 port/atomics.o > atomic_cas_32 port/atomics.o Hmm. Do you get any warnings about references to those functions earlier in the build? src/include/port/atomics/generic-sunpro.h cites these references as authority for believing that those functions exist in Solaris: http://www.unix.com/man-page/opensolaris/3c/atomic_cas/ http://docs.oracle.com/cd/E23824_01/html/821-1465/atomic-cas-3c.html I see that the first of those mentions it's for SunOS 5.11 whereas your machine says it's 5.10 ... is it possible the functions were new in 5.11? regards, tom lane -- 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] postgresql-9.5.3 compilation on Solaris SPARC
On Fri, May 20, 2016 at 10:38 AM, Jan de Visser wrote: > I would suggest reporting this on pgsql-hackers. I know some work was done on > the atomics over the last little while. If that's an issue (no sparc environment here), we're looking at b64d92f1 here that was new stuff in 9.5. -- Michael -- 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] postgresql-9.5.3 compilation on Solaris SPARC
On Friday, May 20, 2016 3:14:54 PM EDT Venkata Balaji N wrote: > Hi, > > "make" command is generating the following error while compiling > postgresql-9.5.3 on Solaris SPARC. > > I tried compiling 9.2 and 9.3, works fine. This is only happening on 9.5. ... snip ... > > Regards, > Venkata B N > > Fujitsu Australia I would suggest reporting this on pgsql-hackers. I know some work was done on the atomics over the last little while. -- 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] PostgreSql Doubts
On Fri, May 20, 2016 at 6:17 AM, aluka raju wrote: > Hello , > > 1) We are building an application where it needs a SQL engine to process > the data. We are evaluating whether to use postgreSQL along with the > foreign data wrappers. Can you please help us in letting know if postgreSQL > can be used in embedded mode. > > 2) We want to have SQLEngine component also embedded into our application. > > please help me. > Abandon trying to use PostgreSQL if you need an embedded SQL language. I, personally, would suggest either SQLite (https://www.sqlite.org) or FireBird SQL (www.firebirdsql.org). SQLite uses SQL which rather easy, but with its own peculiarities. It's main excellence is that it is indeed "lite" as in "not adding a lot of code to your project". The author is brilliant and takes a _very_ active role in supporting it. The license is basically "do whatever you want with the code" because he's donated to the "Public Domain" (not copyrighted it in any way). You can use it on Linux, Windows, and Mac OSX. I don't know much about FireBird. I (not a lawyer) think it has a very good license. One interesting thing is that it says that it can run as a "server", like PostgreSQL, or "embedded", like SQLite. But I can't really figure out how the "embedded" is actually "embedded". Personally, despite some strange details (such as not enforcing data types, e.g. you can INSERT a string value into a column defined as NUMERIC), I think that SQLite is likely your best option. If you go to the web page mentioned previously and sign up for the "sqlite-users" forum, you'll get a good idea of how community minded the people using SQLite are. I think there are some very intelligent, articulate, and _nice_ people over there (unlike some forums I've been on). > > > Thanks & Regards, > aluka > -- The unfacts, did we have them, are too imprecisely few to warrant our certitude. Maranatha! <>< John McKown
Re: [GENERAL] Londiste 3 pgq events_1_1 table huge
El 20/05/16 a las 10:19, Leonardo M. Ramé escribió: El 19/05/16 a las 12:39, Saiful Muhajir escribió: This has happened to us where we have dead or unmanaged consumer. Turns out londiste is keeping the event even if the consumer is unreachable. This is to ensure that the consumer gets what it should. To clean this up, delete the unused/dead consumer, with qadmin or manually if necessary. The table won't be deleted immediately though. We have to restart pgqd and workers and wait for two days. Thanks Rene and Saiful, I found two unused consumers, but after "unregister consumer " those aren't deleted, what can I do to remove them?. Sorry, I successfully deleted them by using: unregister consumer CONSUMER_NAME from QUEUE_NAME The 2nd param QUEUE_NAME is a *must*. Now I'm waiting for the events deletion... Regards, -- Leonardo M. Ramé Medical IT - Griensu S.A. Av. Colón 636 - Piso 8 Of. A X5000EPT -- Córdoba Tel.: +54(351)4246924 +54(351)4247788 +54(351)4247979 int. 19 Cel.: +54 9 (011) 40871877 -- 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] Londiste 3 pgq events_1_1 table huge
El 19/05/16 a las 12:39, Saiful Muhajir escribió: This has happened to us where we have dead or unmanaged consumer. Turns out londiste is keeping the event even if the consumer is unreachable. This is to ensure that the consumer gets what it should. To clean this up, delete the unused/dead consumer, with qadmin or manually if necessary. The table won't be deleted immediately though. We have to restart pgqd and workers and wait for two days. Thanks Rene and Saiful, I found two unused consumers, but after "unregister consumer " those aren't deleted, what can I do to remove them?. -- Leonardo M. Ramé Medical IT - Griensu S.A. Av. Colón 636 - Piso 8 Of. A X5000EPT -- Córdoba Tel.: +54(351)4246924 +54(351)4247788 +54(351)4247979 int. 19 Cel.: +54 9 (011) 40871877 -- 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] PostgreSql Doubts
On Fri, May 20, 2016 at 9:06 AM, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Fri, May 20, 2016 at 7:17 AM, aluka raju > wrote: > >> Hello , >> >> 1) We are building an application where it needs a SQL engine to process >> the data. We are evaluating whether to use postgreSQL along with the >> foreign data wrappers. Can you please help us in letting know if postgreSQL >> can be used in embedded mode. >> >> 2) We want to have SQLEngine component also embedded into our application. >> >> please help me. >> >> > PostgreSQL is a standalone server - it cannot be embedded. > > I don't understand #2 (what is SQLEngine?) but I suspect the above answer > covers it as well. > > Apparently there is even an FAQ entry for this... https://wiki.postgresql.org/wiki/FAQ#Can_PostgreSQL_be_embedded.3F David J.
Re: [GENERAL] PostgreSql Doubts
On Fri, May 20, 2016 at 7:17 AM, aluka raju wrote: > Hello , > > 1) We are building an application where it needs a SQL engine to process > the data. We are evaluating whether to use postgreSQL along with the > foreign data wrappers. Can you please help us in letting know if postgreSQL > can be used in embedded mode. > > 2) We want to have SQLEngine component also embedded into our application. > > please help me. > > PostgreSQL is a standalone server - it cannot be embedded. I don't understand #2 (what is SQLEngine?) but I suspect the above answer covers it as well. David J.
[GENERAL] No warnings or errors after same sequential revoke
Hello! Why we have no warnings or errors about that we have no such grant after first revoke? postgres=> grant select(i2) on table user1.t2 to user2; GRANT postgres=> revoke select(i2) on table user1.t2 from user2; REVOKE postgres=> revoke select(i2) on table user1.t2 from user2; REVOKE postgres=> revoke select(i2) on table user1.t2 from user2; REVOKE postgres=> revoke select(i2) on table user1.t2 from user2; REVOKE No warnings about that this grant is not available. It looks like revoking nonexisting grants is allowed??? -- Alex Ignatov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
[GENERAL] PostgreSql Doubts
Hello , 1) We are building an application where it needs a SQL engine to process the data. We are evaluating whether to use postgreSQL along with the foreign data wrappers. Can you please help us in letting know if postgreSQL can be used in embedded mode. 2) We want to have SQLEngine component also embedded into our application. please help me. Thanks & Regards, aluka
