Re: rare crash - FailedAssertion snapbuild.c Line: 580
Hello all, Any update on this? Thanks and regards Pradeep On Thu, Jul 25, 2024 at 1:09 PM Pradeep Kumar wrote: > Hello all, > > Message Id: > https://www.postgresql.org/message-id/flat/3808dc548e144c860fc3fe57de013809%40xs4all.nl#72629a188e99e14387230fccc8eef518 > > Actually I'm also facing this issue. Any solution regarding this? .Kindly > give me the explanation of why this error occurs. > > Thanks and regards > Pradeep >
rare crash - FailedAssertion snapbuild.c Line: 580
Hello all, Message Id: https://www.postgresql.org/message-id/flat/3808dc548e144c860fc3fe57de013809%40xs4all.nl#72629a188e99e14387230fccc8eef518 Actually I'm also facing this issue. Any solution regarding this? .Kindly give me the explanation of why this error occurs. Thanks and regards Pradeep
Re: Need clarification on compilation errors in PG 16.2
Hi, I found out that for using memset() library is not referred from "/Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/usr/include/string.h" , it referred from "/Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/usr/include/secure/_string.h", in that file didn't defined the memset_s() macro. Thanks and regards Pradeep On Wed, May 29, 2024 at 11:30 AM Pradeep Kumar wrote: > Hello Tom, > > >That's correct for recent versions of macOS. I see you are > >building against a recent SDK: > > > > >/Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk/usr/include/string.h > > > >but I wonder if maybe the actual OS version is back-rev? > > Currently Im using "MacOSX14.4.sdk" , path is > "/Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/usr/include/string.h". > When I go through the header file and search for the memset_s(), I found > that library is defined in a conditional macro refer below, am I breaking > the macro below? > > #if defined(__STDC_WANT_LIB_EXT1__) && __STDC_WANT_LIB_EXT1__ >= 1 > #include > #include > > __BEGIN_DECLS > errno_t memset_s(void *__s, rsize_t __smax, int __c, rsize_t __n) > __OSX_AVAILABLE_STARTING(__MAC_10_9, __IPHONE_7_0); > __END_DECLS > #endif > > Thanks and Regards > Pradeep > > On Wed, May 29, 2024 at 2:21 AM Tom Lane wrote: > >> Pradeep Kumar writes: >> > Yes it was defined in "pg_config.h" >> > /* Define to 1 if you have the `memset_s' function. */ >> > #define HAVE_MEMSET_S 1 >> >> That's correct for recent versions of macOS. I see you are >> building against a recent SDK: >> >> >> /Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk/usr/include/string.h >> >> but I wonder if maybe the actual OS version is back-rev? >> >> regards, tom lane >> >
Re: Need clarification on compilation errors in PG 16.2
Hello Tom, >That's correct for recent versions of macOS. I see you are >building against a recent SDK: > >/Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk/usr/include/string.h > >but I wonder if maybe the actual OS version is back-rev? Currently Im using "MacOSX14.4.sdk" , path is "/Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/usr/include/string.h". When I go through the header file and search for the memset_s(), I found that library is defined in a conditional macro refer below, am I breaking the macro below? #if defined(__STDC_WANT_LIB_EXT1__) && __STDC_WANT_LIB_EXT1__ >= 1 #include #include __BEGIN_DECLS errno_t memset_s(void *__s, rsize_t __smax, int __c, rsize_t __n) __OSX_AVAILABLE_STARTING(__MAC_10_9, __IPHONE_7_0); __END_DECLS #endif Thanks and Regards Pradeep On Wed, May 29, 2024 at 2:21 AM Tom Lane wrote: > Pradeep Kumar writes: > > Yes it was defined in "pg_config.h" > > /* Define to 1 if you have the `memset_s' function. */ > > #define HAVE_MEMSET_S 1 > > That's correct for recent versions of macOS. I see you are > building against a recent SDK: > > > /Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk/usr/include/string.h > > but I wonder if maybe the actual OS version is back-rev? > > regards, tom lane >
Re: Need clarification on compilation errors in PG 16.2
Hi Long, >In fact, whether the HAVE_MEMSET_S macro is defined determines whether the implementation >of the explicit_bzero() function calls memset_s() or memset(). This macro is undefined by default >in pg_config.h, so check to see if your build environment has a HAVE_MEMSET_S macro defined. Yes it was defined in "pg_config.h" /* Define to 1 if you have the `memset_s' function. */ #define HAVE_MEMSET_S 1 Thanks On Tue, May 28, 2024 at 12:27 PM Long Song wrote: > > > > > > Hi Pradeep, > > > At 2024-05-28 12:37:08, "Pradeep Kumar" wrote: > > > Hi , > > While we try to install PG 16.2 from the source code in macbook we > getting this following errors > > ``` > > > > explicit_bzero.c:22:9: error: call to undeclared function 'memset_s'; > ISO C99 and later do not support implicit function declarations > [-Wimplicit-function-declaration] > > (void) memset_s(buf, len, 0, len); > >^ > > explicit_bzero.c:22:9: note: did you mean 'memset'? > > > /Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk/usr/include/string.h:74:7: > note: 'memset' declared here > > voidmemset(void __b, int __c, size_t __len); > > ^ > > 1 error generated. > > make[2]: *** [explicit_bzero.o] Error 1 > > make[2]: *** Waiting for unfinished jobs > > make[1]: *** [all-port-recurse] Error 2 > > make: *** [all-src-recurse] Error 2 > > > > ``` > > then I changed the function memset_s(buf, len, 0, len) to memset(buf, 0, > len) and it's working. need a clarification on this? > In fact, whether the HAVE_MEMSET_S macro is defined determines whether the > implementation > of the explicit_bzero() function calls memset_s() or memset(). This macro > is undefined by default > in pg_config.h, so check to see if your build environment has a > HAVE_MEMSET_S macro defined. > > Best Regards, > Long
Re: Need clarification on compilation errors in PG 16.2
Hi, >This codepath would only be reached if the buildsystem determined that memset_s >was available so something is fairly wrong here. Did you change any builfiles >after running configure? Re-install or upgrade XCode after running configure? I didn't touch any of the buildfiles , even didn't touch the PG's source code and didn't reinstall or upgrade Xcode. Just configure the PG and gave 'make' and I got this error. >memset_s and memset have the same prototype, and are functionally equivalent, >but memset_s have certain properties which are required in this codepath. Ok Thanks and regards On Tue, May 28, 2024 at 11:52 AM Daniel Gustafsson wrote: > > On 28 May 2024, at 07:37, Pradeep Kumar > wrote: > > This requires more information to be shared in order to figure out what > could > be happening. > > > ``` > > explicit_bzero.c:22:9: error: call to undeclared function 'memset_s'; > ISO C99 and later do not support implicit function declarations > [-Wimplicit-function-declaration] > > (void) memset_s(buf, len, 0, len); > >^ > > This codepath would only be reached if the buildsystem determined that > memset_s > was available so something is fairly wrong here. Did you change any > builfiles > after running configure? Re-install or upgrade XCode after running > configure? > > > then I changed the function memset_s(buf, len, 0, len) to memset(buf, 0, > len) and it's working. need a clarification on this? > > memset_s and memset have the same prototype, and are functionally > equivalent, > but memset_s have certain properties which are required in this codepath. > > -- > Daniel Gustafsson > >
Need clarification on compilation errors in PG 16.2
Hi , While we try to install PG 16.2 from the source code in macbook we getting this following errors ``` *explicit_bzero.c:22:9: error: call to undeclared function 'memset_s'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration](void) memset_s(buf, len, 0, len); ^explicit_bzero.c:22:9: note: did you mean 'memset'?/Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk/usr/include/string.h:74:7: note: 'memset' declared herevoidmemset(void __b, int __c, size_t __len); ^1 error generated.make[2]: *** [explicit_bzero.o] Error 1make[2]: *** Waiting for unfinished jobsmake[1]: *** [all-port-recurse] Error 2make: *** [all-src-recurse] Error 2* ``` then I changed the function memset_s(buf, len, 0, len) to memset(buf, 0, len) and it's working. need a clarification on this? Thanks and regards Pradeep
Possible Bug in relation_open
Hello Hackers, If the user tries to open the relation in RangeVar and NoLock mode calling *table_openrv(relation, NoLock), *it will internally call relation_openrv()-->relation_open(). In *relation_open() *we checking the Assert(lockmode >= NoLock && lockmode < MAX_LOCKMODES); , here we expecting the lockmode is *NoLock or greater than that*, but in same function again we checking this assert case Assert(lockmode != NoLock || IsBootstrapProcessingMode() || CheckRelationLockedByMe(r, AccessShareLock, true)); , here we are expecting (*lockmode != NoLock) *, so why are there two cases that contradict? and What if the user tries to open the relation in NoLock mode? and that will definitely cause the assert failure, Suppose the user who writes some extension and reads some relation oid that is constant, and wants to acquire NoLock?, need some clarification on this. Thanks & Regards Pradeep
Seeking Clarification on Logical Replication Start LSN
Dear Postgres Community, I hope this email finds you well. I am reaching out to seek clarification on an issue I am encountering with logical replication in PostgreSQL. My specific question pertains to determining the appropriate LSN (Log Sequence Number) from which to start logical replication. Allow me to provide detailed context for better understanding: During the process of performing a parallel pg_basebackup, I concurrently execute DML queries. As part of the pg_basebackup command, I utilize the option create-slot to create a replication slot. Subsequently, upon completion of the base backup, I initiate logical replication using the restart_lsn obtained during the execution of the pg_basebackup command. My intention is to ensure consistency between two database clusters. However, I am encountering errors during this process. Specifically, I receive the following error message on the source side: """ 2024-02-27 16:20:09.271 IST [2838457] ERROR: duplicate key value violates unique constraint "table_15_36_pkey" 2024-02-27 16:20:09.271 IST [2838457] DETAIL: Key (col_1, col_2)=(23, 2024-02-27 15:14:24.332557) already exists. 2024-02-27 16:20:09.272 IST [2834967] LOG: background worker "logical replication worker" (PID 2838457) exited with exit code 1 Upon analysis, it appears that the errors stem from starting the logical replication with an incorrect LSN, one that has already been applied to the target side, leading to duplicate key conflicts. """ In light of this issue, I seek guidance on determining the appropriate LSN from which to commence logical replication. To further clarify my problem: 1)I have a source machine and a target machine. 2) I perform a backup from the source to the target using pg_basebackup. 3) Prior to initiating the base backup, I create logical replication slots on the source machine. 4) During the execution of pg_basebackup, DML queries are executed, and I aim to replicate this data on the target machine. 5) My dilemma lies in determining the correct LSN to begin the logical replication process. Your insights and guidance on this matter would be immensely appreciated. Thank you for your time and assistance. Warm regards, Pradeep
Re: Assistance Needed: Issue with pg_upgrade and --link option
This is my numbers. df ~/pradeep_test/pg_upgrade_testing/postgres_11.4/master ~/pradeep_test/pg_upgrade_testing/postgres_14/new_pg Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/nvme0n1p4_crypt 375161856 102253040 270335920 28% /home /dev/mapper/nvme0n1p4_crypt 375161856 102253040 270335920 28% /home On Wed, Jun 28, 2023 at 3:14 PM Peter Eisentraut wrote: > On 28.06.23 08:24, Laurenz Albe wrote: > > On Wed, 2023-06-28 at 11:49 +0530, Pradeep Kumar wrote: > >> I was under the impression that the --link option would create hard > links between the > >> old and new cluster's data files, but it appears that the entire old > cluster data was > >> copied to the new cluster, resulting in a significant increase in the > new cluster's size. > > > > Please provide some numbers, ideally > > > >du -sk > > I don't think you can observe the effects of the --link option this way. > It would just give you the full size count for both directories, even > though the point to the same underlying inodes. > > To see the effect, you could perhaps use `df` to see how much overall > disk space the upgrade step eats up. > >
Re: Assistance Needed: Issue with pg_upgrade and --link option
Sure, du -sk ~/pradeep_test/pg_upgrade_testing/postgres_11.4/master ~/pradeep_test/pg_upgrade_testing/postgres_14/new_pg 11224524 /home/test/pradeep_test/pg_upgrade_testing/postgres_11.4/master 41952 /home/test/pradeep_test/pg_upgrade_testing/postgres_14/new_pg On Wed, Jun 28, 2023 at 11:54 AM Laurenz Albe wrote: > On Wed, 2023-06-28 at 11:49 +0530, Pradeep Kumar wrote: > > I was under the impression that the --link option would create hard > links between the > > old and new cluster's data files, but it appears that the entire old > cluster data was > > copied to the new cluster, resulting in a significant increase in the > new cluster's size. > > Please provide some numbers, ideally > > du -sk > > Yours, > Laurenz Albe >
Assistance Needed: Issue with pg_upgrade and --link option
Dear Postgres Hackers, I hope this email finds you well. I am currently facing an issue while performing an upgrade using the pg_upgrade utility with the --link option. I was under the impression that the --link option would create hard links between the old and new cluster's data files, but it appears that the entire old cluster data was copied to the new cluster, resulting in a significant increase in the new cluster's size. Here are the details of my scenario: - PostgreSQL version: [Old Version: Postgres 11.4 | New Version: Postgres 14.0] - Command used for pg_upgrade: [~/pg_upgrade_testing/postgres_14/bin/pg_upgrade -b ~/pg_upgrade_testing/postgres_11.4/bin -B ~/pg_upgrade_testing/postgres_14/bin -d ~/pg_upgrade_testing/postgres_11.4/replica_db2 -D ~/pg_upgrade_testing/postgres_14/new_pg -r -k - Paths to the old and new data directories: [~/pg_upgrade_testing/postgres_11.4/replica_db2] [~/pg_upgrade_testing/postgres_14/new_pg] - OS information: [Ubuntu 22.04.2 linux] However, after executing the pg_upgrade command with the --link option, I observed that the size of the new cluster is much larger than expected. I expected the --link option to create hard links instead of duplicating the data files. I am seeking assistance to understand the following: 1. Is my understanding of the --link option correct? 2. Is there any additional configuration or step required to properly utilize the --link option? 3. Are there any limitations or considerations specific to my PostgreSQL version or file system that I should be aware of? Any guidance, clarification, or troubleshooting steps you can provide would be greatly appreciated. I want to ensure that I am utilizing the --link option correctly and optimize the upgrade process. Best regards, Pradeep Kumar
Seeking Guidance on Using Valgrind in PostgreSQL for Detecting Memory Leaks in Extension Code
Dear Postgres Hackers, I am writing to seek your guidance and utilization of Valgrind in PostgreSQL for detecting memory leaks in extension-related code. Recently, I have been exploring ways to improve the stability and performance of PostgreSQL extensions by addressing memory-related issues, specifically memory leaks. I have come across Valgrind, a tool for detecting memory errors, leaks, and other memory-related problems in C/C++ programs. However, I am in need of some guidance on how to effectively use Valgrind within the context of PostgreSQL and extensions. I request your assistance in providing insights on the following: 1. Steps for utilizing Valgrind in PostgreSQL: - How do I install Valgrind and integrate it with PostgreSQL? - Are there any specific configurations or flags that need to be set for optimal usage with PostgreSQL? 2. Techniques for detecting memory leaks in extension-related code: - What are the recommended approaches for exercising extension code with Valgrind? - Are there any specific considerations or best practices to keep in mind when analyzing Valgrind's output for memory leaks in extension code? I would appreciate any resources, instructions, or insights you can provide regarding the above points. Thanks and regards, Pradeep
Extensible Rmgr for Table Ams
Hello All, Im working on my postgres FDW extension, to support logical replication I need to use Custom WAL resource manager. In postgres extensions have the flexibility to register their resource managers in RmgrTable[]. But Like RmgrTable[] we have another resource manager related table RmgrDescTable[], there we didn't have the flexibility to register our 1) rm_name 2) rm_desc 3) rm_identify GetRmgrDesc() are widely used in XLogDumpDisplayRecord() and XLogDumpDisplayStats() in pg_waldump.c. In function GetRmgrDesc() for custom resource managers by the default they are assign 1) rm_desc = default_desc 2) rm_identify = default_identify Suggest some ways to register my own rm_desc and rm_identify in RmgrDescTable[]? Attaching the Custom WAL resource managers commit for the reference: https://github.com/postgres/postgres/commit/5c279a6d350205cc98f91fb8e1d3e4442a6b25d1 Thanks and regards Pradeep Kumar
