Re: [GENERAL] libpq: PQreset not reconnecting connection, even though server is running

I wrote: > I'm guessing (from "incomplete startup packet") that the connection > created by the new thread never actually succeeded, is that the > problem? Will PQreset only work on a connection that had previously > connected successfully? And as soon as I hit "send" on this email light dawned: t

[GENERAL] libpq: PQreset not reconnecting connection, even though server is running

Hi I have code in our "run this query" shim that automatically attempts to reconnect to the server if it finds that the connection is bad (usually it's just there to handle unexpected postmaster restarts). while (PQstatus(Conn) == CONNECTION_BAD) { fprintf(stderr, "postgres connection

Re: [GENERAL] libpq confusion

On Wednesday, September 20, 2017 1:47:05 PM EDT Igor Korot wrote: >Thx. >So it is referring to the command not a "command returning no data". ;-) assuming create table t (c int); select c from t; - PQresultStatus(result) == PGRES_TUPLES_OK - PQntuples(result) == number or

Re: [GENERAL] libpq confusion

Thx. So it is referring to the command not a "command returning no data". ;-) On Wed, Sep 20, 2017 at 1:42 PM, John R Pierce wrote: > On 9/20/2017 10:34 AM, Igor Korot wrote: > > >From the documentation: > https://www.postgresql.org/docs/9.1/static/libpq-exec.html > > [quote] > PGRES_COMMAND_OK >

Re: [GENERAL] libpq confusion

On 9/20/2017 10:34 AM, Igor Korot wrote: >From the documentation: https://www.postgresql.org/docs/9.1/static/libpq-exec.html [quote] PGRES_COMMAND_OK Successful completion of a command returning no data. [/quote] No data = no rows, right? from that same page, a bit farther down, clarifying t

Re: [GENERAL] libpq confusion

Hi, John, On Wed, Sep 20, 2017 at 12:02 PM, John R Pierce wrote: > On 9/20/2017 6:30 AM, Igor Korot wrote: > > Hi, guys, > > On Wed, Sep 20, 2017 at 12:20 AM, Allan Harvey > wrote: > > How do I properly check if the record exists from libpq? > > Igor, > I use PQntuples() to check the number of .

Re: [GENERAL] libpq confusion

On 9/20/2017 6:30 AM, Igor Korot wrote: Hi, guys, On Wed, Sep 20, 2017 at 12:20 AM, Allan Harvey wrote: How do I properly check if the record exists from libpq? Igor, I use PQntuples() to check the number of ... tuples, for > 0 I was actually curious - isn't it what "PGRES_COMMAND_OK" for?

Re: [GENERAL] libpq confusion

>How do I properly check if the record exists from libpq? Igor, I use PQntuples() to check the number of ... tuples, for > 0 Allan __ This e-mail message may contain confidential or legally privileged information and is only f

Re: [GENERAL] libpq confusion

Hi, guys, On Wed, Sep 20, 2017 at 12:20 AM, Allan Harvey wrote: > >>How do I properly check if the record exists from libpq? > > Igor, > I use PQntuples() to check the number of ... tuples, for > 0 I was actually curious - isn't it what "PGRES_COMMAND_OK" for? IIUC, this constant indicates succe

Re: [GENERAL] libpq confusion

2017-09-20 5:36 GMT+02:00 Igor Korot : > Hi, ALL, > > draft=# SELECT 1 FROM abcattbl WHERE abt_tnam = 'leagues'; > ?column? > -- > (0 rows) > > > However running it thru the PQexecParam() I am getting "PGRES_TUPLES_OK" > which means that the such record exist. > That means so this comman

[GENERAL] libpq confusion

Hi, ALL, draft=# SELECT 1 FROM abcattbl WHERE abt_tnam = 'leagues'; ?column? -- (0 rows) However running it thru the PQexecParam() I am getting "PGRES_TUPLES_OK" which means that the such record exist. How do I properly check if the record exists from libpq? -- Sent via pgsql-genera

[GENERAL] libpq Windows Debug binaries

Hi, ALL, Does anybody have a ready-to-use solution for libpq binaries for the Debug build on Windows? Thank you. -- 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] libpq backwards compatbility

PostgreSQL platforms have been upgraded to 9.6. Or make it a dependency of the application release that the PostgreSQL platform is 9.6. Andy From: Michael Paquier Sent: 03 November 2016 09:35 To: Andy Halsall Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] li

