At Tue, 7 May 2019 10:55:06 +0900, Michael Paquier wrote
in <20190507015506.gc1...@paquier.xyz>
> On Tue, May 07, 2019 at 10:16:54AM +0900, Kyotaro HORIGUCHI wrote:
> > The fake symlinks need correction after the data directory and
> > tablespsce directory are moved. Maybe needs to call
> >
On Tue, May 07, 2019 at 10:16:54AM +0900, Kyotaro HORIGUCHI wrote:
> The fake symlinks need correction after the data directory and
> tablespsce directory are moved. Maybe needs to call
> CorrectSymlink() or something at startup... Or relative
> tablespaces should be rejected on Windows?
It took
Hello.
At Fri, 26 Apr 2019 12:25:10 -0700, Andres Freund wrote in
<20190426192510.dndtaxslneoh4...@alap3.anarazel.de>
> On 2019-04-26 17:29:56 +0900, Kyotaro HORIGUCHI wrote:
> > Win32 implement cannot have symbolic link feature as Linux-like
> > OSes for some restrictions. (Windows 7 and 10
Hi,
On 2019-04-26 17:29:56 +0900, Kyotaro HORIGUCHI wrote:
> Win32 implement cannot have symbolic link feature as Linux-like
> OSes for some restrictions. (Windows 7 and 10 behave differently,
> as I heard.)
>
> So the 0002 patch implemnets "fake" symbolic link as mentioned in
> its commit
Hello.
Win32 implement cannot have symbolic link feature as Linux-like
OSes for some restrictions. (Windows 7 and 10 behave differently,
as I heard.)
So the 0002 patch implemnets "fake" symbolic link as mentioned in
its commit message.
Also I fixed 0001 slightly.
regards.
At Thu, 25 Apr 2019
At Wed, 24 Apr 2019 09:30:12 -0700, Andres Freund wrote in
<20190424163012.7wzdl6j2v73cu...@alap3.anarazel.de>
> Hi,
>
> On 2019-04-24 17:02:28 +0900, Kyotaro HORIGUCHI wrote:
> > +/*
> > + * Check if the path is in the data directory strictly.
> > + */
> > +static bool
> >
Andres Freund writes:
> On 2019-04-24 10:13:09 -0400, Tom Lane wrote:
>> I can't say that I like 0001 at all. It adds a bunch of complication and
>> new failure modes (e.g., having to panic on chdir failure) in order to do
>> what exactly? I've not been following the thread closely, but the
>>
On Wed, Apr 24, 2019 at 9:25 AM Andres Freund wrote:
> The inability
> to reasonably test master/standby setups on a single machine is pretty
> jarring (yes, one can use basebackup tablespace maps - but that doesn't
> work well for new tablespaces).
+1 agree. Feature which can't be easily
Hi,
On 2019-04-24 17:02:28 +0900, Kyotaro HORIGUCHI wrote:
> +/*
> + * Check if the path is in the data directory strictly.
> + */
> +static bool
> +is_in_data_directory(const char *path)
> +{
> + char cwd[MAXPGPATH];
> + char abspath[MAXPGPATH];
> + char absdatadir[MAXPGPATH];
> +
>
Hi,
On 2019-04-24 10:13:09 -0400, Tom Lane wrote:
> Kyotaro HORIGUCHI writes:
> > At Wed, 24 Apr 2019 13:23:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> > wrote in
> > <20190424.132304.40676137.horiguchi.kyot...@lab.ntt.co.jp>
> >> We need to adjust relative path between PGDATA-based
Kyotaro HORIGUCHI writes:
> At Wed, 24 Apr 2019 13:23:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
> <20190424.132304.40676137.horiguchi.kyot...@lab.ntt.co.jp>
>> We need to adjust relative path between PGDATA-based and
>> pg_tblspc based. The attached first patch does that.
>
Hello.
At Wed, 24 Apr 2019 13:23:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190424.132304.40676137.horiguchi.kyot...@lab.ntt.co.jp>
> > > with a check that forces relative paths to be outside of PGDATA (baring
> > > symlinks). As far as I can tell
Sorry, I was in haste.
At Wed, 24 Apr 2019 13:18:45 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190424.131845.116224815.horiguchi.kyot...@lab.ntt.co.jp>
> At Tue, 23 Apr 2019 10:05:03 -0700, Andres Freund wrote
> in <20190423170503.uw5jxrujqlozg...@alap3.anarazel.de>
> > Hi,
>
At Tue, 23 Apr 2019 10:05:03 -0700, Andres Freund wrote in
<20190423170503.uw5jxrujqlozg...@alap3.anarazel.de>
> Hi,
>
> On 2019-04-23 16:08:18 +0900, Michael Paquier wrote:
> > On Mon, Apr 22, 2019 at 11:00:03PM -0700, Andres Freund wrote:
> > > FWIW, I think the right fix for this is to
Hi,
On 2019-04-23 16:08:18 +0900, Michael Paquier wrote:
> On Mon, Apr 22, 2019 at 11:00:03PM -0700, Andres Freund wrote:
> > FWIW, I think the right fix for this is to simply drop the requirement
> > that tablespace paths need to be absolute. It's not buying us anything,
> > it's just making
At Tue, 23 Apr 2019 19:00:54 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190423.190054.262966274.horiguchi.kyot...@lab.ntt.co.jp>
> > For TAP tests, we can point generated temporary directory by
> > "../../".
Wrong. A generating tmpdir (how?) in "../" (that is, in the node
At Tue, 23 Apr 2019 17:44:18 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190423.174418.262292011.horiguchi.kyot...@lab.ntt.co.jp>
> At Tue, 23 Apr 2019 16:08:18 +0900, Michael Paquier
> wrote in <20190423070818.gm2...@paquier.xyz>
> > On Mon, Apr 22, 2019 at 11:00:03PM -0700,
At Tue, 23 Apr 2019 16:08:18 +0900, Michael Paquier wrote
in <20190423070818.gm2...@paquier.xyz>
> On Mon, Apr 22, 2019 at 11:00:03PM -0700, Andres Freund wrote:
> > FWIW, I think the right fix for this is to simply drop the requirement
> > that tablespace paths need to be absolute. It's not
At Tue, 23 Apr 2019 14:53:28 +0900, Michael Paquier wrote
in <20190423055328.gk2...@paquier.xyz>
> On Tue, Apr 23, 2019 at 01:33:39PM +0900, Kyotaro HORIGUCHI wrote:
> > I think this is rahter a testing or debugging feature. This can
> > be apply to all paths, so the variable might be
On Mon, Apr 22, 2019 at 11:00:03PM -0700, Andres Freund wrote:
> FWIW, I think the right fix for this is to simply drop the requirement
> that tablespace paths need to be absolute. It's not buying us anything,
> it's just making things more complicated. We should just do a simple
> check against
Hi,
On 2019-04-22 15:52:59 +0530, Kuntal Ghosh wrote:
> Hello hackers,
>
> With a master-standby setup configured on the same machine, I'm
> getting a panic in tablespace test while running make installcheck.
>
> 1. CREATE TABLESPACE regress_tblspacewith LOCATION 'blah';
> 2. DROP TABLESPACE
On Tue, Apr 23, 2019 at 01:33:39PM +0900, Kyotaro HORIGUCHI wrote:
> I think this is rahter a testing or debugging feature. This can
> be apply to all paths, so the variable might be "path_prefix" or
> something more generic than tablespace_chroot.
>
> Does it make sense?
A GUC which enforces
At Tue, 23 Apr 2019 13:33:39 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190423.19.113770648.horiguchi.kyot...@lab.ntt.co.jp>
> At Tue, 23 Apr 2019 11:27:06 +0900, Michael Paquier
> wrote in <20190423022706.gg2...@paquier.xyz>
> > On Mon, Apr 22, 2019 at 03:52:59PM +0530,
At Tue, 23 Apr 2019 11:27:06 +0900, Michael Paquier wrote
in <20190423022706.gg2...@paquier.xyz>
> On Mon, Apr 22, 2019 at 03:52:59PM +0530, Kuntal Ghosh wrote:
> > I accept that configuring master-standby on the same machine for this
> > test is not okay. But, can we avoid the PANIC somehow?
On Mon, Apr 22, 2019 at 03:52:59PM +0530, Kuntal Ghosh wrote:
> I accept that configuring master-standby on the same machine for this
> test is not okay. But, can we avoid the PANIC somehow? Or, is this
> intentional and I should not include testtablespace in this case?
Well, it is a bit more
On Mon, Apr 22, 2019 at 6:07 PM Kyotaro HORIGUCHI
wrote:
> If you don't have a problem using TAP test suite, tablespace is
> allowed with a bit restricted steps using the first patch in my
> just posted patchset[1]. This will work for you if you are okay
> with creating a standby after creating a
Hello.
At Mon, 22 Apr 2019 15:52:59 +0530, Kuntal Ghosh
wrote in
> Hello hackers,
>
> With a master-standby setup configured on the same machine, I'm
> getting a panic in tablespace test while running make installcheck.
>
> 1. CREATE TABLESPACE regress_tblspacewith LOCATION 'blah';
> 2. DROP
Hello hackers,
With a master-standby setup configured on the same machine, I'm
getting a panic in tablespace test while running make installcheck.
1. CREATE TABLESPACE regress_tblspacewith LOCATION 'blah';
2. DROP TABLESPACE regress_tblspacewith;
3. CREATE TABLESPACE regress_tblspace LOCATION
28 matches
Mail list logo
