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
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 w
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.
"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 th
"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
"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 o
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
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?
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 broadcast)--
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
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 w
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
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
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 nu
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
>
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
suppose
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 ps
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) acc
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 ha
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
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_ HO
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
Ü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
-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
> requi
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
>
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 importa
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 rec
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
>
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 PROTE
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 ad
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.
> >
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 expl
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 mo
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 wo
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
> chang
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
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
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, an
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 go
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
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
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 t
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 stateme
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
"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
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...)
b
> > 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-conf
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 u
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 Usenet,
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 bu
51 matches
Mail list logo
