From sw@zpmt.de Sun Jul 5 22:08:02 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j8mFt-0001VS-0a for pgsql-interfaces@arkaria.postgresql.org; Mon, 02 Mar 2020 14:41:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j8mFr-0004bH-Fs for pgsql-interfaces@arkaria.postgresql.org; Mon, 02 Mar 2020 14:41:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j8mFr-0004b6-5d for pgsql-interfaces@lists.postgresql.org; Mon, 02 Mar 2020 14:41:11 +0000 Received: from mo6-p01-ob.smtp.rzone.de ([2a01:238:20a:202:5301::7]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j8mFn-0007Xc-3L for pgsql-interfaces@lists.postgresql.org; Mon, 02 Mar 2020 14:41:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1583160066; s=strato-dkim-0002; d=zpmt.de; h=Message-ID:Date:Subject:In-Reply-To:References:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=6mf0lcRKlhjhKvfzWM3qveQp3O4JLT8v/Txtd9RIHA4=; b=mk8a8yxm34hItbWYgIYOWEn+9wYHYuyxUdFQcBdmCM/GlutwmJWfNRWiG0B5jGRjVP vx/hQ8y8ksES06E52Smiq/xe/tYpCZAfhMYkZfTNimmTQAHRQi+PJDmjzhtu8VADKaxk /ADENUfyn1iNY/819e82p2FAY8DZjp5as/k8jjSHOeW7mHUe8tCxerUkix7KF3el0Ifh 6QGdnhs2lUu7JZOigHdtfiT90zYLWEBQIG4OZCViQWRDwn9FNkJsQvlsZH+z0wPGs/t+ 9SJ+jI2lfJheYzk11ZnEiVFddm/2S23cc0mkmYhp2SQgx/12ucgQ5BYCt6sqGLDxRb5j 0Adw== X-RZG-AUTH: ":P3skb1Clb7FflLtjx7SyHqq9vvRtyij2FeY9PjvgVpE8mmdz07+nqRe9cAwvD3gi4Su8us1NAkL8Mh8sOPQiVf5HLNY=" X-RZG-CLASS-ID: mo00 Received: from SWHP2016 by smtp.strato.de (RZmta 46.2.0 AUTH) with ESMTPSA id V0ba32w22Ef57Mx (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)) (Client did not present a certificate) for ; Mon, 2 Mar 2020 15:41:05 +0100 (CET) From: "Stefan Wolf" To: References: In-Reply-To: Subject: MS-ACCESS 2010, ODBC 12.01, Out of Memory Date: Mon, 2 Mar 2020 15:41:05 +0100 Message-ID: <000e01d5f0a0$9aeec2f0$d0cc48d0$@zpmt.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01D5F0A8.FCB3A020" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdXwmqj1zTn1zrOLSMG7POwaKM0rfAABYSNw Content-Language: de List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multipart message in MIME format. ------=_NextPart_000_000F_01D5F0A8.FCB3A020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Win10-Client: MS-ACCESS 2010 (32-Bit), ODBC-Driver: 12.01 Linux-Server (1): PostgreSQL 12.2 Linux-Server (2): PostgreSQL 9.6 We are currently migrating from PG 9.6. to 12.x. We've created System-DSNs (PostgreSQL Unicode) with [Defaults] for both Server. In MS-ACCESS our biggest Server-Tables (>14.000.000 Rows) can be opened (on both Servers). But it takes a lot of time and uses a lot of memory - more than 450MB on the client and some GB on the server. The indexes are recognized an filtering is fast. Trying to open more than one "big table" will result in MS-ACCESS "Out of memory". Best regards -Stefan Wolf- ------=_NextPart_000_000F_01D5F0A8.FCB3A020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Win10-Client:= MS-ACCESS 2010 (32-Bit), ODBC-Driver: = 12.01

Linux-Server = (1): PostgreSQL 12.2

Linux-Server = (2): PostgreSQL 9.6

We are = currently migrating from PG 9.6. to = 12.x.

