Re: PGXLOG variable worthwhile?

Hi everyone,

Am just wondering if we've ever considered adding a PGXLOG environment
variable that would point to the pg_xlog directory?

In a Unix environment it's not real necessary as filesystem links can be
created, but in other environments (i.e. the Native windows port) it's
looking like it might be useful.

:-)

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

We dealt this this (painfully) during 7.3 development. Some wanted a -X
flag to initdb/postgres/postmaster that would identify the pg_xlog
directory while others wanted the flag only on initdb and have initdb
create a symlink.

Finally, we decided to do nothing. and continue to recommend manually
moving pg_xlog using symlinks.

Also, I have heard symlinks are available in native Windows but the
interface to them isn't clearly visible. Can someone clarify that?

---------------------------------------------------------------------------

Justin Clift wrote:
> Hi everyone,
>
> Am just wondering if we've ever considered adding a PGXLOG environment
> variable that would point to the pg_xlog directory?
>
> In a Unix environment it's not real necessary as filesystem links can be
> created, but in other environments (i.e. the Native windows port) it's
> looking like it might be useful.
>
> :-)
>
> Regards and best wishes,
>
> Justin Clift
>
> --
> "My grandfather once told me that there are two kinds of people: those
> who work and those who take the credit. He told me to try to be in the
> first group; there was less competition there."
> - Indira Gandhi
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Thu, 12 Sep 2002, Justin Clift wrote:

> Am just wondering if we've ever considered adding a PGXLOG environment
> variable that would point to the pg_xlog directory?

IMHO, a much better way to support this is to put this information into
the config file. That way it can't easily change when you happen to, say,
start postgres in the wrong window.

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC

Curt Sampson <cjs(at)cynic(dot)net> writes:
> On Thu, 12 Sep 2002, Justin Clift wrote:
>> Am just wondering if we've ever considered adding a PGXLOG environment
>> variable that would point to the pg_xlog directory?

> IMHO, a much better way to support this is to put this information into
> the config file. That way it can't easily change when you happen to, say,
> start postgres in the wrong window.

Yes. We rejected environment-variable-based xlog location for reasons
that apply equally well to Windows. The xlog location *must* be stored
in a physical file in the data directory; anything else is too unsafe.
The current technology for that is a symlink.

While it doesn't have to be a symlink as opposed to some sort of config
file, I don't have the slightest problem with saying that we don't
support relocation of xlog on older Windoid platforms.

regards, tom lane

Tom Lane wrote:
> Curt Sampson <cjs(at)cynic(dot)net> writes:
> > On Thu, 12 Sep 2002, Justin Clift wrote:
> >> Am just wondering if we've ever considered adding a PGXLOG environment
> >> variable that would point to the pg_xlog directory?
>
> > IMHO, a much better way to support this is to put this information into
> > the config file. That way it can't easily change when you happen to, say,
> > start postgres in the wrong window.
>
> Yes. We rejected environment-variable-based xlog location for reasons
> that apply equally well to Windows. The xlog location *must* be stored
> in a physical file in the data directory; anything else is too unsafe.
> The current technology for that is a symlink.
>
> While it doesn't have to be a symlink as opposed to some sort of config
> file, I don't have the slightest problem with saying that we don't
> support relocation of xlog on older Windoid platforms.

Agreed. Win 4.X is pretty dead. I added this thread to TODO.detail.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:
>
> Tom Lane wrote:
<snip>
> > While it doesn't have to be a symlink as opposed to some sort of config
> > file, I don't have the slightest problem with saying that we don't
> > support relocation of xlog on older Windoid platforms.
>
> Agreed. Win 4.X is pretty dead. I added this thread to TODO.detail.

Huh? You've got to be joking.