Re: [GENERAL] libpq backwards compatbility

On Wed, Nov 2, 2016 at 11:58 PM, Andy Halsall wrote: > Can we assume that the 9.6 libpq library is backwards compatible with > applications compiled against 9.3 headers? I wouldn't expect to have to > re-compile our application against 9.6 libpq headers and redeploy because > we're not taking adva

[GENERAL] libpq backwards compatbility

We have a libpq application written in C++. There are existing running deployments of our application that were compiled against PostgreSQL version 9.3. We want to move to PostgreSQL version 9.6. Can we assume that the 9.6 libpq library is backwards compatible with applications compiled agai

Re: [GENERAL] libpq heartbeat

On Thu, Oct 27, 2016 at 12:45 PM, Francisco Olarte wrote: > Merlin: > > On Thu, Oct 27, 2016 at 7:29 PM, Merlin Moncure wrote: >> On Thu, Oct 27, 2016 at 11:18 AM, Francisco Olarte >> wrote: >>> It is, but handling them is not easy, and you have to deal with things >>> like DoS which are not tri

Re: [GENERAL] libpq heartbeat

r for some reasons? I'll be able to check this next morning. Regards Marcin Od: "Tom Lane" Do: "Francisco Olarte" DW: "depesz" , "Marcin Giedz" , pgsql-general@postgresql.org Wysłane: czwartek, 27 październik 2016 18:32:54 Temat: Re: [GENERAL

Re: [GENERAL] libpq heartbeat

Merlin: On Thu, Oct 27, 2016 at 7:29 PM, Merlin Moncure wrote: > On Thu, Oct 27, 2016 at 11:18 AM, Francisco Olarte > wrote: >> It is, but handling them is not easy, and you have to deal with things >> like DoS which are not trivial on the server ( as it is a heavy >> service ). It can be done,

Re: [GENERAL] libpq heartbeat

On Thu, Oct 27, 2016 at 11:18 AM, Francisco Olarte wrote: > Merlin: > > On Thu, Oct 27, 2016 at 6:10 PM, Merlin Moncure wrote: >> On Thu, Oct 27, 2016 at 10:01 AM, Francisco Olarte >> wrote: >>> And I'd like to point libpq sessions does not sound to be the best >>> kind of traffic across a firew

Re: [GENERAL] libpq heartbeat

Tom: On Thu, Oct 27, 2016 at 6:32 PM, Tom Lane wrote: > Francisco Olarte writes: >> Isn't this a server setting, and so going to affect every connection, > Yes, Ok, just checking. > but there are equivalent libpq parameters for firing heartbeat > pings from the client side. Those are per-conn

Re: [GENERAL] libpq heartbeat

Francisco Olarte writes: > On Thu, Oct 27, 2016 at 5:01 PM, hubert depesz lubaczewski > wrote: >> On Thu, Oct 27, 2016 at 04:43:55PM +0200, Marcin Giedz wrote: >>> I'm wondering if there is any natural implementation of heartbeats in >>> libpq library? >> check tcp_keepalives_* in postgresql.con

Re: [GENERAL] libpq heartbeat

Merlin: On Thu, Oct 27, 2016 at 6:10 PM, Merlin Moncure wrote: > On Thu, Oct 27, 2016 at 10:01 AM, Francisco Olarte > wrote: >> And I'd like to point libpq sessions does not sound to be the best >> kind of traffic across a firewall, not a good service / protocol to >> expose. > meh -- it's perf

Re: [GENERAL] libpq heartbeat

On Thu, Oct 27, 2016 at 10:01 AM, Francisco Olarte wrote: > And I'd like to point libpq sessions does not sound to be the best > kind of traffic across a firewall, not a good service / protocol to > expose. meh -- it's perfectly fine to expose postgres to the internet as long as you've handled th

Re: [GENERAL] libpq heartbeat

On Thu, Oct 27, 2016 at 5:01 PM, hubert depesz lubaczewski wrote: > On Thu, Oct 27, 2016 at 04:43:55PM +0200, Marcin Giedz wrote: ... >> I'm wondering if there is any natural implementation of heartbeats in >> libpq library? ... > check tcp_keepalives_* in postgresql.conf Isn't this a server set

