On Fri, May 15, 2020 at 1:51 AM Robert Haas <robertmh...@gmail.com> wrote: > > On Thu, May 14, 2020 at 2:18 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > To support that, we need to consider a few things. > > a. Currently, we increment the command counter each time we take a key > > share lock on a tuple during trigger execution. I am really not sure > > if this is required during Copy command execution or we can just > > increment it once for the copy. If we need to increment the command > > counter just once for copy command then for the parallel copy we can > > ensure that we do it just once at the end of the parallel copy but if > > not then we might need some special handling. > > My sense is that it would be a lot more sensible to do it at the > *beginning* of the parallel operation. Once we do it once, we > shouldn't ever do it again; that's how it works now. Deferring it > until later seems much more likely to break things. >
AFAIU, we always increment the command counter after executing the command. Why do we want to do it differently here? > > b. Another point is that after inserting rows we record CTIDs of the > > tuples in the event queue and then once all tuples are processed we > > call FK trigger for each CTID. Now, with parallelism, the FK checks > > will be processed once the worker processed one chunk. I don't see > > any problem with it but still, this will be a bit different from what > > we do in serial case. Do you see any problem with this? > > I think there could be some problems here. For instance, suppose that > there are two entries for different workers for the same CTID. > First, let me clarify the CTID I have used in my email are for the table in which insertion is happening which means FK table. So, in such a case, we can't have the same CTIDs queued for different workers. Basically, we use CTID to fetch the row from FK table later and form a query to lock (in KEY SHARE mode) the corresponding tuple in PK table. Now, it is possible that two different workers try to lock the same row of PK table. I am not clear what problem group locking can have in this case because these are non-conflicting locks. Can you please elaborate a bit more? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
