On Wed, Jun 11, 2025 at 8:06 AM Dmitry Koval wrote:
>
> >Do getAttributesList need to care about pg_attribute.attidentity?
> >currently MERGE PARTITION seems to work fine with identity columns,
> >this issue i didn't dig deeper.
>
> Probably after commit [3] partition's identity columns shares
hi.
we generally no need to worry about the partitioned table check constraint,
generated column does not apply to newly merged partitions.
since partitioned table constraints apply to each individual partition,
including newly created partitions.
However, there are corner cases:
constraints incl
Hi Dmitry,
On Tue, Jun 10, 2025 at 6:48 AM Dmitry Koval wrote:
>
> Hi, Jian He!
>
> Thanks for the suggestions and patches!
> This email contains comments to three emails (05/06/2025).
> I hope to read two emails (for 06/06/2025) tomorrow.
>
> 1.
> >What should we do when any to be merged partit
On Tue, Jun 10, 2025 at 6:48 AM Dmitry Koval wrote:
> 3.
> >i think, we can do the following way:
> >if (modelRel->rd_rel->relam)
> > elog(ERROR, "error");
> >relamId = modelRel->rd_rel->relam;
>
> Can you clarify what is reason to change the current AM-logic for
> creating a new partition?
>
hi.
in createTableConstraints
+ /* Add a pre-cooked default expression. */
+ StoreAttrDefault(newRel, num, def, true);
+
+ /* Store CHECK constraints. */
+ StoreConstraints(newRel, cookedConstraints, false);
Here, StoreConstraints last argument should be set to true?
see also StoreAttrDefault.
+
hi.
one more patch for regress tests.
ALTER TABLE salespeople MERGE PARTITIONS (salespeople10_20,
salespeople20_30, salespeople30_40) INTO salespeople10_40;
the trigger on the merged partition will be dropped.
For example, here, trigger on salespeople10_20 will be dropped.
I am surprised that pa
Hi, jian he!
Thank you very much for your emails!
Unfortunately, due to urgent tasks at my work, I do not have time to
look through your notes today and tomorrow.
But I will definitely do it at the beginning of next week.
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgr
hi.
When using ALTER TABLE ... MERGE PARTITIONS, some of the new
partition's properties will
not be inherited from to be merged partitions; instead, they will be directly
copied from the root partitioned table.
so we need to test this behavior.
The attached test file is for test table properties:
hi.
bug in transformPartitionCmdForMerge "equal(name, name2))"
+static void
+transformPartitionCmdForMerge(CreateStmtContext *cxt, PartitionCmd *partcmd)
+{
+
+
+ foreach(listptr, partcmd->partlist)
+ {
+ RangeVar *name = (RangeVar *) lfirst(listptr);
+
+ /* Partitions in the list should have di
hi.
the following are review of
v40-0001-Implement-ALTER-TABLE-.-MERGE-PARTITIONS-.-comma.patch
ALTER TABLE sales_range MERGE PARTITIONS (sales_feb2022,
sales_mar2022) INTO sales_feb_mar_apr2022;
There are no tests when sales_feb2022 or sales_mar2022 have any constraints.
a partition can have its
Hi Dmitry!
On Wed, Jun 4, 2025 at 10:44 PM Dmitry Koval wrote:
> Thank you very much for review.
Thank you for your work on this patch. I have some additional notes on
this patch.
Why don't you use *existing_relation_id argument of
RangeVarGetAndCheckCreationNamespace(), when it is called from
On Wed, Jun 4, 2025 at 4:53 AM Dmitry Koval wrote:
> Added some changes to documentation.
> Patches are attached to the email.
>
hi.
I haven't touched v39-0002 yet.
The following are reviews of v39-0001.
+CREATE INDEX sales_range_sales_date_idx ON sales_range USING btree
(sales_date);
+INSERT IN
Some notes to the patch. ...
Thanks for the notes!
I'll try to make edits in the next few days.
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
Hi, Dmitry!
On Tue, May 20, 2025 at 1:36 AM Dmitry Koval wrote:
> Changes in patches:
>
> 1) Added usage of SECURITY_RESTRICTED_OPERATION for SPLIT/MERGE
> PARTITION(S) commands.
>
> 2) For SPLIT PARTITION command: new partitions will have the same owner
> as the parent.
>
> 3) For MERGE PARTITIO
On Thu, May 22, 2025 at 11:57 AM Dmitry Koval wrote:
> > superuser can bypass all permission checks.
> > superuser can attach any table to the partitioned table as he wants.
>
> That's right.
> Using SUPERUSER may be a rare situation, but it needs to be processed.
I suggest that owner of new part
superuser can bypass all permission checks.
superuser can attach any table to the partitioned table as he wants.
That's right.
Using SUPERUSER may be a rare situation, but it needs to be processed.
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
On Thu, May 22, 2025 at 1:01 AM Dmitry Koval wrote:
>
> > for example:
> > ...
>
> If in both examples you replace
>
> create role bob;
>
> with
>
> create role bob SUPERUSER;
>
> and in the second example add "set role bob;" before "alter table ..."
> query, then no error will be occur.
>
That i
for example:
...
If in both examples you replace
create role bob;
with
create role bob SUPERUSER;
and in the second example add "set role bob;" before "alter table ..."
query, then no error will be occur.
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
On Wed, May 21, 2025 at 8:30 PM Dmitry Koval wrote:
>
> Hi!
>
> >per https://www.postgresql.org/docs/current/sql-altertable.html
> >"You must own the table to use ALTER TABLE."
> >That means the current user must own the to be SPLITed partition.
>
> Last statement may be incorrect (if the logic
Hi!
>per https://www.postgresql.org/docs/current/sql-altertable.html
>"You must own the table to use ALTER TABLE."
>That means the current user must own the to be SPLITed partition.
Last statement may be incorrect (if the logic is different).
Current user can attach another user's partition. If
On Mon, May 12, 2025 at 4:31 PM Dmitry Koval wrote:
>
> Hi!
>
> We (with colleagues) discussed further improvements to SPLIT/MERGE
> PARTITION(S). As a result of the discussion, the following answers to
> the questions remained:
>
> 1. Who should be the owner of new partitions (SPLIT PARTITION com
Hi!
We (with colleagues) discussed further improvements to SPLIT/MERGE
PARTITION(S). As a result of the discussion, the following answers to
the questions remained:
1. Who should be the owner of new partitions (SPLIT PARTITION command)
if owner of the partition being split is not the same as
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
1 - 100 of 154 matches
Mail list logo
