Re: accessing postgres from c++

[Dominique Devienne]

On Tue, Jun 21, 2022 at 7:59 AM Laurenz Albe  wrote:
> I am surprised that you choose to be fettered by the constraints of a generic 
> API like ODBC.
> For me, that only makes sense if you want to be portable to different 
> databases.

Ditto.

> I would use ... C API of libpq, or, .. C++ boilerplate around it, use libpqxx.

There's also this modern C++ libpq wrapper, announced on this list
earlier this year:
https://github.com/dmitigr/pgfe

PS: Haven't used it. but followed it's development (to inform my own
non-OSS C++ wrapper dev), and it looked solid from a distance.
PPS: I think we tried libpqxx in the past, and I kinda remember it
forced you into non-binary mode, which was a non-started for
performance.

INSERT ALL with DML ERROR Logging replacement in PostgreSQL

[Jagmohan Kaintura]

Hi Team,
We are working on a project where we are moving from Oracle to PostgreSQL
and working on a migration tool which mostly have statements for inserting
the records which are correct and logging the errors in error table using
ORACLE inbuilt statement for INSERT ALL with DML ERROR logging.

As part of the postgresql best practices, what approach are we taking to
move these types of statements in Postgresql as we don't have any such
equivalent mechanism to load correct data in the main table and error
record in error table with error reason.

The statements mostly used are -->
INSERT ALL INTO
target_table
(COLUMN LIST)
VALUES()
LOG ERROR INTO ...
SELECT statement considering the source tables;

)
Can anyone please help me with what could be the best approach to convert
this in the tool.

-- 
*Best Regards,*
Jagmohan

Re: INSERT ALL with DML ERROR Logging replacement in PostgreSQL

[Gilles Darold]

Le 21/06/2022 à 09:08, Jagmohan Kaintura a écrit :

Hi Team,
We are working on a project where we are moving from Oracle to 
PostgreSQL and working on a migration tool which mostly have 
statements for inserting the records which are correct and logging the 
errors in error table using ORACLE inbuilt statement for INSERT ALL 
with DML ERROR logging.


As part of the postgresql best practices, what approach are we taking 
to move these types of statements in Postgresql as we don't have any 
such equivalent mechanism to load correct data in the main table and 
error record in error table with error reason.


The statements mostly used are -->
INSERT ALL INTO
target_table
(COLUMN LIST)
VALUES()
LOG ERROR INTO ...
SELECT statement considering the source tables;

)
Can anyone please help me with what could be the best approach to 
convert this in the tool.


--
*Best Regards,*
Jagmohan



Hi,


Maybe what you are looking for is here 
https://github.com/MigOpsRepos/pg_dbms_errlog , this is a PostgreSQL 
extension that emulates the DBMS_ERRLOG Oracle package.



Best regards,

--
Gilles Darold
http://www.darold.net/

Re: accessing postgres from c++

[Matthias Apitz]

We are developing a huge Library Management System with some 400 tables
and which is/was running on many UNIX derivates (SINIX, HP-UX, AIX,
SunOS, Linux) and all kind of databases one can imagine (INFORMIX,
Oracle, Sybase and now PostgreSQL). The system is written in C, C++ and
Perl and the C/C++ dblayer uses ESQL/C which made it highly portable between
the above mentioned DBSes. The PostgreSQL ESQL/C has an unbeatable
logging feature which logs all ESQL/C operations with their arguments
and results, like this:

[20746] [20.06.2022 11:57:19:817]: ECPGconnect: opening database test01 on 
bvbzflltdb1 port 5432 with options application_name=SunRise DBCALL V7.2 
(pid=20746) for user sisis
[20746] [20.06.2022 11:57:19:821]: ecpg_execute on line 822: query: select 
current_date; with 0 parameter(s) on connection test01
[20746] [20.06.2022 11:57:19:821]: ecpg_execute on line 822: using PQexec
[20746] [20.06.2022 11:57:19:821]: ecpg_process_output on line 822: correctly 
got 1 tuples with 1 fields
[20746] [20.06.2022 11:57:19:821]: ecpg_get_data on line 822: RESULT: 
20.06.2022 offset: 80; array: no
[20746] [20.06.2022 11:57:19:822]: prepare_common on line 936: name 
sid_sisisinst; query: "SELECT ctid, * from sisisinst WHERE version  = $1"
[20746] [20.06.2022 11:57:19:823]: ecpg_execute on line 1174: query: declare 
sisisinst_seq cursor with hold for SELECT ctid, * from sisisinst WHERE version  
= $1; with 1 parameter(s) on connection test01
[20746] [20.06.2022 11:57:19:823]: ecpg_execute on line 1174: using PQexecParams
[20746] [20.06.2022 11:57:19:823]: ecpg_free_params on line 1174: parameter 1 = 
V7.2
[20746] [20.06.2022 11:57:19:823]: ecpg_process_output on line 1174: OK: 
DECLARE CURSOR
[20746] [20.06.2022 11:57:19:823]: ecpg_execute on line 1585: query: fetch 
sisisinst_seq; with 0 parameter(s) on connection test01
[20746] [20.06.2022 11:57:19:823]: ecpg_execute on line 1585: using PQexec
[20746] [20.06.2022 11:57:19:823]: ecpg_process_output on line 1585: correctly 
got 1 tuples with 7 fields
[20746] [20.06.2022 11:57:19:823]: ecpg_get_data on line 1585: RESULT: (0,35) 
offset: 19; array: no
[20746] [20.06.2022 11:57:19:823]: ecpg_get_data on line 1585: RESULT: 
22.09.2021 offset: 137; array: no
[20746] [20.06.2022 11:57:19:823]: ecpg_get_data on line 1585: RESULT: 
srap34dxr1-20210616   offset: 137; array: no
...

The only missing thing in this logging was the PID and exact timestamp
of the operation. The latter makes performance analysing very easy.
We added this (PID and timestamp) to the sources of the ecpglib:

postgresql-14.1/src/interfaces/ecpg/ecpglib/misc.c

I could share the diff for maybe to be included in the original
sources.

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!

Re: INSERT ALL with DML ERROR Logging replacement in PostgreSQL

[Jagmohan Kaintura]

Hi Gilles,

I was going though this earlier today but didn't compiled it as I read it
may not be able to capture the errors if we have below type of statement
and most of our statements are of INSERT .. SELECT statements only.

The form INSERT INTO  SELECT ... will not have the same behavior
than in Oracle. It will not stored the successful insert and logged the
rows in error. This is not supported because it is a single transaction for
PostgreSQL and everything is rolled back in case of error.

Our all statements are of that form will it be still useful.

On Tue, Jun 21, 2022 at 1:07 PM Gilles Darold  wrote:

> Le 21/06/2022 à 09:08, Jagmohan Kaintura a écrit :
>
> Hi Team,
> We are working on a project where we are moving from Oracle to PostgreSQL
> and working on a migration tool which mostly have statements for inserting
> the records which are correct and logging the errors in error table using
> ORACLE inbuilt statement for INSERT ALL with DML ERROR logging.
>
> As part of the postgresql best practices, what approach are we taking to
> move these types of statements in Postgresql as we don't have any such
> equivalent mechanism to load correct data in the main table and error
> record in error table with error reason.
>
> The statements mostly used are -->
> INSERT ALL INTO
> target_table
> (COLUMN LIST)
> VALUES()
> LOG ERROR INTO ...
> SELECT statement considering the source tables;
>
> )
> Can anyone please help me with what could be the best approach to convert
> this in the tool.
>
> --
> *Best Regards,*
> Jagmohan
>
>
> Hi,
>
>
> Maybe what you are looking for is here
> https://github.com/MigOpsRepos/pg_dbms_errlog , this is a PostgreSQL
> extension that emulates the DBMS_ERRLOG Oracle package.
>
>
> Best regards,
>
> --
> Gilles Daroldhttp://www.darold.net/
>
>

-- 
*Best Regards,*
Jagmohan

Re: INSERT ALL with DML ERROR Logging replacement in PostgreSQL

[Gilles Darold]

Le 21/06/2022 à 10:28, Jagmohan Kaintura a écrit :

