>> Here is a new patch that replaces the previous one; it adds two
>> macros LDAP_LIBS_FE and LDAP_LIBS_BE for frontend and backend,
>> respectively.
>
>> I did not only add them to the Makefile for interfaces/libpq,
>> but also everywhere something is linked against libpq in case
>> somebody link
On Sun, 10 Sep 2006, Kevin Brown wrote:
> Tom Lane wrote:
> > (does anyone know the cost of ntohl() on modern
> > Intel CPUs?)
>
> I have a system with an Athlon 64 3200+ (2.0 GHz) running in 64-bit
> mode, another one with the same processor running in 32-bit mode, a a
> third running a Pentium 4
Tom Lane wrote:
> (does anyone know the cost of ntohl() on modern
> Intel CPUs?)
I wrote a simple test program to determine this:
#include
int main (int argc, char *argv[]) {
unsigned long i;
uint32_t a;
a = 0;
for (i = 0 ; i < 40L ; ++i) {
#ifdef CALL_N
Michael Fuhr <[EMAIL PROTECTED]> writes:
> The uninstall scripts for dblink and ltree were missing some
> functions.
Applied, thanks.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space
After a long battle with technology, [EMAIL PROTECTED] (Tom Lane), an
earthling, wrote:
> Log Message:
> ---
> Install a cleaner solution to the AIX libpq linking problem, as per
> an earlier discussion. Centralize assumptions about what libpq depends
> on in one place in Makefile.global.
Tom Lane wrote:
> After further thought I have an alternate proposal that does that,
> but it's got its own disadvantage: it requires storing uncompressed
> 4-byte length words in big-endian byte order everywhere. This might
> be a showstopper (does anyone know the cost of ntohl() on modern
> Inte
Gregory Stark <[EMAIL PROTECTED]> writes:
> I'm a bit confused by this and how it would be handled in your sketch. I
> assumed we needed a bit pattern dedicated to 4-byte length headers because
> even though it would never occur on disk it would be necessary to for the
> uncompressed and/or detoast
Gregory Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> Either way, I think it would be interesting to consider
> > >>
> > >> (a) length word either one or two bytes, not four. You can't need more
> > >> than 2 byte
Tom Lane <[EMAIL PROTECTED]> writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Either way, I think it would be interesting to consider
> >>
> >> (a) length word either one or two bytes, not four. You can't need more
> >> than 2 bytes for a datum that fits in a disk pag
Joshua D. Drake wrote:
>
> >In any case the same logic that leads to it being desirable to report all
> >the
> >errors to the user in a UI and not just report them one by one also
> >applies to
> >the database. I'm not sure it's the most important issue in the world, but
> >it
> >does seem like
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I see this in the CVS commits for 8.2. Did we determine the proper
> number of lock partitions? Should it be based on the number of buffers
> or concurrent sessions allowed?
No. NUM_LOCK_PARTITIONS needs to be a compile-time constant for a
number of r
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Should untsearch2.sql be renamed to uninstall_tsearch2.sql to be
> consistent with all the other uninstall scripts?
Yeah, that and lo_drop are outliers that probably ought to be renamed.
Offhand I don't see any serious compatibility objection --- who does
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Either way, I think it would be interesting to consider
>>
>> (a) length word either one or two bytes, not four. You can't need more
>> than 2 bytes for a datum that fits in a disk page ...
> That is an interesting observation, thoug
I see this in the CVS commits for 8.2. Did we determine the proper
number of lock partitions? Should it be based on the number of buffers
or concurrent sessions allowed?
Divide the lock manager's shared state into 'partitions', so as to
reduce contention for the former single LockMgrLock. Per
On Sun, Sep 10, 2006 at 07:38:24PM -0400, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > I spent a few minutes doing the same tests I did a few months ago
> > and found problems with dblink and ltree; I'll submit patches for
> > those. Tom, do you recall which modules gave you trou
Tom Lane wrote:
> [EMAIL PROTECTED] (Bruce Momjian) writes:
> > Back out patch added during 8.2.X development:
> > Allow to_char() "D" format specifiers for interval/time.
> > It doesn't work, and I doubt it is useful enough to fix ("D" = day of
> > week).
>
> Hm, shouldn't there be a document
contrib/xml2 currently has PG_MODULE_MAGIC in xslt_proc.c, which
results in a runtime error on systems that built the module without
support for libxslt per the comments in the Makefile. Should
PG_MODULE_MAGIC be in xpath.c instead?
--
Michael Fuhr
---(end of broadcast)-
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > * Consider ways of storing rows more compactly on disk
> > o Support a smaller header for short variable-length fields?
>
> With respect to the business of having different on-disk and in-memory
> representations, we h
Michael Fuhr <[EMAIL PROTECTED]> writes:
> I spent a few minutes doing the same tests I did a few months ago
> and found problems with dblink and ltree; I'll submit patches for
> those. Tom, do you recall which modules gave you trouble?
Um ... hstore and tsearch2, I think. I fixed those, but was
On Sun, Sep 10, 2006 at 01:50:39PM -0700, Joshua D. Drake wrote:
> O.k., I will start working through it and report at the end of the week.
I spent a few minutes doing the same tests I did a few months ago
and found problems with dblink and ltree; I'll submit patches for
those. Tom, do you recall
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Back out patch added during 8.2.X development:
> Allow to_char() "D" format specifiers for interval/time.
> It doesn't work, and I doubt it is useful enough to fix ("D" = day of
> week).
Hm, shouldn't there be a documentation update to go with that
Bruce Momjian <[EMAIL PROTECTED]> writes:
> * Consider ways of storing rows more compactly on disk
> o Support a smaller header for short variable-length fields?
With respect to the business of having different on-disk and in-memory
representations, we have that already today:
Tom Lane wrote:
Mark Dilger <[EMAIL PROTECTED]> writes:
... The argument made upthread that a
quadratic number of conversion operators is necessitated doesn't seem
right to me, given that each type could upcast to the canonical built in
type. (int1 => smallint, int3 => integer, ascii1 => text
Added to TODO:
* Consider ways of storing rows more compactly on disk
o Store disk pages with no alignment/padding?
o Reorder physical storage order to reduce padding?
o Support a smaller header for short variable-length fie
Let me know if you need an extra pair of eyes.
G.-
On 9/10/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Seems like this area needs more attention ... anyone want to work on it?
>
>> I'll take it. How long d
Mark Dilger <[EMAIL PROTECTED]> writes:
> ... The argument made upthread that a
> quadratic number of conversion operators is necessitated doesn't seem
> right to me, given that each type could upcast to the canonical built in
> type. (int1 => smallint, int3 => integer, ascii1 => text, ascii2 =
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Seems like this area needs more attention ... anyone want to work on it?
I'll take it. How long do I have?
Since it's contrib, I don't think we need to hold you to being done
before beta1. But the sooner the bet
"Jeremy Kronuz" <[EMAIL PROTECTED]> writes:
> Tom, I'm attaching the new patch now... it's now using the GET_TEXT(), I've
> updated the README and I've used the -c format as you suggested.
> Please, let me know how it goes for you.
Looks great, applied.
If you are interested, consider working up
Martijn van Oosterhout wrote:
On Sun, Sep 10, 2006 at 11:55:35AM -0700, Mark Dilger wrote:
Well, it is unless you are willing to give up support of non-Intel CPUs;
most other popular chips are strict about alignment, and will fail an
attempt to do a nonaligned fetch.
Intel CPUs are detectable at
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Seems like this area needs more attention ... anyone want to work on it?
> I'll take it. How long do I have?
Since it's contrib, I don't think we need to hold you to being done
before beta1. But the sooner the better of course.
On Sun, Sep 10, 2006 at 12:09:24PM -0700, Joshua D. Drake wrote:
> Tom Lane wrote:
> >Awhile back, someone went around and made sure that all the contrib
> >modules had uninstall scripts, but most of the new contributions since
> >then don't have 'em:
> > adminpack hstore pg_freespacemap pgrowl
On Sun, Sep 10, 2006 at 11:55:35AM -0700, Mark Dilger wrote:
> >Well, it is unless you are willing to give up support of non-Intel CPUs;
> >most other popular chips are strict about alignment, and will fail an
> >attempt to do a nonaligned fetch.
>
> Intel CPUs are detectable at compile time, righ
> ... Tom, were you able to apply the patch without problems
> ('cause this is one of the first times I post a patch in a mailing
list.)
Um, no, doesn't work at all unfortunately:
$ patch --dry <~/ean.patch
patching file isn.c
patch: malformed patch at line 6: enum isn_type { INVALID, ANY
Tom Lane wrote:
Awhile back, someone went around and made sure that all the contrib
modules had uninstall scripts, but most of the new contributions since
then don't have 'em:
adminpack hstore pg_freespacemap pgrowlocks sslinfo
all seem to need one. Also, I tested a few of the existing u
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
No one has mentioned that we page value on disk to match the CPU
alignment. This is done for efficiency, but is not strictly required.
Well, it is unless you are willing to give up support of non-Intel CPUs;
most other popular chips ar
"Jeremy Kronuz" <[EMAIL PROTECTED]> writes:
> ... Tom, were you able to apply the patch without problems
> ('cause this is one of the first times I post a patch in a mailing list.)
Um, no, doesn't work at all unfortunately:
$ patch --dry <~/ean.patch
patching file isn.c
patch: malformed pat
Awhile back, someone went around and made sure that all the contrib
modules had uninstall scripts, but most of the new contributions since
then don't have 'em:
adminpack hstore pg_freespacemap pgrowlocks sslinfo
all seem to need one. Also, I tested a few of the existing uninstall
scripts i
On Sun, 10 Sep 2006, Gregory Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Stephan Szabo <[EMAIL PROTECTED]> writes:
> > > I think if we were going to do this that all the constraint violations for
> > > unique, not null, check and foreign keys should be handled similarly, so
> > > we'
In any case the same logic that leads to it being desirable to report all the
errors to the user in a UI and not just report them one by one also applies to
the database. I'm not sure it's the most important issue in the world, but it
does seem like a "it would be nice" feature if it reported al
Tom Lane <[EMAIL PROTECTED]> writes:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > I think if we were going to do this that all the constraint violations for
> > unique, not null, check and foreign keys should be handled similarly, so
> > we'd probably want something more general than just a way
> Tom, I've checked the version in the cvs and I had made significant
changes
> from that version.
Hm, it sounds like I guessed wrong about which version was newer ... is
there something flaky about your machine's system clock? The file
timestamps in the two tarballs definitely pointed the othe
Stephan Szabo <[EMAIL PROTECTED]> writes:
> I think if we were going to do this that all the constraint violations for
> unique, not null, check and foreign keys should be handled similarly, so
> we'd probably want something more general than just a way for the ri
> triggers to do this. I don't hav
On Sun, 10 Sep 2006, Gregory Stark wrote:
> Chris Mair <[EMAIL PROTECTED]> writes:
>
> > What's the purpose of letting you insert 1000 records, then, at the end
> > say: "hah, all is rolled back becauase the 2nd record was invalid".
> > PG justly throws the exception immediately to let you know it
Chris Mair <[EMAIL PROTECTED]> writes:
> What's the purpose of letting you insert 1000 records, then, at the end
> say: "hah, all is rolled back becauase the 2nd record was invalid".
> PG justly throws the exception immediately to let you know it's futile
> inserting 998 more records.
Well there'
MAR - Secretariado Geral wrote:
> Hi everybody,
>
> First of all i'de like to apolagize cause my poor english. After this, i
> shuould say that i beleavee a year ago i brought this problem to the
> community but i donn't remember some answering about it. The problem is:
>
> Every time a users m
> First of all i'de like to apolagize cause my poor english. After this,
> i shuould say that i beleavee a year ago i brought this problem to the
> community but i donn't remember some answering about it. The problem
> is:
>
> Every time a users misses a external refrenced key the PGSql raises
46 matches
Mail list logo