Re: [GENERAL] libpq heartbeat

Hi Marcin: On Thu, Oct 27, 2016 at 4:43 PM, Marcin Giedz wrote: > I'm wondering if there is any natural implementation of heartbeats in libpq > library? We've been facing specially in firewall env occasionally session > drops between client and server. Extending session timeout directly on > fire

Re: [GENERAL] libpq heartbeat

On Thu, Oct 27, 2016 at 04:43:55PM +0200, Marcin Giedz wrote: > Hello all > > I'm wondering if there is any natural implementation of heartbeats in > libpq library? We've been facing specially in firewall env > occasionally session drops between client and server. Extending > session timeout dire

[GENERAL] libpq heartbeat

Hello all I'm wondering if there is any natural implementation of heartbeats in libpq library? We've been facing specially in firewall env occasionally session drops between client and server. Extending session timeout directly on firewalls is not possible (company rules). Perhaps there is suc

Re: [GENERAL] Libpq functions & string to obtain connection parameters

On Fri, Oct 7, 2016 at 5:01 PM Adrian Klaver wrote: > On 10/07/2016 07:58 AM, arnaud gaboury wrote: > > > > > > > > > GGGrrrh > > > > --- > > # systemctl restart postgresql > > # su mattermost > > bash-4.3$ psql postgresql://mmuser:XXX@/mattermost? > > psql (9

Re: [GENERAL] Libpq functions & string to obtain connection parameters

arnaud gaboury writes: > OK. Now I know unix user mattermost can connect to mattermost Db via unix > socket. BUT when trying to write this in my URI: > postgresql://mmuser:MyPwd@/mattermost?connect_timeout=10 > I get this from my app : > Failed to ping db err:pq: SSL is not enabled on the server

Re: [GENERAL] Libpq functions & string to obtain connection parameters

On 10/07/2016 07:58 AM, arnaud gaboury wrote: GGGrrrh --- # systemctl restart postgresql # su mattermost bash-4.3$ psql postgresql://mmuser:XXX@/mattermost? psql (9.5.4) Type "help" for help. mattermost=> \q - O

Re: [GENERAL] Libpq functions & string to obtain connection parameters

On Fri, Oct 7, 2016 at 4:42 PM Adrian Klaver wrote: On 10/07/2016 07:28 AM, arnaud gaboury wrote: > > > On Fri, Oct 7, 2016 at 3:56 PM Adrian Klaver > wrote: > > On 10/07/2016 06:42 AM, arnaud gaboury wrote: > > > > > > > > > Honestly not so

Re: [GENERAL] Libpq functions & string to obtain connection parameters

On 10/07/2016 07:28 AM, arnaud gaboury wrote: On Fri, Oct 7, 2016 at 3:56 PM Adrian Klaver mailto:adrian.kla...@aklaver.com>> wrote: On 10/07/2016 06:42 AM, arnaud gaboury wrote: > > > > Honestly not so much, as it is a nearly perfect Copy/past of postgresql > offi

Re: [GENERAL] Libpq functions & string to obtain connection parameters

On Fri, Oct 7, 2016 at 3:56 PM Adrian Klaver wrote: > On 10/07/2016 06:42 AM, arnaud gaboury wrote: > > > > > > > > > Honestly not so much, as it is a nearly perfect Copy/past of postgresql > > official doc[0]. > > My postgresql socket is in the usual place: > > /run/postgresql/.s.PGSQL.5432= >

Re: [GENERAL] Libpq functions & string to obtain connection parameters

On 10/07/2016 06:42 AM, arnaud gaboury wrote: > > > > Honestly not so much, as it is a nearly perfect Copy/past of postgresql > official doc[0]. > My postgresql socket is in the usual place: > /run/postgresql/.s.PGSQL.5432= > So no need to specify it. But for the rest, I am still not sure of m

Re: [GENERAL] Libpq functions & string to obtain connection parameters

On 10/07/2016 06:42 AM, arnaud gaboury wrote: does that help? Honestly not so much, as it is a nearly perfect Copy/past of postgresql official doc[0]. My postgresql socket is in the usual place: /run/postgresql/.s.PGSQL.5432= So no need to specify it. But for the rest, I am still not

Re: [GENERAL] Libpq functions & string to obtain connection parameters