Hi Gilles,

I was going though this earlier today but didn't compiled it as I read 
it may not be able to capture the errors if we have below type of 
statement and most of our statements are of INSERT .. 
SELECT statements only.


The form |INSERT INTO  SELECT ...| will not have the same 
behavior than in Oracle. It will not stored the successful insert and 
logged the rows in error. This is not supported because it is a single 
transaction for PostgreSQL and everything is rolled back in case of error.


Our all statements are of that form will it be still useful.



Right, this was not obvious in your post, but yes if you are using 
INSERT + SELECT this is not possible with the current version of this 
extension. Maybe that could be possible by rewriting internally the 
query to loop over the result of the select and generate an insert per 
row returned, but with performances lost of courses.



Best regards,

--
Gilles Darold
http://www.darold.net/

Reminder: Call for Papers for PostgreSQL Conference Europe 2022 is closing soon!

[Andreas 'ads' Scherbaum]

PostgreSQL Conference Europe 2022 takes place in Berlin, Germany, on 
October 25-28. The Call for Papers is closing soon!


We are accepting proposals for talks in English. Each session will last 
45 minutes, and may be on any topic related to PostgreSQL. The 
submission deadline is June 27th. Selected speakers will be notified 
before July 17th, 2022.


Please submit your proposals by going to 
https://2022.pgconf.eu/call-for-papers/ and follow the instructions. The 
proposals will be considered by the program committee. The members of 
the program committee are listed on the website linked above.


All selected speakers will get free entry to the conference (excluding 
training sessions and other add-ons). We do not in general cover travel 
and accommodations for speakers, but may be able to do so in limited 
cases. If you require assistance with funding to be able to attend, 
please make a note of this in the submission notes field or contact us 
separately before the submission deadline.


As usual, if you have any questions, don't hesitate to contact us at 
cont...@pgconf.eu.


We look forward to seeing you in Berlin in October!

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project

Re: Postgresql error : PANIC: could not locate a valid checkpoint record

[Mateusz Henicz]

Could you also answer on questions asked by Laurenz Albe a few emails back?
That could shed some light into your issue. We would know if the upgrade
was performed properly and possibly point where the issue can be.
Also, are you able to reproduce the issue? I.e. try restoring the database
to state before upgrade, try to upgrade again. Does this corruption happen
again?
About pg_resetwal, you are right that it should be done as a last resort.
On the other hand, if your production database does not start after upgrade
and you do not have any way to rollback your changes it might be it.

Cheers,
Mateusz

wt., 21 cze 2022 o 14:02 Mahendrakar, Prabhakar - Dell Team <
prabhakar.mahendr...@dellteam.com> napisał(a):

