Re: [HACKERS] Waiting for archive to complete

[Simon Riggs]

On Mon, 2007-06-25 at 18:14 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > A simple solution is to introduce a new function:
> 
> > pg_archive_wait(integer maxwait);
> > maxwait = 0 means wait forever, otherwise time measured in seconds.
> 
> maxwait is redundant; people who want a timeout should use
> statement_timeout.

> > This will get the current xlog position and wait for all files prior to
> > that point to be shown as archive done.
> 
> Including the current one?  If so, it'll wait longer than necessary;
> if not, ISTM it's a gotcha waiting to trap the unwary.
> 
> Perhaps better is a variant of pg_stop_backup that includes a wait for
> the pushed-out xlog segment to be archived.

OK, will do.


For a timeout, I think you are suggesting this:

SET statement_timeout = X;
pg_stop_backup_wait();

So no need to include a function parameter for the wait time?
If thats what you are thinking, OK to that also.

-- 
  Simon Riggs 
  EnterpriseDB   http://www.enterprisedb.com



---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Winner of naming discussions: Synchronous Commit

[Tom Lane]

Jim Nasby <[EMAIL PROTECTED]> writes:
> I'm wondering if it would be wise to throw a warning at startup if  
> either sync_commit or fsync were set to off, ideally so that it would  
> both appear in the logs as well as in output from pg_ctl.

Egad.  And no doubt also complain about politically incorrect settings
of full_page_writes, add_missing_from, standard_conforming_strings, etc?
Mebbe throw a warning if listen_addresses allows any nonlocal
connections, since obviously you expose yourself to danger that way.

If you think you can get the motion to pass, propose removing these
options entirely.  Don't bother us with nanny-ism.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Winner of naming discussions: Synchronous Commit

[Jim Nasby]

On Jun 25, 2007, at 3:30 AM, Dave Page wrote:

Simon Riggs wrote:

So, although its a knife edge decision, I'd say go with
synchronous_commit = off.


I agree - I'm not entirely sure why but it just feels more natural  
than asynchronous_commit = on. Plus the reasons you give seem valid.


On the flip-side, experienced DBAs are likely tuned into anything  
labeled as "asynchronous"...


I'm wondering if it would be wise to throw a warning at startup if  
either sync_commit or fsync were set to off, ideally so that it would  
both appear in the logs as well as in output from pg_ctl.

--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)



---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

Re: [HACKERS] Bugtraq: Having Fun With PostgreSQL

[Tom Lane]

"Andrew Hammond" <[EMAIL PROTECTED]> writes:
> On 6/25/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> The normal build process for any open-source package is
>> 
>> ./configure
>> make
>> sudo make install
>> ... now what?  OK, time to read the manual ...

> Since they presumably don't know about initdb yet, yeah, I figure
> they'll be reading the manual. We already talk  about how to initdb.
> It seems reasonable to have the manual talk about how to initially
> connect to your "secure by default" database and create a
> non-superuser working user.

+1 on having such a discussion in the manual (someone else suggested
that already IIRC).  But I'm not seeing what a configure flag brings
to the party.

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Bugtraq: Having Fun With PostgreSQL

[Andrew Hammond]

On 6/25/07, Tom Lane <[EMAIL PROTECTED]> wrote:

Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Mon, Jun 25, 2007 at 01:31:52PM -0400, Tom Lane wrote:
>> Why is that better than the initdb-time option we already have?
>> Locking down options earlier rather than later is usually not a win.

> Like I said, I don't actually think it _is_ better.  But it would
> solve the problem that some people think it's a bad thing that you
> run superuser-type commands without reading the manual, and then get
> a badly-secured system.  (The idea here, incidentally, is not to
> replace the initdb-time option, but to set the default of the initdb
> command.)

But, per previous discussion, the people that would be affected are
only the ones building from source.  If they didn't read the manual
for initdb (nor notice the warning it puts out about trust auth),
they *certainly* didn't look for any nonstandard configure options.
The normal build process for any open-source package is

./configure
make
sudo make install
... now what?  OK, time to read the manual ...


Since they presumably don't know about initdb yet, yeah, I figure
they'll be reading the manual. We already talk  about how to initdb.
It seems reasonable to have the manual talk about how to initially
connect to your "secure by default" database and create a
non-superuser working user.

I like the idea of it being a configure flag, it seems the least
invasive way to do it.

Andrew

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] libpq protocol version 2

[Tom Lane]

"Chuck McDevitt" <[EMAIL PROTECTED]> writes:
> Is protocol version 2 still used by anything?  Is there a reason why
> this is still supported?

Even if you're not concerned about breaking old clients, I believe that
the JDBC folk are still giving out advice to use ProtocolVersion=2 as
a workaround for various arcane portability issues for Java clients.

In any case, AFAICS there's no very good reason to remove it.  The
amount of backend code involved is pretty trivial.

regards, tom lane

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] Waiting for archive to complete

[Tom Lane]

"Simon Riggs" <[EMAIL PROTECTED]> writes:
> A simple solution is to introduce a new function:

> pg_archive_wait(integer maxwait);
> maxwait = 0 means wait forever, otherwise time measured in seconds.

maxwait is redundant; people who want a timeout should use
statement_timeout.

> This will get the current xlog position and wait for all files prior to
> that point to be shown as archive done.

Including the current one?  If so, it'll wait longer than necessary;
if not, ISTM it's a gotcha waiting to trap the unwary.

Perhaps better is a variant of pg_stop_backup that includes a wait for
the pushed-out xlog segment to be archived.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

[HACKERS] libpq protocol version 2

[Chuck McDevitt]

Is protocol version 2 still used by anything?  Is there a reason why
this is still supported?


---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

[HACKERS] Waiting for archive to complete

[Simon Riggs]

A number of people have complained that it is possible to make a base
backup and then shutdown the server before the last xlog file has been
archived. Others say they would like to be able to make a backup and
know it is complete.

Making the archiver continue while the file is archived can cause
problems when we do a restart, which has prevented some possible
solutions.

A simple solution is to introduce a new function:

pg_archive_wait(integer maxwait);
maxwait = 0 means wait forever, otherwise time measured in seconds.

This will get the current xlog position and wait for all files prior to
that point to be shown as archive done. Code to do this is very similar
to XLogArchiveCheckDone() in a wait loop, testing once per second.

Simple enough for this release?

Comments?

-- 
  Simon Riggs 
  EnterpriseDB   http://www.enterprisedb.com



---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Bugtraq: Having Fun With PostgreSQL

[Tom Lane]

Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Mon, Jun 25, 2007 at 01:31:52PM -0400, Tom Lane wrote:
>> Why is that better than the initdb-time option we already have?
>> Locking down options earlier rather than later is usually not a win.

> Like I said, I don't actually think it _is_ better.  But it would
> solve the problem that some people think it's a bad thing that you
> run superuser-type commands without reading the manual, and then get
> a badly-secured system.  (The idea here, incidentally, is not to
> replace the initdb-time option, but to set the default of the initdb
> command.)