We’ve = created System-DSNs (PostgreSQL Unicode) with [Defaults] for both = Server.

In MS-ACCESS = our biggest Server-Tables (>14.000.000 Rows) can be opened (on both = Servers).

But it takes = a lot of time and uses a lot of memory - more than 450MB on the client and some GB on the = server.

The indexes = are recognized an filtering is fast.

Trying to = open more than one “big table” will result in MS-ACCESS = “Out of memory”.

Best = regards

-Stefan = Wolf-

------=_NextPart_000_000F_01D5F0A8.FCB3A020-- From pavlo.golub@cybertec.at Sun Jul 5 22:08:02 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j8mIH-0001ZS-6N for pgsql-interfaces@arkaria.postgresql.org; Mon, 02 Mar 2020 14:43:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j8mIF-0008VH-VJ for pgsql-interfaces@arkaria.postgresql.org; Mon, 02 Mar 2020 14:43:39 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j8mIF-0008VA-KA for pgsql-interfaces@lists.postgresql.org; Mon, 02 Mar 2020 14:43:39 +0000 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1j8mID-00069L-1p for pgsql-interfaces@lists.postgresql.org; Mon, 02 Mar 2020 14:43:38 +0000 Received: by mail-wm1-x330.google.com with SMTP id g83so8708262wme.1 for ; Mon, 02 Mar 2020 06:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references:reply-to :user-agent:mime-version; bh=BF7BGhsAXt6+oly9uzWiINesEyT162iKjz6MpCHuavw=; b=fwG6BKD9pFz5nITaoBFGE4/MMs9OF72S7Vki53DquBNyIIH6ePCLsHRKwmpvCq8Pyc KnoisDjeqP1tJWrUzCyJ62VqGlycjEjTVAnIDl6U/RAfsvhqxC9L0rjob7G+jRgYBtVU 3USq8iPnmDZiUgYlDbB4w9mNg7/6atTNBmONUWEv+rAYV9ukr415m1kTJG4UbMgEkv/I XbkzWw+DWaQullC6FuRU7XljO4q9yA4tfUCZE/SvSPvEmP1aA0x1bIWhkHy71KpDuRN+ jKh/j7Ojt4daR9fcOtrZyp4WY44UTKuifqkMx18WkC3p7u/nv/vChV+9zmXAQN/ghixr OHUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:reply-to:user-agent:mime-version; bh=BF7BGhsAXt6+oly9uzWiINesEyT162iKjz6MpCHuavw=; b=GsagWwvYvb/n7EnTUrwIcumoGfcdLZA/Qutk+o3nylv1bI548swwnqFI3Fsr6WXozu 48JzKEF0/FnyR8p9aCxxVHaGjMcqzQ0WwrND/SUbzV+qeatx6ekyVCwkyMWuxy7SRJ3I jgOUh40CHFuDHeFm9k2kaMvPewMhMn2JssYCWVQNTOqaTieRpvxloHwF+PzNW2C35ojv cWy+tV6NyhY17Zxm9xBPngpbxAdeoM8fgK7DEdcOQKUn5TFeEPNlbcwjmmsJdZFwYxGM 7mFZxA0wsht0171CCSyJXHsUmIzfbnalPSAJGTcyFrGoLUnhdN+pB1eDc2sZZN6PTPAQ MWDQ== X-Gm-Message-State: APjAAAW/MKyrezcz3Wm1YmbcZjFkgHx5iYbD/woOk6MxsE7SgThLRM4H ALAkr8krDqJq2TXKgvm8URuUu8r1Shg= X-Google-Smtp-Source: APXvYqws7eYbFYyt3nz/pPte+XTe3o9MdF1qjMPF9chFFq/pQYLRXX1wTIGLWZVqvUsvSdr4uqWtlg== X-Received: by 2002:a1c:80d4:: with SMTP id b203mr20786100wmd.91.1583160215402; Mon, 02 Mar 2020 06:43:35 -0800 (PST) Received: from ?IPv6:2a02:ab04:149:6d00:68a3:e1bb:e30d:4ff8? (2a02-ab04-0149-6d00-68a3-e1bb-e30d-4ff8.dynamic.v6.chello.sk. [2a02:ab04:149:6d00:68a3:e1bb:e30d:4ff8]) by smtp.gmail.com with ESMTPSA id n3sm16176985wmc.42.2020.03.02.06.43.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2020 06:43:34 -0800 (PST) From: "Pavlo Golub" To: "Stefan Wolf" , pgsql-interfaces@lists.postgresql.org Subject: Re: MS-ACCESS 2010, ODBC 12.01, Out of Memory Date: Mon, 02 Mar 2020 14:43:32 +0000 Message-Id: In-Reply-To: <000e01d5f0a0$9aeec2f0$d0cc48d0$@zpmt.de> References: <000e01d5f0a0$9aeec2f0$d0cc48d0$@zpmt.de> Reply-To: "Pavlo Golub" User-Agent: eM_Client/7.2.37929.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB7257EB53-46FE-4049-98CD-E1C48C94769E" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --------=_MB7257EB53-46FE-4049-98CD-E1C48C94769E Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable ------ Original Message ------ From: "Stefan Wolf" To: pgsql-interfaces@lists.postgresql.org Sent: 2020-03-02 15:41:05 Subject: MS-ACCESS 2010, ODBC 12.01, Out of Memory >Win10-Client: MS-ACCESS 2010 (32-Bit), ODBC-Driver: 12.01 > >Linux-Server (1): PostgreSQL 12.2 > >Linux-Server (2): PostgreSQL 9.6 > > > > > >We are currently migrating from PG 9.6. to 12.x. > > > >We=E2=80=99ve created System-DSNs (PostgreSQL Unicode) with [Defaults] for = both=20 >Server. > > > >In MS-ACCESS our biggest Server-Tables (>14.000.000 Rows) can be opened=20 >(on both Servers). > >But it takes a lot of time and uses a lot of memory - more than 450MBon=20 >the client and some GB on the server. > > > This is for sure MsAcess problem, and not a bug of PostgreSQL. > > >The indexes are recognized an filtering is fast. > > > >Trying to open more than one =E2=80=9Cbig table=E2=80=9D will result in MS= -ACCESS =E2=80=9COut=20 >of memory=E2=80=9D. > Sounds like msAccess fetches all rows and put them into memory which is=20 weird and unwise. Not a bug of PostgreSQL > > > > >Best regards > >-Stefan Wolf- > > > --------=_MB7257EB53-46FE-4049-98CD-E1C48C94769E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