> Could you please provide some insights in the below query. We are in need
> of this as it this issue is seen at some of our customer’s site.
>
>
>
> Thanks,
>
> Prabhakar
>
>
>
>
>
> Internal Use - Confidential
>
> *From:* Mahendrakar, Prabhakar - Dell Team
> *Sent:* Monday, June 20, 2022 4:22 PM
> *To:* Mateusz Henicz
> *Cc:* pgsql-general@lists.postgresql.org
> *Subject:* RE: Postgresql error : PANIC: could not locate a valid
> checkpoint record
>
>
>
> Thanks for the response.
>
> Yes, we have taken care of proper shut down of Postgres before initiating
> the Upgrade.
>
> pg_resetwal – I have read that using pg_resetwal may cause the Database
> more inconsistent and should be used only as a last resort.
>
>
>
> Also this problem ( *checkpoint* related issue -could not locate a valid
> checkpoint record ) is not happening frequently. This issue is seen with
> the large size of Data base.
>
> Please let me know if you require any more information.
>
>
>
> Thanks,
>
> Prabhakar
>
>
>
> *From:* Mateusz Henicz 
> *Sent:* Friday, June 17, 2022 3:39 PM
> *To:* Mahendrakar, Prabhakar - Dell Team
> *Cc:* pgsql-general@lists.postgresql.org
> *Subject:* Re: Postgresql error : PANIC: could not locate a valid
> checkpoint record
>
>
>
> [EXTERNAL EMAIL]
>
> Assuming you have shut down your postgres properly before upgrading, it
> should be safe for you to run pg_resetwal.
>
> https://www.postgresql.org/docs/current/app-pgresetwal.html
> [postgresql.org]
> 
>
>
> It should help in this case.
>
>
>
> pt., 17 cze 2022 o 12:03 Mahendrakar, Prabhakar - Dell Team <
> prabhakar.mahendr...@dellteam.com> napisał(a):
>
> Yes, We are using the pg_upgrade utility of Postgres.
>
>
>
> *From:* Mateusz Henicz 
> *Sent:* Friday, June 17, 2022 3:31 PM
> *To:* Mahendrakar, Prabhakar - Dell Team
> *Cc:* pgsql-general@lists.postgresql.org
> *Subject:* Re: Postgresql error : PANIC: could not locate a valid
> checkpoint record
>
>
>
> [EXTERNAL EMAIL]
>
> Hi,
>
> Have you done pg_upgrade post Postgres 13 installation?
>
>
> https://www.postgresql.org/docs/13/pgupgrade.html [postgresql.org]
> 
>
>
>
> Cheers,
> Mateusz
>
>
>
> pt., 17 cze 2022 o 11:20 Mahendrakar, Prabhakar - Dell Team <
> prabhakar.mahendr...@dellteam.com> napisał(a):
>
> Hello,
>
>
>
> Good Morning !
>
>
>
> We are facing *checkpoint* related issues from PostGreSQL 13.4 ( could
> not locate a valid checkpoint record) and Postgres service fails to come up.
>
>
> 
>
> *LOG:  starting PostgreSQL 13.4 on x86_64-pc-linux-gnu, compiled by gcc
> (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16), 64-bit*
>
> *LOG:  listening on IPv4 address "127.0.0.1", port 9003*
>
> *LOG:  listening on IPv4 address "10.xx.xx.x..", port 9003*
>
> *LOG:  listening on Unix socket "/tmp/.s.PGSQL.9003"*
>
> *LOG:  database system was shut down at 2022-06-09 10:19:24 CEST*
>
> *LOG:  invalid primary checkpoint record*
>
> *PANIC:  could not locate a valid checkpoint record*
>
> *LOG:  startup process (PID 8773) was terminated by signal 6: Aborted*
>
> *LOG:  aborting startup due to startup process failure*
>
> *LOG:  database system is shut down*
>
>
>
> This issue is seen in both Windows and Linux OS platforms.
>
>
>
> To Brief on the Scenario: Our product say example with Version A1 uses
> Postgres 10 and in the latest version of our product (Say A2) we upgraded
> the Postgres to 13.
>
>When we try to upgrade our
> Product through InstallAnyWhere from A1 to A2, Postgres service fails with
> above mentioned error.
>
>
>
>  Could you please suggest the probable cause of the issue. Let us know if
> you require any more information.
>
>
>
> Thanks,
>
> Prabhakar
>
>
>
>
>
> Internal Use - Confidential
>
>
>
> Internal Use - Confidential
>
>
>
> Internal Use - Confidential
>
>

Re: accessing postgres from c++

[Rino Mardo]

a db connector that will fit everyone? i think that's timely.

i have tried, once, libpqxx but i think it forces me to use the source.
couldn't find a binary that will just install and use like how python
works, i.e., "pip install psycopg2".



On Tue, 21 Jun 2022, 3:57 pm Matthias Apitz  wrote:

>
> We are developing a huge Library Management System with some 400 tables
> and which is/was running on many UNIX derivates (SINIX, HP-UX, AIX,
> SunOS, Linux) and all kind of databases one can imagine (INFORMIX,
> Oracle, Sybase and now PostgreSQL). The system is written in C, C++ and
> Perl and the C/C++ dblayer uses ESQL/C which made it highly portable
> between
> the above mentioned DBSes. The PostgreSQL ESQL/C has an unbeatable
> logging feature which logs all ESQL/C operations with their arguments
> and results, like this:
>
> [20746] [20.06.2022 11:57:19:817]: ECPGconnect: opening database test01 on
> bvbzflltdb1 port 5432 with options application_name=SunRise DBCALL V7.2
> (pid=20746) for user sisis
> [20746] [20.06.2022 11:57:19:821]: ecpg_execute on line 822: query: select
> current_date; with 0 parameter(s) on connection test01
> [20746] [20.06.2022 11:57:19:821]: ecpg_execute on line 822: using PQexec
> [20746] [20.06.2022 11:57:19:821]: ecpg_process_output on line 822:
> correctly got 1 tuples with 1 fields
> [20746] [20.06.2022 11:57:19:821]: ecpg_get_data on line 822: RESULT:
> 20.06.2022 offset: 80; array: no
> [20746] [20.06.2022 11:57:19:822]: prepare_common on line 936: name
> sid_sisisinst; query: "SELECT ctid, * from sisisinst WHERE version  = $1"
> [20746] [20.06.2022 11:57:19:823]: ecpg_execute on line 1174: query:
> declare sisisinst_seq cursor with hold for SELECT ctid, * from sisisinst
> WHERE version  = $1; with 1 parameter(s) on connection test01
> [20746] [20.06.2022 11:57:19:823]: ecpg_execute on line 1174: using
> PQexecParams
> [20746] [20.06.2022 11:57:19:823]: ecpg_free_params on line 1174:
> parameter 1 = V7.2
> [20746] [20.06.2022 11:57:19:823]: ecpg_process_output on line 1174: OK:
> DECLARE CURSOR
> [20746] [20.06.2022 11:57:19:823]: ecpg_execute on line 1585: query: fetch
> sisisinst_seq; with 0 parameter(s) on connection test01
> [20746] [20.06.2022 11:57:19:823]: ecpg_execute on line 1585: using PQexec
> [20746] [20.06.2022 11:57:19:823]: ecpg_process_output on line 1585:
> correctly got 1 tuples with 7 fields
> [20746] [20.06.2022 11:57:19:823]: ecpg_get_data on line 1585: RESULT:
> (0,35) offset: 19; array: no
> [20746] [20.06.2022 11:57:19:823]: ecpg_get_data on line 1585: RESULT:
> 22.09.2021 offset: 137; array: no
> [20746] [20.06.2022 11:57:19:823]: ecpg_get_data on line 1585: RESULT:
> srap34dxr1-20210616   offset: 137; array: no
> ...
>
> The only missing thing in this logging was the PID and exact timestamp
> of the operation. The latter makes performance analysing very easy.
> We added this (PID and timestamp) to the sources of the ecpglib:
>
> postgresql-14.1/src/interfaces/ecpg/ecpglib/misc.c
>
> I could share the diff for maybe to be included in the original
> sources.
>
> matthias
> --
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/
> +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
> May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
>

How to use 32 bit ODBC driver

[Aditya Bhardwaj]

Hi,
For Postgres, I'd like to utilize a 32-bit ODBC driver. I attempted to download 
it, but it does not appear in the 32-bit ODBC Data Source. Please assist me in 
locating or downloading the PostgresSql 32Bit OBDC driver.

Regards,
Aditya Bhardwaj
Disclaimer: The content of this email is confidential and intended for the 
recipient specified in message only. It is strictly forbidden to share any part 
of this message with any third party, without a written consent of the sender. 
If you received this message by mistake, please reply to this message and 
follow with its deletion, so that we can ensure such a mistake does not occur 
in the future.

RE: Postgresql error : PANIC: could not locate a valid checkpoint record

[Mahendrakar, Prabhakar - Dell Team]

Could you please provide some insights in the below query. We are in need of 
this as it this issue is seen at some of our customer's site.

Thanks,
Prabhakar



Internal Use - Confidential
From: Mahendrakar, Prabhakar - Dell Team
Sent: Monday, June 20, 2022 4:22 PM
To: Mateusz Henicz
Cc: pgsql-general@lists.postgresql.org
Subject: RE: Postgresql error : PANIC: could not locate a valid checkpoint 
record

Thanks for the response.
Yes, we have taken care of proper shut down of Postgres before initiating the 
Upgrade.
pg_resetwal - I have read that using pg_resetwal may cause the Database more 
inconsistent and should be used only as a last resort.

