Re: [GENERAL] How to fix lost synchronization with server
Where to get this fix in binary form for Windows 32-bit ? Here, but you will need to wait until 9.3.5 is out: http://www.postgresql.org/download/windows/. When 9.3.5 or Windows x32 nightly build or test build will be out ? Andrus. -- 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 fix lost synchronization with server
I looked back at the previous thread you mentioned (bug #7914) and was reminded that we never did understand what was going on in that report. I'm not sure if you are seeing the same thing though. That user reported that he was able to see pg_dump's memory consumption bloating well beyond what it ought to be (I suppose he was watching the process in whatever Windows' equivalent of ps or top is). Do you see that? This occurs in customer computer which I din't observe. I added --inserts parameter to pg_dump and ssl=false in postgresql.conf file. After that backup works OK. Is it OK to use --inserts parameter ? Andrus. -- 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 fix lost synchronization with server
Andrus kobrule...@hot.ee writes: I looked back at the previous thread you mentioned (bug #7914) and was reminded that we never did understand what was going on in that report. I'm not sure if you are seeing the same thing though. That user reported that he was able to see pg_dump's memory consumption bloating well beyond what it ought to be (I suppose he was watching the process in whatever Windows' equivalent of ps or top is). Do you see that? This occurs in customer computer which I din't observe. I added --inserts parameter to pg_dump and ssl=false in postgresql.conf file. After that backup works OK. Now that we've identified the actual problem [1], I'm guessing the reason why --inserts appears to make it go away is that then pg_dump uses a SELECT which requires more server-side effort than COPY. So that slows down the server just a bit, and if the phase of the moon is favorable the timing no longer results in this buffer-bloat behavior. But I wouldn't call that a reliable fix. You'd be better off applying the patch. regards, tom lane [1] http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=2f557167b19af79ffecb8faedf8b7bce4d48f3e1 -- 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 fix lost synchronization with server
But I wouldn't call that a reliable fix. You'd be better off applying the patch. Where to get this fix in binary form for Windows 32-bit ? pg_dump.exe uses files below [1]. Is it sufficient to replace libpq.dll file ? Where to get its compiled version or how to compile it in Windows ? [1] libeay32.dll libiconv.dll libintl.dll libpq.dll msvcr100.dll pg_dump.exe ssleay32.dll zlib1.dll -- 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 fix lost synchronization with server
On Fri, May 9, 2014 at 2:37 AM, Andrus kobrule...@hot.ee wrote: Where to get this fix in binary form for Windows 32-bit ? Here, but you will need to wait until 9.3.5 is out: http://www.postgresql.org/download/windows/. If you are in a hurry, you can still compile manually pg_dump and deploy it where you need it... Where to get its compiled version or how to compile it in Windows ? There are many ways to do that, the most popular methods involving MinGW or msvc. More information is available on the docs as well: http://www.postgresql.org/docs/9.3/static/install-windows.html And here are some more resources. https://wiki.postgresql.org/wiki/Running_%26_Installing_PostgreSQL_On_Native_Windows https://wiki.postgresql.org/wiki/Building_With_MinGW Regards, -- 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] How to fix lost synchronization with server
Andrus kobrule...@hot.ee writes: pg_dump: Dumping the contents of table attachme failed: PQgetCopyData() failed. pg_dump: Error message from server: lost synchronization with server: got message type d, length 5858454 pg_dump: The command was: COPY firma1.attachme (id, idmailbox, attachname, attachbody, attachtype) TO stdout; attachme table contains 4487 records Its total size is 1016 MB. Most data is contained in one bytea column I think this is probably an out-of-memory situation inside pg_dump, ie libpq failing to make its input buffer large enough for the incoming row. It's hard to believe that there's not 6MB available on any modern machine, so I'm thinking this is an OS-level restriction on how much memory we can get. On a Unix machine I'd recommend looking at the ulimit settings pg_dump is being run under. Dunno the equivalent for Windows. 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] How to fix lost synchronization with server
Hi! pg_dump: Error message from server: lost synchronization with server: got message type d, length 5858454 I think this is probably an out-of-memory situation inside pg_dump, ie libpq failing to make its input buffer large enough for the incoming row. It's hard to believe that there's not 6MB available on any modern machine, so I'm thinking this is an OS-level restriction on how much memory we can get. On a Unix machine I'd recommend looking at the ulimit settings pg_dump is being run under. Dunno the equivalent for Windows. Backup computer has modern Windows client OS. It has GBs of memory and swap file possibility. Based on my knowledge there is no memory settings in windows which can restrict 6MB allocation. On memory shortage Windows shows message like Increasing swap file size. Customer did'nt report such message. Dump worked for years without issues when server was 32 bit Windows 2003 server and Postgres and pg_dump were earlier version 9 (but after upgrade new rows are added to attachme table). How to create backup copies or diagnose the issue ? I can change pg_dump execution parameters. I can install VC++ Express and compile something to add diagnozing if this can help. Maybe this message can improved to include more details about the reason. Andrus. -- 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 fix lost synchronization with server
Andrus Moor wrote Dump worked for years without issues when server was 32 bit Windows 2003 server and Postgres and pg_dump were earlier version 9 (but after upgrade new rows are added to attachme table). How to create backup copies or diagnose the issue ? I can change pg_dump execution parameters. I can install VC++ Express and compile something to add diagnozing if this can help. Maybe this message can improved to include more details about the reason. Given this is an upgrade, though the specifics were omitted, is there some possibility of a pg_dump/server version mis-match being the cause. I could see where a 32-bit client connecting to a 64bit server could possible exhibit apparent memory-related issues. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/How-to-add-xml-data-to-table-tp4881402p5803020.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 fix lost synchronization with server
Hi! Given this is an upgrade, though the specifics were omitted, is there some possibility of a pg_dump/server version mis-match being the cause. I could see where a 32-bit client connecting to a 64bit server could possible exhibit apparent memory-related issues. pg_dump is 32-bit version. pg_dump -V returns pg_dump (PostgreSQL) 9.3.0 Server is x64 : PostgreSQL 9.3.3 on x86_64-unknown-linux-gnu, compiled by gcc (Debian 4.7.2-5) 4.7.2, 64-bit Can this cause the issue ? Andrus. -- 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 fix lost synchronization with server
Hi! Given this is an upgrade, though the specifics were omitted, is there some possibility of a pg_dump/server version mis-match being the cause. I could see where a 32-bit client connecting to a 64bit server could possible exhibit apparent memory-related issues. pg_dump is 32-bit version. pg_dump -V returns pg_dump (PostgreSQL) 9.3.0 Server is x64 : PostgreSQL 9.3.3 on x86_64-unknown-linux-gnu, compiled by gcc (Debian 4.7.2-5) 4.7.2, 64-bit Can this cause the issue ? Andrus. -- 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 fix lost synchronization with server
Andrus kobrule...@hot.ee writes: Given this is an upgrade, though the specifics were omitted, is there some possibility of a pg_dump/server version mis-match being the cause. I could see where a 32-bit client connecting to a 64bit server could possible exhibit apparent memory-related issues. pg_dump is 32-bit version. pg_dump -V returns pg_dump (PostgreSQL) 9.3.0 Can this cause the issue ? Hm. It wouldn't *cause* the issue, but certainly a 32-bit pg_dump would have lots less headroom if there were a memory bloat problem. I looked back at the previous thread you mentioned (bug #7914) and was reminded that we never did understand what was going on in that report. I'm not sure if you are seeing the same thing though. That user reported that he was able to see pg_dump's memory consumption bloating well beyond what it ought to be (I suppose he was watching the process in whatever Windows' equivalent of ps or top is). Do you see that? If there is a memory leakage type issue involved then it's less surprising that a request for a mere 6MB would fail --- once we've leaked enough memory, it's certainly gonna fail at some point. This doesn't get us much closer to understanding the problem though. 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