------ Original Message ------

From: "Stefan Wolf" <sw@zpmt.de&g= t;

To: pgsql-int= erfaces@lists.postgresql.org

Sent: 2020-03-02 15:41:05

Subject: MS-ACCESS 2010, ODBC 12.01, Out of Memory

Win10-Client: =C2=A0MS-ACCESS 2010 (32-Bit),=C2=A0 ODBC-Driver: =C2=A012.= 01
Linux-Server (1):=C2=A0 PostgreSQL 12.2
= Linux-Server (2):=C2=A0 PostgreSQL =C2=A09.6
=C2=A0
=C2=A0
We are currently migrating from PG 9.6. to 12.x.
=C2=A0
We=E2=80=99ve created System-DSNs (PostgreSQL Unicode) with [Def= aults] for both Server.
=C2=A0
In MS-ACCES= S our biggest Server-Tables (>14.000.000 Rows) can be opened (on both Se= rvers).
But it takes a lot of time and uses a lot of memory = - more than 450MB on the client and s= ome GB on the server.

This is for sure MsAcess problem, and not a bug of= PostgreSQL.

=C2=A0
The indexes are recognized an filtering is fast.
=C2=A0
Trying to open more than one =E2=80=9Cbig table=E2=80=9D wi= ll result in MS-ACCESS =E2=80=9COut of memory=E2=80=9D.