Many of the *really large* enterprises around (i.e. with 40k+ PC's, etc)
are still running WinNT 4, due to the migration issues with upgrading.
Aka, Too Many Things Break when they move to Win2k, etc.

Although MS no longer considers WinNT 4.0 to be a supported platform,
there are *lots* of big places still running it.

That's part of the reason some of the bigger corporates are looking for
MS alternatives.

Regards and best wishes,

Justin Clift

>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Justin Clift wrote:
> Bruce Momjian wrote:
> >
> > Tom Lane wrote:
> <snip>
> > > While it doesn't have to be a symlink as opposed to some sort of config
> > > file, I don't have the slightest problem with saying that we don't
> > > support relocation of xlog on older Windoid platforms.
> >
> > Agreed. Win 4.X is pretty dead. I added this thread to TODO.detail.
>
> Huh? You've got to be joking.
>
> Many of the *really large* enterprises around (i.e. with 40k+ PC's, etc)
> are still running WinNT 4, due to the migration issues with upgrading.
> Aka, Too Many Things Break when they move to Win2k, etc.
>
> Although MS no longer considers WinNT 4.0 to be a supported platform,
> there are *lots* of big places still running it.
>
> That's part of the reason some of the bigger corporates are looking for
> MS alternatives.

Oh, that is bad news. Well, can we accept they will not be moving XLOG
around?

The problem with the non-symlink solution is that it is error-prone/ugly
on all the platforms, not just NT4.X.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:
<snip>
> Oh, that is bad news. Well, can we accept they will not be moving XLOG
> around?
>
> The problem with the non-symlink solution is that it is error-prone/ugly
> on all the platforms, not just NT4.X.

What you guys are saying isn't necessarily wrong, in that it may not
definitely be very pretty.

However, moving the WAL files to another disk has a significant
performance gain attached to it for loaded servers, so we how about we
take the viewpoint that if WinNT/2k/XP are to be supported then we might
as well let it do things properly instead of handicapping it?

Does anyone care to estimate what the coding time+issues involved would
be, for adding a parameter to the postgresql.conf file that allows
PostgreSQL to directly use a different directory path for the WAL files?

'wal_path'

or

'wal_directory'

or similar. In the postgresql.conf it would probably be placed in the
'Write-ahead log (WAL)' or 'Misc' sections.

No guarantees just yet but if it's not an extremely expensive thing to
add, then there might be people willing to pay for it (have a group in
mind already).

:-)

Regards and best wishes,

Justin Clift

> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Justin Clift <justin(at)postgresql(dot)org> writes:
> However, moving the WAL files to another disk has a significant
> performance gain attached to it for loaded servers, so we how about we
> take the viewpoint that if WinNT/2k/XP are to be supported then we might
> as well let it do things properly instead of handicapping it?

Considering that we do not yet have support for WinAnything except via
cygwin, this thread strikes me as mighty premature.

And, to be blunt, I'm not likely to go out of my way to improve support
for WinAnything even when we do have a native port. In words of one
syllable: WinAnything is not, and never will be, a preferred platform
for Postgres. Accordingly, performance improvements for it are just a
distraction from our real business; a distraction which plays into the
hands of Gates & Co. No thank you. I'm okay with providing minimal
support for those who really want to run toy databases on a toy
platform. I will *not* buy into trying to make it a non-toy platform.

regards, tom lane

On Sun, 15 Sep 2002, Bruce Momjian wrote:

> The problem with the non-symlink solution is that it is error-prone/ugly
> on all the platforms, not just NT4.X.

Actually, it's really just the environment variable solution that's
error prone, I think. Putting it in the config file is fine. It's
just a matter of someone coding it.

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC

Tom Lane wrote:
<snip>
> And, to be blunt, I'm not likely to go out of my way to improve support
> for WinAnything even when we do have a native port. In words of one
> syllable: WinAnything is not, and never will be, a preferred platform
> for Postgres. Accordingly, performance improvements for it are just a
> distraction from our real business; a distraction which plays into the
> hands of Gates & Co. No thank you. I'm okay with providing minimal
> support for those who really want to run toy databases on a toy
> platform. I will *not* buy into trying to make it a non-toy platform.

Understood, and that's ok.

Allowing PostgreSQL to be productively used as best it can be, whereever
it can be, makes sense doesn't it? Especially when the real target here
would be to give existing MS places a lower cost of entry to the
PostgreSQL world.

Financial example :

WinNT/2k/XP costs a few hundred dollars.

MS SQL Server costs a few thousand dollars.

Whenever we displace MS SQL Server, we divert more revenue away from MS
than if we just say "Sorry but we're not happy with making the Windows
port perform in ways that let it compete adequately with MS SQL Server".

We both know the arguments for and against. You're in the "against"
camp, and I'm in the "for" camp.

Personally I'm hoping there are some other PostgreSQL coders around in
the "for" camp too that can assist with this as we're beginning to gain
some good public enterprise level of interest.

:-)

Regards and best wishes,

Justin Clift

>
> regards, tom lane

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Justin Clift wrote:
>
> Bruce Momjian wrote:
> <snip>
> > Oh, that is bad news. Well, can we accept they will not be moving XLOG
> > around?
> >
> > The problem with the non-symlink solution is that it is error-prone/ugly
> > on all the platforms, not just NT4.X.
>
> What you guys are saying isn't necessarily wrong, in that it may not
> definitely be very pretty.
>
> However, moving the WAL files to another disk has a significant
> performance gain attached to it for loaded servers, so we how about we
> take the viewpoint that if WinNT/2k/XP are to be supported then we might
> as well let it do things properly instead of handicapping it?

