Commit Graph

30783 Commits

Author SHA1 Message Date
Alvaro Herrera
247fd8105a Mention DROP TABLE as well as ALTER TABLE NO INHERIT
... when talking about how good they are in replacement of bulk DELETE
in partitioned setups.

The original wording was a bit confusing.

Per an observation from David Wheeler.
2011-06-14 11:20:52 -04:00
Alvaro Herrera
a03f1d399d Fix aboriginal copy-paste mistake in error message
Spotted by Jaime Casanova
2011-06-13 17:54:36 -04:00
Alvaro Herrera
2602e63750 Expand warnings on locks acquired by CREATE INDEX CONCURRENTLY
The previous wording wasn't explicit enough, which could misled readers
into thinking that the locks acquired are more restricted in nature than
they really are.  The resulting optimism can be damaging to morale when
confronted with reality, as has been observed in the field.

Greg Smith
2011-06-13 17:21:15 -04:00
Robert Haas
6350d75bf2 Remove parentheses from mention of current_schemas function.
This is more consistent with what we do elsewhere, and hopefully avoids
creating the perception that current_schemas takes no arguments.

As suggested by Brendan Jurd
2011-06-13 13:04:13 -04:00
Robert Haas
c06bdaf92c Add doc cross-reference to search_path discussion of current_schemas().
Brendan Jurd
2011-06-13 12:38:47 -04:00
Tom Lane
45d792f702 Work around gcc 4.6.0 bug that breaks WAL replay.
ReadRecord's habit of using both direct references to tmpRecPtr and
references to *RecPtr (which is pointing at tmpRecPtr) triggers an
optimization bug in gcc 4.6.0, which apparently has forgotten about
aliasing rules.  Avoid the compiler bug, and make the code more readable
to boot, by getting rid of the direct references.  Improve the comments
while at it.

Back-patch to all supported versions, in case they get built with 4.6.0.

Tom Lane, with some cosmetic suggestions from Alex Hunsaker
2011-06-10 17:03:11 -04:00
Magnus Hagander
cdd08887b9 Use the correct eventlog severity for error 2011-06-09 18:26:29 +02:00
Magnus Hagander
15fe829b23 Support silent mode for service registrations on win32
Using -s when registering a service will now suppress
the application eventlog entries stating that the service
is starting and started.

MauMau
2011-06-09 18:26:25 +02:00
Peter Eisentraut
ffa653b945 Fix documentation of information_schema.element_types
The documentation of the columns collection_type_identifier and
dtd_identifier was wrong.  This effectively reverts commits
8e1ccad519 and
57352df66d and updates the name
array_type_identifier (the name in SQL:1999) to
collection_type_identifier.

closes bug #5926
2011-06-09 07:27:51 +03:00
Andrew Dunstan
cb252c2acd Allow building with perl 5.14.
Patch from Alex Hunsaker.
2011-06-04 19:35:04 -04:00
Peter Eisentraut
39dbc62ade Fix documentation reference to "above" example
found by Thom Brown
2011-06-04 23:13:28 +03:00
Peter Eisentraut
ec688fd346 More ECPG documentation fixes
Marc Cousin
2011-06-04 22:52:25 +03:00
Peter Eisentraut
843c280626 ECPG documentation fix
Marc Cousin, Satoshi Nagayasu
2011-06-04 22:52:25 +03:00
Tom Lane
ab1aaf3d22 Expose the "*VALUES*" alias that we generate for a stand-alone VALUES list.
We were trying to make that strictly an internal implementation detail,
but it turns out that it's exposed anyway when dumping a view defined
like
	CREATE VIEW test_view AS VALUES (1), (2), (3) ORDER BY 1;
This comes out as
	CREATE VIEW ... ORDER BY "*VALUES*".column1;
which fails to parse when reloading the dump.

Hacking ruleutils.c to suppress the column qualification looks like it'd
be a risky business, so instead promote the RTE alias to full-fledged
usability.