But, per previous discussion, the people that would be affected are
only the ones building from source.  If they didn't read the manual
for initdb (nor notice the warning it puts out about trust auth),
they *certainly* didn't look for any nonstandard configure options.
The normal build process for any open-source package is

./configure
make
sudo make install
... now what?  OK, time to read the manual ...

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Bugtraq: Having Fun With PostgreSQL

[Andrew Sullivan]

On Mon, Jun 25, 2007 at 01:31:52PM -0400, Tom Lane wrote:
> Why is that better than the initdb-time option we already have?
> Locking down options earlier rather than later is usually not a win.

Like I said, I don't actually think it _is_ better.  But it would
solve the problem that some people think it's a bad thing that you
run superuser-type commands without reading the manual, and then get
a badly-secured system.  (The idea here, incidentally, is not to
replace the initdb-time option, but to set the default of the initdb
command.)

A

-- 
Andrew Sullivan  | [EMAIL PROTECTED]
When my information changes, I alter my conclusions.  What do you do sir?
--attr. John Maynard Keynes

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] msvc and vista fun

[Andrew Dunstan]

Mark Cave-Ayland wrote:

This has come up quite recently on the MingW lists - see
http://sourceforge.net/mailarchive/forum.php?thread_name=00fc01c7a0af%
240a037c30%240200a8c0%40AMD2500&forum_name=mingw-users for a discussion
of the problem and solution.



  


Thanks. I've actually got past this issue, and moved on to the problem 
of having to downgrade far enough to get past the gettimeofday 
redefinition problem :-)


cheers

andrew

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] msvc and vista fun

[Mark Cave-Ayland]

On Sun, 2007-06-24 at 13:23 -0400, Andrew Dunstan wrote:

(cut)

> On a somewhat related note, I have had spectacular lack of success in 
> getting either MSVC or MinGW builds to work on Vista - so much so that I 
> have currently abandoned my attempts on that platform and I resorted to 
> resuscitating an old XP box for testing. Following some advice from 
> Magnus, I added ACLs to the build root for both an admin and a non-admin 
> user (cacls buildroot /E /T /G AdminUser:C and similarly for a non-admin 
> user) . I can build as the admin user but when I come to run initdb it 
> fails, complaining that it can't find the postgres executable. If I then 
> switch to the non-admin user, it can run initdb just fine. However, that 
> user can't build, because it gets a mysterious failure from mt.exe. 
> MinGW is even worse - it says it can't run gcc because it can't run 
> cc1.exe (IIRC), so it fails at the configure stage! All of this has cost 
> me quite a few hours in the last week, with very little to show for it.


Hi Andrew,

This has come up quite recently on the MingW lists - see
http://sourceforge.net/mailarchive/forum.php?thread_name=00fc01c7a0af%
240a037c30%240200a8c0%40AMD2500&forum_name=mingw-users for a discussion
of the problem and solution.


Kind regards,

Mark.

-- 
ILande - Open Source Consultancy
http://www.ilande.co.uk



---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Frustrating issue with PGXS

[Tom Lane]

Fabien COELHO <[EMAIL PROTECTED]> writes:
> With the assumption that the above "that one" refered to the "PG_CONFIG" 
> macro definition in "Makefile.global". As existing extension makefiles do 
> not defined PG_CONFIG, relying on one would break them wrt future 
> releases?

Ah, I see.  I was thinking in terms of breaking them intentionally ;-)
but perhaps that's not such a great idea.  The reason that I was
thinking that way was that as long as module Makefiles look like

PGXS := $(shell pg_config --pgxs)
include $(PGXS)

there will be room for people to make the same mistake as Eddie, ie,
try to modify that shell command to select a pg_config that's not
first in $PATH.

If we're worrying about cross-version compatibility then it seems there
isn't any really nice way to make both combinations do the ideal thing.
If someone has an updated module Makefile, ie,

PG_CONFIG := pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)

then it will look like changing PG_CONFIG in the Makefile would work;
but that will not work with an older PG release, because Makefile.global
will override the value.  So neither way of writing the module Makefile
is going to be foolproof with both old and new PG installations.

Reading between the lines in the gmake manual, it seems like writing
the module Makefile as

override PG_CONFIG := pg_config
etc

might work to override the setting in old copies of Makefile.global,
but this cure is worse than the disease, because it prevents specifying
PG_CONFIG on the make command line.  (And I'm not sure it works anyway;
have not tried it.)

Anyone see a way to handle all these cases at the same time?

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Frustrating issue with PGXS

[Fabien COELHO]

Dear Tom,


That would break existing Makefiles that use the "please take the first
pg_config in the path" feature, which rather make sense (it just means
that you want the extension for your current postgresql).


How would it break them?  The default definition is still PG_CONFIG =
pg_config, this just moves where that definition appears.


I think that I was answering to:

...
Tom> I'm not sure though how to get this setting to
Tom> override the one in Makefile.global ... 
Tom> or should we just remove that one?


With the assumption that the above "that one" refered to the "PG_CONFIG" 
macro definition in "Makefile.global". As existing extension makefiles do 
not defined PG_CONFIG, relying on one would break them wrt future 
releases? That's why I suggested to replace the "Makefile.global" 
definition by a conditional one.


But it is also entirely possible that I did not fully understand your 
sentence:-)


--
Fabien.

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [HACKERS] Frustrating issue with PGXS

[Fabien COELHO]

Dear Eddie,


MODULES = example
PGXS := $(shell ~/install_dir/bin/pg_config --pgxs)


This is indeed not the intented use of pgxs: it breaks a desirable 
property of the makefile that is should be "generic" wrt postgresql, that 
is not particular to an installation.


You are really expected to rely on the path, although the definition you 
wrote is indeed tempting, although doomed to failure. From the 
documentation, one finds:


"""
33.9.7. Extension Building Infrastructure

...

PGXS := $(shell pg_config --pgxs)
include $(PGXS)

The last two lines should always be the same. Earlier in the file, you 
assign variables or add custom make rules.


...

The extension is compiled and installed for the PostgreSQL installation 
that corresponds to the first pg_config command found in your path.

"""

There could be a clearer comment about the path assumption in "pgxs.mk" 
and how to change the path easily from the shell?  The "should be the 
same" could be changed for "MUST always be the same..." with some 
additional comments.




Could this have been avoided if the Makefile.global had
PG_CONFIG = $(prefix)/bin/pg_config ?


That would not work, because "pg_config" is needed to know what the prefix 
(or rather bindir) is, as Tom pointed out. I think this is also because 
the "installation" may be moved around, so it is not necessarily the 
configure-time prefix which is used with some package systems.


His suggestion about using a PG_CONFIG macro in the initial makefile, 
which may be redefined if required, would also provide an alternative way 
supplying the right pg_config, at the price of one additional line. Mm.

