[HACKERS] PostgreSQL 9.4 InterlockedCompareExchange appearing in mingw64-w32 causing issue with PostGIS win32 load
Not sure if people know this, but PostGIS windows builds are built with mingw64-w32 and mingw64-w64 chains and usually used with EDB VC++ built PostgreSQL. This is mostly because there is too much unix stuff ingrained in PostGIS toolchain making it difficult to compile in VC++. Anyrate this has worked fine in the past, but when I tried the mingw64-w32 build in the EDB PostgreSQL 9.4beta1 Windows 32, it failed to load. The 64-bit chain still works fine and regresses fine against PostGIS tests. I looked at dependency walker, and noticed what was additional in the mingw postgres that couldn't be found in the 9.4beta1 EDB postgres was a function: InterlockedCompareExchange@12 I'm pretty sure this must be something that has changed in 9.4 because I'm using the same chain to build 9.3 for 32-bit and this InterlockedCompareExchange call doesn't exist in 9.3 (niether the ming compiled or edb compiled) I'm using mingw64-w32 gcc 4.8.0 rev2. I have the same chain mingw64-w64 to build the 64-bit. The only place I could find reference to this function is in src\include\storage\s_lock.h I have related PostGIS ticket here: http://trac.osgeo.org/postgis/ticket/2746 Thanks, Regina Obe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] relaying errors from background workers
On 22/05/14 06:21, Robert Haas wrote: The main thing I'm not sure about is how to format the message that we write to the shm_mq. One option is to try to use the good old FEBE protocol. This doesn't look entirely straightforward, because send_message_to_frontend() assembles the message using pq_sendbyte() and pq_sendstring(), and then sends it out to the client using pq_endmessage() and pq_flush(). This infrastructure assumes that the connection to the frontend is a socket. It doesn't seem impossible to kludge that infrastructure to be able to send to either a socket or a shm_mq, but I'm not sure whether it's a good idea. Alternatively, we could devise some other message format specific to this problem; it would probably look a lot like an ErrorData protocol message, but maybe that's doesn't really matter. Any thoughts? I played with this a bit already and even have some (very much hacked up) prototype based on ErrorData as it seemed better solution than using sockets. Obviously some of the ErrorData fields don't really have meaning during transport (send_to_client for example) as those must be set based on the connection options and I didn't get to making this nicer yet. Another thing to think about is that, most likely, many users of the background worker facility will want to respond to a relayed error by rethrowing it. That means that whatever format we use to send the error from one process to the other has to be able to be decoded by the receiving process. That process will probably want to do something like add add a bit more to the context (e.g. in background worker PID %d) and throw the resulting error preserving the rest of the original fields. I'm not sure exactly what make sense here, but the point is that ideally the message format should be something that the receiver can rethrow, possibly after tweaking it a bit. This is one advantage of using ErrorData or ErrorData-like structure based messaging, rethrowing is simpler, but I guess if we really needed we could provide some conversion api. One side effect of the rethrowing that maybe deserves a bit of thought is that we are going to log the same error from both bgworker and backend if we rethrow it. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 9.5 commit fest schedule
For those who were not at the developer meeting, here is the commit fest schedule for 9.5: June 15 August 15 October 15 December 15 February 15 beta in June 2015 The obvious change is that there will be five commit fests instead of four. Also, the time between beta and release is planned to be a bit shorter. The first commit fest will continue to use the existing web app (https://commitfest.postgresql.org/action/commitfest_view?id=22), while the new one continues to be developed. We need a volunteer to manage the first commit fest. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] relaying errors from background workers
On Thu, May 22, 2014 at 6:33 AM, Petr Jelinek p...@2ndquadrant.com wrote: On 22/05/14 06:21, Robert Haas wrote: The main thing I'm not sure about is how to format the message that we write to the shm_mq. One option is to try to use the good old FEBE protocol. This doesn't look entirely straightforward, because send_message_to_frontend() assembles the message using pq_sendbyte() and pq_sendstring(), and then sends it out to the client using pq_endmessage() and pq_flush(). This infrastructure assumes that the connection to the frontend is a socket. It doesn't seem impossible to kludge that infrastructure to be able to send to either a socket or a shm_mq, but I'm not sure whether it's a good idea. Alternatively, we could devise some other message format specific to this problem; it would probably look a lot like an ErrorData protocol message, but maybe that's doesn't really matter. Any thoughts? I played with this a bit already and even have some (very much hacked up) prototype based on ErrorData as it seemed better solution than using sockets. Obviously some of the ErrorData fields don't really have meaning during transport (send_to_client for example) as those must be set based on the connection options and I didn't get to making this nicer yet. I didn't mean the ErrorData structure that the backend uses internally; it doesn't seem practical to use that because it contains pointers. Even if we stored all the data in the DSM (which seems rather hard without a shared-memory allocator), it might not be mapped at the same address in both backends. I meant the libpq wire protocol used to transmit errors to the client; I guess the message is actually called ErrorResponse rather than ErrorData: http://www.postgresql.org/docs/current/static/protocol-message-formats.html ErrorResponse of course wouldn't contain anything like send_to_client, as that's a server-internal thing. Another thing to think about is that, most likely, many users of the background worker facility will want to respond to a relayed error by rethrowing it. That means that whatever format we use to send the error from one process to the other has to be able to be decoded by the receiving process. That process will probably want to do something like add add a bit more to the context (e.g. in background worker PID %d) and throw the resulting error preserving the rest of the original fields. I'm not sure exactly what make sense here, but the point is that ideally the message format should be something that the receiver can rethrow, possibly after tweaking it a bit. This is one advantage of using ErrorData or ErrorData-like structure based messaging, rethrowing is simpler, but I guess if we really needed we could provide some conversion api. One side effect of the rethrowing that maybe deserves a bit of thought is that we are going to log the same error from both bgworker and backend if we rethrow it. Yeah, I'm not sure how to handle that. It probably wouldn't be hard to make the routine that re-throws the error suppress sending it to the server log, but that could also be confusing if someone is trying to follow the progress of a particular session. Having the background worker suppress sending it to the log also seems bad; it has no guarantee that it will successfully relay the message, or that the recipient will re-throw it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.5 commit fest schedule
At 2014-05-22 07:22:42 -0400, pete...@gmx.net wrote: We need a volunteer to manage the first commit fest. I volunteer. -- Abhijit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.5 commit fest schedule
Em quinta-feira, 22 de maio de 2014, Peter Eisentraut pete...@gmx.net escreveu: For those who were not at the developer meeting, here is the commit fest schedule for 9.5: June 15 August 15 October 15 December 15 February 15 beta in June 2015 Actually you meant: June 14 August 14 October 14 December 14 February 15 Beta in June 2015 Ok? Fabrízio Mello -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Timbira: http://www.timbira.com.br Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello
Re: [HACKERS] 9.5 commit fest schedule
On 05/22/2014 07:55 AM, Fabrízio de Royes Mello wrote: Em quinta-feira, 22 de maio de 2014, Peter Eisentraut pete...@gmx.net escreveu: For those who were not at the developer meeting, here is the commit fest schedule for 9.5: June 15 August 15 October 15 December 15 February 15 beta in June 2015 Actually you meant: June 14 August 14 October 14 December 14 February 15 Beta in June 2015 Ok? No, those numbers are dates, not years: June 15th, 2014 August 15th, 2014 October 15th, 2014 December 15th, 2014 February 15th, 2015 - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.5 commit fest schedule
Em quinta-feira, 22 de maio de 2014, Heikki Linnakangas hlinnakan...@vmware.com escreveu: On 05/22/2014 07:55 AM, Fabrízio de Royes Mello wrote: Em quinta-feira, 22 de maio de 2014, Peter Eisentraut pete...@gmx.net escreveu: For those who were not at the developer meeting, here is the commit fest schedule for 9.5: June 15 August 15 October 15 December 15 February 15 beta in June 2015 Actually you meant: June 14 August 14 October 14 December 14 February 15 Beta in June 2015 Ok? No, those numbers are dates, not years: June 15th, 2014 August 15th, 2014 October 15th, 2014 December 15th, 2014 February 15th, 2015 Deadlines? Fabrízio Mello -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Timbira: http://www.timbira.com.br Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello
Re: [HACKERS] pg_upgrade fails: Mismatch of relation OID in database 8.4 - 9.3
On Wed, May 21, 2014 at 04:37:13PM -0400, Bruce Momjian wrote: On Wed, May 21, 2014 at 04:23:34PM -0400, Tom Lane wrote: Bruce Momjian br...@momjian.us writes: On Wed, May 21, 2014 at 10:56:59AM -0600, Jeff Ross wrote: Yes, using 9.3's pg_dump of 8.4 and applying it to both an 8.4 and a 9.3 cluster, the contact_email table now has toast in both 8.4 and 9.3. So the big question is why doesn't the existing 8.4 table have a toast table? Did you use pg_upgrade on the old cluster before, e.g. from 8.3? I have a vague recollection that we changed the calculations about whether a toast table would be needed, but I can't find it in the commit logs right now --- and anyway I think this was pre-8.4. The only item I can think of that would cause this is someone changing the length of a string. Did someone modify pg_attribute directly to increase the length of one of the character columns? I just tested ALTER TABLE in 8.4 and it does create a toast table for this case in 9.4: CREATE TABLE test (x CHAR(10)); ALTER TABLE test ALTER COLUMN x TYPE CHAR(8000); Has anyone changed the database encoding by modifying the system catalogs? That might cause the problem too. Moving forward, I think you need to add a dummy column to each problem table and drop the column that will create a toast table and allow you to do the upgrade. I could have pg_upgrade detect this problem, but until I know the cause, I don't think that is wise. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.5 commit fest schedule
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= fabriziome...@gmail.com writes: Deadlines? I think the plan is 1 month for each of the first 4 fests, and a bit more for the last one (6-8 weeks maybe). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL 9.4 InterlockedCompareExchange appearing in mingw64-w32 causing issue with PostGIS win32 load
Paragon Corporation l...@pcorp.us writes: Not sure if people know this, but PostGIS windows builds are built with mingw64-w32 and mingw64-w64 chains and usually used with EDB VC++ built PostgreSQL. This is mostly because there is too much unix stuff ingrained in PostGIS toolchain making it difficult to compile in VC++. Anyrate this has worked fine in the past, but when I tried the mingw64-w32 build in the EDB PostgreSQL 9.4beta1 Windows 32, it failed to load. The 64-bit chain still works fine and regresses fine against PostGIS tests. I looked at dependency walker, and noticed what was additional in the mingw postgres that couldn't be found in the 9.4beta1 EDB postgres was a function: InterlockedCompareExchange@12 I'm pretty sure this must be something that has changed in 9.4 because I'm using the same chain to build 9.3 for 32-bit and this InterlockedCompareExchange call doesn't exist in 9.3 (niether the ming compiled or edb compiled) Hm. s_lock.h does define TAS() in terms of InterlockedCompareExchange() if WIN32_ONLY_COMPILER is defined ... but that code hasn't changed in quite a long time. It seems like the combination of an extension built with WIN32_ONLY_COMPILER and a core built without that flag should never have worked, if the core is what has to link in InterlockedCompareExchange. I wonder if there is something you're doing that results in inlining a spinlock call given the 9.4 headers, but did not previously. Can you narrow down what part of your code is giving rise to the undefined reference? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade fails: Mismatch of relation OID in database 8.4 - 9.3
Bruce Momjian wrote: Moving forward, I think you need to add a dummy column to each problem table and drop the column that will create a toast table and allow you to do the upgrade. I could have pg_upgrade detect this problem, but until I know the cause, I don't think that is wise. Maybe --check mode could examine both clusters and see whether each table having toast table or not matches. That wouldn't solve the actual problem but at least give a clue, instead of these very obscure problems. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade fails: Mismatch of relation OID in database 8.4 - 9.3
Alvaro Herrera alvhe...@2ndquadrant.com writes: Bruce Momjian wrote: Moving forward, I think you need to add a dummy column to each problem table and drop the column that will create a toast table and allow you to do the upgrade. I could have pg_upgrade detect this problem, but until I know the cause, I don't think that is wise. Maybe --check mode could examine both clusters and see whether each table having toast table or not matches. That wouldn't solve the actual problem but at least give a clue, instead of these very obscure problems. Well, the case of not needing a toast table anymore is expected (drop a wide column). What we're scratching our heads over is the other case. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] uuid-ossp (Re: [pgsql-packagers] Postgresapp 9.4 beta build ready)
On Sun, May 18, 2014 at 12:28 AM, Tom Lane t...@sss.pgh.pa.us wrote: I was intending to draft something more self-contained to present to -hackers, but since this is where we're at ... the quoted material omits a couple of important points: (1) People had been working around uuid-ossp's issues on OS X by patching a #define _XOPEN_SOURCE into contrib/uuid-ossp/uuid-ossp.c. As of 9.4 this is no longer sufficient because we upgraded to autoconf 2.69, which uses stricter testing for include-file validity than older versions did. The test to see if uuid.h is available therefore fails, unless that #define is also patched into the configure script. In any case #define _XOPEN_SOURCE has enough potential implications that this doesn't seem like a very recommendable solution. (2) Palle's patch mentioned above can be seen here: http://svnweb.freebsd.org/ports/head/databases/postgresql93-server/files/patch-contrib-uuid?revision=348732view=markup Basically it jacks up contrib/uuid-ossp and rolls the BSD uuid functions underneath. It looks like this is based on work by Andrew Gierth. So, having seen that proof-of-concept, I'm wondering if we shouldn't make an effort to support contrib/uuid-ossp with a choice of UUID libraries underneath it. There is a non-OSSP set of UUID library functions available on Linux (libuuid from util-linux-ng). I don't know whether that's at all compatible with the BSD functions, but even if it's not, presumably a shim for it wouldn't be much larger than the BSD patch. Well, if you want to do the work, I'm fine with that. But if you want to just shoot uuid-ossp in the head, I'm fine with that, too. As Peter says, perfectly reasonable alternatives are available. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] uuid-ossp (Re: [pgsql-packagers] Postgresapp 9.4 beta build ready)
Robert Haas robertmh...@gmail.com writes: On Sun, May 18, 2014 at 12:28 AM, Tom Lane t...@sss.pgh.pa.us wrote: So, having seen that proof-of-concept, I'm wondering if we shouldn't make an effort to support contrib/uuid-ossp with a choice of UUID libraries underneath it. There is a non-OSSP set of UUID library functions available on Linux (libuuid from util-linux-ng). I don't know whether that's at all compatible with the BSD functions, but even if it's not, presumably a shim for it wouldn't be much larger than the BSD patch. Well, if you want to do the work, I'm fine with that. But if you want to just shoot uuid-ossp in the head, I'm fine with that, too. As Peter says, perfectly reasonable alternatives are available. Well, *I* don't want to do that work. I was hoping to find a volunteer, but the silence has been notable. I think deprecation is the next step. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade fails: Mismatch of relation OID in database 8.4 - 9.3
On 5/21/14, 2:37 PM, Bruce Momjian wrote: On Wed, May 21, 2014 at 04:23:34PM -0400, Tom Lane wrote: Bruce Momjian br...@momjian.us writes: On Wed, May 21, 2014 at 10:56:59AM -0600, Jeff Ross wrote: Yes, using 9.3's pg_dump of 8.4 and applying it to both an 8.4 and a 9.3 cluster, the contact_email table now has toast in both 8.4 and 9.3. So the big question is why doesn't the existing 8.4 table have a toast table? Did you use pg_upgrade on the old cluster before, e.g. from 8.3? I have a vague recollection that we changed the calculations about whether a toast table would be needed, but I can't find it in the commit logs right now --- and anyway I think this was pre-8.4. The only item I can think of that would cause this is someone changing the length of a string. Did someone modify pg_attribute directly to increase the length of one of the character columns? I don't know, sorry. I just tested ALTER TABLE in 8.4 and it does create a toast table for this case in 9.4: CREATE TABLE test (x CHAR(10)); ALTER TABLE test ALTER COLUMN x TYPE CHAR(8000); I just tried this on the problem table and it did indeed create a toast table. I then retried pg_upgrade and it failed with the same problem on a different table in the same database. Of the 67 databases in the 8.4 cluster, 5 (so far) have had this problem on at least one table. Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL 9.4 InterlockedCompareExchange appearing in mingw64-w32 causing issue with PostGIS win32 load
Hm. s_lock.h does define TAS() in terms of InterlockedCompareExchange()
if WIN32_ONLY_COMPILER is defined ... but that code hasn't changed in quite
a long time. It
seems like the combination of an extension built with WIN32_ONLY_COMPILER
and a core built without that flag should never have worked, if the core is
what has to link
in InterlockedCompareExchange.
I wonder if there is something you're doing that results in inlining a
spinlock call given the 9.4 headers, but did not previously. Can you narrow
down what part of
your code is giving rise to the undefined reference?
regards, tom lane
Tom,
Does it with all extensions, not just PostGIS (before I could swap between
say for example hstore mingw compiled and VC compiled and had no issue).
The Load function as you guessed shows in the extension .dll postgres.exe
reference but not clear where to tell where that is coming thru.
I'm compiling PostgreSQL the same way in both 9.3 and 9.4:
With something that looks like this:
export MINGHOST=i686-w64-mingw32
PG_VER=9.4
./configure --prefix=${PROJECTS}/postgresql/rel/pg${PG_VER}\
--build=${MINGHOST} \
--with-pgport=8443 --disable-float8-byval --enable-cassert
--enable-debug \
--enable-integer-datetimes --without-zlib
With just the PG_VER being different.
What I did notice is that in 9.3, the config.log shows this for
9.4:
LDFLAGS=-Wl,--allow-multiple-definition -Wl,--disable-auto-import
-Wl,--as-needed
and
9.3:
LDFLAGS=-Wl,--allow-multiple-definition -Wl,--as-needed
You know what would cause those to change between versions?
I thought maybe the --disable-auto-import was doing something.
I'm trying to override the flag now to see if it makes a difference, but
having difficulty changing what I am seeing in the config.log
When I do any of the below:
export LDFLAGS=-Wl,--allow-multiple-definition -Wl,--enable-auto-import
-Wl,--as-needed
export LDFLAGS=-Wl,--allow-multiple-definition -Wl,--enable-auto-import
-Wl,--as-needed
export LDFLAGS=-Wl,--allow-multiple-definition -Wl,--as-needed
Thanks,
Regina
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] uuid-ossp (Re: [pgsql-packagers] Postgresapp 9.4 beta build ready)
On 22/05/2014 17:07, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Sun, May 18, 2014 at 12:28 AM, Tom Lane t...@sss.pgh.pa.us wrote: So, having seen that proof-of-concept, I'm wondering if we shouldn't make an effort to support contrib/uuid-ossp with a choice of UUID libraries underneath it. There is a non-OSSP set of UUID library functions available on Linux (libuuid from util-linux-ng). I don't know whether that's at all compatible with the BSD functions, but even if it's not, presumably a shim for it wouldn't be much larger than the BSD patch. Well, if you want to do the work, I'm fine with that. But if you want to just shoot uuid-ossp in the head, I'm fine with that, too. As Peter says, perfectly reasonable alternatives are available. Well, *I* don't want to do that work. I was hoping to find a volunteer, but the silence has been notable. I think deprecation is the next step. This sounds an easy enough task to try and submit a patch, if I'm able to allocate enough time to work on it. I have successfully compiled the extension on a NetBSD box using a slightly modified version of Palle's patch. I have a few doubts though: - should we keep the extension name? If not, what would be the plan? - the patch also uses BSD's own md5 and sha1 implementations: for md5 I should be able to use pg's own core version, but I'm not sure about sha1, as it lives in pgcrypto. Any suggestion? Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] uuid-ossp (Re: [pgsql-packagers] Postgresapp 9.4 beta build ready)
On Thu, May 22, 2014 at 11:07 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Sun, May 18, 2014 at 12:28 AM, Tom Lane t...@sss.pgh.pa.us wrote: So, having seen that proof-of-concept, I'm wondering if we shouldn't make an effort to support contrib/uuid-ossp with a choice of UUID libraries underneath it. There is a non-OSSP set of UUID library functions available on Linux (libuuid from util-linux-ng). I don't know whether that's at all compatible with the BSD functions, but even if it's not, presumably a shim for it wouldn't be much larger than the BSD patch. Well, if you want to do the work, I'm fine with that. But if you want to just shoot uuid-ossp in the head, I'm fine with that, too. As Peter says, perfectly reasonable alternatives are available. Well, *I* don't want to do that work. I was hoping to find a volunteer, but the silence has been notable. I think deprecation is the next step. If we can't get it fixed up, I think we should remove it outright. If we merely deprecate it, then either people will still be trying to build and package it (in which case we haven't solved any problem), or we'll never get around to really removing it, or both. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] -DDISABLE_ENABLE_ASSERT
Hi, Since there seem to be multiple static checkers (coverity, clang checker) having problems with assert_enabled can we just optionally disable it? I am thinking of replacing it by a AssertionsEnabled() macro which then is unconditionally defined when DISABLE_ENABLE_ASSERT is defined. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] -DDISABLE_ENABLE_ASSERT
On Thu, May 22, 2014 at 4:31 PM, Andres Freund and...@2ndquadrant.com wrote: Since there seem to be multiple static checkers (coverity, clang checker) having problems with assert_enabled can we just optionally disable it? I am thinking of replacing it by a AssertionsEnabled() macro which then is unconditionally defined when DISABLE_ENABLE_ASSERT is defined. Uh, probably. But I think you need a better name; specifically, one that doesn't contain two words which are antonyms. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] -DDISABLE_ENABLE_ASSERT
Andres Freund and...@2ndquadrant.com writes: Since there seem to be multiple static checkers (coverity, clang checker) having problems with assert_enabled can we just optionally disable it? I am thinking of replacing it by a AssertionsEnabled() macro which then is unconditionally defined when DISABLE_ENABLE_ASSERT is defined. We could do that ... but I wonder if we shouldn't remove assert_enabled altogether. What's the use case for turning it off? Not matching the speed of a non-cassert build, because for instance MEMORY_CONTEXT_CHECKING doesn't get turned off. If we went this direction I'd suggest keeping the GUC but turning it into a read-only report of whether the backend was compiled with assertions. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] -DDISABLE_ENABLE_ASSERT
On 2014-05-22 16:37:35 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: Since there seem to be multiple static checkers (coverity, clang checker) having problems with assert_enabled can we just optionally disable it? I am thinking of replacing it by a AssertionsEnabled() macro which then is unconditionally defined when DISABLE_ENABLE_ASSERT is defined. We could do that ... but I wonder if we shouldn't remove assert_enabled altogether. What's the use case for turning it off? Not matching the speed of a non-cassert build, because for instance MEMORY_CONTEXT_CHECKING doesn't get turned off. I've used it once or twice to avoid having to recompile postgres when I wanted things not to be *that* slow (AtEOXactBuffers() I am looking at you). But I wouldn't be very sad if it'd go. Anybody against that? If we went this direction I'd suggest keeping the GUC but turning it into a read-only report of whether the backend was compiled with assertions. Yes, that makes sense. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] -DDISABLE_ENABLE_ASSERT
Andres Freund wrote: On 2014-05-22 16:37:35 -0400, Tom Lane wrote: We could do that ... but I wonder if we shouldn't remove assert_enabled altogether. What's the use case for turning it off? Not matching the speed of a non-cassert build, because for instance MEMORY_CONTEXT_CHECKING doesn't get turned off. I've used it once or twice to avoid having to recompile postgres when I wanted things not to be *that* slow (AtEOXactBuffers() I am looking at you). But I wouldn't be very sad if it'd go. Anybody against that? I have used it too (for a different reason IIRC), but like you I wouldn't have a problem if it weren't there. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.4 release notes
Hi, I have two comments about 9.4 release notes. 1. typo Pg_upgrade now uses -U to specify the user name (Bruce Momjian) It should be pg_upgrade. 2. undesirable link Allow pg_recvlogical to receive data logical decoding data (Andres Freund) The term of pg_recvlogical jumps to a page of pg_receivexlog. It should jump to pg_recvlogical(app-pgrecvlogical.html). regards, Tomonari Katsumata -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Congrats Andres Freund, the newest PostgreSQL Commiter!
Hi All, At the Developer Meeting that occurred 21th May 2014 was announced a new PostgreSQL commiter [1], Mr. Andres Freund. I had the opportunity to work and be mentored by him. He deserves very much this confidence, for the excellent work that has been doing for the community. Thank you and Congrats Andres! [1] https://wiki.postgresql.org/wiki/PgCon_2014_Developer_Meeting#New_Committer -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Timbira: http://www.timbira.com.br Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello
Re: [HACKERS] Congrats Andres Freund, the newest PostgreSQL Commiter!
On Fri, May 23, 2014 at 11:24 AM, Fabrízio de Royes Mello fabriziome...@gmail.com wrote: Thank you and Congrats Andres! +1. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Congrats Andres Freund, the newest PostgreSQL Commiter!
On Thu, May 22, 2014 at 11:24:47PM -0300, Fabrízio de Royes Mello wrote: Hi All, At the Developer Meeting that occurred 21th May 2014 was announced a new PostgreSQL commiter [1], Mr. Andres Freund. I had the opportunity to work and be mentored by him. He deserves very much this confidence, for the excellent work that has been doing for the community. Thank you and Congrats Andres! Congratulations, Andres! Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Congrats Andres Freund, the newest PostgreSQL Commiter!
Congrats Andres! On Fri, May 23, 2014 at 7:54 AM, Fabrízio de Royes Mello fabriziome...@gmail.com wrote: Hi All, At the Developer Meeting that occurred 21th May 2014 was announced a new PostgreSQL commiter [1], Mr. Andres Freund. I had the opportunity to work and be mentored by him. He deserves very much this confidence, for the excellent work that has been doing for the community. Thank you and Congrats Andres! [1] https://wiki.postgresql.org/wiki/PgCon_2014_Developer_Meeting#New_Committer -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Timbira: http://www.timbira.com.br Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello -- Regards, Atri *l'apprenant*
