fix comment typo in xlogprefetcher.c
Hello I found a comment typo in xlogprefetcher.c. Any thoughts? --- a/src/backend/access/transam/xlogprefetcher.c +++ b/src/backend/access/transam/xlogprefetcher.c @@ -19,7 +19,7 @@ * avoid a second buffer mapping table lookup. * * Currently, only the main fork is considered for prefetching. Currently, - * prefetching is only effective on systems where BufferPrefetch() does + * prefetching is only effective on systems where PrefetchBuffer() does * something useful (mainly Linux). * *- regards sho kato fix-typo-comment.patch Description: fix-typo-comment.patch
RE: Synchronizing slots from primary to standby
Hello, This patch status is already returned with feedback. However, I've applied this patch on 27b77ecf9f and tested so report it. make installcheck-world is passed. However, when I promote the standby server and update on the new primary server, apply worker could not start logical replication and emmit the following error. LOG: background worker "logical replication worker" (PID 14506) exited with exit code 1 LOG: logical replication apply worker for subscription "sub1" has started ERROR: terminating logical replication worker due to timeout LOG: background worker "logical replication worker" (PID 14535) exited with exit code 1 LOG: logical replication apply worker for subscription "sub1" has started It seems that apply worker does not start because wal sender is already exist on the new primary. Do you have any thoughts about what the cause might be? test script is attached. regards, sho kato failover.sh Description: failover.sh
Re: fix crash with Python 3.11
Hello, I run vcregeress plcheck on Windows Server 2016 with python 3.11.0a3 and python 3.9.7 which are installed using installer. All tests are passed. I'm not familiar with PL/Python but I think it's good. regards, sho kato
RE: Farewell greeting
>I'm moving to another company from July 1st. I may possibly not be allowed to >do open source activities there, so let me say >goodbye once. Thank you all >for your help. I really enjoyed learning PostgreSQL and participating in its >development. Thank you for everything, Tsunakawa-san. Good luck !!! Regards Sho Kato -Original Message- From: tsunakawa.ta...@fujitsu.com Sent: Sunday, June 27, 2021 4:41 PM To: pgsql-hackers@lists.postgresql.org Cc: MauMau Subject: Farewell greeting Hello all, I'm moving to another company from July 1st. I may possibly not be allowed to do open source activities there, so let me say goodbye once. Thank you all for your help. I really enjoyed learning PostgreSQL and participating in its development. It's a pity that I may not be able to part of PostgreSQL's great history until it becomes the most popular database (in the DB-Engines ranking.) However, if possible, I'd like to come back as just MauMau. I hope you all will succeed. Regards Takayuki Tsunakawa
RE: Creating foreign key on partitioned table is too slow
On Wednesday, August 5, 2020 9:43 AM I wrote: > I'll report the result before the end of August . I test v2-0001-build-partdesc-memcxt.patch at 9a9db08ae4 and it is ok. Firstly, I execute ALTER TABLE ADD CONSTRAINT FOREIGN KEY on the table which has 8k tables. This query execution completes in about 22 hours without OOM. Secondary, I confirm the reduction of memory context usage. Running with 8k partitions takes too long, I confirm with 1k partitions. I use gdb and call MemoryContextStats(TopMemoryContext) at addFkRecurseReferencing(). CacheMemoryContext size becomes small, so I think it is working as expected. The Results are as follows. - before applying patch TopMemoryContext: 418896 total in 18 blocks; 91488 free (13 chunks); 327408 used pgstat TabStatusArray lookup hash table: 65536 total in 4 blocks; 16808 free (7 chunks); 48728 used TopTransactionContext: 4194304 total in 10 blocks; 1045728 free (18 chunks); 3148576 used TableSpace cache: 8192 total in 1 blocks; 2048 free (0 chunks); 6144 used Type information cache: 24624 total in 2 blocks; 2584 free (0 chunks); 22040 used Operator lookup cache: 24576 total in 2 blocks; 10712 free (4 chunks); 13864 used RowDescriptionContext: 8192 total in 1 blocks; 6880 free (0 chunks); 1312 used MessageContext: 8192 total in 1 blocks; 3064 free (0 chunks); 5128 used Operator class cache: 8192 total in 1 blocks; 512 free (0 chunks); 7680 used smgr relation table: 32768 total in 3 blocks; 16768 free (8 chunks); 16000 used TransactionAbortContext: 32768 total in 1 blocks; 32504 free (0 chunks); 264 used Portal hash: 8192 total in 1 blocks; 512 free (0 chunks); 7680 used TopPortalContext: 8192 total in 1 blocks; 7648 free (0 chunks); 544 used PortalContext: 9621216 total in 1179 blocks; 13496 free (13 chunks); 9607720 used: Relcache by OID: 16384 total in 2 blocks; 3424 free (3 chunks); 12960 used CacheMemoryContext: 4243584 total in 12 blocks; 1349808 free (12 chunks); 2893776 used index info: 2048 total in 2 blocks; 736 free (0 chunks); 1312 used: pg_trigger_tgconstraint_index index info: 2048 total in 2 blocks; 736 free (0 chunks); 1312 used: pg_trigger_oid_index index info: 2048 total in 2 blocks; 352 free (1 chunks); 1696 used: pg_inherits_relid_seqno_index partition descriptor: 65344 total in 12 blocks; 7336 free (4 chunks); 58008 used: accounts index info: 2048 total in 2 blocks; 736 free (0 chunks); 1312 used: pg_inherits_parent_index partition key: 1024 total in 1 blocks; 160 free (0 chunks); 864 used: accounts ... index info: 2048 total in 2 blocks; 736 free (2 chunks); 1312 used: pg_database_oid_index index info: 2048 total in 2 blocks; 736 free (2 chunks); 1312 used: pg_authid_rolname_index WAL record construction: 49776 total in 2 blocks; 6344 free (0 chunks); 43432 used PrivateRefCount: 8192 total in 1 blocks; 2584 free (0 chunks); 5608 used MdSmgr: 8192 total in 1 blocks; 5528 free (0 chunks); 2664 used LOCALLOCK hash: 131072 total in 5 blocks; 26376 free (15 chunks); 104696 used Timezones: 104128 total in 2 blocks; 2584 free (0 chunks); 101544 used ErrorContext: 8192 total in 1 blocks; 7928 free (3 chunks); 264 used Grand total: 19322960 bytes in 1452 blocks; 2743560 free (186 chunks); 16579400 used - after applying patch TopMemoryContext: 418896 total in 18 blocks; 91488 free (13 chunks); 327408 used pgstat TabStatusArray lookup hash table: 65536 total in 4 blocks; 16808 free (7 chunks); 48728 used TopTransactionContext: 4194304 total in 10 blocks; 1045728 free (18 chunks); 3148576 used RowDescriptionContext: 8192 total in 1 blocks; 6880 free (0 chunks); 1312 used MessageContext: 8192 total in 1 blocks; 3064 free (0 chunks); 5128 used Operator class cache: 8192 total in 1 blocks; 512 free (0 chunks); 7680 used smgr relation table: 32768 total in 3 blocks; 16768 free (8 chunks); 16000 used TransactionAbortContext: 32768 total in 1 blocks; 32504 free (0 chunks); 264 used Portal hash: 8192 total in 1 blocks; 512 free (0 chunks); 7680 used TopPortalContext: 8192 total in 1 blocks; 7648 free (0 chunks); 544 used PortalContext: 9621216 total in 1179 blocks; 13496 free (13 chunks); 9607720 used: Relcache by OID: 16384 total in 2 blocks; 3424 free (3 chunks); 12960 used CacheMemoryContext: 2113600 total in 10 blocks; 556240 free (10 chunks); 1557360 used index info: 2048 total in 2 blocks; 736 free (0 chunks); 1312 used: pg_trigger_tgconstraint_index index info: 2048 total in 2 blocks; 736 free (0 chunks); 1312 used: pg_trigger_oid_index index info: 2048 total in 2 blocks; 352 free (1 chunks); 1696 used: pg_inherits_relid_seqno_index partition descriptor: 65344 total in 12 blocks; 7336 free (4 chunks); 58008 used: accounts index info: 2048 total in 2 blocks; 736 free (0 chunks); 1312 used: pg_inherits_parent_index partition key: 1024 total in 1 blocks; 160 free (0 chunks); 864 used:
RE: Creating foreign key on partitioned table is too slow
On Tuesday, July 14, 2020 11:29 PM, Daniel Fustafsson wrote: >Are you able to test Alvaros latest patch to see if that solves the originally >reported problem, so that we can reach >closure on this item during the >commitfest? Sorry for the too late replay. I missed this mail. And, thanks for writing patches. I start test now. I'll report the result before the end of August . Regards, Sho kato
RE: Performing partition pruning using row value
>So, after looking at these functions and modifying this patch, I would like to >add this patch to the next I updated this patch and registered for the next CF . https://commitfest.postgresql.org/29/2654/ regards, sho kato pruning-with-row-wise-comparison-v2.patch Description: pruning-with-row-wise-comparison-v2.patch
RE: Performing partition pruning using row value
Amit-san Friday, July 10, 2020 10:00 AM, Amit Langote wrote: >Speaking of which, I hope that Kato-san has looked at functions >match_rowcompare_to_indexcol(), expand_indexqual_rowcompare(), etc. in >indxpath.c as starting points >for the code to match RowCompares to partition >keys. Hmm, I did not look at these functions. So, after looking at these functions and modifying this patch, I would like to add this patch to the next CF. thanks for providing this information. regards, sho kato
RE: Performing partition pruning using row value
Hi, I made a patch that enable partition pruning using row-wise comparison. Please review and comment on this patch. regards, sho kato > -Original Message- > From: kato-...@fujitsu.com > Sent: Wednesday, July 8, 2020 10:33 AM > To: 'Etsuro Fujita' > Cc: PostgreSQL-development > Subject: RE: Performing partition pruning using row value > > Fujita san > > On Tuesday, July 7, 2020 6:31 PM Etsuro Fujita > wrote: > > Just to be clear, the condition (c1, c2) < (99, 99) is not equivalent > > to the condition c1 < 99 and c2 < 99 (see the documentation note in [1]). > > Thanks for sharing this document. I have understood. > > > but I don't think the main reason for that is that it takes time to > > parse expressions. > > Yeah, I think it's great to support row-wise comparison not only with > > the small number of args but with the large number of them. > > These comments are very helpful. > Ok, I try to make POC that allows row-wise comparison with partition-pruning. > > Regards, > sho kato > > -Original Message- > > From: Etsuro Fujita > > Sent: Tuesday, July 7, 2020 6:31 PM > > To: Kato, Sho/加藤 翔 > > Cc: PostgreSQL-development > > Subject: Re: Performing partition pruning using row value > > > > Kato-san, > > > > On Mon, Jul 6, 2020 at 5:25 PM kato-...@fujitsu.com > > > > wrote: > > > I would like to ask about the conditions under which partition > > > pruning is > > performed. > > > In PostgreSQL 12, when I executed following SQL, partition pruning > > > is not > > performed. > > > > > > postgres=# explain select * from a where (c1, c2) < (99, 99); > > >QUERY PLAN > > > > > > Append (cost=0.00..60.00 rows=800 width=40) > > >-> Seq Scan on a1 a_1 (cost=0.00..28.00 rows=400 width=40) > > > Filter: (ROW(c1, c2) < ROW(99, 99)) > > >-> Seq Scan on a2 a_2 (cost=0.00..28.00 rows=400 width=40) > > > Filter: (ROW(c1, c2) < ROW(99, 99)) > > > (5 rows) > > > > > > However, pruning is performed when I changed the SQL as follows. > > > > > > postgres=# explain select * from a where c1 < 99 and c2 < 99; > > >QUERY PLAN > > > > > > Seq Scan on a1 a (cost=0.00..28.00 rows=133 width=40) > > >Filter: ((c1 < 99) AND (c2 < 99)) > > > (2 rows) > > > > Just to be clear, the condition (c1, c2) < (99, 99) is not equivalent > > to the condition c1 < 99 and c2 < 99 (see the documentation note in [1]). > > > > > Looking at the code, "(c1, c2) < (99, 99)" is recognized as > > > RowCompExpr and > > "c1 < 99 and c2 < 99" is recognized combination of OpExpr. > > > > > > Currently, pruning is not performed for RowCompExpr, is this correct? > > > > Yeah, I think so. > > > > > Because it would take a long time to parse all Expr nodes, does > > match_cluause_to_partition_key() return PART_CLAUSE_UNSUPPORTED > when > > such Expr node is passed? > > > > I don't know the reason why that function doesn't support row-wise > > comparison, but I don't think the main reason for that is that it > > takes time to parse expressions. > > > > > If the number of args in RowCompExpr is small, I would think that > > > expanding > > it would improve performance. > > > > Yeah, I think it's great to support row-wise comparison not only with > > the small number of args but with the large number of them. > > > > Best regards, > > Etsuro Fujita > > > > [1] > > https://www.postgresql.org/docs/current/functions-comparisons.html#ROW > > - > > WISE-COMPARISON pruning-with-row-wise-comparison.patch Description: pruning-with-row-wise-comparison.patch
RE: Performing partition pruning using row value
Fujii-san Wednesday, July 8, 2020 3:20 PM, Fujii Masao wrote: > Seems we can do partition pruning even in Kato-san's case by dong > > create type hoge as (c1 int, c2 int); > create table a( c1 int, c2 int, c3 varchar) partition by range(((c1, > c2)::hoge)); > create table a1 partition of a for values from((0, 0)) to ((100, 100)); > create table > a2 partition of a for values from((100, 100)) to ((200, 200)); explain select > * from > a where (c1, c2)::hoge < (99, 99)::hoge; I hadn't thought of it that way. Thanks. Regards, Sho kato > -Original Message- > From: Fujii Masao > Sent: Wednesday, July 8, 2020 3:20 PM > To: Kato, Sho/加藤 翔 ; 'Amit Langote' > > Cc: Etsuro Fujita ; PostgreSQL-development > > Subject: Re: Performing partition pruning using row value > > > > On 2020/07/08 13:25, kato-...@fujitsu.com wrote: > > Amit-san > > > > On Wednesday, July 8, 2020 11:53 AM, Amit Langote > : > >> I think the only reason that this is not supported is that I hadn't > >> tested such a query when developing partition pruning, nor did anyone > >> else suggest doing so. :) > > Seems we can do partition pruning even in Kato-san's case by dong > > create type hoge as (c1 int, c2 int); > create table a( c1 int, c2 int, c3 varchar) partition by range(((c1, > c2)::hoge)); > create table a1 partition of a for values from((0, 0)) to ((100, 100)); > create table > a2 partition of a for values from((100, 100)) to ((200, 200)); explain select > * from > a where (c1, c2)::hoge < (99, 99)::hoge; > > I'm not sure if this method is officially supported or not, though... > > Regards, > > -- > Fujii Masao > Advanced Computing Technology Center > Research and Development Headquarters > NTT DATA CORPORATION
RE: Performing partition pruning using row value
Amit-san On Wednesday, July 8, 2020 11:53 AM, Amit Langote : > I think the only reason that this is not supported is that I hadn't tested > such a > query when developing partition pruning, nor did anyone else suggest doing > so. :) Thanks for the information. I'm relieved to hear this reason. Regards, Sho kato > -Original Message- > From: Amit Langote > Sent: Wednesday, July 8, 2020 11:53 AM > To: Kato, Sho/加藤 翔 > Cc: Etsuro Fujita ; PostgreSQL-development > > Subject: Re: Performing partition pruning using row value > > Kato-san, > > On Wed, Jul 8, 2020 at 10:32 AM kato-...@fujitsu.com > wrote: > > On Tuesday, July 7, 2020 6:31 PM Etsuro Fujita > wrote: > > > Just to be clear, the condition (c1, c2) < (99, 99) is not > > > equivalent to the condition c1 < 99 and c2 < 99 (see the documentation > note in [1]). > > > > Thanks for sharing this document. I have understood. > > > > > but I don't think the main reason for that is that it takes time to > > > parse expressions. > > I think the only reason that this is not supported is that I hadn't tested > such a > query when developing partition pruning, nor did anyone else suggest doing > so. :) > > > > Yeah, I think it's great to support row-wise comparison not only > > > with the small number of args but with the large number of them. > > +1 > > > These comments are very helpful. > > Ok, I try to make POC that allows row-wise comparison with > partition-pruning. > > That would be great, thank you. > > -- > Amit Langote > EnterpriseDB: http://www.enterprisedb.com
RE: Performing partition pruning using row value
Fujita san On Tuesday, July 7, 2020 6:31 PM Etsuro Fujita wrote: > Just to be clear, the condition (c1, c2) < (99, 99) is not equivalent to the > condition c1 < 99 and c2 < 99 (see the documentation note in [1]). Thanks for sharing this document. I have understood. > but I don't think the main reason for that is that it takes time to parse > expressions. > Yeah, I think it's great to support row-wise comparison not only with the > small > number of args but with the large number of them. These comments are very helpful. Ok, I try to make POC that allows row-wise comparison with partition-pruning. Regards, sho kato > -Original Message- > From: Etsuro Fujita > Sent: Tuesday, July 7, 2020 6:31 PM > To: Kato, Sho/加藤 翔 > Cc: PostgreSQL-development > Subject: Re: Performing partition pruning using row value > > Kato-san, > > On Mon, Jul 6, 2020 at 5:25 PM kato-...@fujitsu.com > wrote: > > I would like to ask about the conditions under which partition pruning is > performed. > > In PostgreSQL 12, when I executed following SQL, partition pruning is not > performed. > > > > postgres=# explain select * from a where (c1, c2) < (99, 99); > >QUERY PLAN > > > > Append (cost=0.00..60.00 rows=800 width=40) > >-> Seq Scan on a1 a_1 (cost=0.00..28.00 rows=400 width=40) > > Filter: (ROW(c1, c2) < ROW(99, 99)) > >-> Seq Scan on a2 a_2 (cost=0.00..28.00 rows=400 width=40) > > Filter: (ROW(c1, c2) < ROW(99, 99)) > > (5 rows) > > > > However, pruning is performed when I changed the SQL as follows. > > > > postgres=# explain select * from a where c1 < 99 and c2 < 99; > >QUERY PLAN > > > > Seq Scan on a1 a (cost=0.00..28.00 rows=133 width=40) > >Filter: ((c1 < 99) AND (c2 < 99)) > > (2 rows) > > Just to be clear, the condition (c1, c2) < (99, 99) is not equivalent to the > condition c1 < 99 and c2 < 99 (see the documentation note in [1]). > > > Looking at the code, "(c1, c2) < (99, 99)" is recognized as RowCompExpr and > "c1 < 99 and c2 < 99" is recognized combination of OpExpr. > > > > Currently, pruning is not performed for RowCompExpr, is this correct? > > Yeah, I think so. > > > Because it would take a long time to parse all Expr nodes, does > match_cluause_to_partition_key() return PART_CLAUSE_UNSUPPORTED > when such Expr node is passed? > > I don't know the reason why that function doesn't support row-wise comparison, > but I don't think the main reason for that is that it takes time to parse > expressions. > > > If the number of args in RowCompExpr is small, I would think that expanding > it would improve performance. > > Yeah, I think it's great to support row-wise comparison not only with the > small > number of args but with the large number of them. > > Best regards, > Etsuro Fujita > > [1] > https://www.postgresql.org/docs/current/functions-comparisons.html#ROW- > WISE-COMPARISON
Performing partition pruning using row value
Hello I would like to ask about the conditions under which partition pruning is performed. In PostgreSQL 12, when I executed following SQL, partition pruning is not performed. postgres=# explain select * from a where (c1, c2) < (99, 99); QUERY PLAN Append (cost=0.00..60.00 rows=800 width=40) -> Seq Scan on a1 a_1 (cost=0.00..28.00 rows=400 width=40) Filter: (ROW(c1, c2) < ROW(99, 99)) -> Seq Scan on a2 a_2 (cost=0.00..28.00 rows=400 width=40) Filter: (ROW(c1, c2) < ROW(99, 99)) (5 rows) However, pruning is performed when I changed the SQL as follows. postgres=# explain select * from a where c1 < 99 and c2 < 99; QUERY PLAN Seq Scan on a1 a (cost=0.00..28.00 rows=133 width=40) Filter: ((c1 < 99) AND (c2 < 99)) (2 rows) These tables are defined as follows. create table a( c1 int, c2 int, c3 varchar) partition by range(c1, c2); create table a1 partition of a for values from(0, 0) to (100, 100); create table a2 partition of a for values from(100, 100) to (200, 200); Looking at the code, "(c1, c2) < (99, 99)" is recognized as RowCompExpr and "c1 < 99 and c2 < 99" is recognized combination of OpExpr. Currently, pruning is not performed for RowCompExpr, is this correct? Also, at the end of match_clause_to_partition_key(), the following Comments like. "Since the qual didn't match up to any of the other qual types supported here, then trying to match it against any other partition key is a waste of time, so just return PARTCLAUSE_UNSUPPORTED." Because it would take a long time to parse all Expr nodes, does match_cluause_to_partition_key() return PART_CLAUSE_UNSUPPORTED when such Expr node is passed? If the number of args in RowCompExpr is small, I would think that expanding it would improve performance. regards, sho kato
Creating foreign key on partitioned table is too slow
Hello To benchmark with tpcb model, I tried to create a foreign key in the partitioned history table, but backend process killed by OOM. the number of partitions is 8192. I tried in master(commit: ad4b7aeb84). I did the same thing in another server which has 200GB memory, but creating foreign key did not end in 24 hours. Is the community aware of this? is anyone working on this? If you are discussing, please let me know the thread. Table definition and pstack are as follows. * table definition * CREATE TABLE accounts (aid INTEGER, bid INTEGER, abalance INTEGER, filler CHAR(84)) PARTITION BY HASH(aid); CREATE TABLE history (tid INTEGER, bid INTEGER, aid INTEGER, delta INTEGER, mtime TIMESTAMP, filler CHAR(22)) PARTITION BY HASH(aid); \o /dev/null SELECT 'CREATE TABLE accounts_' || p || ' PARTITION OF accounts FOR VALUES WITH (modulus 8192, remainder ' || p || ');' FROM generate_series(0, 8191) p; \gexec SELECT 'CREATE TABLE history_' || p || ' PARTITION OF history FOR VALUES WITH (modulus 8192, remainder ' || p || ');' FROM generate_series(0, 8191) p; \gexec \o ALTER TABLE accounts ADD CONSTRAINT accounts_pk PRIMARY KEY (aid); ALTER TABLE history ADD CONSTRAINT history_fk3 FOREIGN KEY (aid) REFERENCES accounts (aid); * pstack before killed by OOM * #0 0x00a84aec in ReleaseSysCache (tuple=0x7fbb0a15dc28) at syscache.c:1175 #1 0x00a7135d in get_rel_relkind (relid=164628) at lsyscache.c:1816 #2 0x00845f0a in RelationBuildPartitionDesc (rel=0x7fbadb9bfb10) at partdesc.c:230 #3 0x00a78b9a in RelationBuildDesc (targetRelId=139268, insertIt=false) at relcache.c:1173 #4 0x00a7b52e in RelationClearRelation (relation=0x7fbb0a1393e8, rebuild=true) at relcache.c:2534 #5 0x00a7bacf in RelationFlushRelation (relation=0x7fbb0a1393e8) at relcache.c:2692 #6 0x00a7bbe1 in RelationCacheInvalidateEntry (relationId=139268) at relcache.c:2744 #7 0x00a6e11d in LocalExecuteInvalidationMessage (msg=0x7fbadb62e480) at inval.c:589 #8 0x00a6de7d in ProcessInvalidationMessages (hdr=0x1d36d48, func=0xa6e01a ) at inval.c:460 #9 0x00a6e94e in CommandEndInvalidationMessages () at inval.c:1095 #10 0x00559c93 in AtCCI_LocalCache () at xact.c:1458 #11 0x005596ac in CommandCounterIncrement () at xact.c:1040 #12 0x006b1811 in addFkRecurseReferenced (wqueue=0x7fffcb0a0588, fkconstraint=0x20cf6a0, rel=0x7fbb0a1393e8, pkrel=0x7fbadb9bbe90, indexOid=189582, parentConstr=204810, numfks=1, pkattnum=0x7fffcb0a0190, fkattnum=0x7fffcb0a0150, pfeqoperators=0x7fffcb09ff50, ppeqoperators=0x7fffcb09fed0, ffeqoperators=0x7fffcb09fe50, old_check_ok=false) at tablecmds.c:8168 #13 0x006b1a0b in addFkRecurseReferenced (wqueue=0x7fffcb0a0588, fkconstraint=0x20cf6a0, rel=0x7fbb0a1393e8, pkrel=0x7fbadc188840, indexOid=188424, parentConstr=0, numfks=1, pkattnum=0x7fffcb0a0190, fkattnum=0x7fffcb0a0150, pfeqoperators=0x7fffcb09ff50, ppeqoperators=0x7fffcb09fed0, ffeqoperators=0x7fffcb09fe50, old_check_ok=false) at tablecmds.c:8219 #14 0x006b13e0 in ATAddForeignKeyConstraint (wqueue=0x7fffcb0a0588, tab=0x20cf4d8, rel=0x7fbb0a1393e8, fkconstraint=0x20cf6a0, parentConstr=0, recurse=true, recursing=false, lockmode=6) at tablecmds.c:8005 #15 0x006afa0c in ATExecAddConstraint (wqueue=0x7fffcb0a0588, tab=0x20cf4d8, rel=0x7fbb0a1393e8, newConstraint=0x20cf6a0, recurse=true, is_readd=false, lockmode=6) at tablecmds.c:7419 #16 0x006a8a7a in ATExecCmd (wqueue=0x7fffcb0a0588, tab=0x20cf4d8, rel=0x7fbb0a1393e8, cmd=0x20cf648, lockmode=6) at tablecmds.c:4300 #17 0x006a8448 in ATRewriteCatalogs (wqueue=0x7fffcb0a0588, lockmode=6) at tablecmds.c:4185 #18 0x006a7bf9 in ATController (parsetree=0x1cb4350, rel=0x7fbb0a1393e8, cmds=0x20cf428, recurse=true, lockmode=6) at tablecmds.c:3843 #19 0x006a78a4 in AlterTable (relid=139268, lockmode=6, stmt=0x1cb4350) at tablecmds.c:3504 #20 0x00914999 in ProcessUtilitySlow (pstate=0x1cb3a10, pstmt=0x1c91380, queryString=0x1c90170 "ALTER TABLE history ADD CONSTRAINT history_fk3 FOREIGN KEY (aid) REFERENCES accounts (aid);", context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0x1c91470, completionTag=0x7fffcb0a0d20 "") at utility.c:1131 #21 0x00914490 in standard_ProcessUtility (pstmt=0x1c91380, queryString=0x1c90170 "ALTER TABLE history ADD CONSTRAINT history_fk3 FOREIGN KEY (aid) REFERENCES accounts (aid);", context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0x1c91470, completionTag=0x7fffcb0a0d20 "") at utility.c:927 #22 0x00913534 in ProcessUtility (pstmt=0x1c91380, queryString=0x1c90170 "ALTER TABLE history ADD CONSTRAINT history_fk3 FOREIGN KEY (aid) REFERENCES accounts (aid);", context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0x1c91470, completionTag=0x7fffcb0a0d20 "") at utility.c:360 #23 0x0091245a in PortalRunUtility (portal=0x1cf5ee0,