I think a doc improvement is at least welcome.

--
Fabien.

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Frustrating issue with PGXS

[Fabien COELHO]

ifdef USE_PGXS
PGXS := $(shell pg_config --pgxs)
include $(PGXS)

but something like

ifdef USE_PGXS
PG_CONFIG := pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)

to sync these invocations of pg_config with the ones in
Makefile.global.  I'm not sure though how to get this setting to
override the one in Makefile.global ... or should we just remove
that one?


That would break existing Makefiles that use the "please take the first 
pg_config in the path" feature, which rather make sense (it just means 
that you want the extension for your current postgresql).


However you may replace the other appearance with the following:

ifndef PG_CONFIG
PG_CONFIG   = pg_config
endif

So as to enable

sh> make PG_CONFIG=/my/manual/path/to/pg_config install

invocations without fear to be overwritten, if some people do not like the 
path convention. Otherwise the following does the trick with a temporary 
replacement of the PATH environment variable just for one command under 
sh-compatible shells:


sh> PATH=/my/manual/path/to:$PATH make install

and is shorter. This could be added to the documentation.

--
Fabien.

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Frustrating issue with PGXS

[Tom Lane]

Fabien COELHO <[EMAIL PROTECTED]> writes:
>> ifdef USE_PGXS
>> PGXS := $(shell pg_config --pgxs)
>> include $(PGXS)
>> 
>> but something like
>> 
>> ifdef USE_PGXS
>> PG_CONFIG := pg_config
>> PGXS := $(shell $(PG_CONFIG) --pgxs)
>> include $(PGXS)

> That would break existing Makefiles that use the "please take the first 
> pg_config in the path" feature, which rather make sense (it just means 
> that you want the extension for your current postgresql).

How would it break them?  The default definition is still PG_CONFIG =
pg_config, this just moves where that definition appears.

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Bugtraq: Having Fun With PostgreSQL

[Tom Lane]

Andrew Sullivan <[EMAIL PROTECTED]> writes:
> To achieve the "secure by default" feature that you want (and I like
> the scare-quotes -- I agree with those that think this adds no real
> security, but I think you're right to worry about the perception
> angle in this case), why not have a ./configure option that sets the
> default trust level for the build?

Why is that better than the initdb-time option we already have?
Locking down options earlier rather than later is usually not a win.

regards, tom lane

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] Blowback from text conversion changes

[Tom Lane]

Gregory Stark <[EMAIL PROTECTED]> writes:
> This seems odd. It's not deciding that it's ambiguous or coming from another
> datatype for which no implicit cast exists. It knows perfectly well that it
> wants to convert to text but fails?

> postgres=# select 'a'||b from (select 'b' as b) as x;
> ERROR:  failed to find conversion function from unknown to text

No, it's always done that.  The problem is that we don't force the
output of the subselect to be non-unknown before freezing our
determination of what it is --- once we start analysis of the upper
query it's too late to change our minds about what the subquery
produces.

This has been complained of before, eg
http://archives.postgresql.org/pgsql-bugs/2007-05/msg0.php

At the time I was thinking of forcing unknown result columns to text
before exiting parse analysis of the subquery.  I thought then, and
still think, that that would have a nontrivial risk of breaking
cases that historically have worked.

Reconsidering it now, I notice there's a kluge in transformInsertStmt()
for a related case in INSERT ... SELECT, viz copy up the unknown-type
Const as a Const instead of a reference to the subquery output.  Perhaps
it'd be a good idea to try to do something similar for cases like this.
You'd have to worry about outer joins and so on, though.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Blowback from text conversion changes

[D'Arcy J.M. Cain]

On Mon, 25 Jun 2007 17:56:28 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
> 
> This seems odd. It's not deciding that it's ambiguous or coming from another
> datatype for which no implicit cast exists. It knows perfectly well that it
> wants to convert to text but fails?
> 
> 
> postgres=# select 'a'||b from (select 'b' as b) as x;
> ERROR:  failed to find conversion function from unknown to text

It isn't the destination type that is the problem here but the source.
I suppose that it could default 'b' to text but really, that isn't
necessarily what '' signifies.  How about '2007-06-25'?  Is that text,
date or timestamp?  Try this.

select 'a'||b from (select 'b'::text as b) as x;

-- 
D'Arcy J.M. Cain <[EMAIL PROTECTED]> |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Bugtraq: Having Fun With PostgreSQL

[Andrew Sullivan]

On Sat, Jun 23, 2007 at 06:14:23PM +0200, Magnus Hagander wrote:
> The benefit would be that PostgreSQL would be "secure by default". Which
> we are *not* today.

To achieve the "secure by default" feature that you want (and I like
the scare-quotes -- I agree with those that think this adds no real
security, but I think you're right to worry about the perception
angle in this case), why not have a ./configure option that sets the
default trust level for the build?  The option could default to
something "secure", but experienced users' build scripts would only
have to be altered to include --default-authentication="trust" or
something like that.  Using this approach, packagers can also
continue to do what they want.

A
-- 
Andrew Sullivan  | [EMAIL PROTECTED]
However important originality may be in some fields, restraint and 
adherence to procedure emerge as the more significant virtues in a 
great many others.   --Alain de Botton

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

[HACKERS] Blowback from text conversion changes

[Gregory Stark]

This seems odd. It's not deciding that it's ambiguous or coming from another
datatype for which no implicit cast exists. It knows perfectly well that it
wants to convert to text but fails?


postgres=# select 'a'||b from (select 'b' as b) as x;
ERROR:  failed to find conversion function from unknown to text


-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com


---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] msvc and vista fun

[Dave Page]

Magnus Hagander wrote:

So it might be worthwhile to see if this is something that happens on <=
XP, and works on >= 2003. Dave, did you test on any server OS other than
2003, or any client that's XP or earlier?


No, my testing was only on 2k3 and vista.

/D

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [HACKERS] msvc and vista fun

[Andrew Dunstan]

Magnus Hagander wrote:
Can we change that or make it switchable? I'd be happy to provide an 
environment variable like RUNNING_BUILDFARM if that would help.



We could, but it seems very ugly. And again, it's *not* required for
buildfarm on my or Daves machines. So I'd rather like to know why it's
actually happening than just blindly change it.


  


Not surprisingly, I am not the only person who has had this problem. See 
http://jira.codehaus.org/browse/CONTINUUM-413 where the suggested 
solution is:


 if "%MAVEN_TERMINATE_CMD%" == "on" exit %ERRORLEVEL%
 exit /b %ERRORLEVEL%

There are 12 lines involved in our .bat files:

build.bat:35:exit /b %E%
builddoc.bat:40:exit /b
builddoc.bat:50:exit /b
install.bat:9:exit /b 1
install.bat:18:exit /b %ERRORLEVEL%
vcregress.bat:35:   if errorlevel 1 exit /b 1
vcregress.bat:51:exit /b %E%
vcregress.bat:64:   if errorlevel 1 exit /b 1
vcregress.bat:66:   if errorlevel 1 exit /b 1
vcregress.bat:86:exit /b %E%
vcregress.bat:97:if %CONTRIBERROR%==1 exit /b 1
vcregress.bat:113:exit /b %E%

Would making a change like this in those 12 places be so ugly?

cheers

andrew



---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [HACKERS] Soft deadlocks

[Tom Lane]

Gregory Stark <[EMAIL PROTECTED]> writes:
> I'm trying to understand what a soft deadlock is as described by deadlock.c.

> As best I understand if a process, A, is waiting for a lock and is being
> blocked only because someone, B, is ahead of it in the queue but hasn't been
> granted the conflicting lock we want to jump A ahead of B.

No, we only do that if it breaks a deadlock.  In your example there is
no reason to move process A ahead of B.

A more typical situation is like this:

Process A:
begin;
select * from T where ...;
-- now A holds AccessShareLock on T

Process B:
lock table T;
-- wants AccessExclusiveLock on T, blocks waiting for A

Process A:
lock table T;
-- blocks behind B?

Fairness would normally demand that A queue behind B for the
AccessExclusiveLock, but if we do that we have a deadlock.
So we spring A ahead of B and let it have the AccessExclusiveLock
out of turn.

This is just the base case; you can get into similar situations
involving more than one lockable object and more than two processes.
I believe that the above case is caught by the test in ProcSleep and
A will be granted the lock upgrade without blocking at all; but any
more-complex situation will only be discovered when someone runs the
deadlock checker.

regards, tom lane

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] Frustrating issue with PGXS

[Tom Lane]

Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Mon, Jun 25, 2007 at 10:43:37AM -0400, Tom Lane wrote:
>> Correct --- how else is it going to find out where the installation is?

> You can specify the full path in the command to pg_config in your Makefile.
> It'd be neat if the makefile could fint that out and use it for further
> references to pg_config. I haven't had time to look into if this is at all
> possible, though.

The trick is to override this bit in Makefile.global:

PG_CONFIG = pg_config

bindir := $(shell $(PG_CONFIG) --bindir)
datadir := $(shell $(PG_CONFIG) --sharedir)
... etc ...

It might be better if the standard invocation of a PGXS build were not

ifdef USE_PGXS
PGXS := $(shell pg_config --pgxs)
include $(PGXS)

but something like

ifdef USE_PGXS
PG_CONFIG := pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)

to sync these invocations of pg_config with the ones in
Makefile.global.  I'm not sure though how to get this setting to
override the one in Makefile.global ... or should we just remove
that one?

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] msvc and vista fun

[Andrew Dunstan]

Dave Page wrote:

Dave Page wrote:

If I then
switch to the non-admin user, it can run initdb just fine. However, 
that user can't build, because it gets a mysterious failure from 
mt.exe. MinGW is even worse - it says it can't run gcc because it 
can't run cc1.exe (IIRC), so it fails at the configure stage! All of 
this has cost me quite a few hours in the last week, with very 
little to show for it.


And that one...


See http://aarongiles.com/?p=199 for more details, but the quick fix I 
used was to add /mingw/libexec/gcc/mingw32/3.4.2 to the path in 
/etc/profile.






That seems to have fixed it. But now of cousre I forgot that the latest 
version is broken w.r.t. gettimeofday ... *sigh*


cheers

andrew

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [Fwd: Re: [HACKERS] tsearch in core patch]

[Mike Rylander]

On 6/25/07, Tom Lane <[EMAIL PROTECTED]> wrote:

"Mike Rylander" <[EMAIL PROTECTED]> writes:
> I can certainly understand the benefit of making the default
> configuration a simple locale to language map, but there are
> definitely uses for searching using different stemmers/stop-lists even
> within the same corpus/index.  So, as a datapoint for the discussion,
> I would ask that the option of multiple languages per DB locale not be
> removed if it can be at all avoided.

Nobody is proposing that --- the issue here is just how we set up the
"default" configuration.



Then I misunderstood.  Sorry for the noise, folks.

--
Mike Rylander

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [HACKERS] msvc and vista fun

[Dave Page]

Andrew Dunstan wrote:

Hmm. Mine says 5.1.2600, which seems to be quite old. I'll see about 
updating ... the strange thing is I'm pretty sure I've seen this on 
other more up to date machines.


You can't update that unless you upgrade to Windows 2003 or Vista. 
That's the XP command shell.


Regards, Dave

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

Re: [HACKERS] msvc and vista fun

[Magnus Hagander]

On Mon, Jun 25, 2007 at 10:45:00AM -0400, Andrew Dunstan wrote:
> 
> 
> Magnus Hagander wrote:
> >cmd.exe from Windows - I assume you haven't installed some funky addon
> >special command interpreter? In that case, it should be the same. So I
> >have:
> >Microsoft Windows [Version 5.2.3790]
> >(C) Copyright 1985-2003 Microsoft Corp.
> >
> >
> >  
> >  
> 
> Hmm. Mine says 5.1.2600, which seems to be quite old. I'll see about 
> updating ... the strange thing is I'm pretty sure I've seen this on 
> other more up to date machines.

That's because you are on XP. 5.1 is XP, 5.2 is 2003. To make things more
interesting, XP x64 is 5.2...

So it might be worthwhile to see if this is something that happens on <=
XP, and works on >= 2003. Dave, did you test on any server OS other than
2003, or any client that's XP or earlier?

//Magnus


---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] Frustrating issue with PGXS

[Magnus Hagander]

On Mon, Jun 25, 2007 at 10:43:37AM -0400, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > I was actually about to post on this just a couple of days ago - it seems
> > pgxs really needs pg_config to be in your PATH.
> 
> Correct --- how else is it going to find out where the installation is?

You can specify the full path in the command to pg_config in your Makefile.
It'd be neat if the makefile could fint that out and use it for further
references to pg_config. I haven't had time to look into if this is at all
possible, though.

This is the easy error btw - you can get some fairly funky results if you
have 8.3devel locally and then say 8.0 with different compile options in
your PATH. Then it'll use your 8.3devel pg_config for the first step and
then fall back on the one in the PATH for later steps..

//Magnus

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] [PATCHES] New Zealand - TZ change

[Zdenek Kotala]

Tom Lane wrote:

Zdenek Kotala <[EMAIL PROTECTED]> writes:
I would like to inform, that New Zealand changed DST rules and new 
timezone files are available.  See 
http://www.dia.govt.nz/diawebsite.nsf/wpg_URL/Services-Daylight-Saving-Daylight-saving-to-be-extended



Patch for head attached.


We do not "patch" those files; the update technique is "download, untar,
commit", and there's really no point in doing it except when a release
is imminent.  See src/timezone/README and src/tools/RELEASE_CHANGES.