Per bug #6049 from Dylan Adams.  Back-patch to all supported branches.
2011-06-04 15:48:25 -04:00
Tom Lane
bc0550f994 Clean up after erroneous SELECT FOR UPDATE/SHARE on a sequence.
My previous commit disallowed this operation, but did nothing about
cleaning up the damage if one had already been done.  With the operation
disallowed, it's okay to just forcibly clear xmax in a sequence's tuple,
since any value seen there could not represent a live transaction's lock.
So, any sequence-specific operation will repair the problem automatically,
whether or not the user has already seen "could not access status of
transaction" failures.
2011-06-02 15:31:02 -04:00
Tom Lane
c117838597 Disallow SELECT FOR UPDATE/SHARE on sequences.
We can't allow this because such an operation stores its transaction XID
into the sequence tuple's xmax.  Because VACUUM doesn't process sequences
(and we don't want it to start doing so), such an xmax value won't get
frozen, meaning it will eventually refer to nonexistent pg_clog storage,
and even wrap around completely.  Since the row lock is ignored by nextval
and setval, the usefulness of the operation is highly debatable anyway.
Per reports of trouble with pgpool 3.0, which had ill-advisedly started
using such commands as a form of locking.

In HEAD, also disallow SELECT FOR UPDATE/SHARE on toast tables.  Although
this does work safely given the current implementation, there seems no
good reason to allow it.  I refrained from changing that behavior in
back branches, however.
2011-06-02 14:46:22 -04:00
Tom Lane
b26d8fda65 Protect GIST logic that assumes penalty values can't be negative.
Apparently sane-looking penalty code might return small negative values,
for example because of roundoff error.  This will confuse places like
gistchoose().  Prevent problems by clamping negative penalty values to
zero.  (Just to be really sure, I also made it force NaNs to zero.)
Back-patch to all supported branches.

Alexander Korotkov
2011-05-31 17:53:55 -04:00
Tom Lane
e73bd1e343 Fix portability bugs in use of credentials control messages for peer auth.
Even though our existing code for handling credentials control messages has
been basically unchanged since 2001, it was fundamentally wrong: it did not
ensure proper alignment of the supplied buffer, and it was calculating
buffer sizes and message sizes incorrectly.  This led to failures on
platforms where alignment padding is relevant, for instance FreeBSD on
64-bit platforms, as seen in a recent Debian bug report passed on by
Martin Pitt (http://bugs.debian.org//cgi-bin/bugreport.cgi?bug=612888).

Rewrite to do the message-whacking using the macros specified in RFC 2292,
following a suggestion from Theo de Raadt in that thread.  Tested by me
on Debian/kFreeBSD-amd64; since OpenBSD and NetBSD document the identical
CMSG API, it should work there too.

Back-patch to all supported branches.
2011-05-30 19:16:11 -04:00
Tom Lane
73bd34c81e Fix VACUUM so that it always updates pg_class.reltuples/relpages.
When we added the ability for vacuum to skip heap pages by consulting the
visibility map, we made it just not update the reltuples/relpages
statistics if it skipped any pages.  But this could leave us with extremely
out-of-date stats for a table that contains any unchanging areas,
especially for TOAST tables which never get processed by ANALYZE.  In
particular this could result in autovacuum making poor decisions about when
to process the table, as in recent report from Florian Helmberger.  And in
general it's a bad idea to not update the stats at all.  Instead, use the
previous values of reltuples/relpages as an estimate of the tuple density
in unvisited pages.  This approach results in a "moving average" estimate
of reltuples, which should converge to the correct value over multiple
VACUUM and ANALYZE cycles even when individual measurements aren't very
good.

This new method for updating reltuples is used by both VACUUM and ANALYZE,
with the result that we no longer need the grotty interconnections that
caused ANALYZE to not update the stats depending on what had happened
in the parent VACUUM command.

Also, fix the logic for skipping all-visible pages during VACUUM so that it
looks ahead rather than behind to decide what to do, as per a suggestion
from Greg Stark.  This eliminates useless scanning of all-visible pages at
the start of the relation or just after a not-all-visible page.  In
particular, the first few pages of the relation will not be invariably
included in the scanned pages, which seems to help in not overweighting
them in the reltuples estimate.

Back-patch to 8.4, where the visibility map was introduced.
2011-05-30 17:07:07 -04:00
Tom Lane
ab7c5a9082 Fix null-dereference crash in parse_xml_decl().
parse_xml_decl's header comment says you can pass NULL for any unwanted
output parameter, but it failed to honor this contract for the "standalone"
flag.  The only currently-affected caller is xml_recv, so the net effect is
that sending a binary XML value containing a standalone parameter in its
xml declaration would crash the backend.  Per bug #6044 from Christopher
Dillard.

In passing, remove useless initializations of parse_xml_decl's output
parameters in xml_parse.

Back-patch to 8.3, where this code was introduced.
2011-05-28 12:36:30 -04:00
Tom Lane
722548e430 Preserve caller's memory context in ProcessCompletedNotifies().
This is necessary to avoid long-term memory leakage, because the main loop
in PostgresMain expects to be executing in MessageContext, and hence is a
bit sloppy about freeing stuff that is only needed for the duration of
processing the current client message.  The known case of an actual leak
is when encoding conversion has to be done on the incoming command string,
but there might be others.  Per report from Per-Olov Esgard.

Back-patch to 9.0, where the bug was introduced by the LISTEN/NOTIFY
rewrite.
2011-05-27 12:10:58 -04:00
Tom Lane
0bd7305ffb Make decompilation of optimized CASE constructs more robust.
We had some hacks in ruleutils.c to cope with various odd transformations
that the optimizer could do on a CASE foo WHEN "CaseTestExpr = RHS" clause.
However, the fundamental impossibility of covering all cases was exposed
by Heikki, who pointed out that the "=" operator could get replaced by an
inlined SQL function, which could contain nearly anything at all.  So give
up on the hacks and just print the expression as-is if we fail to recognize
it as "CaseTestExpr = RHS".  (We must cover that case so that decompiled
rules print correctly; but we are not under any obligation to make EXPLAIN
output be 100% valid SQL in all cases, and already could not do so in some
other cases.)  This approach requires that we have some printable
representation of the CaseTestExpr node type; I used "CASE_TEST_EXPR".

Back-patch to all supported branches, since the problem case fails in all.
2011-05-26 19:25:36 -04:00
Tom Lane
c2a366d9d9 Avoid uninitialized bits in the result of QTN2QT().
Found with additional valgrind testing.

Noah Misch
2011-05-24 14:20:57 -04:00
Tom Lane
e48433e9f8 Lobotomize typmod check in convert_tuples_by_position, back branches only.
convert_tuples_by_position was rejecting attempts to coerce a record field
with -1 typmod to the same type with a non-default typmod.  This is in fact
the "correct" thing to do (since we're just going to do a type relabeling,
not invoke any length-conversion cast function); but it results in
rejecting valid cases like bug #6020, because the source record's tupdesc
is built from Params that don't have typmod assigned.  Since that's a
regression from previous versions, which accepted this code, we have to do
something about it.  In HEAD, I've fixed the problem properly by causing
the Params to receive the correct typmods; but the potential for incidental
behavioral changes seems high enough to make it unattractive to make the
same change in released branches.  (And it couldn't be fixed that way in
8.4 anyway...)  Hence this patch just modifies convert_tuples_by_position
to not complain if either the input or the output tupdesc has typmod -1.
This is still a shade tighter checking than we did before 9.0, since before
that plpgsql failed to consider typmods at all when checking record
compatibility.  (convert_tuples_by_position is currently used only by
plpgsql, so we're not affecting other behavior.)

Back-patch to 8.4, since we recently back-ported convert_tuples_by_position
into that branch.
2011-05-23 14:42:18 -04:00
Heikki Linnakangas
7541d32e86 Replace strdup() with pstrdup(), to avoid leaking memory.
It's been like this since the seg module was introduced, so backpatch to
8.2 which is the oldest supported version.
2011-05-23 20:59:06 +03:00
Tom Lane
168174c445 Install defenses against overflow in BuildTupleHashTable().
The planner can sometimes compute very large values for numGroups, and in
cases where we have no alternative to building a hashtable, such a value
will get fed directly to BuildTupleHashTable as its nbuckets parameter.
There were two ways in which that could go bad.  First, BuildTupleHashTable
declared the parameter as "int" but most callers were passing "long"s,
so on 64-bit machines undetected overflow could occur leading to a bogus
negative value.  The obvious fix for that is to change the parameter to
"long", which is what I've done in HEAD.  In the back branches that seems a
bit risky, though, since third-party code might be calling this function.
So for them, just put in a kluge to treat negative inputs as INT_MAX.
Second, hash_create can go nuts with extremely large requested table sizes
(notably, my_log2 becomes an infinite loop for inputs larger than
LONG_MAX/2).  What seems most appropriate to avoid that is to bound the
initial table size request to work_mem.

This fixes bug #6035 reported by Daniel Schreiber.  Although the reported
case only occurs back to 8.4 since it involves WITH RECURSIVE, I think
it's a good idea to install the defenses in all supported branches.
2011-05-23 12:52:51 -04:00
Tom Lane
30cf86fdf4 Fix write-past-buffer-end in ldapServiceLookup().
The code to assemble ldap_get_values_len's output into a single string
wrote the terminating null one byte past where it should.  Fix that,
and make some other cosmetic adjustments to make the code a trifle more
readable and more in line with usual Postgres coding style.

Also, free the "result" string when done with it, to avoid a permanent
memory leak.

Bug report and patch by Albe Laurenz, cosmetic adjustments by me.
2011-05-12 11:57:05 -04:00
Heikki Linnakangas
fbc56f706c Shut down WAL receiver if it's still running at end of recovery. We used to
just check that it's not running and PANIC if it was, but that can rightfully
happen if recovery stops at recovery target.
2011-05-11 14:35:38 +03:00
Bruce Momjian
f71b5c77fa Update documentation to state there is three-value logic, not
three-value boolean logic.

Backpatch to 9.0.X since we just got another bug report about this
today.
2011-05-09 21:04:22 -04:00
Tom Lane
65a7cd0e9c Fix pull_up_sublinks' failure to handle nested pull-up opportunities.
After finding an EXISTS or ANY sub-select that can be converted to a
semi-join or anti-join, we should recurse into the body of the sub-select.
This allows cases such as EXISTS-within-EXISTS to be optimized properly.
The original coding would leave the lower sub-select as a SubLink, which
is no better and often worse than what we can do with a join.  Per example
from Wayne Conrad.

Back-patch to 8.4.  There is a related issue in older versions' handling
of pull_up_IN_clauses, but they're lame enough anyway about the whole area
that it seems not worth the extra work to try to fix.
2011-05-02 15:56:43 -04:00
Peter Eisentraut
e79518e937 Add missing gitignore file 2011-05-02 01:03:38 +03:00
Peter Eisentraut
c8c93c6e73 Catch errors in for loop in makefile
Add "|| exit" so that the rule aborts when a command fails.

This is the minimal backpatch version.  The fix in head is more
elaborate.
2011-05-02 01:03:38 +03:00
Tom Lane
fb69fd176a Make CLUSTER lock the old table's toast table before copying data.
We must lock out autovacuuming of the old toast table before computing the
OldestXmin horizon we will use.  Otherwise, autovacuum could start on the
toast table later, compute a later OldestXmin horizon, and remove as DEAD
toast tuples that we still need (because we think their parent tuples are
only RECENTLY_DEAD).  Per further thought about bug #5998.
2011-05-01 17:57:40 -04:00
Tom Lane
007a6e53ac Remove special case for xmin == xmax in HeapTupleSatisfiesVacuum().
VACUUM was willing to remove a committed-dead tuple immediately if it was
deleted by the same transaction that inserted it.  The idea is that such a
tuple could never have been visible to any other transaction, so we don't
need to keep it around to satisfy MVCC snapshots.  However, there was
already an exception for tuples that are part of an update chain, and this
exception created a problem: we might remove TOAST tuples (which are never
part of an update chain) while their parent tuple stayed around (if it was
part of an update chain).  This didn't pose a problem for most things,
since the parent tuple is indeed dead: no snapshot will ever consider it
visible.  But MVCC-safe CLUSTER had a problem, since it will try to copy
RECENTLY_DEAD tuples to the new table.  It then has to copy their TOAST
data too, and would fail if VACUUM had already removed the toast tuples.

Easiest fix is to get rid of the special case for xmin == xmax.  This may
delay reclaiming dead space for a little bit in some cases, but it's by far
the most reliable way to fix the issue.

Per bug #5998 from Mark Reid.  Back-patch to 8.3, which is the oldest
version with MVCC-safe CLUSTER.
2011-04-29 16:29:51 -04:00
Tom Lane
cb0bcf45cb Rewrite pg_size_pretty() to avoid compiler bug.
Convert it to use successive shifts right instead of increasing a divisor.
This is probably a tad more efficient than the original coding, and it's
nicer-looking than the previous patch because we don't need a special case
to avoid overflow in the last branch.  But the real reason to do it is to
avoid a Solaris compiler bug, as per results from buildfarm member moa.
2011-04-29 01:45:02 -04:00
Heikki Linnakangas
c02bc6356f The arguments to pg_ctl kill are not optional - remove brackets in the docs.
Fujii Masao
2011-04-28 12:57:51 +03:00
Tom Lane
db3cf25293 Add comments about the need to avoid uninitialized bits in datatype values.
There was already one recommendation in the documentation about writing
C functions to ensure padding bytes are zeroes, but make it stronger.

Also fix an example that was still using direct assignment to a varlena
length word, which no longer works since the varvarlena changes.
2011-04-27 14:06:29 -04:00
Tom Lane
433853e926 Fix array- and path-creating functions to ensure padding bytes are zeroes.
Per recent discussion, it's important for all computed datums (not only the
results of input functions) to not contain any ill-defined (uninitialized)
bits.  Failing to ensure that can result in equal() reporting that
semantically indistinguishable Consts are not equal, which in turn leads to
bizarre and undesirable planner behavior, such as in a recent example from
David Johnston.  We might eventually try to fix this in a general manner by
allowing datatypes to define identity-testing functions, but for now the
path of least resistance is to expect datatypes to force all unused bits
into consistent states.

Per some testing by Noah Misch, array and path functions seem to be the
only ones presenting risks at the moment, so I looked through all the
functions in adt/array*.c and geo_ops.c and fixed them as necessary.  In
the array functions, the easiest/safest fix is to allocate result arrays
with palloc0 instead of palloc.  Possibly in future someone will want to
look into whether we can just zero the padding bytes, but that looks too
complex for a back-patchable fix.  In the path functions, we already had a
precedent in path_in for just zeroing the one known pad field, so duplicate
that code as needed.

Back-patch to all supported branches.
2011-04-27 13:58:44 -04:00
Tom Lane
af9fb26e2d Complain if pg_hba.conf contains "hostssl" but SSL is disabled.
Most commenters agreed that this is more friendly than silently failing
to match the line during actual connection attempts.  Also, this will
prevent corner cases that might arise when trying to handle such a line
when the SSL code isn't turned on.  An example is that specifying
clientcert=1 in such a line would formerly result in a completely
misleading complaint that root.crt wasn't present, as seen in a recent
report from Marc-Andre Laverdiere.  While we could have instead fixed
that specific behavior, it seems likely that we'd have a continuing stream
of such bizarre behaviors if we keep on allowing hostssl lines when SSL is
disabled.

Back-patch to 8.4, where clientcert was introduced.  Earlier versions don't
have this specific issue, and the code is enough different to make this
patch not applicable without more work than it seems worth.
2011-04-26 15:40:14 -04:00
Tom Lane
6ba0d8d5ac Fix pg_size_pretty() to avoid overflow for inputs close to INT64_MAX.
The expression that tried to round the value to the nearest TB could
overflow, leading to bogus output as reported in bug #5993 from Nicola
Cossu.  This isn't likely to ever happen in the intended usage of the
function (if it could, we'd be needing to use a wider datatype instead);
but it's not hard to give the expected output, so let's do so.
2011-04-25 16:22:17 -04:00
Robert Haas
147d6269f3 Fix use of incorrect constant RemoveRoleFromObjectACL.
This could cause failures when DROP OWNED BY attempt to remove default
privileges on sequences.  Back-patching to 9.0.

Shigeru Hanada
2011-04-20 22:26:12 -04:00
Tom Lane
b381b58286 Fix bugs in indexing of in-doubt HOT-updated tuples.
If we find a DELETE_IN_PROGRESS HOT-updated tuple, it is impossible to know
whether to index it or not except by waiting to see if the deleting
transaction commits.  If it doesn't, the tuple might again be LIVE, meaning
we have to index it.  So wait and recheck in that case.

Also, we must not rely on ii_BrokenHotChain to decide that it's possible to
omit tuples from the index.  That could result in omitting tuples that we
need, particularly in view of yesterday's fixes to not necessarily set
indcheckxmin (but it's broken even without that, as per my analysis today).
Since this is just an extremely marginal performance optimization, dropping
the test shouldn't hurt.

These cases are only expected to happen in system catalogs (they're
possible there due to early release of RowExclusiveLock in most
catalog-update code paths).  Since reindexing of a system catalog isn't a
particularly performance-critical operation anyway, there's no real need to
be concerned about possible performance degradation from these changes.

The worst aspects of this bug were introduced in 9.0 --- 8.x will always
wait out a DELETE_IN_PROGRESS tuple.  But I think dropping index entries
on the strength of ii_BrokenHotChain is dangerous even without that, so
back-patch removal of that optimization to 8.3 and 8.4.
2011-04-20 20:34:16 -04:00
Tom Lane
1d6249d64d Set indcheckxmin true when REINDEX fixes an invalid or not-ready index.
Per comment from Greg Stark, it's less clear that HOT chains don't conflict
with the index than it would be for a valid index.  So, let's preserve the
former behavior that indcheckxmin does get set when there are
potentially-broken HOT chains in this case.  This change does not cause any
pg_index update that wouldn't have happened anyway, so we're not
re-introducing the previous bug with pg_index updates, and surely the case
is not significant from a performance standpoint; so let's be as
conservative as possible.
2011-04-20 19:01:25 -04:00
Heikki Linnakangas
8a6d60fd0c Quotes in strings injected into bki file need to escaped. In particular,
"People's Republic of China" locale on Windows was causing initdb to fail.

This fixes bug #5818 reported by yulei. On master, this makes the mapping
of "People's Republic of China" to just "China" obsolete. In 9.0 and 8.4,
just fix the escaping. Earlier versions didn't have locale names in bki
file.
2011-04-20 09:59:46 +03:00
Tom Lane
ebcbc8cfe6 Avoid changing an index's indcheckxmin horizon during REINDEX.
There can never be a need to push the indcheckxmin horizon forward, since
any HOT chains that are actually broken with respect to the index must
pre-date its original creation.  So we can just avoid changing pg_index
altogether during a REINDEX operation.

This offers a cleaner solution than my previous patch for the problem
found a few days ago that we mustn't try to update pg_index while we are
reindexing it.  System catalog indexes will always be created with
indcheckxmin = false during initdb, and with this modified code we should
never try to change their pg_index entries.  This avoids special-casing
system catalogs as the former patch did, and should provide a performance
benefit for many cases where REINDEX formerly caused an index to be
considered unusable for a short time.

Back-patch to 8.3 to cover all versions containing HOT.  Note that this
patch changes the API for index_build(), but I believe it is unlikely that
any add-on code is calling that directly.
2011-04-19 18:51:03 -04:00
Tom Lane
1da9966230 Revert "Prevent incorrect updates of pg_index while reindexing pg_index itself."
This reverts commit a03e3e1fd1 of 2011-04-15.
There's a better way to do it, which will follow shortly.
2011-04-19 16:57:57 -04:00
Heikki Linnakangas
b2e2d3a378 Silence compiler warning about unused variable on Windows. 2011-04-19 14:54:48 +03:00
Tom Lane
a03e3e1fd1 Prevent incorrect updates of pg_index while reindexing pg_index itself.
The places that attempt to change pg_index.indcheckxmin during a reindexing
operation cannot be executed safely if pg_index itself is the subject of
the operation.  This is the explanation for a couple of recent reports of
VACUUM FULL failing with
	ERROR:  duplicate key value violates unique constraint "pg_index_indexrelid_index"
	DETAIL:  Key (indexrelid)=(2678) already exists.

However, there isn't any real need to update indcheckxmin in such a
situation, if we assume that pg_index can never contain a truly broken HOT
chain.  This assumption holds if new indexes are never created on it during
concurrent operations, which is something we don't consider safe for any
system catalog, not just pg_index.  Accordingly, modify the code to not
manipulate indcheckxmin when reindexing any system catalog.

Back-patch to 8.3, where HOT was introduced.  The known failure scenarios
involve 9.0-style VACUUM FULL, so there might not be any real risk before
9.0, but let's not assume that.
2011-04-15 20:19:03 -04:00
Magnus Hagander
c1d4238063 Note that Bison on GnuWin32 has trouble with paths with spaces
Peter Eisentraut
2011-04-15 15:31:41 +02:00
Magnus Hagander
52a6150445 Specify which versions of the Platform SDK are supported
Anything including Visual Studio 2010 compilers is not yet
supported for building on Windows.
2011-04-15 15:31:33 +02:00