Also this problem ( checkpoint related issue -could not locate a valid 
checkpoint record ) is not happening frequently. This issue is seen with the 
large size of Data base.
Please let me know if you require any more information.

Thanks,
Prabhakar

From: Mateusz Henicz mailto:mateuszhen...@gmail.com>>
Sent: Friday, June 17, 2022 3:39 PM
To: Mahendrakar, Prabhakar - Dell Team
Cc: 
pgsql-general@lists.postgresql.org
Subject: Re: Postgresql error : PANIC: could not locate a valid checkpoint 
record


[EXTERNAL EMAIL]
Assuming you have shut down your postgres properly before upgrading, it should 
be safe for you to run pg_resetwal.
https://www.postgresql.org/docs/current/app-pgresetwal.html 
[postgresql.org]
It should help in this case.

pt., 17 cze 2022 o 12:03 Mahendrakar, Prabhakar - Dell Team 
mailto:prabhakar.mahendr...@dellteam.com>> 
napisał(a):
Yes, We are using the pg_upgrade utility of Postgres.

From: Mateusz Henicz mailto:mateuszhen...@gmail.com>>
Sent: Friday, June 17, 2022 3:31 PM
To: Mahendrakar, Prabhakar - Dell Team
Cc: 
pgsql-general@lists.postgresql.org
Subject: Re: Postgresql error : PANIC: could not locate a valid checkpoint 
record


[EXTERNAL EMAIL]
Hi,
Have you done pg_upgrade post Postgres 13 installation?

https://www.postgresql.org/docs/13/pgupgrade.html 
[postgresql.org]

Cheers,
Mateusz

pt., 17 cze 2022 o 11:20 Mahendrakar, Prabhakar - Dell Team 
mailto:prabhakar.mahendr...@dellteam.com>> 
napisał(a):
Hello,

Good Morning !

We are facing checkpoint related issues from PostGreSQL 13.4 ( could not locate 
a valid checkpoint record) and Postgres service fails to come up.

LOG:  starting PostgreSQL 13.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 
4.4.7 20120313 (Red Hat 4.4.7-16), 64-bit
LOG:  listening on IPv4 address "127.0.0.1", port 9003
LOG:  listening on IPv4 address "10.xx.xx.x..", port 9003
LOG:  listening on Unix socket "/tmp/.s.PGSQL.9003"
LOG:  database system was shut down at 2022-06-09 10:19:24 CEST
LOG:  invalid primary checkpoint record
PANIC:  could not locate a valid checkpoint record
LOG:  startup process (PID 8773) was terminated by signal 6: Aborted
LOG:  aborting startup due to startup process failure
LOG:  database system is shut down

This issue is seen in both Windows and Linux OS platforms.

To Brief on the Scenario: Our product say example with Version A1 uses Postgres 
10 and in the latest version of our product (Say A2) we upgraded the Postgres 
to 13.
   When we try to upgrade our Product 
through InstallAnyWhere from A1 to A2, Postgres service fails with above 
mentioned error.

 Could you please suggest the probable cause of the issue. Let us know if you 
require any more information.

Thanks,
Prabhakar



Internal Use - Confidential


Internal Use - Confidential


Internal Use - Confidential

Re: How to use 32 bit ODBC driver

[Rino Mardo]

hi. you didn't mention, after downloading did you install it?

On Tue, 21 Jun 2022, 9:11 pm Aditya Bhardwaj 
wrote:

> Hi,
>
> For Postgres, I'd like to utilize a 32-bit ODBC driver. I attempted to
> download it, but it does not appear in the 32-bit ODBC Data Source. Please
> assist me in locating or downloading the PostgresSql 32Bit OBDC driver.
>
>
>
> Regards,
>
> Aditya Bhardwaj
> Disclaimer: *The content of this email is confidential and intended for
> the recipient specified in message only. It is strictly forbidden to share
> any part of this message with any third party, without a written consent of
> the sender. If you received this message by mistake, please reply to this
> message and follow with its deletion, so that we can ensure such a mistake
> does not occur in the future.*
>