On Fri, Oct 7, 2016 at 3:15 PM Andreas Kretschmer wrote: > arnaud gaboury wrote: > > > I start an app which use a libpq function to read connection params in a > URI. > > Until now, the app was using a tcp connection to connect to postgresql > with > > this URI: > > > > postgres:// > mmuser:mmus

Re: [GENERAL] Libpq functions & string to obtain connection parameters

arnaud gaboury wrote: > I start an app which use a libpq function to read connection params in a URI. > Until now, the app was using a tcp connection to connect to postgresql with > this URI: > > postgres://mmuser:mmuser_password@10.10.10.1:5432/mattermost?sslmode=disable& > connect_timeout=10 >

[GENERAL] Libpq functions & string to obtain connection parameters

I start an app which use a libpq function to read connection params in a URI. Until now, the app was using a tcp connection to connect to postgresql with this URI: postgres:// mmuser:mmuser_password@10.10.10.1:5432/mattermost?sslmode=disable&connect_timeout=10 I want to switch and make the app co

Re: [GENERAL] libpq: why only one PQsendQuery per connection at a time?

2015-01-04 19:02 GMT+03:00 : > Hello! > Question generally to (libpq) developers. > > According to http://www.postgresql.org/docs/9.4/static/libpq-async.html: > "PQsendQuery cannot be called again (on the same connection) until > PQgetResult > has returned a null pointer, indicating that the comma

Re: [GENERAL] libpq: why only one PQsendQuery per connection at a time?

sftf-2 wrote > So question is why this limitaion exists? > > Why PQgetResult(PGconn *conn) operates on connection, > and not on some unique handler that each "PQsend*" could return. > > Is it limitaion of libpq or architecture of postgresql backend or > backend-frontend protocol? IIUC this is a

[GENERAL] libpq: why only one PQsendQuery per connection at a time?

Hello! Question generally to (libpq) developers. According to http://www.postgresql.org/docs/9.4/static/libpq-async.html: "PQsendQuery cannot be called again (on the same connection) until PQgetResult has returned a null pointer, indicating that the command is done." As I guess this is also true

Re: [GENERAL] libpq equivalent of jdbc:default:connection

Thanks David! This is what I needed. I figured I was looking in the wrong place. On Thu, Dec 11, 2014 at 10:58 AM, David G Johnston < david.g.johns...@gmail.com> wrote: > Jim McLaughlin wrote > > Hi all, > > > > I am rewriting a pljava procedure in C++ with libpq. This procedure needs > > to acce

Re: [GENERAL] libpq equivalent of jdbc:default:connection

