On Mon, 3 Feb 2025 at 21:08, Dmitry Koval wrote:
>
> Hi, Alexander!
> Thanks for your advices and recommendations!
>
> >I don't think we need a separate 0003 patch with refactoring. It's
> >probably good idea to keep this functionality as a separate patch, but
> >let's make then it a 0001, whi
> --- a/src/backend/catalog/heap.c
> +++ b/src/backend/catalog/heap.c
> @@ -101,9 +101,6 @@ static ObjectAddress AddNewRelationType(const char
> *typeName,
>
> Oid new_row_type,
>
On Mon, Dec 9, 2024 at 11:01 PM Dmitry Koval wrote:
> >I see fixes for the issues mentioned in [1] and [2] are still not
> >implemented. Do you plan to do this in this release cycle?
>
> I would like to make some changes, but I think it would be appropriate
> to discuss these points first.
> As
Hi!
I'd like to share some thoughts on which particular way this patch could go.
On Thu, Aug 22, 2024 at 8:25 PM Robert Haas wrote:
> Here, aside from the name lookup issues, there are also problems with
> expression evaluation: we can't split partitions without reindexing
> rows that those part
Hi, Dmitry!
On Tue, Jan 28, 2025 at 1:15 AM Dmitry Koval wrote:
>
> >Only patches v34-0001 and 2 has been tested.
> >Patch v34-0003-Refactor-createPartitionTable-to-remove-ProcessU.patch
> >do not apply anymore on src/backend/catalog/heap.c
>
> Thanks, rebased.
> The patches are attached to th
Only patches v34-0001 and 2 has been tested.
Patch v34-0003-Refactor-createPartitionTable-to-remove-ProcessU.patch do not
apply anymore on src/backend/catalog/heap.c
The new status of this patch is: Waiting on Author
Hi!
On Fri, Aug 30, 2024 at 11:43 AM Dmitry Koval wrote:
> I plan to prepare fixes for issues from email [1] as separate commits
> (for better code readability). Attachment in this email is a variant of
> fix for the issue:
>
> > 1. Function createPartitionTable() should be rewritten using
> >
On Tue, Aug 27, 2024 at 2:24 PM Dmitry Koval wrote:
> They contains changes from reverted commits 1adf16b8fb, 87c21bb941, and
> subsequent fixes and improvements including df64c81ca9, c99ef1811a,
> 9dfcac8e15, 885742b9f8, 842c9b2705, fcf80c5d5f, 96c7381c4c, f4fc7cb54b,
> 60ae37a8bc, 259c96fa8f, 44
On Thu, Aug 22, 2024 at 8:25 PM Robert Haas wrote:
>
> On Thu, Aug 22, 2024 at 12:43 PM Alexander Korotkov
> wrote:
> > Thank you for your feedback. Yes, it seems that there is not enough
> > time to even carefully analyze all the issues in these features. The
> > rule of thumb I can get from t
On Thu, Aug 22, 2024 at 12:43 PM Alexander Korotkov
wrote:
> Thank you for your feedback. Yes, it seems that there is not enough
> time to even carefully analyze all the issues in these features. The
> rule of thumb I can get from this experience is "think multiple times
> before accessing somet
Hi!
On Thu, Aug 22, 2024 at 7:33 PM Robert Haas wrote:
> In response to some concerns raised about this fix on the
> pgsql-release list today, I spent some time investigating this patch.
> Unfortunately, I think there are too many problems here to be
> reasonably fixed before release, and I think
On 8/22/24 12:33 PM, Robert Haas wrote:
I think it is very unlikely that the problems mentioned above are the
only ones. They're just what I found in an hour or two of testing.
Even if they were, we're probably too close to release to be rushing
out last minute fixes to multiple unanticipated se
Hi,
In response to some concerns raised about this fix on the
pgsql-release list today, I spent some time investigating this patch.
Unfortunately, I think there are too many problems here to be
reasonably fixed before release, and I think all of SPLIT/MERGE
PARTITION needs to be reverted.
I focus
On Wed, Aug 21, 2024 at 3:06 PM Pavel Borisov wrote:
> On Wed, 21 Aug 2024 at 15:55, Alexander Korotkov wrote:
>>
>> Hi, Pavel!
>>
>> On Wed, Aug 21, 2024 at 1:48 PM Pavel Borisov wrote:
>> > On Mon, 19 Aug 2024 at 02:24, Alexander Korotkov
>> > wrote:
>> >>
>> >> On Sat, Aug 10, 2024 at 6:57
Hi, Alexander!
On Wed, 21 Aug 2024 at 15:55, Alexander Korotkov
wrote:
> Hi, Pavel!
>
> On Wed, Aug 21, 2024 at 1:48 PM Pavel Borisov
> wrote:
> > On Mon, 19 Aug 2024 at 02:24, Alexander Korotkov
> wrote:
> >>
> >> On Sat, Aug 10, 2024 at 6:57 PM Dmitry Koval
> wrote:
> >> > > Probably
> >> >
Hi, Pavel!
On Wed, Aug 21, 2024 at 1:48 PM Pavel Borisov wrote:
> On Mon, 19 Aug 2024 at 02:24, Alexander Korotkov wrote:
>>
>> On Sat, Aug 10, 2024 at 6:57 PM Dmitry Koval wrote:
>> > > Probably
>> > > QueryCompletion struct fits this purpose best from the existing
>> > > parameters. Attached
Hi, Alexander!
On Mon, 19 Aug 2024 at 02:24, Alexander Korotkov
wrote:
> On Sat, Aug 10, 2024 at 6:57 PM Dmitry Koval
> wrote:
> > > Probably
> > > QueryCompletion struct fits this purpose best from the existing
> > > parameters. Attached draft patch implements returning oid of newly
> > > cre
On Sat, Aug 10, 2024 at 6:57 PM Dmitry Koval wrote:
> > Probably
> > QueryCompletion struct fits this purpose best from the existing
> > parameters. Attached draft patch implements returning oid of newly
> > created relation as part of QueryCompletion. Thoughts?
>
> I agree, returning the oid of
Probably
QueryCompletion struct fits this purpose best from the existing
parameters. Attached draft patch implements returning oid of newly
created relation as part of QueryCompletion. Thoughts?
I agree, returning the oid of the newly created relation is the best way
to solve the problem.
(Ex
On Fri, Aug 9, 2024 at 10:18 AM Dmitry Koval wrote:
> > This breaks from the CVE-2014-0062 (commit 5f17304) principle of not
> > repeating
> > name lookups. The attached demo uses this defect to make one partition have
> > two parents.
>
> Thank you very much for information (especially for the
This breaks from the CVE-2014-0062 (commit 5f17304) principle of not repeating
name lookups. The attached demo uses this defect to make one partition have
two parents.
Thank you very much for information (especially for the demo)!
I'm not sure that we can get the identifier of the newly create
On Thu, Aug 8, 2024 at 8:14 PM Noah Misch wrote:
> On Sun, Apr 07, 2024 at 01:22:51AM +0300, Alexander Korotkov wrote:
> > I've pushed 0001 and 0002
>
> The partition MERGE (1adf16b8f) and SPLIT (87c21bb94) v17 patches introduced
> createPartitionTable() with this code:
>
> createStmt->rel
On Sun, Apr 07, 2024 at 01:22:51AM +0300, Alexander Korotkov wrote:
> I've pushed 0001 and 0002
The partition MERGE (1adf16b8f) and SPLIT (87c21bb94) v17 patches introduced
createPartitionTable() with this code:
createStmt->relation = newPartName;
...
wrapper->utilityStmt = (Node
On Sat, May 25, 2024 at 3:53 PM Alexander Korotkov wrote:
> On Fri, May 24, 2024 at 11:00 PM Alexander Lakhin wrote:
> >
> > 24.05.2024 22:29, Tom Lane wrote:
> > > The partition_split test has unstable results, as shown at [1].
> > > I suggest adding "ORDER BY conname" to the two queries shown
>
On Sat, May 25, 2024 at 8:53 PM Justin Pryzby wrote:
> On Fri, May 03, 2024 at 04:32:25PM +0300, Alexander Korotkov wrote:
> > On Fri, May 3, 2024 at 4:23 PM Justin Pryzby wrote:
> > > Note that the error that led to "EXCLUDING IDENTITY" is being discused
> > > over here:
> > > https://www.postgr
On Fri, May 03, 2024 at 04:32:25PM +0300, Alexander Korotkov wrote:
> On Fri, May 3, 2024 at 4:23 PM Justin Pryzby wrote:
> > Note that the error that led to "EXCLUDING IDENTITY" is being discused
> > over here:
> > https://www.postgresql.org/message-id/3b8a9dc1-bbc7-0ef5-6863-c432afac7...@gmail.c
On Fri, May 24, 2024 at 11:00 PM Alexander Lakhin wrote:
>
> 24.05.2024 22:29, Tom Lane wrote:
> > The partition_split test has unstable results, as shown at [1].
> > I suggest adding "ORDER BY conname" to the two queries shown
> > to fail there. Better look at other queries in the test for
> > p
Hello,
24.05.2024 22:29, Tom Lane wrote:
The partition_split test has unstable results, as shown at [1].
I suggest adding "ORDER BY conname" to the two queries shown
to fail there. Better look at other queries in the test for
possible similar problems, too.
Yes, I've just reproduced it on an
The partition_split test has unstable results, as shown at [1].
I suggest adding "ORDER BY conname" to the two queries shown
to fail there. Better look at other queries in the test for
possible similar problems, too.
regards, tom lane
[1]
https://buildfarm.postgresql.org
Hi, Pavel!
On Fri, May 17, 2024 at 2:02 PM Pavel Borisov wrote:
> On Fri, 17 May 2024 at 14:05, Alexander Korotkov wrote:
>>
>> On Tue, May 14, 2024 at 5:49 PM Justin Pryzby wrote:
>> > On Thu, May 09, 2024 at 12:51:32AM +0300, Alexander Korotkov wrote:
>> > > > > However, parent's table extend
Hi, Alexander:
On Fri, 17 May 2024 at 14:05, Alexander Korotkov
wrote:
> On Tue, May 14, 2024 at 5:49 PM Justin Pryzby
> wrote:
> > On Thu, May 09, 2024 at 12:51:32AM +0300, Alexander Korotkov wrote:
> > > > > However, parent's table extended statistics already covers all its
> > > > > children
On Tue, May 14, 2024 at 5:49 PM Justin Pryzby wrote:
> On Thu, May 09, 2024 at 12:51:32AM +0300, Alexander Korotkov wrote:
> > > > However, parent's table extended statistics already covers all its
> > > > children.
> > >
> > > => That's the wrong explanation. It's not that "stats on the parent
>
On Thu, May 09, 2024 at 12:51:32AM +0300, Alexander Korotkov wrote:
> > > However, parent's table extended statistics already covers all its
> > > children.
> >
> > => That's the wrong explanation. It's not that "stats on the parent
> > table cover its children". It's that there are two types of
On Mon, May 13, 2024 at 12:45 PM Dmitry Koval wrote:
> 13.05.2024 11:45, Daniel Gustafsson пишет:
> > Commit 3ca43dbbb67f which adds the permission checks seems to cause
> > conflicts
> > in the pg_upgrade tests
>
> Thanks!
>
> It will probably be enough to rename the roles:
>
> regress_partition
Hi!
13.05.2024 11:45, Daniel Gustafsson пишет:
Commit 3ca43dbbb67f which adds the permission checks seems to cause conflicts
in the pg_upgrade tests
Thanks!
It will probably be enough to rename the roles:
regress_partition_merge_alice -> regress_partition_split_alice
regress_partition_merge_
Commit 3ca43dbbb67f which adds the permission checks seems to cause conflicts
in the pg_upgrade tests:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=piculet&dt=2024-05-13%2008%3A36%3A37
There is an issue with dropping and creating roles which seems to stem from
this commit:
CREATE ROL
Hi!
Attached draft version of fix for [1].
[1]
https://www.postgresql.org/message-id/86b4f1e3-0b5d-315c-9225-19860d64d685%40gmail.com
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.comFrom ece01564aeb848bab2a61617412a1d175e45b934 Mon Sep 17 00:00:00 2001
From: K
Hi!
11.05.2024 12:00, Alexander Lakhin wrote:
Please look at one more anomaly with temporary tables:
Thank you, Alexander!
The problem affects the SPLIT PARTITION command.
CREATE TEMP TABLE t (a int) PARTITION BY RANGE (a);
CREATE TEMP TABLE tp_0 PARTITION OF t FOR VALUES FROM (0) TO (2) ;
-
Hello Dmitry and Alexander,
Please look at one more anomaly with temporary tables:
CREATE TEMP TABLE t (a int) PARTITION BY RANGE (a);
CREATE TEMP TABLE tp_0 PARTITION OF t FOR VALUES FROM (0) TO (1) ;
CREATE TEMP TABLE tp_1 PARTITION OF t FOR VALUES FROM (1) TO (2);
ALTER TABLE t MERGE PARTITION
On Thu, May 9, 2024 at 12:37 AM Justin Pryzby wrote:
>
> On Wed, May 08, 2024 at 09:00:10PM +0300, Alexander Korotkov wrote:
> > On Fri, May 3, 2024 at 4:32 PM Alexander Korotkov
> > wrote:
> > > On Fri, May 3, 2024 at 4:23 PM Justin Pryzby wrote:
> > > > On Wed, May 01, 2024 at 10:51:24PM +030
On Wed, May 08, 2024 at 09:00:10PM +0300, Alexander Korotkov wrote:
> On Fri, May 3, 2024 at 4:32 PM Alexander Korotkov
> wrote:
> > On Fri, May 3, 2024 at 4:23 PM Justin Pryzby wrote:
> > > On Wed, May 01, 2024 at 10:51:24PM +0300, Dmitry Koval wrote:
> > > > 30.04.2024 23:15, Justin Pryzby пиш
On Wed, May 1, 2024 at 12:14 AM Dmitry Koval wrote:
> 30.04.2024 6:00, Alexander Lakhin пишет:
> > Maybe I'm doing something wrong, but the following script:
> > CREATE TABLE t (i int, PRIMARY KEY(i)) PARTITION BY RANGE (i);
> > CREATE TABLE tp_0 PARTITION OF t FOR VALUES FROM (0) TO (1);
> > CREA
On Fri, May 3, 2024 at 4:32 PM Alexander Korotkov wrote:
> On Fri, May 3, 2024 at 4:23 PM Justin Pryzby wrote:
> > On Wed, May 01, 2024 at 10:51:24PM +0300, Dmitry Koval wrote:
> > > 30.04.2024 23:15, Justin Pryzby пишет:
> > > > Is this issue already fixed ?
> > > > I wasn't able to reproduce it
On Fri, May 3, 2024 at 4:23 PM Justin Pryzby wrote:
> On Wed, May 01, 2024 at 10:51:24PM +0300, Dmitry Koval wrote:
> > 30.04.2024 23:15, Justin Pryzby пишет:
> > > Is this issue already fixed ?
> > > I wasn't able to reproduce it. Maybe it only happened with earlier
> > > patch versions applied
On Wed, May 01, 2024 at 10:51:24PM +0300, Dmitry Koval wrote:
> Hi!
>
> 30.04.2024 23:15, Justin Pryzby пишет:
> > Is this issue already fixed ?
> > I wasn't able to reproduce it. Maybe it only happened with earlier
> > patch versions applied ?
>
> I think this was fixed in commit [1].
>
> [1]
Hi!
30.04.2024 23:15, Justin Pryzby пишет:
Is this issue already fixed ?
I wasn't able to reproduce it. Maybe it only happened with earlier
patch versions applied ?
I think this was fixed in commit [1].
[1]
https://github.com/postgres/postgres/commit/fcf80c5d5f0f3787e70fca8fd029d2e08a923f91
Hi!
30.04.2024 6:00, Alexander Lakhin пишет:
Maybe I'm doing something wrong, but the following script:
CREATE TABLE t (i int, PRIMARY KEY(i)) PARTITION BY RANGE (i);
CREATE TABLE tp_0 PARTITION OF t FOR VALUES FROM (0) TO (1);
CREATE TABLE tp_1 PARTITION OF t FOR VALUES FROM (1) TO (2);
CREATE
On Thu, Apr 11, 2024 at 08:00:00PM +0300, Alexander Lakhin wrote:
> 11.04.2024 16:27, Dmitry Koval wrote:
> >
> > Added correction (and test), see
> > v3-0001-Fix-for-SPLIT-MERGE-partitions-of-temporary-table.patch.
>
> Thank you for the correction, but may be an attempt to merge into implicit
>
30.04.2024 03:10, Dmitry Koval wrote:
Hi!
1.
29.04.2024 21:00, Alexander Lakhin wrote:
I still wonder, why that constraint (now with a less questionable name) is
created during MERGE?
The SPLIT/MERGE PARTITION(S) commands for creating partitions reuse the existing code of CREATE TABLE .. LIKE
Hi!
1.
29.04.2024 21:00, Alexander Lakhin wrote:
I still wonder, why that constraint (now with a less questionable name) is
created during MERGE?
The SPLIT/MERGE PARTITION(S) commands for creating partitions reuse the
existing code of CREATE TABLE .. LIKE ... command. A new partition was
cre
Hi Dmitry,
19.04.2024 02:26, Dmitry Koval wrote:
18.04.2024 19:00, Alexander Lakhin wrote:
leaves a strange constraint:
\d+ t*
Table "public.tp_0"
...
Not-null constraints:
"merge-16385-26BCB0-tmp_i_not_null" NOT NULL "i"
Thanks!
Attached fix (
On Sun, Apr 28, 2024 at 08:18:42AM -0500, Justin Pryzby wrote:
> > I will explore this. Do we copy extended stats when we do CREATE
> > TABLE ... PARTITION OF? I think we need to do the same here.
>
> Right, they're not copied because an extended stats objs on the parent
> does something differe
On Sunday, April 28, 2024, Alexander Lakhin wrote:
>
> When we deal with mixed ownership, say, bob is an owner of a
> partitioned table, but not an owner of a partition, should we
> allow him to perform merge with that partition?
>
>
Attaching via alter table requires the user to own both the par
On Sunday, April 28, 2024, Alexander Lakhin wrote:
>
> When we deal with mixed ownership, say, bob is an owner of a
> partitioned table, but not an owner of a partition, should we
> allow him to perform merge with that partition?
>
>
IIUC Merge causes the source tables to be dropped, their data h
On Sun, Apr 28, 2024 at 04:04:54AM +0300, Alexander Korotkov wrote:
> Hi Justin,
>
> Thank you for your review. Please check v9 of the patchset [1].
>
> On Wed, Apr 24, 2024 at 11:26 PM Justin Pryzby wrote:
> > This patch also/already fixes the schema issue I reported. Thanks.
> >
> > If you w
On Sun, Apr 28, 2024 at 2:00 PM Alexander Lakhin wrote:
> 28.04.2024 03:59, Alexander Korotkov wrote:
> > The revised patchset is attached. I'm going to push it if there are
> > no objections.
>
> I have one additional question regarding security, if you don't mind:
> What permissions should a us
Hello,
28.04.2024 03:59, Alexander Korotkov wrote:
The revised patchset is attached. I'm going to push it if there are
no objections.
I have one additional question regarding security, if you don't mind:
What permissions should a user have to perform split/merge?
When we deal with mixed owne
Hi Justin,
Thank you for your review. Please check v9 of the patchset [1].
On Wed, Apr 24, 2024 at 11:26 PM Justin Pryzby wrote:
> This patch also/already fixes the schema issue I reported. Thanks.
>
> If you wanted to include a test case for that:
>
> begin;
> CREATE SCHEMA s;
> CREATE SCHEMA
Hi, Hackers!
On Thu, 25 Apr 2024 at 00:26, Justin Pryzby wrote:
> On Mon, Apr 22, 2024 at 01:31:48PM +0300, Alexander Korotkov wrote:
> > Hi!
> >
> > On Fri, Apr 19, 2024 at 4:29 PM Alexander Korotkov
> wrote:
> > > On Fri, Apr 19, 2024 at 2:26 AM Dmitry Koval
> wrote:
> > > > 18.04.2024 19:00
On Mon, Apr 22, 2024 at 01:31:48PM +0300, Alexander Korotkov wrote:
> Hi!
>
> On Fri, Apr 19, 2024 at 4:29 PM Alexander Korotkov
> wrote:
> > On Fri, Apr 19, 2024 at 2:26 AM Dmitry Koval wrote:
> > > 18.04.2024 19:00, Alexander Lakhin wrote:
> > > > leaves a strange constraint:
> > > > \d+ t*
>
On Thu, Apr 11, 2024 at 10:20:53PM -0400, Robert Haas wrote:
> On Thu, Apr 11, 2024 at 9:54 PM Alexander Korotkov
> wrote:
> > I think we shouldn't unconditionally copy schema name and
> > relpersistence from the parent table. Instead we should throw the
> > error on a mismatch like CREATE TABLE
18.04.2024 20:49, Alvaro Herrera wrote:
On 2024-Apr-18, Alexander Lakhin wrote:
I think the feature implementation should also provide tab completion
for SPLIT/MERGE.
I don't think that we should be imposing on feature authors or
committers the task of filling in tab-completion for whatever fe
Hi!
18.04.2024 19:00, Alexander Lakhin wrote:
leaves a strange constraint:
\d+ t*
Table "public.tp_0"
...
Not-null constraints:
"merge-16385-26BCB0-tmp_i_not_null" NOT NULL "i"
Thanks!
Attached fix (with test) for this case.
The patch should be a
Here are some additional fixes to docs.
>From 6da8beaa5a2b78e785e5b6519894f8357002d916 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Thu, 18 Apr 2024 15:40:44 -0500
Subject: [PATCH] doc review for ALTER TABLE ... SPLIT/MERGE PARTITION
---
doc/src/sgml/ddl.sgml | 4 ++--
doc/src
On Thu, Apr 18, 2024 at 6:35 AM Alexander Korotkov wrote:
> The revised patchset is attached.
> 1) I've split the fix for the CommandCounterIncrement() issue and the
> fix for relation persistence issue into a separate patch.
> 2) I've validated that the lock on the new partition is held in
> crea
On 2024-Apr-18, Alexander Lakhin wrote:
> I think the feature implementation should also provide tab completion
> for SPLIT/MERGE.
I don't think that we should be imposing on feature authors or
committers the task of filling in tab-completion for whatever features
they contribute. I mean, if the
Alexander Lakhin writes:
> Hi Alexander,
>
> 18.04.2024 13:35, Alexander Korotkov wrote:
>>
>> The revised patchset is attached.
>> 1) I've split the fix for the CommandCounterIncrement() issue and the
>> fix for relation persistence issue into a separate patch.
>> 2) I've validated that the lock
Hi Alexander,
18.04.2024 13:35, Alexander Korotkov wrote:
The revised patchset is attached.
1) I've split the fix for the CommandCounterIncrement() issue and the
fix for relation persistence issue into a separate patch.
2) I've validated that the lock on the new partition is held in
createParti
Hi, Dmitry!
On Mon, Apr 15, 2024 at 6:26 PM Dmitry Koval wrote:
>
> Hi!
>
> > Please, find a my version of this fix attached.
>
> Is it possible to make a small addition to the file v6-0001 ... .patch
> (see attachment)?
>
> Most important:
> 1) Line 19:
>
> + mergePartName = makeRangeVar(cmd->na
On Mon, Apr 15, 2024 at 11:00 AM Alexander Lakhin wrote:
> Initially I was confused by that message, because of:
> CREATE TABLE t (i int) PARTITION BY RANGE (i);
> CREATE FOREIGN TABLE ftp_0_1 PARTITION OF t
>FOR VALUES FROM (0) TO (1)
>SERVER loopback OPTIONS (table_name 'lt_0_1');
> CREA
Hi!
Please, find a my version of this fix attached.
Is it possible to make a small addition to the file v6-0001 ... .patch
(see attachment)?
Most important:
1) Line 19:
+ mergePartName = makeRangeVar(cmd->name->schemaname, tmpRelName, -1);
(temporary table should use the same schema as th
Hello Robert,
15.04.2024 17:30, Robert Haas wrote:
On Sat, Apr 13, 2024 at 6:05 AM Alexander Korotkov wrote:
Please, find a my version of this fix attached. I think we need to
check relpersistence in a similar way ATTACH PARTITION or CREATE TABLE
... PARTITION OF do. I'm going to polish this
On Sat, Apr 13, 2024 at 6:05 AM Alexander Korotkov wrote:
> Please, find a my version of this fix attached. I think we need to
> check relpersistence in a similar way ATTACH PARTITION or CREATE TABLE
> ... PARTITION OF do. I'm going to polish this a little bit more.
+ errmsg("\"%s\" is not an o
Hi, Dmitry!
On Fri, Apr 12, 2024 at 10:59 PM Dmitry Koval wrote:
>
> Thanks, Alexander!
>
> > Still now we're able to create a partition in the pg_temp schema
> > explicitly.
>
> Attached patches with fix.
Please, find a my version of this fix attached. I think we need to
check relpersistence i
Thanks, Alexander!
Still now we're able to create a partition in the pg_temp schema
explicitly.
Attached patches with fix.
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.comFrom 2b68bbdb068e881e8ca6e34dec735f7ce656374f Mon Sep 17 00:00:00 2001
From: Koval Dmitry
Hi Dmitry,
12.04.2024 16:04, Dmitry Koval wrote:
Hi!
Attached is a patch with corrections based on comments in previous letters (I
think these corrections are not final).
I'll be very grateful for feedbacks and bug reports.
11.04.2024 20:00, Alexander Lakhin wrote:
> may be an attempt to merg
Hi!
Attached is a patch with corrections based on comments in previous
letters (I think these corrections are not final).
I'll be very grateful for feedbacks and bug reports.
11.04.2024 20:00, Alexander Lakhin wrote:
> may be an attempt to merge into implicit
> pg_temp should fail just like CR
On Thu, Apr 11, 2024 at 9:54 PM Alexander Korotkov wrote:
> I think we shouldn't unconditionally copy schema name and
> relpersistence from the parent table. Instead we should throw the
> error on a mismatch like CREATE TABLE ... PARTITION OF ... does. I'm
> working on revising this fix.
We def
On Thu, Apr 11, 2024 at 8:00 PM Alexander Lakhin wrote:
> 11.04.2024 16:27, Dmitry Koval wrote:
> >
> > Added correction (and test), see
> > v3-0001-Fix-for-SPLIT-MERGE-partitions-of-temporary-table.patch.
> >
>
> Thank you for the correction, but may be an attempt to merge into implicit
> pg_tem
11.04.2024 16:27, Dmitry Koval wrote:
Added correction (and test), see
v3-0001-Fix-for-SPLIT-MERGE-partitions-of-temporary-table.patch.
Thank you for the correction, but may be an attempt to merge into implicit
pg_temp should fail just like CREATE TABLE ... PARTITION OF ... does?
Please l
Hi, Dmitry!
On Thu, Apr 11, 2024 at 4:27 PM Dmitry Koval wrote:
> 1.
> Alexander Lakhin sent a question about index name after MERGE (partition
> name is the same as one of the merged partitions):
>
> start of quote
> I'm also confused by an index name after MERGE:
> CREATE TABLE t (i int
Hi!
1.
Alexander Lakhin sent a question about index name after MERGE (partition
name is the same as one of the merged partitions):
start of quote
I'm also confused by an index name after MERGE:
CREATE TABLE t (i int) PARTITION BY RANGE (i);
CREATE TABLE tp_0_1 PARTITION OF t FOR VALUE
Hi Dmitry,
11.04.2024 11:59, Dmitry Koval wrote:
FWIW, I also proposed a patch earlier that fixes error messages and
comments in the split partition code
Sorry, I thought all the fixes you suggested were already included in v1-0002-Fixes-for-english-text.patch (but they
are not).
Added mis
Hi!
FWIW, I also proposed a patch earlier that fixes error messages and
comments in the split partition code
Sorry, I thought all the fixes you suggested were already included in
v1-0002-Fixes-for-english-text.patch (but they are not).
Added missing lines to v2-0002-Fixes-for-english-text.pa
On Thu, Apr 11, 2024 at 1:22 AM Dmitry Koval wrote:
> 2) v1-0002-Fixes-for-english-text.patch - fixes for English text
> (comments, error messages etc.).
FWIW, I also proposed a patch earlier that fixes error messages and
comments in the split partition code at
https://www.postgresql.org/messag
Hi!
Alexander Korotkov, thanks for the commit of previous fix.
Alexander Lakhin, thanks for the problem you found.
There are two corrections attached to the letter:
1) v1-0001-Fix-for-SPLIT-MERGE-partitions-of-temporary-table.patch - fix
for the problem [1].
2) v1-0002-Fixes-for-english-text
10.04.2024 12:00, Alexander Lakhin wrote:
Hello Alexander and Dmitry,
10.04.2024 02:03, Alexander Korotkov wrote:
Thank you. I've pushed this fix with minor corrections from me.
Please look at another anomaly with MERGE.
CREATE TEMP TABLE t (i int) PARTITION BY RANGE (i);
CREATE TABLE tp_
Hello Alexander and Dmitry,
10.04.2024 02:03, Alexander Korotkov wrote:
On Mon, Apr 8, 2024 at 11:43 PM Dmitry Koval wrote:
Attached fix for the problems found by Alexander Lakhin.
About grammar errors.
Unfortunately, I don't know English well.
Therefore, I plan (in the coming days) to show t
On Mon, Apr 8, 2024 at 11:43 PM Dmitry Koval wrote:
> Attached fix for the problems found by Alexander Lakhin.
>
> About grammar errors.
> Unfortunately, I don't know English well.
> Therefore, I plan (in the coming days) to show the text to specialists
> who perform technical translation of docum
Hi!
Attached fix for the problems found by Alexander Lakhin.
About grammar errors.
Unfortunately, I don't know English well.
Therefore, I plan (in the coming days) to show the text to specialists
who perform technical translation of documentation.
--
With best regards,
Dmitry Koval
Postgres
Hi Tender Wang,
08.04.2024 13:43, Tender Wang wrote:
Hi all,
I went through the MERGE/SPLIT partition codes today, thanks for the works.
I found some grammar errors:
i. in error messages(Users can see this grammar errors, not friendly).
ii. in codes comments
On a quick glance, I saw also
Hi all,
I went through the MERGE/SPLIT partition codes today, thanks for the
works. I found some grammar errors:
i. in error messages(Users can see this grammar errors, not friendly).
ii. in codes comments
Alexander Korotkov 于2024年4月7日周日 06:23写道：
> Hi, Dmitry!
>
> On Fri, Apr 5, 2024 at 4:
Alexander Lakhin, thanks for the problems you found!
Unfortunately I can't watch them immediately (event [1]).
I will try to start solving them in 12-14 hours.
[1] https://pgconf.ru/2024
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
08.04.2024 01:15, Alexander Korotkov wrote:
Thank you for spotting this. This seems like a missing check. I'm
going to get a closer look at this tomorrow.
Thanks!
There is also an anomaly with the MERGE command:
CREATE TABLE t1 (i int, a int, b int, c int) PARTITION BY RANGE (a, b);
CREATE
Hi, Alexander!
On Sun, Apr 7, 2024 at 10:00 PM Alexander Lakhin wrote:
> 07.04.2024 01:22, Alexander Korotkov wrote:
> > I've pushed 0001 and 0002. I didn't push 0003 for the following reasons.
>
> Please try the following (erroneous) query:
> CREATE TABLE t1(i int, t text) PARTITION BY LIST (t)
Hi Alexander and Dmitry,
07.04.2024 01:22, Alexander Korotkov wrote:
I've pushed 0001 and 0002. I didn't push 0003 for the following reasons.
Please try the following (erroneous) query:
CREATE TABLE t1(i int, t text) PARTITION BY LIST (t);
CREATE TABLE t1pa PARTITION OF t1 FOR VALUES IN ('A')
Hi, Alexander!
I didn't push 0003 for the following reasons.
Thanks for clarifying. You are right, these are serious reasons.
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
Hi, Dmitry!
On Fri, Apr 5, 2024 at 4:00 PM Dmitry Koval wrote:
> > I've revised the patchset.
>
> Thanks for the corrections (especially ddl.sgml).
> Could you also look at a small optimization for the MERGE PARTITIONS
> command (in a separate file
> v31-0003-Additional-patch-for-ALTER-TABLE-.-ME
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
All three patches applied nivcely.
Code fits standart, commen
Hi!
> I've fixed that by skipping a copy of the identity of another
> partition (remove CREATE_TABLE_LIKE_IDENTITY from
> TableLikeClause.options).
Thanks for correction!
Probably I should have looked at the code more closely after commit [1].
I'm also very glad that situation [2] was reproduce
1 - 100 of 132 matches
Mail list logo