Thanks for explanation. However there is still the question when we will release 
new 8.0-8.2 versions. The changes will happen after two months and there is not 
much space for packagers to create and release packages.


Zdenek

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

Re: [Fwd: Re: [HACKERS] tsearch in core patch]

[Tom Lane]

"Mike Rylander" <[EMAIL PROTECTED]> writes:
> I can certainly understand the benefit of making the default
> configuration a simple locale to language map, but there are
> definitely uses for searching using different stemmers/stop-lists even
> within the same corpus/index.  So, as a datapoint for the discussion,
> I would ask that the option of multiple languages per DB locale not be
> removed if it can be at all avoided.

Nobody is proposing that --- the issue here is just how we set up the
"default" configuration.

regards, tom lane

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] msvc and vista fun

[Andrew Dunstan]

Magnus Hagander wrote:

cmd.exe from Windows - I assume you haven't installed some funky addon
special command interpreter? In that case, it should be the same. So I
have:
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.


  
  


Hmm. Mine says 5.1.2600, which seems to be quite old. I'll see about 
updating ... the strange thing is I'm pretty sure I've seen this on 
other more up to date machines.


cheers

andrew

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Frustrating issue with PGXS

[Tom Lane]

Magnus Hagander <[EMAIL PROTECTED]> writes:
> I was actually about to post on this just a couple of days ago - it seems
> pgxs really needs pg_config to be in your PATH.

Correct --- how else is it going to find out where the installation is?

Eddie's proposed solution is of course circular reasoning...

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] [PATCHES] New Zealand - TZ change

[Tom Lane]

Zdenek Kotala <[EMAIL PROTECTED]> writes:
> I would like to inform, that New Zealand changed DST rules and new 
> timezone files are available.  See 
> http://www.dia.govt.nz/diawebsite.nsf/wpg_URL/Services-Daylight-Saving-Daylight-saving-to-be-extended

> Patch for head attached.

We do not "patch" those files; the update technique is "download, untar,
commit", and there's really no point in doing it except when a release
is imminent.  See src/timezone/README and src/tools/RELEASE_CHANGES.

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] msvc and vista fun

[Dave Page]

Magnus Hagander wrote:

As for perl, I'm probably not on the very latest, but it's not so old. I'm
on:
This is perl, v5.8.8 built for MSWin32-x64-multi-thread
(with 33 registered patches, see perl -V for more detail)


Dave - what version are you on?


This is perl, v5.8.8 built for MSWin32-x86-multi-thread
(with 50 registered patches, see perl -V for more detail)

/D

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

[HACKERS] Soft deadlocks

[Gregory Stark]

I'm trying to understand what a soft deadlock is as described by deadlock.c.

As best I understand if a process, A, is waiting for a lock and is being
blocked only because someone, B, is ahead of it in the queue but hasn't been
granted the conflicting lock we want to jump A ahead of B.

So if i do something like:

process X:
-
select * from x where i=1 for share;



process B:
-
select * from x where i=1 for update;



process A:
-
select * from x where i=1 for share;


process A will block, but when the deadlock timeout fires it should get jumped
ahead of process B.

If that's right then, uh, it doesn't seem to be working.

Process B:

postgres=# select * from x where i = 0 for update;
LOG:  process 4629 still waiting for ShareLock on transaction 7802 after 
5000.149 ms

Process A:

postgres=# select * from x where i = 0 for share;
LOG:  process 4631 still waiting for ShareLock on tuple (0,1) of relation 16423 
of database 11408 after 5000.151 ms

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] msvc and vista fun

[Magnus Hagander]

On Mon, Jun 25, 2007 at 10:06:57AM -0400, Andrew Dunstan wrote:
> 
> 
> Magnus Hagander wrote:
> >
> >Can you run the build in "broken mode" but *without* using the buildfarm
> >scripts, and see what errorlevel you get? Meaning:
> >build.bat
> >... wait ...
> >echo %errorlevel%
> >
> >It should output 1 if that part works, 0 if it fails. That'll tell us if
> >the problem is in the bf or if it's in the actual build system.
> >
> >
> >  
> 
> It fails and says 1.
> 
> Now, if I change the build script so it says
> 
>  exit %E
> 
> instead of
> 
>  exit /b %E

That's just weird :-( And making that change makes the script unusable from
the commandline.


> I pick up the exit status just fine. I wonder if wer have different 
> flavors of command interpreter? (My perl is the latest one from 
> ActiveState, btw. I assume you're using that.)

cmd.exe from Windows - I assume you haven't installed some funky addon
special command interpreter? In that case, it should be the same. So I
have:
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.


As for perl, I'm probably not on the very latest, but it's not so old. I'm
on:
This is perl, v5.8.8 built for MSWin32-x64-multi-thread
(with 33 registered patches, see perl -V for more detail)


Dave - what version are you on?


> Can we change that or make it switchable? I'd be happy to provide an 
> environment variable like RUNNING_BUILDFARM if that would help.

We could, but it seems very ugly. And again, it's *not* required for
buildfarm on my or Daves machines. So I'd rather like to know why it's
actually happening than just blindly change it.

//Magnus


---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] msvc and vista fun

[Andrew Dunstan]

Magnus Hagander wrote:


Can you run the build in "broken mode" but *without* using the buildfarm
scripts, and see what errorlevel you get? Meaning:
build.bat
... wait ...
echo %errorlevel%

It should output 1 if that part works, 0 if it fails. That'll tell us if
the problem is in the bf or if it's in the actual build system.


  


It fails and says 1.

Now, if I change the build script so it says

 exit %E

instead of

 exit /b %E