I just don't see why that all could become an issue. Someone
running big stuff on NT4 today is not running a native PostgreSQL
port on it. Why would someone want to do a new, big, PG
installation on an old, unsupported NT4 server today?

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being
right. #
# Let's break this rule - forgive
me. #
#==================================================
JanWieck(at)Yahoo(dot)com #

Jan Wieck wrote:
<snip>
>
> I just don't see why that all could become an issue. Someone
> running big stuff on NT4 today is not running a native PostgreSQL
> port on it. Why would someone want to do a new, big, PG
> installation on an old, unsupported NT4 server today?

Corporate Standards. Even if everyone *knows* that NT4 isn't the latest
and greatest, many large companies still use NT4. Purely because so
much stuff they use works with it that they haven't been able to
generate sufficient business cases to migrate their base server OS to
Win2K (or XP).

If this would be a really huge and drastic modification then sure it's
not necessarily an easy thing to decide. But the first thing to
consider is "how much effort would be required?".

:-)

Regards and best wishes,

Justin Clift

> Jan
>
> --
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being
> right. #
> # Let's break this rule - forgive
> me. #
> #==================================================
> JanWieck(at)Yahoo(dot)com #

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Justin Clift writes:

> WinNT/2k/XP costs a few hundred dollars.
>
> MS SQL Server costs a few thousand dollars.

The places that run Windows can be categorized into three camps: (1)
Those that don't have a clue. They will never run PostgreSQL. (2) Those
that are somehow afraid to switch to a different solution. They will be
even more hesitant to switch to PostgreSQL. (3) Those that somehow like
Windows. They will like MS SQL Server as well, no matter what we do.

So where is the market?

--
Peter Eisentraut peter_e(at)gmx(dot)net

On Mon, 16 Sep 2002, Peter Eisentraut wrote:

> Justin Clift writes:
>
> > WinNT/2k/XP costs a few hundred dollars.
> >
> > MS SQL Server costs a few thousand dollars.
>
> The places that run Windows can be categorized into three camps: (1)
> Those that don't have a clue. They will never run PostgreSQL. (2) Those
> that are somehow afraid to switch to a different solution. They will be
> even more hesitant to switch to PostgreSQL. (3) Those that somehow like
> Windows. They will like MS SQL Server as well, no matter what we do.

I would say the only real growth market is "Those who have a clue, and are
looking at migrating off of Windows / MSSQL to a different database."

In the case of my company, that's mostly resulted in Postgresql deployed
on Linux and Solaris. But I can see a use for Postgresql on Windows.
However, for us, all our serious Windows servers have long since been
converted to Win2K. For all those situations, I can't imagine the
database getting big enough and hit hard enough for pg_xlog to be a
problem before it gets moved to a real OS.

So, by the time someone is deciding to dedicate themselves to running
Postgresql, they've probably already decided they should run it on some
flavor of Unix, or the slower performance of Postgresql under Windows is
no great detriment.

Supporting a sane OS like Unix is hard enough, creating more work for the
core developers in trying to work around a broken file system on Windows
is not the best use of the resources available.

If and when someone running postgresql on Windows decides they REALLY need
to move the pg_xlog somewhere else, they can either code it, or move to
Linux. I'd recommend moving to Linux.

Justin Clift wrote:
>
> Jan Wieck wrote:
> <snip>
> >
> > I just don't see why that all could become an issue. Someone
> > running big stuff on NT4 today is not running a native PostgreSQL
> > port on it. Why would someone want to do a new, big, PG
> > installation on an old, unsupported NT4 server today?
>
> Corporate Standards. Even if everyone *knows* that NT4 isn't the latest
> and greatest, many large companies still use NT4. Purely because so
> much stuff they use works with it that they haven't been able to
> generate sufficient business cases to migrate their base server OS to
> Win2K (or XP).

The word construct "corporate standard" is the most expensive and
dangerous form of ignorance I've seen in the business. One of the
best examples I've seen actually fit's very well. An SAP customer
converting from R/2 to R/3 a couple years ago. They ran all their
non-mainframe business on HP3000 MPE/IX systems. We strongly
recommended using HP/UX for the SAP installation instead, but
they followed their "corporate ignorance" anyway. Two weeks
before going life SAP informed all their MPE customers that
support for that operating system will be abandoned and strongly
recommended converting to HP/UX soon because within a few months
not even hotfixes will be provided any more. Outch!