Re: How to use 32 bit ODBC driver

[Adrian Klaver]

On 6/20/22 22:51, Aditya Bhardwaj wrote:

Hi,

For Postgres, I'd like to utilize a 32-bit ODBC driver. I attempted to 
download it, but it does not appear in the 32-bit ODBC Data Source. 
Please assist me in locating or downloading the PostgresSql 32Bit OBDC 
driver.


You will need to provide more information:

1) What did you download from here?:

https://www.postgresql.org/ftp/odbc/versions/

2) What version?

3) Did you read this?:

https://odbc.postgresql.org/faq.html

6.8) Installing psqlODBC on 64bit Windows

It has section on how to access 32 bit version for set up.




Regards,

Aditya Bhardwaj

Disclaimer: /The content of this email is confidential and intended for 
the recipient specified in message only. It is strictly forbidden to 
share any part of this message with any third party, without a written 
consent of the sender. If you received this message by mistake, please 
reply to this message and follow with its deletion, so that we can 
ensure such a mistake does not occur in the future./



--
Adrian Klaver
adrian.kla...@aklaver.com

Re: function currtid2() in SQL and ESQL/C to get the new CTID of a row

[Matthias Apitz]

El día Wednesday, June 01, 2022 a las 09:46:17AM -0400, Tom Lane escribió:

> ...
> 
> > Is this function currtid2() not meant to be used in ESQL/C? Or did we
> > something wrong in ESQL/C?
> 
> This is not about currtid2, this is a fundamental misunderstanding
> of how ECPG works.  You can only inject data values into ordinary
> EXEC SQL commands.  I think you could handle this as
> 
> EXEC SQL SELECT currtid2(:table ::text, :oldCTID ::tid) INTO :newCTID;
> 
> ...

Hello Tom,

We came accross cases where the above SELECT returns as :newCTID the
same as the :oldCTID. The :oldCTID was picked up with FETCH from the
CURSOR and before locking/updating the row in question we're now checking if its
CTID has changed meanwhile we're cycling though the CURSOR. In some cases the
CTID is returned as unchanged but a SELECT for UPDATE fails with the
CTID. I have here an example of the ESQL/C log:

ecpg_execute on line 3480: query: select currtid2 ( 'd01buch' :: text , $1  :: 
tid ); with 1 parameter(s) on connection sisis
ecpg_execute on line 3480: using PQexecParams
ecpg_free_params on line 3480: parameter 1 = (671803,22)
ecpg_process_output on line 3480: correctly got 1 tuples with 1 fields
ecpg_get_data on line 3480: RESULT: (671803,22) offset: 80; array: no 

ecpg_execute on line 2535: query: declare hc_d01buch cursor for SELECT * FROM 
d01buch WHERE ctid = $1 FOR UPDATE; with 1 parameter(s) on connection sisis
ecpg_execute on line 2535: using PQexecParams
ecpg_free_params on line 2535: parameter 1 = (671803,22)
ecpg_process_output on line 2535: OK: DECLARE CURSOR
ecpg_execute on line 2540: query: fetch hc_d01buch; with 0 parameter(s) on 
connection sisis
ecpg_execute on line 2540: using PQexec
ecpg_process_output on line 2540: correctly got 0 tuples with 78 fields
raising sqlcode 100 on line 2540: no data found on line 2540

Why is currtid2() returning the old CTID? Looking from another SQL
session the CITD of the row is indeed (671803,23), i.e. changed.

Thanks

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Source code test data folder don't have CSV files. How to get the CSV file.

[jian he]

trying to understand the source code test part.
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/test/regress/sql/copy.sql;h=d72d226f341f42c69ffcb773c4faf53d9e586894;hb=072132f04e55c1c3b0f1a582318da78de7334379

First I can just ignore all the abs_srcdir, abs_builddir.  Since I can type
the absolute file path. So till line 125, I know how to do it.
Then there is the \set filename :abs_builddir '/results/copytest.csv'.
There is only data,expected, sql folder. So where is the results folder.
How can I easily get the csv file? (because I don't know that much about
MAKE and C)..

-- 
 I recommend David Deutsch's <>

  Jian