I pick up the exit status just fine. I wonder if wer have different 
flavors of command interpreter? (My perl is the latest one from 
ActiveState, btw. I assume you're using that.)


Can we change that or make it switchable? I'd be happy to provide an 
environment variable like RUNNING_BUILDFARM if that would help.


cheers

andrew


---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [Fwd: Re: [HACKERS] tsearch in core patch]

[Mike Rylander]

On 6/25/07, Tom Lane <[EMAIL PROTECTED]> wrote:

Well, it's not hard at all to find chunks of English text that have
embedded bits of French, Spanish, or what-have-you, but that's not an
argument for trying to intermix the stemmers.  I doubt that such simple
bits of program could tell the language difference well enough to
determine which stemming rules to apply.



While I imagine that is probably true of many, if not most, my project
in particular would greatly benefit from the ability to mix stemmers.
I work with complex bibliographic data, which has language information
embedded within records.  This is not limited to the record level
either.  Individual fields within each bibliographic record can be in
different langauges.

Especially in countries where making software multi-lingual (such as
Canada (en_CA/fr_CA)) is a requirement for use in public institutions,
the ability to choose a stemmer and stop-word list at will for any
particular record will actually provide the exact behavior needed.
The obvious generalization from Canada would be to support any mix of
languages supported by tsearch2.

I can certainly understand the benefit of making the default
configuration a simple locale to language map, but there are
definitely uses for searching using different stemmers/stop-lists even
within the same corpus/index.  So, as a datapoint for the discussion,
I would ask that the option of multiple languages per DB locale not be
removed if it can be at all avoided.

Thanks for listening (and for all the great work on getting tsearch
into core! :) ...

--
Mike Rylander

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate

Re: [HACKERS] msvc and vista fun

[Andrew Dunstan]

Dave Page wrote:

Dave Page wrote:
I'm going to run on my Win2K3 animal in a minute - that one runs VC++ 
Express, unlike Baiji and Skylark which I believe are both 'proper' 
Visual Studio. Will report back when it's done.


Yep, it failed at make as well, and reported it appropriately to the BF.




Well, that's *very* curious. I have seen this on more than one machine.

I'll run the test Magnus suggests and see what we can discover.

cheers

andrew

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [HACKERS] Frustrating issue with PGXS

[Magnus Hagander]

On Mon, Jun 25, 2007 at 11:42:28PM +1200, Eddie Stanley wrote:
> Hi, 
> 
> I spent the best part of the day trying to work this out - I was working on a
> system setup with PG 8.2, and wanted to work with 8.3 for development.
> 
> I installed as follows:
> 
> 1. CVS checkout
> 2. ./configure prefix=~/install_dir
> 3. gmake prefix=~/install_dir
> 4. gmake install prefix=~/install_dir
> 
> Got a datastore up and running with initdb; created some test tables, 
> everything
> seemed to be fine. 
> 
> The problem came when I wanted to build a simple C function - I used the
> following makefile: 
> 
> MODULES = example
> PGXS := $(shell ~/install_dir/bin/pg_config --pgxs)
> include $(PGXS)
> 
> The program compiled fine, however I noticed the compilation was refering to
> files in /usr/pkg (from the 8.2 installation). I would have thought specifing
> the version of pg_config from the 8.3 installation would be sufficent, but it
> wasn't. 
> 
> In /lib/postgresql/pgxs/src/Makefile.global, I needed to change
> 
> PG_CONFIG = pg_config
> to
> PG_CONFIG = ~/install_dir/bin/pg_config
> 
> Could this have been avoided if the Makefile.global had
> PG_CONFIG = $(prefix)/bin/pg_config
> ?

I was actually about to post on this just a couple of days ago - it seems
pgxs really needs pg_config to be in your PATH. The quick fix would be for
you to run

PATH=~/install_dir/bin/:$PATH make

That'll make sure your local pg_config gets picked up instaed. That's what
I ended up donig. It's just a workaround, but it's one that works :-)

//Magnus


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

[HACKERS] Frustrating issue with PGXS

[Eddie Stanley]

Hi, 

I spent the best part of the day trying to work this out - I was working on a
system setup with PG 8.2, and wanted to work with 8.3 for development.

I installed as follows:

1. CVS checkout
2. ./configure prefix=~/install_dir
3. gmake prefix=~/install_dir
4. gmake install prefix=~/install_dir

Got a datastore up and running with initdb; created some test tables, everything
seemed to be fine. 

The problem came when I wanted to build a simple C function - I used the
following makefile: 

MODULES = example
PGXS := $(shell ~/install_dir/bin/pg_config --pgxs)
include $(PGXS)

The program compiled fine, however I noticed the compilation was refering to
files in /usr/pkg (from the 8.2 installation). I would have thought specifing
the version of pg_config from the 8.3 installation would be sufficent, but it
wasn't. 

In /lib/postgresql/pgxs/src/Makefile.global, I needed to change

PG_CONFIG = pg_config
to
PG_CONFIG = ~/install_dir/bin/pg_config

Could this have been avoided if the Makefile.global had
PG_CONFIG = $(prefix)/bin/pg_config
?


Eddie


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

[HACKERS] New Zealand - TZ change

[Zdenek Kotala]

I would like to inform, that New Zealand changed DST rules and new 
timezone files are available.  See 
http://www.dia.govt.nz/diawebsite.nsf/wpg_URL/Services-Daylight-Saving-Daylight-saving-to-be-extended


Patch for head attached. I kept zic.c untouched, but I think it would be 
nice to update it as well.


Are there any updated release scheduled 8.0-8.2?


Zdenek

? tz.diff
Index: src/timezone/data/africa
===
RCS file: /projects/cvsroot/pgsql/src/timezone/data/africa,v
retrieving revision 1.5
diff -c -r1.5 africa
*** src/timezone/data/africa	19 Apr 2007 22:44:32 -	1.5
--- src/timezone/data/africa	25 Jun 2007 10:26:50 -
***
*** 1,4 
! # @(#)africa	8.7
  # 
  
  # This data is by no means authoritative; if you think you know better,
--- 1,4 
! # @(#)africa	8.8
  # 
  
  # This data is by no means authoritative; if you think you know better,
***
*** 416,421 
--- 416,435 
  # Namibia
  # The 1994-04-03 transition is from Shanks & Pottenger.
  # Shanks & Pottenger report no DST after 1998-04; go with IATA.
+ 
+ # From Petronella Sibeene (2007-03-30) in
+ # :
+ # While the entire country changes its time, Katima Mulilo and other
+ # settlements in Caprivi unofficially will not because the sun there
+ # rises and sets earlier compared to other regions.  Chief of
+ # Forecasting Riaan van Zyl explained that the far eastern parts of
+ # the country are close to 40 minutes earlier in sunrise than the rest
+ # of the country.
+ # 
+ # From Paul Eggert (2007-03-31):
+ # Apparently the Caprivi Strip informally observes Botswana time, but
+ # we have no details.  In the meantime people there can use Africa/Gaborone.
+ 
  # RULE	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
  Rule	Namibia	1994	max	-	Sep	Sun>=1	2:00	1:00	S
  Rule	Namibia	1995	max	-	Apr	Sun>=1	2:00	0	-
Index: src/timezone/data/australasia
===
RCS file: /projects/cvsroot/pgsql/src/timezone/data/australasia,v
retrieving revision 1.5
diff -c -r1.5 australasia
*** src/timezone/data/australasia	19 Apr 2007 22:44:32 -	1.5
--- src/timezone/data/australasia	25 Jun 2007 10:26:51 -
***
*** 1,4 
! # @(#)australasia	8.6
  # 
  
  # This file also includes Pacific islands.
--- 1,4 
! # @(#)australasia	8.7
  # 
  
  # This file also includes Pacific islands.
***
*** 348,357 
  Rule	Chatham	1976	1989	-	Mar	Sun>=1	2:45s	0	S
  Rule	NZ	1989	only	-	Oct	Sun>=8	2:00s	1:00	D
  Rule	Chatham	1989	only	-	Oct	Sun>=8	2:45s	1:00	D
