Bruce,
The binary was compiled in 32bit mode using Sun Studio compiler, and we
plan to do 64bit soon. Can you point me to the patch? We can certainly
test it!
Regards,
Robert
Bruce Momjian wrote:
Do they work on x86-64 processors using the Solaris compiler? We have a
patch for it in CVS b
Rollback Mountain
A raw, powerful story of two young transactions, one serializable
and the other read-committed, who meet in the summer of 2005 updating
tables in the harsh, high-volume environment of a contemporary
online trading system and form an unorthodox yet session-long bond --
by turns ec
Daisuke Maki wrote:
> Hi,
>
> First, apologies if my question is a bit off-course. Please feel free to
> direct me to a different mailing list if not appropriate.
>
> I'm currently trying to embed Senna full text search engine
> (http://qwik.jp/senna/) into postgres. I'm trying to achieve this by
Do they work on x86-64 processors using the Solaris compiler? We have a
patch for it in CVS but it is not in 8.1.X, and we could use someone to
eyeball and test it.
---
Robert Lor wrote:
>
> With big thanks to Josh Berkus
Folks,
> We have tightly integrated PostgreSQL with Solaris in a manner similar
> to the Linux distributions available on postgresql.org. In fact, the
> directory structures are identical. Starting with Solaris 10 Update 2,
> PostgreSQL will be distributed with every copy of Solaris, via download
With big thanks to Josh Berkus and Devrim Gunduz, I'm happy to announce
that Sun has just released a Solaris distribution of PostgreSQL 8.1.2
with ready-to-install packages for both Sparc and x86. These packages
are currently in Beta, and we expect to FCS in 2 -3 weeks. The
packages, along
On 2006-01-25, Greg Stark <[EMAIL PROTECTED]> wrote:
> I've reported the bug in the one instance I've found.
> What have you found with this omission?
>
> It would be passing strange since most software just passes the text to
> inet_aton or inet_pton.
STANDARDS
The inet_ntop() and inet_pton
We found a bug in the code from my first patch. Since it was a low
frequency, non-destructive type of problem for us, I was able to take my
time and look over the task a little more closely. Attached is a patch
which should come close to implementing the TODO. In particular, it is
now implemente
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> On 2006-01-25, Greg Stark <[EMAIL PROTECTED]> wrote:
> > This isn't an obscure old-fashioned thing. People really do use this syntax.
>
> Given how little code now supports 10.1 meaning 10.0.0.1, that seems a
> questionable point.
I've reported t
On Wed, Jan 25, 2006 at 06:30:47PM - I heard the voice of
Andrew - Supernews, and lo! it spake thus:
> On 2006-01-25, Greg Stark <[EMAIL PROTECTED]> wrote:
> > This isn't an obscure old-fashioned thing. People really do use
> > this syntax.
>
> Given how little code now supports 10.1 meaning 1
On Wed, 2006-01-25 at 19:23 +0100, Thomas Hallgren wrote:
> Make it completely silent by
> default instead and then introduce a --verbose.
+1.
I imagine initdb is usually ran interactively, so I don't think having
the extra output is a big issue considering the normal case, but I think
the "If
Greg Stark <[EMAIL PROTECTED]> writes:
> If we could store inet in four bytes it would be vastly more efficient both in
> disk space usage and in cpu at runtime.
You forgot IPv6.
regards, tom lane
---(end of broadcast)---
TI
Greg Stark <[EMAIL PROTECTED]> writes:
> I always wondered why the Redhat init scripts thought it was a clever idea to
> redirect the output to /dev/null. It seems like a pessimal user interface
> choice. Every time I have to work with a Redhat machine where Postgres isn't
> starting up the first t
"Larry Rosenman" writes:
> We had a **LONG** discussion on the I/O formats back in the 7.2 timeframe.
> the current
> behavior is the result of that.
Well I wasn't around for 7.2 but I was for a discussion around 7.3, maybe it's
the same one. Regardless, back then there was an implied assumptio
Devrim GUNDUZ wrote:
> I was playing with 8.2 RPM init script and thought that instead of
> directing the output to /dev/null, it would be better to use a
> command line option for that.
This is merely an opinion. On what technical grounds would it be
"better"?
(I happen to agree with Greg's po
On Jan 25, 2006, at 10:30 AM, Andrew - Supernews wrote:
On 2006-01-25, Greg Stark <[EMAIL PROTECTED]> wrote:
This isn't an obscure old-fashioned thing. People really do use
this syntax.
Given how little code now supports 10.1 meaning 10.0.0.1, that seems a
questionable point.
All code th
On 2006-01-25, Greg Stark <[EMAIL PROTECTED]> wrote:
> I have a question in a different direction. What is the meaning of the
> network mask in the inet data type anyways? Hosts don't have network masks,
> only networks.
As far as I can tell, the "inet" semantics are supposed to represent a
networ
* Greg Stark ([EMAIL PROTECTED]) wrote:
> I have a question in a different direction. What is the meaning of the network
> mask in the inet data type anyways? Hosts don't have network masks, only
> networks.
>
> If we could store inet in four bytes it would be vastly more efficient both in
> disk
On 2006-01-25, Greg Stark <[EMAIL PROTECTED]> wrote:
> This isn't an obscure old-fashioned thing. People really do use this syntax.
Given how little code now supports 10.1 meaning 10.0.0.1, that seems a
questionable point.
>> Indeed so. However the current behaviour has neither the merit of being
I have a question in a different direction. What is the meaning of the network
mask in the inet data type anyways? Hosts don't have network masks, only
networks.
If we could store inet in four bytes it would be vastly more efficient both in
disk space usage and in cpu at runtime.
I think it woul
On 2006-01-25, Bruce Momjian wrote:
> Andrew - Supernews wrote:
>> Having the behaviour be dependent on which part of the IP space is used
>> is a total nonsense on the modern, CIDR, internet! The C in CIDR even
>> stands for "Classless", so how can you ever justify introducing _new_,
>> non-tradi
Devrim GUNDUZ wrote:
Hi,
On Wed, 2006-01-25 at 11:28 -0500, Tom Lane wrote:
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
Attached is a patch which adds --quiet and --q option to initdb.
Why is this a good idea?
I was playing with 8.2 RPM init script and thought that instead of
directing the ou
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> On 2006-01-25, Bruce Momjian wrote:
> > Agreed. 10.1 as 10.0.0.1 is an old behavior which has been removed from
> > most modern versions of networking tools.
On the contrary not only is it still widely used but it is *required* by POSIX
for the
Andrew - Supernews wrote:
> On 2006-01-25, Bruce Momjian wrote:
> > Agreed. 10.1 as 10.0.0.1 is an old behavior which has been removed from
> > most modern versions of networking tools.
>
> Indeed so. However the current behaviour has neither the merit of being
> traditional nor the merit of bei
Bruce Momjian writes:
> Devrim GUNDUZ wrote:
> > Hi,
> >
> > On Wed, 2006-01-25 at 11:28 -0500, Tom Lane wrote:
> > > Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
> > > > Attached is a patch which adds --quiet and --q option to initdb.
> > >
> > > Why is this a good idea?
> >
> > I was playing wi
On 2006-01-25, Bruce Momjian wrote:
> Agreed. 10.1 as 10.0.0.1 is an old behavior which has been removed from
> most modern versions of networking tools.
Indeed so. However the current behaviour has neither the merit of being
traditional nor the merit of being logical:
=> select '10.1'::cidr;
Devrim GUNDUZ wrote:
> Hi,
>
> On Wed, 2006-01-25 at 11:28 -0500, Tom Lane wrote:
> > Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
> > > Attached is a patch which adds --quiet and --q option to initdb.
> >
> > Why is this a good idea?
>
> I was playing with 8.2 RPM init script and thought that inst
Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > I wonder if this would be an opportunity to fix Postgres's handling of
> > addresses like '10.1'.
>
> You've mistaken this for a proposal to change the I/O behavior, which
> it is specifically not.
>
> > The standard interpretation of t
Hi,
On Wed, 2006-01-25 at 16:32 +0100, Peter Eisentraut wrote:
> > I think a command line options is better and required.
>
> I think we need more proof of that than a use case involving taking
> screen shots.
I've just explained my points as a reply to Tom's mail.
Regards,
--
The PostgreSQL
Peter Eisentraut wrote:
> Devrim GUNDUZ wrote:
> > We have the same options with reindexdb, for example.
>
> reindexdb and friends inherited that option from psql. On a green
> field, they probably wouldn't have it. psql has more complex
> semantics, so it's not clear whether that's the same t
On Tue, 2006-01-24 at 05:17, Gustavo Tonini wrote:
> pgd?
>
or taking a page out of apache's book, databased ?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: if posting/reading thr
Hi,
On Wed, 2006-01-25 at 11:28 -0500, Tom Lane wrote:
> Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
> > Attached is a patch which adds --quiet and --q option to initdb.
>
> Why is this a good idea?
I was playing with 8.2 RPM init script and thought that instead of
directing the output to /dev/nul
Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
>> I wonder if this would be an opportunity to fix Postgres's handling
>> of addresses like '10.1'.
>
> You've mistaken this for a proposal to change the I/O behavior, which
> it is specifically not.
>
>> The standard interpretation of this
If at the sort step of the first query you expect to return 2178 rows,
why would you expect to return 1 row after self-joining those results
back on to the original table?
rms=# explain analyze
rms-# select * from
rms-# ( SELECT
rms(# host_id, max(mtime) as mtime
rms(#
Greg Stark <[EMAIL PROTECTED]> writes:
> I wonder if this would be an opportunity to fix Postgres's handling of
> addresses like '10.1'.
You've mistaken this for a proposal to change the I/O behavior, which
it is specifically not.
> The standard interpretation of this is the same as '10.0.0.1'.
Martijn van Oosterhout wrote:
> On Tue, Jan 24, 2006 at 05:24:28PM -0500, Seneca Cunningham wrote:
>
>>After reading the post on -patches proposing that MemSet be changed to
>>use long instead of int32 on the grounds that a pair of x86-64 linux
>>boxes took less time to execute the long code 64*10
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
> Attached is a patch which adds --quiet and --q option to initdb.
Why is this a good idea?
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> If inet-to-cidr can zero out bits silently, then wouldn't making it an
> assignment cast be rather dangerous and error-prone?
The proposal was to make cidr-to-inet an implicit cast (happens automatically
without being requested) but make cidr-to-i
Philip Warner <[EMAIL PROTECTED]> writes:
> We just had a DB die quite nastily, and have no clear idea why.
Define "die quite nastily" ... you haven't really said what went wrong.
> 2006-01-25 12:25:31 EST [mail,5017]: ERROR: failed to fetch new tuple
> for AFTER trigger
> 2006-01-25 12:26:01 ES
Devrim GUNDUZ wrote:
> We have the same options with reindexdb, for example.
reindexdb and friends inherited that option from psql. On a green
field, they probably wouldn't have it. psql has more complex
semantics, so it's not clear whether that's the same thing.
> I think a command line opti
Hi,
On Wed, 2006-01-25 at 17:22 +0200, Devrim GUNDUZ wrote:
> On Wed, 2006-01-25 at 09:28 -0500, Andrew Dunstan wrote:
> > What's wrong with just sending stdout to /dev/null? If that eats
> error
> > messages too then we should probably fix initdb to send those to
> > stderr.
>
> We have the same
Hi Andrew,
On Wed, 2006-01-25 at 09:28 -0500, Andrew Dunstan wrote:
> What's wrong with just sending stdout to /dev/null? If that eats error
> messages too then we should probably fix initdb to send those to
> stderr.
We have the same options with reindexdb, for example. I think a command
line op
On Wed, 2006-01-25 at 16:08 +0200, Devrim GUNDUZ wrote:
> Hi,
>
> Attached is a patch which adds --quiet and --q option to initdb. I
> personally needed this option while writing a document and taking
> screenshot :) It only shows the error and warning messages, as well as
> the last lines.
>
> I
Philip Warner wrote:
> We just had a DB die quite nastily, and have no clear idea why.
>
> Looking in the system logs shows nothing out of the ordinary, and
> looking in the db logs shows a few odd records:
>
> 2006-01-25 12:25:31 EST [mail,5017]: ERROR: failed to fetch new tuple
> for AFTER tri
Hi,
Attached is a patch which adds --quiet and --q option to initdb. I
personally needed this option while writing a document and taking
screenshot :) It only shows the error and warning messages, as well as
the last lines.
I've updated the docs. Regression tests pass.
This is my first patch to
We just had a DB die quite nastily, and have no clear idea why.
Looking in the system logs shows nothing out of the ordinary, and
looking in the db logs shows a few odd records:
2006-01-25 12:25:31 EST [mail,5017]: ERROR: failed to fetch new tuple
for AFTER trigger
2006-01-25 12:26:01 EST [mail,
46 matches
Mail list logo