On 4/24/2011 1:29 AM, Andrew Dunstan wrote:
The attached patch is intended to clean up a bunch of compiler warnings seen on
Windows due to mismatches of signedness or constness, unused variables,
redefined macros and a missing prototype.
It doesn't clean up all the warnings by any means, but
On 21.04.2011 17:24, Peter Eisentraut wrote:
I would like to collect some specs on this feature. So does anyone have
links to documentation of existing implementations, or their own spec
writeup? A lot of people appear to have a very clear idea of this
concept in their own head, so let's start
On sön, 2011-04-24 at 01:29 -0400, Andrew Dunstan wrote:
One thing I'm a bit confused about is this type of warning:
src\backend\utils\misc\guc-file.c(977): warning C4003: not enough
actual parameters for macro 'GUC_yywrap'
If someone can suggest a good fix That would be nice.
The hunk below looks a bit evil.
At least a comment would be good to explain why this is necessary.
On sön, 2011-04-24 at 01:29 -0400, Andrew Dunstan wrote:
*** a/src/backend/port/win32/socket.c
--- b/src/backend/port/win32/socket.c
***
*** 370,376 pgwin32_recv(SOCKET s,
On 04/24/2011 09:11 AM, Andrew Chernow wrote:
On 4/24/2011 1:29 AM, Andrew Dunstan wrote:
The attached patch is intended to clean up a bunch of compiler
warnings seen on
Windows due to mismatches of signedness or constness, unused variables,
redefined macros and a missing prototype.
It
On 04/24/2011 10:53 AM, Peter Eisentraut wrote:
On sön, 2011-04-24 at 01:29 -0400, Andrew Dunstan wrote:
One thing I'm a bit confused about is this type of warning:
src\backend\utils\misc\guc-file.c(977): warning C4003: not enough
actual parameters for macro 'GUC_yywrap'
If
Peter Eisentraut pete...@gmx.net writes:
The hunk below looks a bit evil.
At least a comment would be good to explain why this is necessary.
Yeah, having to cast away const seems uglier than the original problem.
Can't we avoid that?
BTW, all of my machines as well as the Single Unix Spec are
Andrew Dunstan and...@dunslane.net writes:
The attached patch is intended to clean up a bunch of compiler warnings
seen on Windows due to mismatches of signedness or constness, unused
variables, redefined macros and a missing prototype.
BTW, this hunk:
*** a/src/pl/plpython/plpython.c
---
Hi,
a recent discussion about possible data corruption (in the general list)
suggests that a tool for offline integrity check might be useful.
Something that might be run when the database is shut down, to check
that the data files are OK.
The idea is to read all heap blocks and check for
Hi,
again index access methods, can somebody shed some light into operator
classes for indexes? The documentation is an entry point, but after
reading I still don't have a clue how exactly they are used and created?
Perhaps somebody with great knowledge can supply an 101 on opeartor
classes?
Unlogged tables are a good new feature.
I noticed Bruce had mentioned they were the equivalent of NoSQL, which
I don't really accept. I guess it depends upon whether you mean NoSQL
for caches (e.g. memcached) or NoSQL for useful datastores (e.g.
Mongo). It seems worth discussin now before we get
On 04/24/2011 12:25 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
The attached patch is intended to clean up a bunch of compiler warnings
seen on Windows due to mismatches of signedness or constness, unused
variables, redefined macros and a missing prototype.
BTW, this hunk:
On 04/24/2011 12:14 PM, Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
The hunk below looks a bit evil.
At least a comment would be good to explain why this is necessary.
Yeah, having to cast away const seems uglier than the original problem.
Can't we avoid that?
I'm not sure
On Sun, Apr 24, 2011 at 6:22 PM, Simon Riggs si...@2ndquadrant.com wrote:
My implementation path for that would be to add a crash_number onto
pg_control and pg_index. Any index marked as unlogged, persistent
would only be usable if it's crash number is the same as current
system crash number.
On 04/24/2011 09:11 AM, Andrew Chernow wrote:
On 4/24/2011 1:29 AM, Andrew Dunstan wrote:
The attached patch is intended to clean up a bunch of compiler
warnings seen on
Windows due to mismatches of signedness or constness, unused variables,
redefined macros and a missing prototype.
It
Andrew Dunstan and...@dunslane.net writes:
On 04/24/2011 09:11 AM, Andrew Chernow wrote:
The macro is overriding the prototype declared at line 627, which has
a void argument list (assuming YY_SKIP_YYWRAP is !defined). Since all
code references to this do not provide an argument, I'd say
Simon Riggs si...@2ndquadrant.com writes:
If you don't log changes to tables you have two choices if we crash
1) truncate the table and any indexes
2) rebuild any indexes damaged by the crash
No, you have only one choice, and that's (1), because there's no
guarantee that what's in the table
=?ISO-8859-15?Q?Yves_Wei=DFig?= weis...@rbg.informatik.tu-darmstadt.de writes:
again index access methods, can somebody shed some light into operator
classes for indexes? The documentation is an entry point, but after
reading I still don't have a clue how exactly they are used and created?
Daniele Varrazzo daniele.varra...@gmail.com writes:
On Thu, Apr 21, 2011 at 4:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If you did not actually change the contents of the install script, you
should not change its version number either.
Sorry, I'm not entirely convinced. If I release an
On Apr 24, 2011, at 2:46 PM, Tom Lane wrote:
IMO it'd be better if the bug fix level was tracked outside the
database, for instance via an RPM package version/release number.
I'm not sure whether PGXN has anything for that at the moment.
Distributions may have their own versions independent
David E. Wheeler da...@kineticode.com writes:
On Apr 24, 2011, at 2:46 PM, Tom Lane wrote:
IMO it'd be better if the bug fix level was tracked outside the
database, for instance via an RPM package version/release number.
I'm not sure whether PGXN has anything for that at the moment.
On Apr 24, 2011, at 2:55 PM, Tom Lane wrote:
Hmm ... it's sufficient, but I think people are going to be confused as
to proper usage if you call two different things the version. In RPM
terminology there's a clear difference between version and release;
maybe some similar wording should be
On Sun, Apr 24, 2011 at 10:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniele Varrazzo daniele.varra...@gmail.com writes:
On Thu, Apr 21, 2011 at 4:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If you did not actually change the contents of the install script, you
should not change its version
David E. Wheeler da...@kineticode.com writes:
On Apr 24, 2011, at 2:55 PM, Tom Lane wrote:
Hmm ... it's sufficient, but I think people are going to be confused as
to proper usage if you call two different things the version. In RPM
terminology there's a clear difference between version and
On Sun, Apr 24, 2011 at 10:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
If you don't log changes to tables you have two choices if we crash
1) truncate the table and any indexes
2) rebuild any indexes damaged by the crash
No, you have only one choice,
On Apr 24, 2011, at 3:03 PM, Tom Lane wrote:
Yeah. It seems like a bad idea if the distribution name doesn't
include sufficient information to tell which version it contains.
I had in mind a convention like distribution version x.y.z always
contains extension version x.y. Seems like minor
On Sun, Apr 24, 2011 at 6:15 PM, Simon Riggs si...@2ndquadrant.com wrote:
For large sets of low value data, it makes sense. Deleting all data,
just simply because some of it might be damaged, is not the only
option. IMHO deleting all the data is a surprising option that will
cause many people
On Sun, Apr 24, 2011 at 7:41 PM, Greg Stark gsst...@mit.edu wrote:
On Sun, Apr 24, 2011 at 6:22 PM, Simon Riggs si...@2ndquadrant.com wrote:
My implementation path for that would be to add a crash_number onto
pg_control and pg_index. Any index marked as unlogged, persistent
would only be
On Sat, Apr 23, 2011 at 2:57 PM, Gianni Ciolli
gianni.cio...@2ndquadrant.it wrote:
* avg_usec denotes the average time in microseconds required by each
NOTIFY statement.
h2. Test 1 - PostgreSQL HEAD
n | m | iter | avg_usec
---+---+--+--
10 | 1 | 10 |
On Sat, Apr 23, 2011 at 8:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Gianni Ciolli gianni.cio...@2ndquadrant.it writes:
[ proposes lobotomization of duplicate-elimination behavior in NOTIFY ]
I think this change is likely to be penny-wise and pound-foolish.
The reason the duplicate check is in
I noticed again that make check in contrib doesn't work, so here is a
patch to fix it. Perhaps someone wants to fill in the Windows support
for it. Naturally, this works only for contrib itself, not for external
packages that use pgxs.
A secondary issue that actually led to this: I was
On sön, 2011-04-24 at 12:25 -0400, Tom Lane wrote:
This file is in fundamental violation of the first commandment of
Postgres #includes, which is thou shalt have no other gods before c.h.
We need to put postgres.h *before* the Python.h include. I don't know
what issues led to the current
On fre, 2011-04-22 at 16:32 -0400, Tom Lane wrote:
It's possible that things are not too broken in practice, because it's
likely that the transformations done by these functions only depend on
the encoding indicated by LC_CTYPE, and we (try to) enforce that all
locales used in a given database
On lör, 2011-04-23 at 11:37 -0400, Tom Lane wrote:
I wrote:
* Where they're not, install the locale_t with uselocale(), do
mbstowcs or wcstombs, and revert to the former locale_t setting.
This is ugly as sin, and not thread-safe, but of course lots of
the backend is not thread-safe.
On lör, 2011-04-23 at 13:17 -0400, Tom Lane wrote:
Should we have a TODO item to find a way of providing
platform-independent collation names?
This is a multifold problem.
One issue is, if I'm looking for a locale for, say, English, Canada, I
will find it under en_CA, if it exists at all.
On Thu, Apr 21, 2011 at 1:26 AM, Simon Riggs si...@2ndquadrant.com wrote:
Daniel Farina points out to me that the Linux man page for fsync() says
Calling fsync() does not necessarily ensure that the entry in the directory
containing the file has also reached disk. For that an
explicit
On Sun, Apr 24, 2011 at 11:15 PM, Simon Riggs si...@2ndquadrant.com wrote:
IMHO deleting all the data is a surprising option that will
cause many people to curse us. I don't see preserving some of the data
as being worse.
What possible damage to you want to recover from?
Without WAL logging
On Thu, Apr 21, 2011 at 8:51 PM, Greg Smith g...@2ndquadrant.com wrote:
There's still the fsync'd a data block but not the directory entry yet
issue as fall-out from this too. Why doesn't PostgreSQL run into this
problem? Because the exact code sequence used is this one:
open
write
fsync
On Sat, Apr 23, 2011 at 08:54:31AM -0500, Kevin Grittner wrote:
Even though this didn't show any difference in Dan's performance
tests, it seems like reasonable insurance against creating a new
bottleneck in very high concurrency situations.
Dan, do you have a patch for this, or should I
39 matches
Mail list logo