! Rule	NZ	1990	max	-	Oct	Sun>=1	2:00s	1:00	D
! Rule	Chatham	1990	max	-	Oct	Sun>=1	2:45s	1:00	D
! Rule	NZ	1990	max	-	Mar	Sun>=15	2:00s	0	S
! Rule	Chatham	1990	max	-	Mar	Sun>=15	2:45s	0	S
  # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
  Zone Pacific/Auckland	11:39:04 -	LMT	1868 Nov  2
  			11:30	NZ	NZ%sT	1946 Jan  1
--- 348,361 
  Rule	Chatham	1976	1989	-	Mar	Sun>=1	2:45s	0	S
  Rule	NZ	1989	only	-	Oct	Sun>=8	2:00s	1:00	D
  Rule	Chatham	1989	only	-	Oct	Sun>=8	2:45s	1:00	D
! Rule	NZ	1990	2006	-	Oct	Sun>=1	2:00s	1:00	D
! Rule	Chatham	1990	2006	-	Oct	Sun>=1	2:45s	1:00	D
! Rule	NZ	1990	2007	-	Mar	Sun>=15	2:00s	0	S
! Rule	Chatham	1990	2007	-	Mar	Sun>=15	2:45s	0	S
! Rule	NZ	2007	max	-	Sep	lastSun	2:00s	1:00	D
! Rule	Chatham	2007	max	-	Sep	lastSun	2:45s	1:00	D
! Rule	NZ	2008	max	-	Apr	Sun>=1	2:00s	0	S
! Rule	Chatham	2008	max	-	Apr	Sun>=1	2:45s	0	S
  # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
  Zone Pacific/Auckland	11:39:04 -	LMT	1868 Nov  2
  			11:30	NZ	NZ%sT	1946 Jan  1
***
*** 1146,1151 
--- 1150,1161 
  # transitions at 2:45 local standard time; this confirms that Chatham
  # is always exactly 45 minutes ahead of Auckland.
  
+ # From Colin Sharples (2007-04-30):
+ # DST will now start on the last Sunday in September, and end on the
+ # first Sunday in April.  The changes take effect this year, meaning
+ # that DST will begin on 2007-09-30 2008-04-06.
+ # http://www.dia.govt.nz/diawebsite.nsf/wpg_URL/Services-Daylight-Saving-Daylight-saving-to-be-extended
+ 
  ###
  
  
Index: src/timezone/data/northamerica
===
RCS file: /projects/cvsroot/pgsql/src/timezone/data/northamerica,v
retrieving revision 1.7
diff -c -r1.7 northamerica
*** src/timezone/data/northamerica	19 Apr 2007 22:44:32 -	1.7
--- src/timezone/data/northamerica	25 Jun 2007 10:26:54 -
***
*** 1,4 
! # @(#)northamerica	8.16
  # 
  
  # also includes Central America and the Caribbean
--- 1,4 
! # @(#)northamerica	8.17
  # 
  
  # also includes Central America and the Caribbean
***
*** 2325,2330 
--- 2325,2333 
  #
  # The reason seems to be an energy crisis.
  
+ # From Stephen Colebourne (2007-02-22):
+ # Some IATA info: Hai

Re: [HACKERS] msvc and vista fun

[Dave Page]

Dave Page wrote:
I'm going to run on my Win2K3 
animal in a minute - that one runs VC++ Express, unlike Baiji and 
Skylark which I believe are both 'proper' Visual Studio. Will report 
back when it's done.


Yep, it failed at make as well, and reported it appropriately to the BF.

Regards, Dave

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] msvc and vista fun

[Dave Page]

Magnus Hagander wrote:

Running the same test from the buildfarm script on the same machine, and it
picks up the error and reports it just fine.
(http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylark&dt=2007-06-25%2008:28:31)


I ran on Baiji (renaming the zlib directory, instead of the .lib as 
Magnus did) and see a error as well: 
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=baiji&dt=2007-06-25%2008:36:47


Just for kicks, that was also on Vista. I'm going to run on my Win2K3 
animal in a minute - that one runs VC++ Express, unlike Baiji and 
Skylark which I believe are both 'proper' Visual Studio. Will report 
back when it's done.


Regards, Dave

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] msvc and vista fun

[Magnus Hagander]

On Sun, Jun 24, 2007 at 08:24:43PM -0400, Andrew Dunstan wrote:
> 
> 
> Magnus Hagander wrote:
> >Andrew Dunstan wrote:
> >  
> >>I am still very unhappy about the way the MSVC builds work. Although we
> >>have managed to make it sort of work with the buildfarm script, it is
> >>distinctly fragile. Last night, for example, I had a build failure due
> >>to a badly installed zlib. The error state didn't come back to the
> >>buildfarm script, which carried on merrily to the check stage, which
> >>also naturally failed, but also didn't manage to give back an error
> >>
> >
> >I've heard you report this before, and I've tried and failed many times
> >to reproduce it. It has *always* come back with the proper errorlevel
> >when I've tried. So two questions:
> >
> >1) are you absolutely sure that the problem is not in the buildfarm script?
> >  
> 
> Pretty damn sure, yes. This code has functioned correctly on the 
> buildfarm on every other platform since its inception.

I think you are overestimating the cross-platformness of perl...  :-)


> >2) What exactly was the error? So I can try to reproduce that exact
> >problem here and see if I can find out what it is. What did you do
> >wrong, and what was the error messages if you still have the log.
> >  
> 
> I did indeed keep the logs.
> 
> Steps to reproduce: rename your zdll.lib and then run the buildfarm script.

Ok.

Running this *outside* the buildfarm properly sets errorlevel=1 when it
exits.

Running the same test from the buildfarm script on the same machine, and it
picks up the error and reports it just fine.
(http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylark&dt=2007-06-25%2008:28:31)

Since nobody else (AFAIK) has seen this, I'd be inclined to blame something
in your environment. 

Can you run the build in "broken mode" but *without* using the buildfarm
scripts, and see what errorlevel you get? Meaning:
build.bat
... wait ...
echo %errorlevel%

It should output 1 if that part works, 0 if it fails. That'll tell us if
the problem is in the bf or if it's in the actual build system.



> >>Part of the problem, it seems to me, is that this build system is a
> >>hodge-podge of Perl programs and Windows shell scripts. In at least one
> >>case we call perl to write a dynamically generated .bat file which we
> >>then execute. 
> >>
> >
> >Which one is that? I can't find it. A simple findstr through all the
> >perl files appears to contain nothing of the sort.
> >  
> 
> perl ../../src/tools/msvc/getregress.pl > regress.tmp.bat
> call regress.tmp.bat
> del regress.tmp.bat

Ah. I was looking at the build parts only, not the regress part. My bad.

Anyway, yes, the vcregress.bat file was the only one on the list that made
sense to consider redoing in perl.


