On Thu, 2003-09-11 at 18:25, Tom Lane wrote:
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > hrm OK. Patch forthcoming
>
> BTW, I am not sure it is a good idea to suppress "redundant" vacuuming
> of shared tables in the first place. The trouble with doing so is that
> if you only
On Thursday 11 September 2003 20:13, Peter Eisentraut wrote:
> Darko Prenosil writes:
> > Here is the idea: there is problem to find out in which encoding is using
> > mo file, but we can force gettext to serve known encoding for example
> > utf8. After that we can always convert from unicode to cl
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 11, 2003 10:11 PM
To: Steve Novick
Cc: PostgreSQL-development; PostgreSQL Win32 port list
Subject: Re: [HACKERS] Win32 native port
> Below is the email that prompted me to add the derived files to
On Fri, 12 Sep 2003, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >> Right, though I am not sure people will know _slow_ configuration vs.
> >> PostgreSQL is slow.
>
> > No, but definitely something for those discussion performance to add
> > to their checklist :)
>
> > BTW
> > Below is the email that prompted me to add the derived files to
> > WIN32_DEV CVS.
>
> > However, most people don't want them in there, so I have removed them,
> > and updated the web page to recommend the nightly snapshots (which have
> > the derived files), and mentioned the tools that will
Matthew T. O'Connor wrote:
> On Thu, 2003-09-11 at 18:25, Tom Lane wrote:
> > "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > > hrm OK. Patch forthcoming
> >
> > BTW, I am not sure it is a good idea to suppress "redundant" vacuuming
> > of shared tables in the first place. The trou
Marc G. Fournier wrote:
>
>
> On Fri, 12 Sep 2003, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > >> Right, though I am not sure people will know _slow_ configuration vs.
> > >> PostgreSQL is slow.
> >
> > > No, but definitely something for those discussion performance
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Using $$[.*]\n as a lexical token is a quasi-problematic as the anchor
> is the newline, something that SQL has been free of for as long as I'm
> aware of. By using a static lexical token, such as @@, newline's
> aren't important, thus reducing the num
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> I made a patch to fix this, but in testing it I noticed that the stats
> system doesn't work on shared tables as I was expecting it too (as my
> latest patch requires it too :-). It treats instances of shared tables
> in separate databases as tota
Tom Lane wrote:
> Note that there is no particular need to insist on any nearby newlines.
> If the construct is written just following an identifier or keyword,
> then you do need some intervening whitespace to keep the $Q$ from being
> read as part of that identifier, but I doubt this will bother
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>> If we force people to give a --without-spinlocks config option to build
>> that way, then `pg_config --configure' will reveal the dirty deed ...
> That's not quite what I meant :) Right now, if I understood what Bruce
> was saying, if someone does
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Note that there is no particular need to insist on any nearby newlines.
>> If the construct is written just following an identifier or keyword,
>> then you do need some intervening whitespace to keep the $Q$ from being
>> read as part o
As part of my spinlock testing, I noticed that we test for __cpu__ when
using gcc, and __cpu when not using gcc. However, I see that my i386
gcc 2.95 defines both (shown using src/tools/ccsym):
__GNUC__=2
__GNUC_MINOR__=95
unix
__i386__
i386
__bsdi_
Tom Lane wrote:
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
I made a patch to fix this, but in testing it I noticed that the stats
system doesn't work on shared tables as I was expecting it too (as my
latest patch requires it too :-). It treats instances of shared tables
in separate databas
Bruce Momjian wrote:
> Prompted by confusion over Itanium/Opterion, I have written a patch to
> improve the way we define spinlocks for platforms and cpu's. It
> basically decouples the OS from the CPU spinlock code. In almost all
> cases, the spinlock code cares only about the compiler and CPU,
On Fri, 12 Sep 2003, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >> If we force people to give a --without-spinlocks config option to build
> >> that way, then `pg_config --configure' will reveal the dirty deed ...
>
> > That's not quite what I meant :) Right now, if I un
Marc G. Fournier wrote:
>
>
> On Fri, 12 Sep 2003, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > >> If we force people to give a --without-spinlocks config option to build
> > >> that way, then `pg_config --configure' will reveal the dirty deed ...
> >
> > > That's not
On Fri, 12 Sep 2003, Tom Lane wrote:
> I'm currently leaning to an idea that was suggested yesterday by (I
> think) Andreas: let the quote start marker be a token of the form
> dollarsign zero-or-more-letters dollarsign
> and let the quote body extend to the next occurrence of the identical
Sean Chittenden <[EMAIL PROTECTED]> writes:
> ... then @autoconf me harder@ could be used as the start and ending
> token,
Hm, I should have read your message more carefully --- I missed the bit
at the middle where you propose nearly the same idea I had ;-). But the
flex patterns you wrote don't
Tom Lane wrote:
After sleeping on it, I do think that tying the mechanism to newlines
is just unnecessary complication. I'm currently leaning to an idea that
was suggested yesterday by (I think) Andreas: let the quote start marker
be a token of the form
dollarsign zero-or-more-letters dol
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> 'K, now, I know we acquire all our shared_buffers on startup now ... do we
> do the same with semaphores?
Yes.
> If we do acquire at the start, would it not be trivial to add a message to
> the startup messages, based on #_of_semaphores != max_conn
--On Friday, September 12, 2003 09:53:10 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
As part of my spinlock testing, I noticed that we test for __cpu__ when
using gcc, and __cpu when not using gcc. However, I see that my i386
gcc 2.95 defines both (shown using src/tools/ccsym):
__GN
On Fri, Sep 12, 2003 at 08:57:16AM -0400, Merlin Moncure wrote:
> Here: http://unxutils.sourceforge.net/ are ports of several unix
> utility programs (including bison and flex) for win32. From my
> experiences compiling the Peer Direct port, this is the easiest way to
> get started.
OK, I'll thro
Hi,
after Beta1 I'd reported problems in the regression tests under Digital
Unix/Tru64. Unfortunately I had no time to report about my tests and to
check Beta2 before now.
Beta2 builds fine on Digital Unix 4.0G:
template1=# SELECT version();
version
-
Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > 'K, now, I know we acquire all our shared_buffers on startup now ... do we
> > do the same with semaphores?
>
> Yes.
>
> > If we do acquire at the start, would it not be trivial to add a message to
> > the startup messages, base
Bruce Momjian <[EMAIL PROTECTED]> writes:
> He is uncomfortable with the port/*.h changes at this point, so it seems
> I am going to have to add Itanium/Opteron tests to most of those files.
Why don't you try to put together a proposed patch of that kind, and
then we can look to see how big and ug
Bruce Momjian <[EMAIL PROTECTED]> writes:
> As part of my spinlock testing, I noticed that we test for __cpu__ when
> using gcc, and __cpu when not using gcc.
> ...
> So, I wonder if we should be testing _just_ for __cpu, perhaps starting
> in 7.5.
I might be all wet on this, but I had the idea th
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > As part of my spinlock testing, I noticed that we test for __cpu__ when
> > using gcc, and __cpu when not using gcc.
> > ...
> > So, I wonder if we should be testing _just_ for __cpu, perhaps starting
> > in 7.5.
>
> I might be all we
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I'd like to see pg_dump use this mechanism for quoting, at least for
> function bodies. I guess it could retrieve the text and then keep
> generating delimiters until it found one that didn't occur inside the
> text.
Right, that was what I had in min
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > He is uncomfortable with the port/*.h changes at this point, so it seems
> > I am going to have to add Itanium/Opteron tests to most of those files.
>
> Why don't you try to put together a proposed patch of that kind, and
> then we ca
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > I'd like to see pg_dump use this mechanism for quoting, at least for
> > function bodies. I guess it could retrieve the text and then keep
> > generating delimiters until it found one that didn't occur inside the
> > text.
>
> Rig
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Does this say that Darwin on something other than PPC doesn't have
> spinlocks? Is that going to hit a spinlock define, or fall through?
It says that darwin.h is broken, and always has been, for non-PPC
builds. Since there is no non-PPC Darwin (afaik),
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Does this say that Darwin on something other than PPC doesn't have
> > spinlocks? Is that going to hit a spinlock define, or fall through?
>
> It says that darwin.h is broken, and always has been, for non-PPC
> builds. Since there i
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I'd like to see pg_dump use this mechanism for quoting, at least for
function bodies. I guess it could retrieve the text and then keep
generating delimiters until it found one that didn't occur inside the
text.
Right, that was w
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, here is an Opteron/Itanium patch that might work.
>
> [having now read both patches]
>
> Assuming that this covers the issues (what other OSes might run on
> 64-bit machines within 7.4's lifespan?) I think there is little questio
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, here is an Opteron/Itanium patch that might work.
[having now read both patches]
Assuming that this covers the issues (what other OSes might run on
64-bit machines within 7.4's lifespan?) I think there is little question
that this is the more conser
Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >Because MinGW/Msys doesn't come with flex/bison by default, I have added
> >those derived files to the WIN32_DEV branch in CVS. It makes it easier
> >for people to install _just_ MinGW and compile PostgreSQL on Win32. The
> >branch will live for
You should find that the next daily snapshot and beta3 will properly
detect Opteron/Itanium on your platform.
I don't think we can help you with the compiler bugs, however. ;-)
---
Jeroen Ruigrok/asmodai wrote:
> -On [2003
I need someone running NetBSD to read the top of
src/tools/test_thread_funcs.c and compile and run that function and
report the results.
Thanks.
---
Christopher Kings-Lynne wrote:
> FreeBSD 4.8/i386:
>
> Your gethostbyname
Bruce Momjian writes:
> As part of my spinlock testing, I noticed that we test for __cpu__ when
> using gcc, and __cpu when not using gcc. However, I see that my i386
> gcc 2.95 defines both (shown using src/tools/ccsym):
gcc only documents the __foo__ version, so there is a small reason to lean
On Fri, 2003-09-12 at 09:35, Bruce Momjian wrote:
> Matthew T. O'Connor wrote:
> > I made a patch to fix this, but in testing it I noticed that the stats
> > system doesn't work on shared tables as I was expecting it too (as my
> > latest patch requires it too :-). It treats instances of shared tab
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > As part of my spinlock testing, I noticed that we test for __cpu__ when
> > using gcc, and __cpu when not using gcc. However, I see that my i386
> > gcc 2.95 defines both (shown using src/tools/ccsym):
>
> gcc only documents the __foo__ versi
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Even if this the stats system isn't fixed, this patch still is much
> better about monitoring system tables that aren't shared, so it's an
> improvement no matter what.
How will it act with shared tables if the stats system isn't fixed?
We may de
--On Friday, September 12, 2003 12:18:52 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
I need someone running NetBSD to read the top of
src/tools/test_thread_funcs.c and compile and run that function and
report the results.
I have access to one NetBSD system on an Alpha:
$ uname -a
NetBSD mil
> > ... then @autoconf me harder@ could be used as the start and
> > ending token,
>
> Hm, I should have read your message more carefully --- I missed the
> bit at the middle where you propose nearly the same idea I had ;-).
> But the flex patterns you wrote don't actually support this do they?
T
On Fri, 2003-09-12 at 12:46, Tom Lane wrote:
> How will it act with shared tables if the stats system isn't fixed?
> We may decide that tracking shared tables correctly will have to wait
> for 7.5.
The behavior in the patch will vacuum a shared table only from
template1, and only analyze from all
Larry Rosenman wrote:
-- Start of PGP signed section.
>
>
> --On Friday, September 12, 2003 12:18:52 -0400 Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>
> >
> > I need someone running NetBSD to read the top of
> > src/tools/test_thread_funcs.c and compile and run that function and
> > report the
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> So we would have a problem if commands that effect these tables are done
> from lots of different databases. In reality, I don't think these
> tables change that much (pg_database, pg_shadow, and pg_group), and most
> of commands that do effect t
--On Friday, September 12, 2003 13:03:33 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
-- Start of PGP signed section.
--On Friday, September 12, 2003 12:18:52 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>
> I need someone running NetBSD to read the top of
> src/tool
On Fri, 2003-09-12 at 13:06, Tom Lane wrote:
> > I can hardwire in something to hedge this off like setting the threshold
> > for shared tables much much lower than normal thresholds. I could also
> > do something more complicated and try to aggregate all the activity seen
> > by all the databases
Larry Rosenman wrote:
> > Wow, that is strange. Someone else told me NetBSD supports threads, and
> > doesn't need any special compile flags, but of course, it has to have
> > pthread.h to support threads. NetBSD 1.6.1 is very current, so it isn't
> > an old OS.
> >
> > Can you compile if you rem
--On Friday, September 12, 2003 13:30:38 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
> Wow, that is strange. Someone else told me NetBSD supports threads,
> and doesn't need any special compile flags, but of course, it has to
> have pthread.h to support threads. NetBS
> Wow, that is strange. Someone else told me NetBSD supports threads, and
> doesn't need any special compile flags, but of course, it has to have
> pthread.h to support threads. NetBSD 1.6.1 is very current, so it isn't
> an old OS.
NetBSD-1.6.1 doesn't have native thread. NetBSD-current has i
James Pye writes:
> Type conversion
>
> plpython's current type conversion implementation appears to be dependent
> on strings as the common format. This is fine, but not very extensible as
> is, unless you don't mind explicitly parsing strings inside each function
> that takes an unsupporte
[EMAIL PROTECTED] ("Matthew T. O'Connor") writes:
> So we would have a problem if commands that effect these tables are done
> from lots of different databases. In reality, I don't think these
> tables change that much (pg_database, pg_shadow, and pg_group), and most
> of commands that do effect t
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
He is uncomfortable with the port/*.h changes at this point, so it seems
I am going to have to add Itanium/Opteron tests to most of those files.
Why don't you try to put together a proposed patch of that
Hello:
1st Beta 1 version of PGSqlClient an ADO.NET Data Provider for
PostgreSQL 7.4+ released.
Beta 1 ( 12-09-2003 )
- - -- -- -
* Better fit to ADO.NET.
* Simple Transport Layer security ( TLS 1.0 ) implementation
It's used yet for both TLS and non-TLS connections but it's not finis
Manfred Spraul wrote:
Is the Itanium tas implementation correct? I think it should be
xchg4.aqv instead of just xchg4 - as far as I know a normal atomic
exchange is is not a memory barrier on Itanium. At least the Linux
kernel version contains "cmpxchg4.aqv".
Sorry for the noise, I'm wrong:
Ita
[EMAIL PROTECTED] ("Matthew T. O'Connor") writes:
> OK, well as we wait on the fix for the stats system, let me submit my
> patch for pg_autovacuum. This patch assumes that the stats system will
> be fixed so that all inserts, updates and deletes performed on shared
> tables reguardless of what da
Manfred Spraul <[EMAIL PROTECTED]> writes:
> Is the Itanium tas implementation correct?
FWIW, this evening I did a few dozen iterations of "make check" parallel
regression tests on a 4-way Itanium box at Red Hat's Toronto office,
working from CVS-tip sources. No sign of problems. That's not a pr
On Fri, 12 Sep 2003, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > OK, here is an Opteron/Itanium patch that might work.
> >
> > [having now read both patches]
> >
> > Assuming that this covers the issues (what other OSes might run on
> > 64-bit machi
Tilo Schwarz wrote:
What about the Python approach: The literal text is enclosed either in a pair
of three single quotes or three double quotes. So you can do (e.g. in the
python shell)
It'll only make plpyhon functions harder to write, if you need to use
longstring quoting INSIDE your plpython
62 matches
Mail list logo
