On Mon, Sep 4, 2023 at 11:29 PM Rui Zhao wrote:
> Thank you for your response. It is evident that there is a need
> for this features in our system.
> Firstly, our customers express their desire to utilize tablespaces
> for table management, without necessarily being concerned about
> the director
On Tue, Sep 05, 2023 at 10:28:44AM +0800, Rui Zhao wrote:
> It would be highly appreciated if the official PG could also
> incorporate support for this feature.
This is a development option, and documented as such. You may also
want to be aware of the fact that tablespaces in the data folder
itse
Thank you for your response. It is evident that there is a need
for this features in our system.
Firstly, our customers express their desire to utilize tablespaces
for table management, without necessarily being concerned about
the directory location of these tablespaces.
Secondly, currently PG onl
Thank you for your response. It is evident that there is a need
for this features in our system.
Firstly, our customers express their desire to utilize tablespaces
for table management, without necessarily being concerned about
the directory location of these tablespaces.
Secondly, currently PG onl
On Sat, Aug 19, 2023 at 08:11:28PM +0800, Rui Zhao wrote:
> Please refer to the TAP test I have included for a better understanding
> of my suggestion.
Sure, but it seems to me that my original question is not really
answered: what's your use case for being able to support in-place
tablespaces in
Could you please provide more thoughts about this issue?
pg_upgrade is the final issue of in-place tablespace and we are on the cusp of
success.
--
Best regards,
Rui Zhao
On Sat, Aug 19, 2023 at 12:45 PM +0800, Michael Paquier wrote:
> I am not sure to follow the meaning of this logic. There could be
> in-place tablespaces that got created with the GUC enabled during a
> session, while the GUC has disabled the GUC. Shouldn't this stuff be
> more restrictive and not
On Fri, Aug 18, 2023 at 10:47:04PM +0800, Rui Zhao wrote:
> I have implemented the changes you suggested in our previous
> discussion. I have added the necessary code to ensure that
> pg_upgrade fails gracefully with in-place tablespaces and reports a
> hint to let the check pass.
+ /*
+
On Wed, Aug 09, 2023 at 09:20 AM +0800, Michael Paquier wrote:
> This does not really explain the reason why in-place tablespaces need
> to be skipped (in short they don't need a separate creation or check
> like the others in create_script_for_old_cluster_deletion because they
> are part of the da
On Wed, Aug 09, 2023 at 11:47:58AM +0800, Rui Zhao wrote:
> I believe that utilizing appendPQExpBufferStr(buf, "''"); would be better and
> more meaningful than using appendStringLiteralConn(buf, "", conn); in this
> scenario.
> I apologize for this wrong usage. Please help me fix it.
> I will tr
I have found the patch and upon review, I believe the following code can be
improved.
+ /*
+ * In-place tablespaces use a relative path, and need to be dumped
+ * with an empty string as location.
+ */
+ if (is_absolute_path(spclocation))
+ appendStringLiteralConn(buf, spclocation, conn);
+ else
+
On Tue, Aug 08, 2023 at 04:32:45PM +0900, Michael Paquier wrote:
> The pg_dump part should be OK to allow the restore of in-place
> tablespaces, so I'll get that fixed first, but I think that we should
> add a regression test as well.
I have added a test for that in 002_pg_dump.pl, and applied the
On Tue, Aug 08, 2023 at 12:35:38PM +0800, Rui Zhao wrote:
> I have only enabled allow_in_place_tablespaces to true during a binary
> upgrade.
The pg_dump part should be OK to allow the restore of in-place
tablespaces, so I'll get that fixed first, but I think that we should
add a regression test
Thank you for your reply. I have implemented the necessary changes in
accordance with your suggestions.
On Tue, Aug 08, 2023 at 09:57:00AM +0800, Michael Paquier wrote:
> I don't have a good feeling about enforcing allow_in_place_tablespaces
> in the connection creating the tablespace, as it can b
On Wed, Aug 02, 2023 at 10:38:00PM +0800, Rui Zhao wrote:
> However, when using pg_dump to back up this in-place tablespace, it
> is dumped with a different path:
> CREATE TABLESPACE space_test LOCATION 'pg_tblspc/'
> This can be confusing because it does not match the initial path
> that we creat
> I don't think that your solution is the correct move. Having
> pg_tablespace_location() return the physical location of the
> tablespace is very useful because that's the location where the
> physical files are, and client applications don't need to know the
> logic behind the way a path is built
On Sat, Jul 29, 2023 at 11:10:22PM +0800, Rui Zhao wrote:
> 2) Only check the tablespace with an absolute path in pg_upgrade.
> There are also other solutions, such as supporting the creation of
> relative-path tablespace in function CreateTableSpace. But do we
> really need relative-path table
On Mon, Jul 31, 2023 at 5:36 PM Rui Zhao wrote:
>
> Hello postgres hackers,
> Recently I encountered an issue: pg_upgrade fails when dealing with in-place
> tablespace. As we know, pg_upgrade uses pg_dumpall to dump objects and
> pg_restore to restore them. The problem seems to be that pg_dumpal
18 matches
Mail list logo