> >>Since the perl is pretty much indispensable (or at least
> >>would need replacing by an engine of similar capability), I think we
> >>should make the whole thing a perl suite with some very minimal .bat
> >>wrappers if necessary.
> >>
> >
> >That's mostly how it is now, no? What are you referring to specifically?
> >
> >The only longer ones I can see are:
> >
> >builddoc.bat - could certainly be put into perl stuff, but it's not
> >involved in the buildfarm process, so...
> >
> >clean.bat - doesn't really matter, IMO, and again not involved in the
> >buildfarm process
> >
> >vcregress.bat - sure, it could be made perl, but right now you can
> >actually run the regression tests on an installed system without having
> >perl at all... But that's not really a requirement, so we could change
> >that one.
> >  
> 
> perl2exe ?

No way, that's just too ugly :-) Since you basically ship perl packaged
inside the exe anyway, we might as well accept the requirement of perl to
run the regression tests. Actually, ´given the above we *already* require
perl for the regression tests, I had forgotten about that part.

> 
> >The rest are just thin wrappers.
> >  
> 
> Well, my .bat-fu was last in use around DOS6.2, so I'm not mucjh help 
> with them :-)  I don't think they're really thin enough. Why not just 
> have them call "perl scriptname args"?

I guess you could. The point of the split in build.bat today is basically
that you run mkvcbuild separately if you want to work from the GUI. But
that could of course be dealt with with commandline parameters if there's
really a benefit in it. But I'm not sure there is - there's very little
logic in the bat files, and that's what matters IMO.


> >Speaking of wrappers, are you planning to make the buildfarm use the
> >modules instead of the perlscripts? IIRC, I made those modules
> >specifically for the bf - and it should make it even easier to pick up
> >the errors from there.
> >
> >
> 
> Yes, you did. But as I think I told you, I had a rethink about that. The 
> whole point about the buildfarm is to do things as closely to what a 
> human would do as possible, so I don't want to make it use the perl 
> modules like that unless we really really have to. I also 

Re: [HACKERS] Winner of naming discussions: Synchronous Commit

[Zeugswetter Andreas ADI SD]

> synchronous_commit
> Idea: Greg Stark
> Supporters: Simon, Josh, Tom, Bruce, Florian

There was one more:
asynchronous_commit
Idea: Florian G. Pflug
Supporters: none

But if you are calling the feature that (which imho is good), the guc
might as well get that name.

Andreas

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Winner of naming discussions: Synchronous Commit

[Dave Page]

Simon Riggs wrote:

So, although its a knife edge decision, I'd say go with
synchronous_commit = off. 


I agree - I'm not entirely sure why but it just feels more natural than 
asynchronous_commit = on. Plus the reasons you give seem valid.


Regards, Dave


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] msvc and vista fun

[Dave Page]

Dave Page wrote:

If I then
switch to the non-admin user, it can run initdb just fine. However, 
that user can't build, because it gets a mysterious failure from 
mt.exe. MinGW is even worse - it says it can't run gcc because it 
can't run cc1.exe (IIRC), so it fails at the configure stage! All of 
this has cost me quite a few hours in the last week, with very little 
to show for it.


And that one...


See http://aarongiles.com/?p=199 for more details, but the quick fix I 
used was to add /mingw/libexec/gcc/mingw32/3.4.2 to the path in 
/etc/profile.


Regards, Dave

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate

Re: [HACKERS] Winner of naming discussions: Synchronous Commit

[Simon Riggs]

On Mon, 2007-06-25 at 10:01 +0200, Zeugswetter Andreas ADI SD wrote:
> > synchronous_commit
> > Idea: Greg Stark
> > Supporters: Simon, Josh, Tom, Bruce, Florian
> 
> There was one more:
> asynchronous_commit
> Idea: Florian G. Pflug
> Supporters: none
> 
> But if you are calling the feature that (which imho is good), the guc
> might as well get that name.

Hmmm, so we have a choice of:

synchronous_commit = off
asynchronous_commit = on

For the latter, postgresql.conf would default to 
asynchronous_commit = off. 

Personally, I think the double negative is confusing for the normal
case. For me, the feature is turning off something that we normally
have, rather than actively initiating anything.

The feature is related to fsync = off, so it would be confusing to have
the switches work in opposite directions. Now I look, I see this would
make it the only parameter that turning it on removes something. All
other parameters are positive, e.g. enable_X = on

So, although its a knife edge decision, I'd say go with
synchronous_commit = off. 

-- 
  Simon Riggs 
  EnterpriseDB   http://www.enterprisedb.com



---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] msvc and vista fun

[Dave Page]

Andrew Dunstan wrote:



Dave Page wrote:


Perhaps someone would like to tell me how I can remedy these 
problems. More importantly, this should be in an FAQ or some such. 
Also, I would like to know if we have really tested out on Vista the 
privilege surrendering code that is is supposed to work in Windows. 
It looks to me like it might not be working.


What makes you say that?



It was just a suspicion, but maybe the fact that the admin user can't 
run while the non-admin user can indicates that it is working (possibly 
too well).


Hmm, yes - I see what you mean. How are you defining 'admin user'? When 
I ran into this problem from what I recall I was originally trying to 
swim against the Vista security model by using the Administrator account 
 which is disabled by default (for anyone still doubting that from the 
last discussion on the topic, please see 
http://blogs.msdn.com/windowsvistasecurity/archive/2006/08/27/windowsvistasecurity-.aspx). 
It went away when I started using my own user account which is not 'the' 
administrator, but is a member of the administrators group.


I am not only concerned about the buildfarm, but about the robustness, 
maintainability and simplicity of the build process. Having to have a 
completely separate build system for msvc is really quite sucky.


Well, yes, but unfortunately there's not really any other way to get a 
halfway decent development environment on Windows. Mingw/Msys are 
horrendously maintained - mingw still doesn't work without hacking on 
Vista as you've found, and msys doesn't work at all on 64 bit versions 
for example (at least it didn't the last few times I tried - it's 
possible they've fixed it now). The debugger doesn't work for most 
people, and the development environment is just plain nasty to keep up 
to date.


Now 99.99% of users don't build on Windows anyway, so I'm not so much 
concerned about their ability to maintain and use the build environment 
as ours - if that means we have to fix a few bugs in the MSVC scripts 
during the dev cycle, so be it. The setup I'm using now for 8.3 is 
already orders of magnitude easier to setup and maintain than the 
mingw/msys environment, plus we have a decent debugger (and other tools) 
now, and the ability to run on 64 bit platforms, not to mention a 
compiler with which we can (eventually) build for them as well.


Regards, Dave

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

Re: [HACKERS] msvc and vista fun

[Zeugswetter Andreas ADI SD]

> user) . I can build as the admin user but when I come to run 
> initdb it fails, complaining that it can't find the postgres 
> executable.

FYI, this happens on my Win 2000 also.
Maybe a problem with mixed / \ path separators after RestrictExec.

Andreas

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match