If corporate standard means similar letter heads, similar
appearance of public offices or advertising, absolutely a good
thing and I'm all for it. But if it causes to get stuck with old
technology, then the corporate standard itself is the problem
that needs to be fixed first.

But ... let's put it into the damned config file and move on.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being
right. #
# Let's break this rule - forgive
me. #
#==================================================
JanWieck(at)Yahoo(dot)com #

Peter Eisentraut wrote:
>
> Justin Clift writes:
>
> > WinNT/2k/XP costs a few hundred dollars.
> >
> > MS SQL Server costs a few thousand dollars.
>
> The places that run Windows can be categorized into three camps:
<snip>

How about this?

The places that run Windows can be categorised a number of different
ways, depending on what you're looking for.

1) Places that have in-house staff that can do or learn everything.

Many of these places are really small, some are not. PostgreSQL fits
well here, Windows or not, as these people are prepared to learn how to
use it best.

2) Companies that hire external IT services.

Often the software implemented here will be dependent on outside sources
of advice such as consultants, executives who take an interest in IT
mags, etc.

Look at Windows NT on the server in the first place. Microsoft
leveraged the marketplace through making itself available then promoting
the heck out of itself into the IT press, industry mags, etc.

These places will be receptive to PostgreSQL as our reputation further
becomes known and they can see where PostgreSQL will be useful to them.
PostgreSQL on Win NT/2K/XP will definitely be of use to a sizable number
of these businesses.

3) Companies who depend on multiple external sources of IT support.
i.e. One reasonable sized enterprise here in Australia has over 450
*development* companies presently working on applications for their
environment. Because of the scope of standardisation needed, they
standardised on WinNT many years ago. It still works for them. They
don't even have SP6 installed on their desktops as it breaks too many of
the desktop applications. etc.

These people are not clueless. They make strategic decisions when
they're necessary, and it all comes down to flexibility, reliability,
and cost.

For some things they run Unix, or Windows, or Novell, or OS/390, or any
number of other stuff.

Because of the years of experience some of their support companies have
with WinNT, it works reliably enough for them. They don't have the
"need to reboot once per week" thing with their servers.

These guys will become receptive to PostgreSQL too, and it will be in
our favour to be able to demonstrate very good performance across all
platforms that we can, not just our own *personally preferred*
platforms.

By giving them options when it doesn't take a *whole bunch of effort* to
do so, we open up ways for PostgreSQL to be used that we haven't even
thought of before. We all know this already.

It wouldn't really surprise me greatly if at some point this proved
beneficial to a non-Windows platform for some reason too.

:-)

Regards and best wishes,

Justin Clift

> So where is the market?
>
> --
> Peter Eisentraut peter_e(at)gmx(dot)net

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

It seems all of this discussion misses the point. Either it has a large
amount of impact and the idea gets rejected because of implementation
issues, or it has little impact but it's nothing the core group wants to
implement. If the problem is finding someone to implement it, it sounds
like Justin has found such a person, so are we going to stand in his way
while we wax poetic about OS religion and corporate philosophies or can
he start submitting patches?

Robert Treat

On Mon, 2002-09-16 at 14:11, Justin Clift wrote:
> Peter Eisentraut wrote:
> >
> > Justin Clift writes:
> >
> > > WinNT/2k/XP costs a few hundred dollars.
> > >
> > > MS SQL Server costs a few thousand dollars.
> >
> > The places that run Windows can be categorized into three camps:
> <snip>
>
> How about this?
>
> The places that run Windows can be categorised a number of different
> ways, depending on what you're looking for.
>
> 1) Places that have in-house staff that can do or learn everything.
>
> Many of these places are really small, some are not. PostgreSQL fits
> well here, Windows or not, as these people are prepared to learn how to
> use it best.
>
>
> 2) Companies that hire external IT services.
>
> Often the software implemented here will be dependent on outside sources
> of advice such as consultants, executives who take an interest in IT
> mags, etc.
>
> Look at Windows NT on the server in the first place. Microsoft
> leveraged the marketplace through making itself available then promoting
> the heck out of itself into the IT press, industry mags, etc.
>
> These places will be receptive to PostgreSQL as our reputation further
> becomes known and they can see where PostgreSQL will be useful to them.
> PostgreSQL on Win NT/2K/XP will definitely be of use to a sizable number
> of these businesses.
>
>
> 3) Companies who depend on multiple external sources of IT support.
> i.e. One reasonable sized enterprise here in Australia has over 450
> *development* companies presently working on applications for their
> environment. Because of the scope of standardisation needed, they
> standardised on WinNT many years ago. It still works for them. They
> don't even have SP6 installed on their desktops as it breaks too many of
> the desktop applications. etc.
>
> These people are not clueless. They make strategic decisions when
> they're necessary, and it all comes down to flexibility, reliability,
> and cost.
>
> For some things they run Unix, or Windows, or Novell, or OS/390, or any
> number of other stuff.
>
> Because of the years of experience some of their support companies have
> with WinNT, it works reliably enough for them. They don't have the
> "need to reboot once per week" thing with their servers.
>
> These guys will become receptive to PostgreSQL too, and it will be in
> our favour to be able to demonstrate very good performance across all
> platforms that we can, not just our own *personally preferred*
> platforms.
>
> By giving them options when it doesn't take a *whole bunch of effort* to
> do so, we open up ways for PostgreSQL to be used that we haven't even
> thought of before. We all know this already.
>
> It wouldn't really surprise me greatly if at some point this proved
> beneficial to a non-Windows platform for some reason too.
>
> :-)
>
> Regards and best wishes,
>
> Justin Clift
>
>
> > So where is the market?
> >
> > --
> > Peter Eisentraut peter_e(at)gmx(dot)net
>
> --
> "My grandfather once told me that there are two kinds of people: those
> who work and those who take the credit. He told me to try to be in the
> first group; there was less competition there."
> - Indira Gandhi
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

