Re: printing PGresult content with gdb
Envoyé: mercredi 3 juillet 2024 à 17:55
De: "Tom Lane"
À: clippe...@gmx.fr
Cc: pgsql-general@lists.postgresql.org
Objet: Re: printing PGresult content with gdb
clippe...@gmx.fr writes:
> I don't know if it is the right mailing list, but i was
> wondering if one could introspect via gdb the content of PGresult.
You might have better luck with that if you install the debuginfo
RPM corresponding to your libpq RPM. PGresult's innards are not
exposed to applications by libpq-fe.h, so your own app's debug
data is not going to contain the details of the struct. But I think
it would be available to gdb if libpq's debug symbols were installed.
regards, tom lane
thanks Tom
Indeed installing the debuginfo rpm on my system solves the issue, i could print the content
see trace below
(gdb) p *res
$2 = {ntups = 0, numAttributes = 0, attDescs = 0x0, tuples = 0x0, tupArrSize = 0, numParameters = 0, paramDescs = 0x0, resultStatus = PGRES_FATAL_ERROR,
cmdStatus = "\000ELECT 3\000\061", '\000' , binary = 0, noticeHooks = {noticeRec = 0x7f0731f40770 , noticeRecArg = 0x0,
noticeProc = 0x7f0731f40500 , noticeProcArg = 0x0}, events = 0x0, nEvents = 0, client_encoding = 6,
errMsg = 0x7f07180076e8 "server closed the connection unexpectedly\n\tThis probably means the server terminated abnormally\n\tbefore or while processing the request.\n",
errFields = 0x0, errQuery = 0x0, null_field = "", curBlock = 0x7f07180076e0, curOffset = 146, spaceLeft = 1902, memorySize = 2264}
[no subject]
Hi all I bumped into a weird case that i don't really understand...maybe someone in this list could have a clue We have 2 Postgres databases configured as master/slave replica (Postgresq 12, RHEL8) We have applications which write data into the master and applications which reads data from the replica. A group of applications reads data using libpq: it declares a select statement as cursor and then there is fetch which can retrieve at most 25k rows. The select statement contains a between clause with T1 and T2. T1 is injected via input parameter but T2=floor(extract (epoch from coalesce(pg_last_xact_replay_timestamp(),now(-120. It is passed directly like that in the query. In other words we have something like select * from ZZ where ... and timestamp between $T1 and floor(extract (epoch from coalesce(pg_last_xact_replay_timestamp(),now(-120; when this query gets executed, from time to time it returns a truncated number of rows.. less than if i was doing between T1 and T1... T2 being an integer so either T2=T1 and I would expect at least #rows greater or equal to the number of rows between T1 and T1, Note that we are talking about a total number of rows less than 2000. Then when i fixed T2, in other words i do a query using between $T1 and $T2 (where T2=floor(extract (epoch from coalesce(pg_last_xact_replay_timestamp(),now(-120) then there is no issues, number of rows are retrieved correctly. I also confirmed via metrics collection that the data is there when the query is being performed. I would appreciate any explanations on this behavior, and hoping i'm clear. Thanks Doris
