On Tue, Oct 19, 2021 at 7:14 AM Alvaro Herrera wrote:
> Pushed now to all branches. Thanks much!
Thanks Álavro.
--
Amit Langote
EDB: http://www.enterprisedb.com
Pushed now to all branches. Thanks much!
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
"The important things in the world are problems with society that we don't
understand at all. The machines will become more complicated but they won't
be more complicated tha
On 2021-Oct-18, Alvaro Herrera wrote:
> Thanks. I'm looking at it now. I notice that if I take out the code
> fix and keep the tests, I only see the ATTACH side of the problem have a
> failure; I expected to see a failure for DETACH too.
Ah, no, the test covers both cases; it's just that if it
On 2021-Oct-18, Pavel Borisov wrote:
> > Yeah, maybe the link is unnecessary in the test comment, so removed.
> > Though, I do occasionally see one of those in the test files (try `git
> > grep https src/test`).
Yeah, for example the test stanza just above says "test case for but
16242". Sadly t
>
> Oops, you're right. I had failed to notice when reading the code that
> the second transaction takes an AccessExclusiveLock on the target
> partition. Reverted back to how this was in v3.
>
> > Also I'd recommend removing the link to a discussion from the test.
> Anyway we have link in a comm
Hi Pavel,
On Fri, Oct 15, 2021 at 5:02 PM Pavel Borisov wrote:
>> The lock taken on the parent is either ShareUpdateExclusiveLock or
>> AccessExclusiveLock depending on whether CONCURRENTLY is specified or
>> not. Maybe that should be considered also when locking the children.
>>
>> I've updated
>
> The lock taken on the parent is either ShareUpdateExclusiveLock or
> AccessExclusiveLock depending on whether CONCURRENTLY is specified or
> not. Maybe that should be considered also when locking the children.
>
> I've updated the patch that way. (Also, reintroduced the slightly
> longer comm
On Wed, Oct 6, 2021 at 10:40 PM Pavel Borisov wrote:
>
> Hi, hackers!
>
> We've reviewed patch v3 and found it right. Completely agree that in case we
> attach/detach partition relcaches for all child relations (if they exist)
> need invalidation.
> Installcheck world succeeds after the patch. T
Hi, hackers!
We've reviewed patch v3 and found it right. Completely agree that in case
we attach/detach partition relcaches for all child relations (if they
exist) need invalidation.
Installcheck world succeeds after the patch. Tests from the patch fail as
they should when run on the master branch
I have reviewed the patch and it looks good to me. However I have one comment.
+ foreach(l, attachrel_children)
+ {
+ Oid partOid = lfirst_oid(l);
+
+ CacheInvalidateRelcacheByRelid(partOid);
+ }
Can
On Thu, Aug 5, 2021 at 11:32 AM Amit Langote wrote:
> On Wed, Jul 14, 2021 at 11:16 AM houzj.f...@fujitsu.com
> > On Tuesday, July 13, 2021 2:52 AM Alvaro Herrera
> > wrote:
> > > Did you have a misbehaving test for the ATTACH case?
> >
> > Thanks for the response.
>
> Thank you both.
>
> > Yes,
Sorry that I missed this thread.
On Wed, Jul 14, 2021 at 11:16 AM houzj.f...@fujitsu.com
wrote:
> On Tuesday, July 13, 2021 2:52 AM Alvaro Herrera
> wrote:
> > On 2021-Jun-23, houzj.f...@fujitsu.com wrote:
> >
> > > For a multi-level partition, for example: table 'A' is partition of
> > > table
On Tuesday, July 13, 2021 2:52 AM Alvaro Herrera
wrote:
> On 2021-Jun-23, houzj.f...@fujitsu.com wrote:
>
> > For a multi-level partition, for example: table 'A' is partition of
> > table 'B', and 'B' is also partition of table 'C'. After I 'ALTER
> > TABLE C DETACH B', I thought partition const
On 2021-Jun-23, houzj.f...@fujitsu.com wrote:
> For a multi-level partition, for example: table 'A' is partition of table
> 'B', and 'B' is also partition of table 'C'. After I 'ALTER TABLE C DETACH B',
> I thought partition constraint check of table 'C' does not matter anymore if
> INSERT INTO ta
On Wednesday, June 23, 2021 12:16 PM I wrote:
> When directly INSERT INTO partition, postgres will invoke ExecPartitionCheck
> which will execute its parent's and grandparent's partition constraint check.
> From the code, the whole constraint check is saved in relcache::rd_partcheck.
>
> For a mul
Hi,
When directly INSERT INTO partition, postgres will invoke ExecPartitionCheck
which will execute its parent's and grandparent's partition constraint check.
>From the code, the whole constraint check is saved in relcache::rd_partcheck.
For a multi-level partition, for example: table 'A' is part
16 matches
Mail list logo
