On 2014-03-25 21:09:13 +0900, MauMau wrote:
! /*
! * Remove old symlink in recovery, in case it points to the wrong place.
! * On Windows, lstat() reports junction points as directories.
! */
if (InRecovery)
{
! if (lstat(linkloc, st) == 0
MauMau maumau...@gmail.com writes:
[ remove_tblspc_symlink_v6.patch ]
Committed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
From: Amit Kapila amit.kapil...@gmail.com
If you think that above scenario is not possible, then you just need to
modify comment:
! * Remove old symlink in recovery
Hm, my scenario seems impossible. I reverted the comment.
One more minor point about patch:
+ struct stat st;
if
On Tue, Mar 25, 2014 at 5:39 PM, MauMau maumau...@gmail.com wrote:
OK, I removed the second (existing) definition of st.
This patch version looks fine, I have verified the issue, regression tests
passed.
I had attached the latest version of patch in CF app and marked it as
Ready For Committer.
On Fri, Mar 21, 2014 at 12:24 PM, MauMau maumau...@gmail.com wrote:
From: Amit Kapila amit.kapil...@gmail.com
On Wed, Jan 15, 2014 at 8:12 PM, MauMau maumau...@gmail.com wrote:
Thanks for reviewing and testing the patch. Yes, at first I did what you
mentioned, but modified the patch
From: Amit Kapila amit.kapil...@gmail.com
1. Assume a tablespace tbs already exists.
2. Create table t1(c1 int) tablespace tbs;
3. drop table t1;
4. Drop tablespace tbs;
5. Do immediate shutdown (pg_ctl stop -mi);
6. During recovery it will create a table in directory (in function
On Mon, Mar 24, 2014 at 7:49 PM, MauMau maumau...@gmail.com wrote:
A bit contrived example is:
1. After the directory is created by TablespaceCreateDbspace(), recovery is
stopped (e.g. due to power outage). The directory remains.
2. Restart the server, redoing CREATE TABLESPACE during
From: Amit Kapila amit.kapil...@gmail.com
On Wed, Jan 15, 2014 at 8:12 PM, MauMau maumau...@gmail.com wrote:
Thanks for reviewing and testing the patch. Yes, at first I did what you
mentioned, but modified the patch according to some advice in the mail
thread. During redo,
On Fri, Mar 21, 2014 at 12:24 PM, MauMau maumau...@gmail.com wrote:
From: Amit Kapila amit.kapil...@gmail.com
If create_tablespace_directories() needs to handle with directory both on
Windows/Linux, then shouldn't it be a runtime check as in your first
version rather than compile time check?
From: Amit Kapila amit.kapil...@gmail.com
The comments in your first version needs to be improved, as there
you just mentioned a Windows specific comment:
+ /* On Windows, lstat()
I think you can change comments (make it somewhat similar to
destroy_tablespace_directories) and then submit it as
On Wed, Jan 15, 2014 at 8:12 PM, MauMau maumau...@gmail.com wrote:
From: Asif Naeem anaeem...@gmail.com
As you have
followed destroy_tablespace_directories() function, Is there any specific
reason not to use same logic to detect type of the file/link i.e.
(lstat(linkloc, st) == 0
I'm sorry, I'm replying to an older mail, because I lost your latest mail by
mistake.
Ah. Sorry, I missed that part. As NTFS junctions and symbolic links are
different (although they behave similarly), there seems only a minor
inconvenience related to misleading error message i.e.
You are
I did worked on testing the patch on Windows, test scenario mentioned above
thread is reproducible and the provided patch resolve the issue. In case of
junction or directory unlink function
(deprecatedhttp://msdn.microsoft.com/en-us/library/ms235350.aspx)
returns -1 with errno “EACCES” (i.e.
From: Asif Naeem anaeem...@gmail.com
As you have
followed destroy_tablespace_directories() function, Is there any specific
reason not to use same logic to detect type of the file/link i.e.
“(lstat(linkloc, st) == 0 S_ISDIR(st.st_mode))”, It also seems have
more appropriate error message i.e.
Hi MauMau,
Ah. Sorry, I missed that part. As NTFS junctions and symbolic links are
different (although they behave similarly), there seems only a minor
inconvenience related to misleading error message i.e.
+ #ifdef WIN32
+ if (rmdir(linkloc) 0 errno != ENOENT)
+ #else
if
Hello,
I've found and fixed a bug that causes recovery (crash recovery, PITR) to
fail. Please find attached the patch against HEAD.
[Bug]
To reproduce the problem, do the following on Windows:
1. pg_ctl start
2. CREATE TABLESPACE tbs LOCATION 'some_tblspc_path';
3. pg_ctl stop -mi
4.
On 10/31/2013 08:40 AM, MauMau wrote:
Hello,
I've found and fixed a bug that causes recovery (crash recovery, PITR)
to fail. Please find attached the patch against HEAD.
[Bug]
To reproduce the problem, do the following on Windows:
1. pg_ctl start
2. CREATE TABLESPACE tbs LOCATION
From: Andrew Dunstan and...@dunslane.net
Why are you making this a runtime check instead of a compile time check?
I thought the same situation could happen as in
destroy_tablespace_directories(), but it doesn't seem to apply on second
thought. Revised patch attached, which is very simple
From: MauMau maumau...@gmail.com
I thought the same situation could happen as in
destroy_tablespace_directories(), but it doesn't seem to apply on second
thought. Revised patch attached, which is very simple based on compile
time
check.
Sorry, I was careless to leave an old comment. Please
19 matches
Mail list logo