Jim McLaughlin wrote > Hi all, > > I am rewriting a pljava procedure in C++ with libpq. This procedure needs > to access some temp tables that the calling procedure creates and > populates. It seems that the connection created by PQconnectdb creates a > new connection (I have tried all permutation

[GENERAL] libpq equivalent of jdbc:default:connection

Hi all, I am rewriting a pljava procedure in C++ with libpq. This procedure needs to access some temp tables that the calling procedure creates and populates. It seems that the connection created by PQconnectdb creates a new connection (I have tried all permutations of conninfo I could think of).

Re: [GENERAL] libpq: indefinite block on poll during network problems

On Fri, May 30, 2014 at 4:00 PM, Dmitry Samonenko wrote: > I'm troubled with possible 'imperfection' of very simple, yet core feature > - PQexec, which can lead to blocked applications. You believe that the > problem is caused by client design flaw. Okay, fine. Is it possible to mark > this poten

Re: [GENERAL] libpq: indefinite block on poll during network problems

Sorry, my last mail got truncated. I'm starting to like Gmail mobile. On Saturday, May 31, 2014, Dmitry Samonenko wrote: > > >> Though this then begs the question: if the connection comes back up what >> happens in the client? > > > >> Depends on the state of the server. If problem was purely net

Re: [GENERAL] libpq: indefinite block on poll during network problems

On Friday, May 30, 2014, David G Johnston wrote: > Tom Lane-2 wrote > > That argument seems nonsensical from here. If you need HA then you > should > > be using network service monitoring tools, not relying on some random > > libpq client to decide that its connection has been lost. I'm troub

Re: Fwd: [GENERAL] libpq: indefinite block on poll during network problems

Tom Lane-2 wrote > Dmitry Samonenko < > shreddingwork@ > > writes: >> Yeah, that will work. Looks simple to implement in the client. Question >> is: >> why don't you think it should be a part of the libpq's API? It's a must >> have feature in high availability environments where only several minu

Re: Fwd: [GENERAL] libpq: indefinite block on poll during network problems

Dmitry Samonenko writes: > Yeah, that will work. Looks simple to implement in the client. Question is: > why don't you think it should be a part of the libpq's API? It's a must > have feature in high availability environments where only several minutes > of Out of Service per year are tolerable.

Re: Fwd: [GENERAL] libpq: indefinite block on poll during network problems

On Fri, May 30, 2014 at 8:19 PM, Martijn van Oosterhout wrote: > I don't think the suggestion is to move to async command processing. I > think the suggestion is to use those methods to make a > PGgetResultWithTimeout() that does what you want. > > Have a nice day, > -- > Martijn van Oosterhout

Re: Fwd: [GENERAL] libpq: indefinite block on poll during network problems

On Fri, May 30, 2014 at 07:48:00PM +0400, Dmitry Samonenko wrote: > > BTW, you might consider using libpq's nonblock mode to push the waiting > > out to the application level, and then you could just decide when you've > > waited too long for yourself. > > > Do you mean PQsendQuery / PQisBusy / PQg

Re: Fwd: [GENERAL] libpq: indefinite block on poll during network problems

On Fri, May 30, 2014 at 6:08 PM, Tom Lane wrote: [ shrug... ] This is not a bug. It might be a feature request, but > I doubt that it's a feature anybody would be interested in implementing. > Don't count me out. > Adding timeouts to libpq would mean adding hard-to-test (and therefore > easy-

Re: Fwd: [GENERAL] libpq: indefinite block on poll during network problems

Dmitry Samonenko writes: > So, should I fill a bug report? [ shrug... ] This is not a bug. It might be a feature request, but I doubt that it's a feature anybody would be interested in implementing. Adding timeouts to libpq would mean adding hard-to-test (and therefore easy-to-break) logic paths

Re: Fwd: [GENERAL] libpq: indefinite block on poll during network problems

So, should I fill a bug report? With regards, Dmitry Samonenko.

Re: Fwd: [GENERAL] libpq: indefinite block on poll during network problems

Martijn van Oosterhout writes: > Something very important to note: those settings do nothing unless the > SO_KEEPALIVE option is turned on for the socket. AFAICT libpq does not > enable this option, hence they (probably) have no effect. AFAICS, it does so by default since 9.0.

Re: Fwd: [GENERAL] libpq: indefinite block on poll during network problems

Please, look inside attached strace_export.txt. Second line. With regard, Dmitry Samonenko.

Re: Fwd: [GENERAL] libpq: indefinite block on poll during network problems

On Thu, May 29, 2014 at 12:27:50PM +0400, Dmitry Samonenko wrote: > Guys, first of all: thank you for you help and cooperation. I have received > several mails suggesting tweaks for tcp_keepalive and usage of postgresql > server functions/features (cancel, statement timeout), but as I said - it > w

Re: Fwd: [GENERAL] libpq: indefinite block on poll during network problems

Guys, first of all: thank you for you help and cooperation. I have received several mails suggesting tweaks for tcp_keepalive and usage of postgresql server functions/features (cancel, statement timeout), but as I said - it won't help. I have reproduced the problem scenario. Logs are attached. I w

Re: Fwd: [GENERAL] libpq: indefinite block on poll during network problems

On 05/28/2014 02:04 AM, Dmitry Samonenko wrote: On Tue, May 27, 2014 at 6:10 PM, Tom Lane mailto:t...@sss.pgh.pa.us>> wrote: Would you provide some evidence for these claims? If the keepalive stuff didn't work, somebody would certainly have noticed by now. Sure. I'll try to provi

Re: Fwd: [GENERAL] libpq: indefinite block on poll during network problems

On Tue, May 27, 2014 at 6:10 PM, Tom Lane wrote: > > Would you provide some evidence for these claims? If the keepalive stuff > didn't work, somebody would certainly have noticed by now. > > Sure. I'll try to provide it. > Our general approach to network-error handling is that dropping a > con

Re: Fwd: [GENERAL] libpq: indefinite block on poll during network problems

Dmitry Samonenko writes: > On Tue, May 27, 2014 at 2:35 PM, Albe Laurenz wrote: >> In PostgreSQL you can handle the problem of dying connections by setting >> the >> tcp_keepalives_* parameters (see >> http://www.postgresql.org/docs/current/static/runtime-config-connection.html >> ). >> >> That s

Fwd: [GENERAL] libpq: indefinite block on poll during network problems

On Tue, May 27, 2014 at 2:35 PM, Albe Laurenz wrote: > In PostgreSQL you can handle the problem of dying connections by setting > the > tcp_keepalives_* parameters (see > http://www.postgresql.org/docs/current/static/runtime-config-connection.html > ). > > That should take care of the problem, rig

Re: [GENERAL] libpq: indefinite block on poll during network problems

Dmitry Samonenko wrote: > I have an application which uses libpq for interaction with remote PostgreSQL > 9.2.4 server. Clients > and Server nodes are running Linux and connection is established using TCPv4. > The client application > has some small fault-tolerance features, which are activated w

[GENERAL] libpq: indefinite block on poll during network problems

I have an application which uses libpq for interaction with remote PostgreSQL 9.2.4 server. Clients and Server nodes are running Linux and connection is established using TCPv4. The client application has some small fault-tolerance features, which are activated when server related problems are enco

Re: [GENERAL] libpq - lack of support to set the fetch size

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > Second, the feature needed to do this without even > using a cursor was added 1.5 years ago (PQsetSingleRowMode). The DBD::Pg > was just not taught how to use it yet. True. And we were hoping for something better, so we can make one request

Re: [GENERAL] libpq - lack of support to set the fetch size

On Mar 12, 2014, at 5:57 AM, matshyeq wrote: > I don't see why? I can't think of any single SQL tool I've been working with > that didn't have this functionality, really. > The principle I find very simple and useful. > There is defined "fetch row size" parameter (each tool calls give its own

Re: [GENERAL] libpq - lack of support to set the fetch size

On 03/12/2014 06:05 AM, matshyeq wrote: Don't fully agree with last statement. FETCH is WAY better and more functional than LIMIT. PQsetSingleRowMode() is not meant for partial resultsets, but it can be used if you accept the downsides. Given the 'discretion mode' I'm still not

Re: [GENERAL] libpq - lack of support to set the fetch size

On Wed, Mar 12, 2014 at 9:30 AM, Marko Kreen wrote: > On Tue, Mar 11, 2014 at 12:39:12PM +, matshyeq wrote: > > - when using PQsetSingleRowMode() function - does it give an option to > > define how many rows to cache on client's side (like JDBC setFetchSize() > > does) or leaves it at pqli

Re: [GENERAL] libpq - lack of support to set the fetch size

> > > Well, I don't know what "streamed" exactly means here. > > If server pushes sequentially all the data not asking client if ready > to > > receive then that's what the issue is about. > > This problem is handled in kernel's TCP stack - it will slow down > the connection if userspace does not

Re: [GENERAL] libpq - lack of support to set the fetch size

On Wed, Mar 12, 2014 at 10:57:03AM +, matshyeq wrote: > On Wed, Mar 12, 2014 at 9:30 AM, Marko Kreen wrote: > > This option would not make sense as you are not "fetching" anything, > > full resultset is being streamed from server over TCP connection. > > Well, I don't know what "streamed" exa

Re: [GENERAL] libpq - lack of support to set the fetch size

On Tue, Mar 11, 2014 at 12:39:12PM +, matshyeq wrote: > - when using PQsetSingleRowMode() function - does it give an option to > define how many rows to cache on client's side (like JDBC setFetchSize() > does) or leaves it at pqlib's discretion? This option would not make sense as you are not

Re: [GENERAL] libpq - lack of support to set the fetch size

Marko, Tom, Adrian, Jeff, Daniel - thank you all for valuable feedback! Two general questions: - when using PQsetSingleRowMode() function - does it give an option to define how many rows to cache on client's side (like JDBC setFetchSize() does) or leaves it at pqlib's discretion? - is it/would

Re: [GENERAL] libpq - lack of support to set the fetch size

matshyeq wrote: > The only solution is CURSOR based which I find an awkward low level hack > comparing to elegant option supported by native library. That's not the only solution, even with the current DBD::Pg you could do: $dbh->do("COPY (sql-squery) TO STDOUT"); my $data; while ($dbh->

Re: [GENERAL] libpq - lack of support to set the fetch size

On Sun, Mar 9, 2014 at 6:43 AM, matshyeq wrote: > Hello, > > I've found an issue when tried to implement fetching rows from big table > (2mln rows) in my app. > Basically I don't find an elegant and easy way (other than always use > cursors) to limit the number of rows returned. > This causes my

Re: [GENERAL] libpq - lack of support to set the fetch size

matshyeq writes: > If 'SingleRowMode' goes row-by-row then again it's not a solution, > especially given that this particular issue applies to rather large row > sets. Perhaps you should actually experiment with that solution instead of rejecting it out of hand. Or at least RTFM about it. It do

Re: [GENERAL] libpq - lack of support to set the fetch size

On 03/10/2014 04:51 AM, matshyeq wrote: Albe Laurenz wrote: I would believe the stackoverflow (http://stackoverflow.com/questions/21960121/perl-script-fails-when-selecting-data-from-big-postgresql-table) question referred to explains the issue well. You can retrieve the full result set, not

Re: [GENERAL] libpq - lack of support to set the fetch size

>Albe Laurenz wrote: I would believe the stackoverflow ( http://stackoverflow.com/questions/21960121/perl-script-fails-when-selecting-data-from-big-postgresql-table) question referred to explains the issue well. > You can retrieve the full result set, not an option because of client memory limita

Re: [GENERAL] libpq - lack of support to set the fetch size

Fully agree with Laurenz. LIMIT in some (limited!) cases could be seen as a workaround but it's far from being elegant (what if your end user types the query?) If 'SingleRowMode' goes row-by-row then again it's not a solution, especially given that this particular issue applies to rather large row

Re: [GENERAL] libpq - lack of support to set the fetch size

On Mon, Mar 10, 2014 at 06:58:26AM +, Albe Laurenz wrote: > Daniel Verite wrote: > > matshyeq wrote: > > [ runs out of memory on the client because all results from a large query are > retrieved at once ] > > >> "Unfortunately, this is a limitation in the underlying driver (libpq) > >> rath

Re: [GENERAL] libpq - lack of support to set the fetch size

On 3/9/2014 6:43 AM, matshyeq wrote: Hello, I've found an issue when tried to implement fetching rows from big table (2mln rows) in my app. Basically I don't find an elegant and easy way (other than always use cursors) to limit the number of rows returned. This causes my application to break d

Re: [GENERAL] libpq - lack of support to set the fetch size

matshyeq wrote: > Postgresql is there for a good while perceived as one of the best (or just > simply the best!?) > available open source DB solution, so I'm really surprised this functionality > is not yet supported... You can retrieve the full result set, you can retrieve it row by row, you ca

Re: [GENERAL] libpq - lack of support to set the fetch size

Daniel Verite wrote: > matshyeq wrote: [ runs out of memory on the client because all results from a large query are retrieved at once ] >> "Unfortunately, this is a limitation in the underlying driver (libpq) rather >> than DBD::Pg itself. There have been talks over the years of supporting >> t

Re: [GENERAL] libpq - lack of support to set the fetch size

matshyeq wrote: > "Unfortunately, this is a limitation in the underlying driver (libpq) rather > than DBD::Pg itself. There have been talks over the years of supporting > this, but nothing concrete yet. Your best bet would be to ask about this on > the Postgres lists" > > Would you consid

Re: [GENERAL] libpq - lack of support to set the fetch size

On 03/09/2014 06:43 AM, matshyeq wrote: Hello, I've found an issue when tried to implement fetching rows from big table (2mln rows) in my app. Basically I don't find an elegant and easy way (other than always use cursors) to limit the number of rows returned. This causes my application to break

[GENERAL] libpq - lack of support to set the fetch size

Hello, I've found an issue when tried to implement fetching rows from big table (2mln rows) in my app. Basically I don't find an elegant and easy way (other than always use cursors) to limit the number of rows returned. This causes my application to break due to the excessive memory consumption.

Re: [GENERAL] libpq compatibility

On Tue, Feb 12, 2013 at 10:19 AM, Philipp Kraus wrote: > Hello, > > I'm using PG 9.2.2 with Qt for accessing the server. If I compile Qt with the > 9.2.2 libpg, can I use this libpg also with eg 8.3 ? > So can I use the libpg with earlier Postgres database versions? Yes, you can use the most rec

[GENERAL] libpq compatibility

Hello, I'm using PG 9.2.2 with Qt for accessing the server. If I compile Qt with the 9.2.2 libpg, can I use this libpg also with eg 8.3 ? So can I use the libpg with earlier Postgres database versions? Thanks Phil -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make c

Re: [GENERAL] Libpq and multithreading

A back-trace would definitely be helpful to analyze the issue. -- Thanks & Regards, Ashesh Vashi EnterpriseDB INDIA: Enterprise PostgreSQL Company *http://www.linkedin.com/in/asheshvashi* On Fri, Jan 18, 2013 at 7:35 PM, A

Re: [GENERAL] Libpq and multithreading

I am sure that I am using seperate threads with seperate connection objects and libpq is compiled to be threadsafe. I get access violation both with ssl and without it (without ssl it seems to be more stable, however afer several hundred connects/disconnects it fails). J. -- Sent via pgsql-ge

Re: [GENERAL] Libpq and multithreading

On Mon, Jan 14, 2013 at 9:57 AM, Asia wrote: > It is not possible because connection is local variable in both thread > functions, no common variables are used. > > I checked that it also crashes without SSL. Two threads connecting to the > same server, different databases. hm, where is your li

Re: [GENERAL] Libpq and multithreading

It is not possible because connection is local variable in both thread functions, no common variables are used. I checked that it also crashes without SSL. Two threads connecting to the same server, different databases. Joanna -- Sent via pgsql-general mailing list (pgsql-general@postgresql.

Re: [GENERAL] Libpq and multithreading

On Mon, Jan 14, 2013 at 8:28 AM, Alban Hertroys wrote: > An access violation means that you're trying to access memory that doesn't > belong to your process. I'm not sure where it's originating, that could be > the server but I suspect the issue is at the client-side. > > You're probably just forg

Re: [GENERAL] Libpq and multithreading

An access violation means that you're trying to access memory that doesn't belong to your process. I'm not sure where it's originating, that could be the server but I suspect the issue is at the client-side. You're probably just forgetting to free memory somewhere. On 14 January 2013 13:50, Asia

Re: [GENERAL] Libpq and multithreading

I am using 2 threads, each declares seperate PGconn conenction object. It connects e.g. 60 times, one connection from one thread, the other connection from the other thread, usually one after each other. And it fails at 61'st connection with access violation. I already tried with PQconnect and P

Re: [GENERAL] Libpq and multithreading

On Fri, Jan 11, 2013 at 04:27:42PM +0100, Asia wrote: > Hello, > > I am trying to use libpq in two threads, the issue is that I am getting > access violation after several successful connections. > Each thread connects to different db and disconnects immediately after making > a conenction. > >

[GENERAL] Libpq and multithreading

Hello, I am trying to use libpq in two threads, the issue is that I am getting access violation after several successful connections. Each thread connects to different db and disconnects immediately after making a conenction. So my question is if this is supported by libpq? Is it possible to us

Re: [GENERAL] libpq thread safety

Tom Lane wrote: Mark Morgan Lloyd writes: Do any special precautions need to be taken when PQNotifies is being called, to make sure that nothing else is referencing the handle? It's pretty much the same as any other operation on a PGconn: if there could be more than one thread touching the co

Re: [GENERAL] libpq thread safety

Mark Morgan Lloyd writes: > Do any special precautions need to be taken when PQNotifies is being > called, to make sure that nothing else is referencing the handle? It's pretty much the same as any other operation on a PGconn: if there could be more than one thread touching the connection object

[GENERAL] libpq thread safety

Do any special precautions need to be taken when PQNotifies is being called, to make sure that nothing else is referencing the handle? The sort of nightmare scenario I'm thinking about is when a background thread is periodically pulling data from a table into a buffer, but a foreground (GUI) t

Re: [GENERAL] libpq - prevent automatic reconnect

Chris Angelico wrote: On Thu, Dec 6, 2012 at 5:56 AM, Tom Lane wrote: I suspect this action isn't dropping the TCP connection. It's only equivalent to a momentary glitch in your network connectivity --- and you'd be very unhappy if that caused TCP connections to go down, because networks have

  1   2   3   4   >