Dave Page wrote:
but the CRC is still different for some as-yet unknown reason...
Unknown because I wasn't fully grokking what it was a CRC of. Everything
looks good now :-)
/D
---(end of broadcast)---
TIP 1: if posting/reading through
Tom Lane wrote:
AFAIK, time_t is a Unix-ism, so it's pretty unlikely to be used in the
APIs of anything on Windows.
Oh, it is.
I guess my advice would be to see if we can define _USE_32BIT_TIME_T
in port/win32.h and make it go away that way. It'd definitely be nice
if MSVC and Mingw builds
Alvaro Herrera a écrit :
Guillaume Lelarge wrote:
Tom Lane a écrit :
Guillaume Lelarge [EMAIL PROTECTED] writes:
I try to answer a simple question : what happens when I do a simple
INSERT on a just started PostgreSQL server.
From what I understand with the INSERT statement, here is what
Magnus Hagander [EMAIL PROTECTED] writes:
I guess my advice would be to see if we can define _USE_32BIT_TIME_T
in port/win32.h and make it go away that way. It'd definitely be nice
if MSVC and Mingw builds weren't binary-incompatible.
The attached patch defines it in the MSVC project
I guess my advice would be to see if we can define _USE_32BIT_TIME_T
in port/win32.h and make it go away that way. It'd definitely be nice
if MSVC and Mingw builds weren't binary-incompatible.
The attached patch defines it in the MSVC project files along with the
other API-config
Hi everyone,
I think that I may have found a minor bug with PostgreSQL 8.3beta4 with
respect to md5 authentication. I actually discovered this on Win32, but
it appears that the behaviour is the same under Linux too.
As part of the PostGIS install under Win32, I have a few scripts that
check for
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
Gregory Stark wrote:
An alternative is leaving it in the project file but putting something like
this in c.h:
Put it in win32.h, please. c.h shouldn't get cluttered with
platform-specific kluges when there's no need for it.
Is there a
Dave Page [EMAIL PROTECTED] writes:
Gregory Stark wrote:
An alternative is leaving it in the project file but putting something like
this in c.h:
Put it in win32.h, please. c.h shouldn't get cluttered with
platform-specific kluges when there's no need for it.
Is there a good reason not to
On 12/7/07, Dave Page [EMAIL PROTECTED] wrote:
Tom Lane wrote:
AFAIK, time_t is a Unix-ism, so it's pretty unlikely to be used in the
APIs of anything on Windows.
Oh, it is.
It's confined to the C Runtime libraries, not part of the Windows API
proper. (Three exceptions: IP Helper uses the
Dave Page [EMAIL PROTECTED] writes:
Just to add a note to that - when running it in the same shell from
which I started the server with messages going to stdout, it seemed
clear that it trys to connect once using PGPASSWORD, then when that
fails, it prompts for the password instead, and
Mark Cave-Ayland wrote:
H. So even though PGPASSWORD is set (and the command works if the
database exists within the cluster), if I specify a non-existent
database then I still get prompted for a password.
Just to add a note to that - when running it in the same shell from
which I started
I use often pgdump... and we have many bytea on our database...
Without binary COPY, backup is very slow and takes 4x more space on the
network wire...
It would be great to have an option (--binary) with eventually a WARNING
message (that your backup could be not portable across architecture...)
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Historically, the only way to troubleshoot some of the contrib modules
was to e-mail the author. If people think that we've reached a standard
that everything in /contrib is now well-documented and supported by the
general community, the
Gregory Stark wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I guess my advice would be to see if we can define _USE_32BIT_TIME_T
in port/win32.h and make it go away that way. It'd definitely be nice
if MSVC and Mingw builds weren't binary-incompatible.
The attached patch defines it in the
On Fri, 2007-12-07 at 11:03 -0500, Tom Lane wrote:
Hmmm ... it seems the problem is that we've defined
PQconnectionUsedPassword in such a way that it returns true (causing a
prompt) regardless of whether the reason for the connection failure was
a bad password or not. We might need to
On Dec 7, 2007 9:03 AM, Andrew Dunstan [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Historically, the only way to troubleshoot some of the contrib
modules was to e-mail the author. If people think that we've
reached a standard
On Thu, 2007-12-06 at 19:43 -0800, David Fetter wrote:
On Thu, Dec 06, 2007 at 07:19:44PM -0800, Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 06 Dec 2007 20:44:49 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
Simon Riggs wrote:
- Heap-Only Tuples (HOT) accelerate space reuse for UPDATEs
change to
Heap-Only Tuples (HOT) improve performance of frequent UPDATEs
I think we need to qualify this, or it could be quite misleading.
perhaps add that don't affect
Gregory Stark [EMAIL PROTECTED] writes:
We could always tighten this up a bit by listing the alignment of a
handful of built-in data types but I suppose there will always be
holes in this area anyways.
In theory yeah, but the note in pg_control.h still applies to every
platform I've heard of:
Gregory Stark [EMAIL PROTECTED] writes:
Argh, As soon as I sent it I realized even that's not right. The
alignments of our datums is specified by pg_type and doesn't vary by
platform. There has been some thought of making 8-byte data types like
bigint pass-by-value on 64-bit machines in which
Gregory Stark wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Josh Berkus [EMAIL PROTECTED] writes:
I've just noticed that pg_controldata doesn't say anything about whether
the database is 64-bit or 32-bit.
That's because there is no such concept.
I think
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Josh Berkus [EMAIL PROTECTED] writes:
I've just noticed that pg_controldata doesn't say anything about whether
the database is 64-bit or 32-bit.
That's because there is no such concept.
I think the relevant
Tom Lane [EMAIL PROTECTED] writes:
Josh Berkus [EMAIL PROTECTED] writes:
I've just noticed that pg_controldata doesn't say anything about whether
the database is 64-bit or 32-bit.
That's because there is no such concept.
I think the relevant concept is whether Datum is 32-bit or 64-bit
On Dec 7, 2007 10:25 PM, Greg Smith [EMAIL PROTECTED] wrote:
Smoothed makes a lot of sense for me. We used to have a checkpoint
spike, now we don't.
To be accurate, there used to be a huge and unavoidable spike, now there's
a control that aims to make it smaller. The problem hasn't
Folks,
I've just noticed that pg_controldata doesn't say anything about whether
the database is 64-bit or 32-bit. Since the data files can be
incompatible based on word length, shouldn't that be in pg_controldata?
--Josh Berkus
---(end of
Simon Riggs wrote:
On Fri, 2007-12-07 at 16:21 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
Maybe the importance of the patches that were removed wasn't clear
enough, so let me explain my viewpoint. On another part of this thread I
summarised the feedback from others to a list of
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Stefan Kaltenbrunner wrote:
Let me give you the criteria I use for the release notes. The release
notes try to document all changes visible to the average user in a way
that is understandable to the average user.
hmm I'm not so sure
Simon Riggs wrote:
On Fri, 2007-12-07 at 16:21 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
Maybe the importance of the patches that were removed wasn't clear
enough, so let me explain my viewpoint. On another part of this thread I
summarised the feedback from others to a list of
Bruce Momjian wrote:
Stefan Kaltenbrunner wrote:
Let me give you the criteria I use for the release notes. The release
notes try to document all changes visible to the average user in a way
that is understandable to the average user.
hmm I'm not so sure about that - there are a number of
On Fri, 2007-12-07 at 16:21 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
Maybe the importance of the patches that were removed wasn't clear
enough, so let me explain my viewpoint. On another part of this thread I
summarised the feedback from others to a list of features that were
Andrew Dunstan wrote:
I still think this needs to be qualified either way. As it stands it's
quite misleading. Many update scenarios will not benefit one whit from
HOT updates.
Doesn't the detail description qualify it enought? The heading isn't
suppose to have all the
On Fri, 2007-12-07 at 12:33 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Fri, 2007-11-30 at 09:49 +, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
If people understand there aren't 13 performance improvements there are
at *least* 19+ that is a positive
Andrew Dunstan wrote:
Bruce Momjian wrote:
- Heap-Only Tuples (HOT) accelerate space reuse for UPDATEs
change to
Heap-Only Tuples (HOT) improve performance of frequent UPDATEs
I used the original text because it tries to explain _how_ HOT improves
performance. The
Josh Berkus wrote:
Greg,
Frankly I think the release notes are already too long. People who judge a
release by counting the number of items in the release notes are not worth
appeasing. Including every individual lock removed or code path optimized
will only obscure the important points
Simon Riggs wrote:
On Fri, 2007-11-30 at 09:49 +, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
If people understand there aren't 13 performance improvements there are
at *least* 19+ that is a positive message to help people decide to
upgrade.
Frankly I think
Simon Riggs wrote:
On Fri, 2007-11-30 at 06:31 +, Simon Riggs wrote:
I also notice that two performance features have disappeared from the
release notes. (Presumably they have been removed from source). Both of
them have changes that can be seen by users, so can't see why we would
Joshua D. Drake wrote:
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Historically, the only way to troubleshoot some of the contrib
modules was to e-mail the author. If people think that we've
reached a standard that everything in /contrib is now
well-documented and supported by
On Fri, 7 Dec 2007, Simon Riggs wrote:
Smoothed makes a lot of sense for me. We used to have a checkpoint
spike, now we don't.
To be accurate, there used to be a huge and unavoidable spike, now there's
a control that aims to make it smaller. The problem hasn't completely
gone away yet.
Josh Berkus [EMAIL PROTECTED] writes:
I've just noticed that pg_controldata doesn't say anything about whether
the database is 64-bit or 32-bit.
That's because there is no such concept.
Since the data files can be
incompatible based on word length, shouldn't that be in pg_controldata?
Bruce Momjian wrote:
Andrew Dunstan wrote:
I still think this needs to be qualified either way. As it stands it's
quite misleading. Many update scenarios will not benefit one whit from
HOT updates.
Doesn't the detail description qualify it enought? The heading isn't
Stefan Kaltenbrunner wrote:
Let me give you the criteria I use for the release notes. The release
notes try to document all changes visible to the average user in a way
that is understandable to the average user.
hmm I'm not so sure about that - there are a number of changes to psql
Bruce Momjian wrote:
Simon Riggs wrote:
[ Sorry for my delay in replying to this.]
Few proposals
- Can we say smoothed rather than distributed checkpoints?
Smoothed checkpoints greatly reduce checkpoint I/O spikes
Agreed. Changed.
- Heap-Only Tuples (HOT) accelerate space reuse
Gregory Stark [EMAIL PROTECTED] writes:
Oh, I see what you meant now. Datum is a purely in-memory concept, it doesn't
actually reach disk.
We could always tighten this up a bit by listing the alignment of a handful of
built-in data types but I suppose there will always be holes in this area
Simon Riggs wrote:
On Fri, 2007-12-07 at 12:33 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Fri, 2007-11-30 at 09:49 +, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
If people understand there aren't 13 performance improvements there
are
at
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
- Heap-Only Tuples (HOT) accelerate space reuse for UPDATEs
change to
Heap-Only Tuples (HOT) improve performance of frequent UPDATEs
I used the original text because it tries to explain _how_ HOT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 7 Dec 2007 14:47:22 -0500 (EST)
Bruce Momjian [EMAIL PROTECTED] wrote:
It is true we don't have a tracker but I have not seen a major demand
for it,
Are you kidding?
or at least not enough for someone to actually do the work
required
Simon Riggs wrote:
[ Sorry for my delay in replying to this.]
Few proposals
- Can we say smoothed rather than distributed checkpoints?
Smoothed checkpoints greatly reduce checkpoint I/O spikes
Agreed. Changed.
- Heap-Only Tuples (HOT) accelerate space reuse for UPDATEs
change to
Usama Dar wrote:
i agree that release notes should not be too long, but may be there should
be (if there isn't one already) something like a change log where people
can find out all the changes done from the previous release, if they are
intrested ?
Right now only the CVS logs provide more
Bruce Momjian wrote:
- Heap-Only Tuples (HOT) accelerate space reuse for UPDATEs
change to
Heap-Only Tuples (HOT) improve performance of frequent UPDATEs
I used the original text because it tries to explain _how_ HOT improves
performance. The item that has the descriptive text
Ühel kenal päeval, R, 2007-12-07 kell 18:22, kirjutas Simon Riggs:
On Thu, 2007-12-06 at 19:43 -0800, David Fetter wrote:
On Thu, Dec 06, 2007 at 07:19:44PM -0800, Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 06 Dec 2007 20:44:49 -0500
Tom Lane
Mark Cave-Ayland [EMAIL PROTECTED] writes:
On Fri, 2007-12-07 at 11:03 -0500, Tom Lane wrote:
Hmmm ... it seems the problem is that we've defined
PQconnectionUsedPassword in such a way that it returns true (causing a
prompt) regardless of whether the reason for the connection failure was
a
51 matches
Mail list logo