<= br />

Sounds like msAccess fetches all rows and put them = into memory which is weird and unwise. Not a bug of PostgreSQL

=C2=A0
Best regards
-Ste= fan Wolf-
= =C2=A0

--------=_MB7257EB53-46FE-4049-98CD-E1C48C94769E-- From jonah.harris@gmail.com Sun Jul 5 22:08:02 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j8mut-0002iF-Qc for pgsql-interfaces@arkaria.postgresql.org; Mon, 02 Mar 2020 15:23:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j8mus-0002Eh-G0 for pgsql-interfaces@arkaria.postgresql.org; Mon, 02 Mar 2020 15:23:34 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j8mus-0002Ea-5R for pgsql-interfaces@lists.postgresql.org; Mon, 02 Mar 2020 15:23:34 +0000 Received: from mail-oi1-x22b.google.com ([2607:f8b0:4864:20::22b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1j8mup-0006Rv-JC for pgsql-interfaces@lists.postgresql.org; Mon, 02 Mar 2020 15:23:33 +0000 Received: by mail-oi1-x22b.google.com with SMTP id j80so8634887oih.7 for ; Mon, 02 Mar 2020 07:23:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pLmCaT3adnlIEIojGM+lBpWY18Jf2nDpncRhEbOh9Xc=; b=GGj/wcpcIpE2M8uhqA8EsYw+rEt8oVrl9ZfWdeJADtg4CEkQkx1c3s/CHf6TPY19Dr PAi7eWvaE7FZN0/CZ82NV3JqAQfRfId9zoD+P4JJNSe1gKPKzpuJLqPl5mLhDsx8Mqkw j8BlDiAICD103oyC+Pw8IkZEuY+CEY5GHW2YKgEHtVxy5P8woiMEq7uL1rHuEExNxj+U f+5rd8l7WeEiGOSBuDJ+7Wi7onW9EThlpnxu4RZW26mPanDVzfamxxt8v3G9hDUlNIUu y4IBlLmh1R/ZbaqNAhaCquTnLQISGPk3XE5ZaYW47v5D5jCydtVic3c+7Yp4OGPrN+Hm 0RKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pLmCaT3adnlIEIojGM+lBpWY18Jf2nDpncRhEbOh9Xc=; b=UGJlT1CZWYm12aDCCXb7fBMNopdoTVhy66kHqN3ejY7HQrpTR8dH7I8f5aMPpw0fpk mD8k3DEEsPUWxXRs4J3CN6AmKn+oMoK4eJMWVbSLCU0QN8HIJsXItfOE/5dGRhwlBUUz 8xrKW5hdpy7rYRBUYQSeHe/nefuyJLR0xLd/N+1ReObBPdqjGE734ddiyxyKXlXQwgaF B48wT60Qgusu7rG24DzrsALD0HhJlf8qmelba5eaXAcUwqkEjzaahDqqFpnHMYygLtvI xdd1CyFEN+y9wkt9GYv0EhfNF2hVZ+OxGiZ3LulLPwA0ao9Lz5yum3nX6A07OW++lrGz Tfkw== X-Gm-Message-State: ANhLgQ2mfLwfIMvd7QF4k1P7JiqgCFp9cUVwCGl8qpSl/bvykXkmaWNz yzb1Hr5MiIdhRD7myli1H6OksTcRBoRqStdRF1ff8KWf X-Google-Smtp-Source: ADFU+vvtpcJ5XnOlAw0OFcxW283/hRviowyp+xqCT4/yg8IVM5fuyxZ07hclMYXmtzt0ZHRchSlUq1ZUkS91/3hrGoY= X-Received: by 2002:aca:f305:: with SMTP id r5mr16498oih.174.1583162610773; Mon, 02 Mar 2020 07:23:30 -0800 (PST) MIME-Version: 1.0 References: <000e01d5f0a0$9aeec2f0$d0cc48d0$@zpmt.de> In-Reply-To: From: "Jonah H. Harris" Date: Mon, 2 Mar 2020 10:23:19 -0500 Message-ID: Subject: Re: MS-ACCESS 2010, ODBC 12.01, Out of Memory To: Pavlo Golub Cc: Stefan Wolf , pgsql-interfaces@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000000973e0059fe0c5e7" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000000973e0059fe0c5e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 2, 2020 at 9:43 AM Pavlo Golub wrote: > > ------ Original Message ------ > From: "Stefan Wolf" > To: pgsql-interfaces@lists.postgresql.org > Sent: 2020-03-02 15:41:05 > Subject: MS-ACCESS 2010, ODBC 12.01, Out of Memory > > Win10-Client: MS-ACCESS 2010 (32-Bit), ODBC-Driver: 12.01 > > Linux-Server (1): PostgreSQL 12.2 > > Linux-Server (2): PostgreSQL 9.6 > > > > > > We are currently migrating from PG 9.6. to 12.x. > > > > We=E2=80=99ve created System-DSNs (PostgreSQL Unicode) with [Defaults] fo= r both > Server. > > > > In MS-ACCESS our biggest Server-Tables (>14.000.000 Rows) can be opened > (on both Servers). > > But it takes a lot of time and uses a lot of memory - more than 450MB on > the client and some GB on the server. > > > This is for sure MsAcess problem, and not a bug of PostgreSQL. > Is it? > > The indexes are recognized an filtering is fast. > > > > Trying to open more than one =E2=80=9Cbig table=E2=80=9D will result in M= S-ACCESS =E2=80=9COut of > memory=E2=80=9D. > > > Sounds like msAccess fetches all rows and put them into memory which is > weird and unwise. Not a bug of PostgreSQL > Sounds like the ODBC driver configuration isn't using UseDeclareFetch=3D1 and, as such, is defaulting to Postgres' crappy default buffer-all-results-on-the-client-at-once protocol - a problem that would exist in any client software not overriding that behavior. --=20 Jonah H. Harris --0000000000000973e0059fe0c5e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Mar 2, 2020 at 9:43 AM Pavlo Golu= b <pavlo.go= lub@cybertec.at> wrote:

------ Original Message ------

From: "Stefan Wolf" <sw@zpmt.de>

To: pgsql-interfaces@lists.postgresql.org

Sent: 2020-03-02 15:41:05

Subject: MS-ACCESS 2010, ODBC 12.01, Out of Memory

Win10-Client: =C2=A0MS-ACCESS 2010 (32-Bit),=C2= =A0 ODBC-Driver: =C2=A012.01
Linux-Server (1):=C2=A0 PostgreSQL 12.2
Linux-Server (2):=C2=A0 PostgreSQL =C2=A09.6
=C2=A0
=C2=A0
We are cur= rently migrating from PG 9.6. t= o 12.x.
=C2=A0=
We=E2=80=99ve created System-DSNs (Postgr= eSQL Unicode) with [Defaults] for both Server.
=C2=A0
In= MS-ACCESS our biggest Server-Tables (>14.000.000 Rows) can be opened (o= n both Servers).
But it tak= es a lot of time and uses a lot of memory - more than 450MB on the client and some GB on the server.

This is for sure = MsAcess problem, and not a bug of PostgreSQL.

Is it?

=C2=A0

The indexes are recognized an filtering i= s fast.
=C2=A0=
Trying to open more than one =E2=80=9Cbig= table=E2=80=9D will result in MS-ACCESS =E2=80=9COut of memory=E2=80=9D.

So= unds like msAccess fetches all rows and put them into memory which is weird= and unwise. Not a bug of PostgreSQL

Sounds like the ODBC driver configuration isn't using= =C2=A0UseDeclareFetch=3D1 and, as such, is defaulting to Postgres' crap= py default buffer-all-results-on-the-client-at-once protocol - a problem th= at would exist in any client software not overriding that behavior.

Jonah H. H= arris

--0000000000000973e0059fe0c5e7--