Resending... The previous 3 attempt haven't succeeded, probably because of size restrictions; so sending in two parts.On 10/18/06, Gurjeet Singh
[EMAIL PROTECTED] wrote:Hi all, Please refer to the following link for a new algorithm to calculate CRC, developed by Intel.
Simon Riggs wrote:
RelationCacheInitFileInvalidate() is also called on each
FinishPreparedTransaction().
It's only called if the prepared transaction invalidated the init file.
If that is called 100% of the time, then we
can skip writing an additional record for prepared transactions by
Hi Jim, On 10/18/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
Also how many times a relation has been vacuumed (which puts all theother numbers in more perspective... good catch Simon). And I thinknumber of pages that could not be added to the FSM would also beextremely valuable.
By the above, do
Resending... The previous 3 attempt haven't succeeded, probably because of size restrictions; so sending in two parts. This is part 2; unfortunately, the size of the gzipped file is still a bit big (26 KB), so I have uploaded it to
http://www.geocities.com/gurjeet79/crc_sb8_test.tar.gz Please
Gurjeet Singh wrote:
Can someone let us all know what is the limit on the attachments
sent to the -hackers list?
Generally it's probably best not to send attachments to -hackers at all.
If you have a patch, send it to -hackers. Or you can publish it
somewhere on the web and post
Andrew Dunstan wrote:
If you have a patch, send it to -hackers.
I mean -patches of course. Sorry.
cheers
andrew
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
When setting log_statement = 'all', statements that fail parsing are not
logged. For example:
LOG: connection received: host=[local]
LOG: connection authorized: user=peter database=peter
LOG: statement: select * from pg_class;
LOG: duration: 19.084 ms
### here a log entry is missing
ERROR:
Peter Eisentraut [EMAIL PROTECTED] writes:
When setting log_statement = 'all', statements that fail parsing are not
logged.
Is that intentional?
The 'mod' and 'ddl' settings obviously can't be handled until after
basic parsing. We could create a completely separate code path for
'all' but I'm
Tom Lane wrote:
The 'mod' and 'ddl' settings obviously can't be handled until after
basic parsing. We could create a completely separate code path for
'all' but I'm not sure I see the point.
The users are evidently expecting that log all statements means to log
all statements issued by the
On Thu, Oct 19, 2006 at 04:10:46PM +0530, NikhilS wrote:
Hi Jim,
On 10/18/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
Also how many times a relation has been vacuumed (which puts all the
other numbers in more perspective... good catch Simon). And I think
number of pages that could not be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Oct 19, 2006 at 04:28:17PM +0200, Peter Eisentraut wrote:
When setting log_statement = 'all', statements that fail parsing are not
logged. For example:
[...]
HA! This one has bitten me just today :-)
The problem was a faulty client
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
To some extent the logging
settings are only meant to capture successfully executed statements
Then it should be changed to log *only* successfully executed statements
and explicitly documented as such.
Well, maybe we should do
Jim C. Nasby [EMAIL PROTECTED] writes:
BTW, if we add these counters we'll be up to 7 stats dealing with vacuum
and analyze, and NikhilS has a patch we're finalizing that would add 3
more. Right now there's 4 slated to go into pg_stat_* in 8.2, but maybe
we should have a separate view for
On Thu, Oct 19, 2006 at 11:47:53AM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
BTW, if we add these counters we'll be up to 7 stats dealing with vacuum
and analyze, and NikhilS has a patch we're finalizing that would add 3
more. Right now there's 4 slated to go into
Magnus Hagander [EMAIL PROTECTED] writes:
Attached patch removes a couple of extern definitions from adminpack,
replacing some of them with a #include. (Cam eup with this because we
got a duplicate definition of DataDir when building with Visual C++).
That isn't going to work unless we put
Magnus Hagander [EMAIL PROTECTED] writes:
A couple of the Makefiles in contrib don't define OBJS= as standard,
instead they define SRCS= and then a makefile rule for OBJS= that does a
replacement on that.
Is there any actual reason for that?
Can't see one.
If not, could the attached patch
A couple of the Makefiles in contrib don't define OBJS= as
standard,
instead they define SRCS= and then a makefile rule for
OBJS= that does
a replacement on that.
Is there any actual reason for that?
Can't see one.
Ok. Thanks.
If not, could the attached patch
please be
Attached patch removes a couple of extern definitions from
adminpack,
replacing some of them with a #include. (Cam eup with this
because we
got a duplicate definition of DataDir when building with
Visual C++).
That isn't going to work unless we put DLLIMPORT into the
main
Magnus Hagander [EMAIL PROTECTED] writes:
The reason for redeclaring these in the contrib files is to
get DLLIMPORT onto them...
Interedting - it builds on MSVC without it :-O
Anyway. That certainly explains why MSVC is complaining - it's getting
completely different definitions of these
I just tried a rebuild of the MSVC stuff, and got the following error.
Any ideas on the best way to fix that?
(as you notice, I haven't pulled the very latest cvs so I haven't for
the min() fix that's put in now. Just let me know if the rest is also
fixed ;-))
//Magnus
Build started: Project:
The reason for redeclaring these in the contrib files is to get
DLLIMPORT onto them...
Interedting - it builds on MSVC without it :-O
Anyway. That certainly explains why MSVC is complaining -
it's getting
completely different definitions of these variables from the header
and
I've set up my laptop to sync down the full cvs repository using rsync
(remember - windows = no cvsup). This works well, except every now and
then (not every time, but definitly often enough to bother me) it
resyncs the entire repository, and not just the files that have had
commits to them.
Magnus Hagander [EMAIL PROTECTED] writes:
I just tried a rebuild of the MSVC stuff, and got the following error.
Any ideas on the best way to fix that?
1.\src\port\qsort.c(53) : warning C4005: 'min' : macro redefinition
C:\Program Files\Microsoft Visual Studio
This is fixed already
Magnus Hagander [EMAIL PROTECTED] writes:
The same redeclaration technique is being used elsewhere
(pg_buffercache and pg_freespacemap it looks like). Aren't
you getting warnings there too?
I am - I just started working on getting those done as well.
OK, I guess we gotta play them all
MSVCRTD.lib(MSVCR80D.dll) : error LNK2005: _qsort already
defined in
qsort.obj
Hmm. I've been seeing related complaints on Darwin, but they
were just warnings (about our qsort conflicting with the one in libc).
Yeah, seems it works in Mingw, but for some reason it's fatal in MSVC.
On Thu, Oct 19, 2006 at 01:56:24PM -0400, Tom Lane wrote:
Is it worth renaming our qsort to pg_qsort to avoid this? (I'd be
inclined to do that via a macro #define qsort pg_qsort, not by running
around and changing all the code.)
Redefining a function that is defined in POSIX and present on
On Thu, 2006-10-19 at 19:52 +0200, Magnus Hagander wrote:
I've set up my laptop to sync down the full cvs repository using rsync
(remember - windows = no cvsup).
Yeah, I do this as well, and for similar reasons (cvsup is unmaintained
and annoying to build, at least on AMD64/Debian).
This
Magnus Hagander [EMAIL PROTECTED] writes:
Is it worth renaming our qsort to pg_qsort to avoid this?
(I'd be inclined to do that via a macro #define qsort
pg_qsort, not by running around and changing all the code.)
Yeah, I think it is ;-) Just make sure it happens before we pull in
This works well, except every now and
then (not every time, but definitly often enough to bother me) it
resyncs the entire repository, and not just the files that have had
commits to them.
I haven't noticed this personally, although I might have just
missed it.
Are you sure you're
Is it worth renaming our qsort to pg_qsort to avoid this?
(I'd be inclined to do that via a macro #define qsort
pg_qsort, not
by running around and changing all the code.)
Yeah, I think it is ;-) Just make sure it happens before we pull in
stdlib.h, so we don't rename tha tone as
On Thu, 2006-10-19 at 13:56 -0400, Tom Lane wrote:
Is it worth renaming our qsort to pg_qsort to avoid this? (I'd be
inclined to do that via a macro #define qsort pg_qsort, not by running
around and changing all the code.)
Why not change each call site? I don't think it would hurt to be clear
Neil Conway [EMAIL PROTECTED] writes:
On Thu, 2006-10-19 at 13:56 -0400, Tom Lane wrote:
Is it worth renaming our qsort to pg_qsort to avoid this? (I'd be
inclined to do that via a macro #define qsort pg_qsort, not by running
around and changing all the code.)
Why not change each call site?
Magnus Hagander wrote:
I've set up my laptop to sync down the full cvs repository using rsync
(remember - windows = no cvsup). This works well, except every now and
then (not every time, but definitly often enough to bother me) it
resyncs the entire repository, and not just the files that have
I've set up my laptop to sync down the full cvs repository
using rsync
(remember - windows = no cvsup). This works well, except
every now and
then (not every time, but definitly often enough to bother me) it
resyncs the entire repository, and not just the files that have had
Why does adminpack install functions into pg_catalog? This is
inconsistent with the rest of the contrib/ packages, not to mention the
definition of pg_catalog itself (which ought to hold builtin object
definitions). And as AndrewSN pointed out on IRC, it also breaks
pg_dump.
-Neil
both cube and seg seems to do some funky stuff with flex/bison, if I'm
not entirely mistaken. Cube, for example, uses a rule that builds
cubeparse.o from cubescan.c. (which in turnis built from flex/bison
files).
Is there any reason why we don't build a file called cubescan.o from
cubescan.c and
both cube and seg seems to do some funky stuff with
flex/bison, if I'm not entirely mistaken. Cube, for example,
uses a rule that builds cubeparse.o from cubescan.c.
(which in turnis built from flex/bison files).
Is there any reason why we don't build a file called
cubescan.o from
Recently I ran into a disk full problem with my database. I had to
play with the tablespaces and locations symlinks... until the disk could
be cleaned just enough for the database to continue operation. I had
plenty of space on another disk but found no *easy* way to humbly ask
postgres to
Gevik Babakhani [EMAIL PROTECTED] writes:
Now I am thinking what it would take to give pg the functionality to
extend tablespaces automatically.
It's called LVM ... and no, we are not interested in reimplementing
filesystem-level functionality ...
regards, tom lane
Where are we on releasing beta2 or perhaps going right to an RC1
release? Seems it is time for one of them.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of
On Sun, Oct 15, 2006 at 14:26:12 -0400,
Neil Conway [EMAIL PROTECTED] wrote:
At least according to [1], kernel AIO on Linux still doesn't work for
buffered (i.e. non-O_DIRECT) files. There have been patches available
for quite some time that implement this, but I'm not sure when they are
Hello
Im new to PostgreSQL development and I would like to make introduce
patch that will satisfied this point of TODO:
%Allow GRANT/REVOKE permissions to be applied to all schema objects with
one command
The proposed syntax is:
GRANT SELECT ON ALL TABLES IN public TO phpuser; GRANT
looks to me that NEW TABLES are the tables created AFTER the GRANT :)Is that?[]'s- WalterOn 10/19/06, Krycek
[EMAIL PROTECTED] wrote:HelloIm new to PostgreSQL development and I would like to make introduce
patch that will satisfied this point of TODO:%Allow GRANT/REVOKE permissions to be applied
Bruce Momjian [EMAIL PROTECTED] writes:
Where are we on releasing beta2 or perhaps going right to an RC1
release? Seems it is time for one of them.
I think we need a beta2 now, and perhaps RC1 in a week. We've done
enough portability hacking recently that some more beta seems indicated.
Okay, thank you.
On Thu, 2006-10-19 at 15:56 -0400, Tom Lane wrote:
Gevik Babakhani [EMAIL PROTECTED] writes:
Now I am thinking what it would take to give pg the functionality to
extend tablespaces automatically.
It's called LVM ... and no, we are not interested in reimplementing
Magnus Hagander [EMAIL PROTECTED] writes:
Attached patch removes a couple of extern definitions from adminpack,
replacing some of them with a #include.
I've now removed all the local DLLIMPORT-redeclarations I could find
in favor of marking the relevant variables in the main header files.
Attached patch removes a couple of extern definitions from
adminpack,
replacing some of them with a #include.
I've now removed all the local DLLIMPORT-redeclarations I
could find in favor of marking the relevant variables in the
main header files.
Thanks. All affected projects build
Magnus Hagander [EMAIL PROTECTED] writes:
A define is needed to expose the M_PI define from the system headers.
It seems like the other places where we depend on M_PI, we instead have
#ifndef M_PI
#define M_PI 3.14159265358979323846
#endif
Perhaps that's a better solution?
Magnus Hagander [EMAIL PROTECTED] writes:
This patch adds a #define for BYTE_ORDER to win32.h if it's not pulled
in elsewhere, as needed by msvc build of pgcrypto. Seems several other
platforms define it in their port file already, but not win32.
Done, but I think you forgot the defs for
A define is needed to expose the M_PI define from the
system headers.
It seems like the other places where we depend on M_PI, we
instead have
#ifndef M_PI
#define M_PI 3.14159265358979323846
#endif
Perhaps that's a better solution?
Oh. I actually did that for my quick-n-dirty fix
This patch adds a #define for BYTE_ORDER to win32.h if it's
not pulled
in elsewhere, as needed by msvc build of pgcrypto. Seems
several other
platforms define it in their port file already, but not win32.
Done, but I think you forgot the defs for LITTLE_ENDIAN and
friends ... it
Magnus Hagander [EMAIL PROTECTED] writes:
Done, but I think you forgot the defs for LITTLE_ENDIAN and
friends ... it seems unlikely that a platform would provide
those and then forget BYTE_ORDER.
Well, it compiled just fine, so it must've found it somewhere :-)
I think the #if tests
Magnus Hagander [EMAIL PROTECTED] writes:
oid2name requires an extern char*optarg to build on win32.
[ looks around... ] zic.c seems to need it too.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading
On 10/19/06, Krycek [EMAIL PROTECTED] wrote:
The proposed syntax is:
GRANT SELECT ON ALL TABLES IN public TO phpuser; GRANT SELECT ON NEW
TABLES IN public TO phpuser;
GRANT SELECT ON NEW TABLES IN public TO phpuser;?
What does NEW TABLES mean in this context?
the point is to allow tables
This change has broken my AIX 5.2 buildfarm machine (asp/kookaburra),
but doesn't seem to break the 5.3 member (grebe).
It appears to have problems with stats being off now?
What can I do to help debug the situation?
-rocco
-Original Message-
From: [EMAIL PROTECTED]
Rocco Altier [EMAIL PROTECTED] writes:
This change has broken my AIX 5.2 buildfarm machine (asp/kookaburra),
but doesn't seem to break the 5.3 member (grebe).
Sigh, count on IBM to make life complicated.
Instead of hacking servname, I suppose we will have to poke the correct
value into
I wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Then it should be changed to log *only* successfully executed statements
and explicitly documented as such.
Well, maybe we should do that.
I fooled around with doing that, and while it's a simple code change,
I realized that it's got a
Gurjeet Singh [EMAIL PROTECTED] writes:
Please refer to the following link for a new algorithm to calculate
CRC, developed by Intel.
http://www.intel.com/technology/magazine/communications/slicing-by-8-0306.htm
I can't help wondering what the patent status of this algorithm is.
(This from a
Tom Lane wrote:
Gurjeet Singh [EMAIL PROTECTED] writes:
Please refer to the following link for a new algorithm to calculate
CRC, developed by Intel.
http://www.intel.com/technology/magazine/communications/slicing-by-8-0306.htm
I can't help wondering what the patent status of this
On Thu, Oct 19, 2006 at 06:32:08PM -0400, Tom Lane wrote:
So I'm inclined to leave the behavior as-is. The documentation for
log_statement already says
Note: Statements that generate syntax errors are not logged. Set
log_min_error_statement to error to log such statements.
On Thu, Oct 19, 2006 at 02:37:34PM -0400, Neil Conway wrote:
Why does adminpack install functions into pg_catalog? This is
inconsistent with the rest of the contrib/ packages, not to mention the
definition of pg_catalog itself (which ought to hold builtin object
definitions). And as AndrewSN
On 19/10/06 19:37, Neil Conway [EMAIL PROTECTED] wrote:
Why does adminpack install functions into pg_catalog? This is
inconsistent with the rest of the contrib/ packages, not to mention the
definition of pg_catalog itself (which ought to hold builtin object
definitions).
The adminpack
Hi, On 10/18/06, Martijn van Oosterhout kleptog@svana.org wrote:
On Wed, Oct 18, 2006 at 08:04:29PM +1300, Mark Kirkwood wrote: bgwriter doing aysncronous I/O for the dirty buffers that it is supposed to sync Another decent use-case?
Good idea, but async i/o is generally poorly supported.
Async
On 10/20/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
It doesn't say anything aboutbeing free of patents though.The Sourceforge project referred to in the article (but for which nolink is given) seems to be this one:
http://sourceforge.net/projects/slicing-by-8Yes. I had already mentioned that link
64 matches
Mail list logo