> The places that run Windows can be categorized into three camps: (1)
> Those that don't have a clue. They will never run PostgreSQL. (2) Those
> that are somehow afraid to switch to a different solution. They will be
> even more hesitant to switch to PostgreSQL. (3) Those that somehow like
> Windows. They will like MS SQL Server as well, no matter what we do.
>
> So where is the market?

Ask MySQL - they have many, many Windows users.

Chris

Robert Treat wrote:
> It seems all of this discussion misses the point. Either it has a large
> amount of impact and the idea gets rejected because of implementation
> issues, or it has little impact but it's nothing the core group wants to
> implement. If the problem is finding someone to implement it, it sounds
> like Justin has found such a person, so are we going to stand in his way
> while we wax poetic about OS religion and corporate philosophies or can
> he start submitting patches?

Actually, the work is minimal. Look at the commit I used to remove
PGXLOG, trim that to remove the changes to make the path name dynamic in
size (added too much complexity for little benefit) and hang the path
coding off a GUC variable rather than an environment variable.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

> > It seems all of this discussion misses the point. Either it has a large
> > amount of impact and the idea gets rejected because of implementation
> > issues, or it has little impact but it's nothing the core group wants to
> > implement. If the problem is finding someone to implement it, it sounds
> > like Justin has found such a person, so are we going to stand in his way
> > while we wax poetic about OS religion and corporate philosophies or can
> > he start submitting patches?
>
> Actually, the work is minimal. Look at the commit I used to remove
> PGXLOG, trim that to remove the changes to make the path name dynamic in
> size (added too much complexity for little benefit) and hang the path
> coding off a GUC variable rather than an environment variable.

I personally don't see the problem with a GUC variable...that seems like the
perfect solution to me...

Chris

Christopher Kings-Lynne wrote:
> > > It seems all of this discussion misses the point. Either it has a large
> > > amount of impact and the idea gets rejected because of implementation
> > > issues, or it has little impact but it's nothing the core group wants to
> > > implement. If the problem is finding someone to implement it, it sounds
> > > like Justin has found such a person, so are we going to stand in his way
> > > while we wax poetic about OS religion and corporate philosophies or can
> > > he start submitting patches?
> >
> > Actually, the work is minimal. Look at the commit I used to remove
> > PGXLOG, trim that to remove the changes to make the path name dynamic in
> > size (added too much complexity for little benefit) and hang the path
> > coding off a GUC variable rather than an environment variable.
>
> I personally don't see the problem with a GUC variable...that seems like the
> perfect solution to me...

Well, let's see if we ever run on native NT4.X and we can decide then.
Actually, don't our Cygnus folks have a problem with moving pg_xlog
already?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Robert Treat wrote:
> It seems all of this discussion misses the point. Either it has a large
> amount of impact and the idea gets rejected because of implementation
> issues, or it has little impact but it's nothing the core group wants to
> implement. If the problem is finding someone to implement it, it sounds
> like Justin has found such a person, so are we going to stand in his way
> while we wax poetic about OS religion and corporate philosophies or can
> he start submitting patches?

Well, I have Win32 patches here I am reviewing. I think I can say that
the changes are minimal and probably will be accepted for addition into
7.4. I am actually surprised at how little is required.

Right now, 7.4 is targeted with point-in-time recovery and Win32. And,
in fact, both patches are almost ready for inclusion into CVS, so we
may find that 7.4 has a very short release cycle.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073