[GENERAL] Re: Male/female

2006-12-08 Thread Bernhard Weisshuhn
On Fri, Dec 08, 2006 at 05:26:22PM +0100, Harald Armin Massa <[EMAIL 
PROTECTED]> wrote:

> Now we just need fast, stable and native replication for " The Girl
> That Every Man Secretly Wishes He Was Married To!"

I want replication WITH that girl!

Any chance for 8.3?
  bkw

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [GENERAL] Error in installing compat-postgresql-libs rpm

2006-12-06 Thread Bernhard Weisshuhn
Devrim GUNDUZ schrieb:
> Hi,
> 
> On Wed, 2006-12-06 at 15:39 +0100, Bernhard Weisshuhn wrote:
>> error: unpacking of archive failed on file
>> /usr/lib64/libpq.so.4;4576d3af: cpio: MD5 sum mismatch
> 
> Please download the RPM from another mirror, or re-download it. I could
> not duplicate that error.

I don't get it. I tried three mirrors, all gave me the same file.
I verified the md5sum against the MD5SUM file on the server, it is correct.
What is going on? Something wrong with my rpm (the program)?

Could somebody verify the md5sum of /usr/lib64/libpq.so.4.1 for me?

Here is what I tried:

| % md5sum compat-postgresql-libs-4-1PGDG.x86_64.rpm
| 9d292c0a677888ffe5e37a64c2638624
compat-postgresql-libs-4-1PGDG.x86_64.rpm
|
| % rpm -qlp --verbose compat-postgresql-libs-4-1PGDG.x86_64.rpm
| -rwxr-xr-x1 rootroot   138872 Nov 26 10:21
/usr/lib64/libpq.so.4
| -rwxr-xr-x1 rootroot   138872 Nov 26 10:21
/usr/lib64/libpq.so.4.1
|
|
| % rpm2cpio compat-postgresql-libs-4-1PGDG.x86_64.rpm | cpio -idv
| ./usr/lib64/libpq.so.4
| ./usr/lib64/libpq.so.4.1
| 544 blocks
|
| % md5sum usr/lib64/libpq.so.4.1
| eb5c38c731f4e0bb0a52a3a267c0b43d  usr/lib64/libpq.so.4.1
|
| % sudo rpm -Uvh compat-postgresql-libs-4-1PGDG.x86_64.rpm
| Preparing...
### [100%]
|1:compat-postgresql-libs
### [100%]
| error: unpacking of archive failed on file
/usr/lib64/libpq.so.4;4576de9b: cpio: MD5 sum mismatch
|
| % rpm -q rpm cpio
| rpm-4.4.2-32
| cpio-2.6-21.fc6


any hint appreciated,
bkw

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [GENERAL] Error in installing compat-postgresql-libs rpm

2006-12-06 Thread Bernhard Weisshuhn
Devrim GUNDUZ schrieb:
> Hi,
> 
> On Wed, 2006-12-06 at 13:14 +0100, Albe Laurenz wrote:
>> I have notified the packager and hope that the problem will be fixed
>> soon. 
> 
> After thinking about it a bit, I thought it is the only solution to
> prepare different RPMs per platform :-(
> 
> Per this, I built new packages for RHEL4 for both x86 and x86_64. They
> are versioned as 2PGDG. I uploaded them. They will sync to main FTP
> server in an hour. 
> 
> Could you please test it? I could install in both on  RHEL x86_64 and
> x86 boxes.
> 
> I will be fixing FC5 and FC4 shortly.

While trying to install compat-postgresql-libs-4-1PGDG.x86_64.rpm from
the fedora-core-6-x86_64 directory on ftp.postgresql.org, I get the
following error:

   2:compat-postgresql-libs ###
[ 25%]
error: unpacking of archive failed on file
/usr/lib64/libpq.so.4;4576d3af: cpio: MD5 sum mismatch

Is the srpm for compat-postgresql downloadable somewhere?

regards,
bkw

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [GENERAL] How to increace nightly backup speed

2006-11-29 Thread Bernhard Weisshuhn
Chris Browne schrieb:

> There are other options out there that could conceivably change the
> price of compression, such as:
> 
> http://www.lzop.org/
> http://www.quicklz.com/
> 
> Of course, those are not as well known compression systems, and so are
> not as well trusted.  Maybe worth looking into, tho.

LZO is pretty much rock solid. It is used in OpenVPN and supposedly was
used for the communication with NASAs Mars Rovers Spirit and
Opportunity, if that counts as trusted.

regards,
  bkw

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org/


Re: [GENERAL] Functional Index

2006-11-22 Thread Bernhard Weisshuhn
On Wed, Nov 22, 2006 at 11:24:33AM -0500, Tom Lane <[EMAIL PROTECTED]> wrote:

> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Wed, 22 Nov 2006, Alexander Presber wrote:
> >> CREATE INDEX idx_main_subject ON pdb.main (lower(main_subject::text)
> >> using varchar_ops);
> 
> > IIRC, unless you're in C locale, you'll want varchar_pattern_ops rather
> > than varchar_ops on the index to make it considered for a LIKE search.
> 
> text_pattern_ops would be better, seeing that the output of lower() is
> text not varchar.  I'm a bit surprised the planner is able to make use
> of this index at all.


Since the original poster Alex is a colleage of mine and just ran out
the door, let me pass on his big THANK YOU on his behalf. He is all
smiles now, and the query is fast now.

He should also be wearing that ole' brown paper bag, since we even
have an inhouse wiki page documenting the need for varchar_pattern_ops :-)

Anyway, thanks a bunch everybody!

regards,
  Alex & bkw


---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [GENERAL] cyclical redundancy checksum algorithm(s)?

2006-09-28 Thread Bernhard Weisshuhn

Joachim Wieland schrieb:

On Thu, Sep 28, 2006 at 07:09:43AM +0100, John Sidney-Woollett wrote:
Why not use an update trigger on the affected tables to record a 
lastupdated timestamp value when the record is changed.



Surely this is simpler thanks computing some kind of row hash?


It depends on how you define "change". With the triggers you propose an

UPDATE table SET col = col;

is a change because there was a write operation. Any hash function's output
would be "no change" because the actual data did not change. An update might
entail an expensive update of some external data so you might want to make
sure that data really got modified.



You can always compare the old and new values in the trigger function to 
detect that kind of non-update.


bkw

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [GENERAL] PostgreSQL slammed by PHP creator

2006-09-18 Thread Bernhard Weisshuhn

Scott Ribe schrieb:
I've 
never used a hammer to put in a screw.


So I guess you're one of those ivory-tower theory-purist academic types, at
least when it comes to home repairs. As a more practical person myself, let
me just say that sometimes a 3lb hammer is exactly the right tool to get a
screw set in quickly ;-)


Old german saying: "hammered-in screw much better than screwed-in nail"

bkw

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [GENERAL] Migration

2006-09-15 Thread Bernhard Weisshuhn
On Fri, Sep 15, 2006 at 12:33:37PM -0400, Daniel Corbe <[EMAIL PROTECTED]> 
wrote:

> I heard from a bunch of PHP guys that Postgres is total crap.  Can
> anyone recommend a guide for migrating to MySQL?

Hello slashdot!


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [GENERAL] Is it possible to have multiple names for a column?

2006-09-14 Thread Bernhard Weisshuhn
On Thu, Sep 14, 2006 at 12:18:05PM -0700, [EMAIL PROTECTED] wrote:

> We have a need to rename some columns, but since we can't update both
> the database and the programs instantly, we'd like to temporarily
> assign both names to the same column while the updates are in
> progress.  Something like this would be super nifty :-)
> 
> ALTER TABLE howdy_doody ADD NAME xyzzy TO COLUMN plugh;

If the clients only read the column, you could just add the new
column and create triggers that copy the value from the other column on
any modification.
Later you drop the old column and the triggers.

Maybe an approch based on rules might work? Dunno, haven't used them yet.

regards,
  bkw

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [GENERAL] PostgreSQL slammed by PHP creator

2006-09-14 Thread Bernhard Weisshuhn

Arturo Perez wrote:


Any response to this:
http://www.internetnews.com/dev-news/article.php/3631831


Oh please! Can we skip this one?
Maybe on the advocacy groups, not on [GENERAL], pleze!

thanks,
bkw

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [GENERAL] Majordomo drops multi-line Subject:

2006-08-23 Thread Bernhard Weisshuhn

Guido Neitzer wrote:

So they don't contain line feeds or carriage returns and so the can't  
be multi-line. If a mail client sends multi line subjects it does  
something against the RFC and I assume with that, it does something  wrong.


This is the theory in RFC 2822 as far as I understand it.


I think he referred to a long subject line being "folded" as per section 
2.2.3 of rfc2822.


--
bkw

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [GENERAL] "Upcalls" (sort of) from the database

2006-04-06 Thread Bernhard Weisshuhn

Don Y wrote:

Hi,

I wasn't prepared to ask this question, yet :<  but
all the talk of stored procedures, etc. suggests
this might be a good time to venture forth...

Humor me:  assume I have done the analysis and *know*
this to be correct for my situation  :>

I want to embed a good deal of the invariant aspects
of my application *domain* in the databases that
service it -- instead of in the applications riding
*above* them.  So, I let the database, itself, do
sanity checking of data on input -- if the database
rejects the INSERT, the application *knows* there is
something wrong with the data (instead of building
libraries to check each datum in each application
and *hoping* that the checks are implemented
consistently from one application to the next, etc.)

Anyway, the problem I have is how to handle cases
where the "database" needs user confirmation of an
action (!).  I.e. it has verified that the data
coming in is legitimate (adheres to all of the rules)
and *can* be stored in the appropriate tables -- BUT,
notices "something" that causes it to wonder if the
user REALLY wants to INSERT this data.  The database
would like to alert the user to what it has noticed
and get confirmation from the user (of course, I
mean my *application* wants to do this -- but, based
on observations made *by* the database, itself).

By way of example, the *toy* application I am playing with
to explore my implementation options is a "book" database;
it tracks titles, books, authors, publishers, etc.
The sort of thing a library could use to manage its
collection.

Assume the user tries to INSERT an entry for a "book".
Legitimately, this can be:
- a new title that the database has never seen before
- a new title by an author with other titles in the database
- an existing title thus another copy of that title

However, it can also just *appear* to be a legitimate new
title!

For example, the title may match an existing entry -- but
the author may be different (e.g., misspelled, or some
"other" author listed on a book having multiple authors, etc.).
Ideally, I would like the database to suspend the INSERT,
ask for confirmation (and "why") and then, either commit
the INSERT or abort it (based on the user's response).

Nearest I can imagine, there's only one ways I can do this:
issue a query that looks for these types of problems and
based on the result, let the *application* prompt the
user for confirmation.  Then, *if* confirmed, do the real
INSERT.


You could *insert* the data and then *rollback* the transaction. Then 
you would *know* the data is *valid*.
Only if the user *confirms* the action, then you do it *again* and 
actually *commit* the transaction.


P.S. these* *stars* are *unnerving* ;-)

bkw

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [GENERAL] Implementation Suggestions

2006-03-29 Thread Bernhard Weisshuhn

Kenneth Downs wrote:

I have been meaning to investigate it because it is the only system I've 
heard of that makes the same claim that I do, which is to have 
eliminated entire categories of labor through automation.


Have you looked at http://catalyst.perl.org/ lately?
IMHO it's "Rails done right" and it's perl, so it just /has/ to be good ;-)

sorry, couldn't resist.
bkw


---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org


Re: [GENERAL] Some pgbench results

2006-03-23 Thread Bernhard Weisshuhn

Just Someone wrote:


2 10K SCSI disks in RAID1 for OS and WAL (with it's own partiton on
ext3),


You'll want the WAL on its own spindle. IIRC a separate partition on a 
shared disc won't give you much benefit. The idea is to keep the disc's 
head from moving away for other tasks. Or so they say.


regards,
bkw

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [GENERAL] ltree + gist index performance degrades significantly over a night

2006-02-27 Thread Bernhard Weisshuhn
On Mon, Feb 27, 2006 at 10:27:20AM -0800, CG <[EMAIL PROTECTED]> wrote:

> [...] I'd need to see if the space required for the varchar+btree tables are
> comparible, better, or worse than the ltree+gist tables with regards to size.

Please test this, I'm guessing (hoping actually) that having bazillions of
combinations of 26 (or so) characters (ltree labels) might be consuming
less space than having bazillions of substings in the database.

Or maybe some clever combination of both approaches?

If you find out something interesting, please let me know.

regards,
bkw


---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [GENERAL] ltree + gist index performance degrades significantly over a night

2006-02-27 Thread Bernhard Weisshuhn
On Mon, Feb 27, 2006 at 09:14:40AM -0800, CG <[EMAIL PROTECTED]> wrote:

> I could probably get even better performance out of the table, at the cost of 
> a
> significant increase in table and index size, by chopping up the columns into
> smaller chunks.
> 
> "Hello World" would yield
> 
> 'h.e.l.l.o.w.o.r.l.d'
> 'e.l.l.o.w.o.r.l.d'
> 'l.l.o.w.o.r.l.d'
> 'l.o.w.o.r.l.d'
> 'o.w.o.r.l.d'
> 'w.o.r.l.d'
> 'o.r.l.d'
> 'r.l.d'
> 
> and using a wildcard search "search_vector ~ 'o.r.l.*'" would jump right to 
> the
> vectors which start with "o.r.l" ... 

But with this approch you'd be fine with a normal varchar_ops btree index
for textfields and searching using "like 'world%'", wouldn't you?
Or is the ltree approch more efficient?

I'm not trying to be smart-assed, it's a naive question, since I'm
looking for an efficient substring search solution in postgresql myself.

regards,
bkw


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [GENERAL] Temporal Databases

2006-02-23 Thread Bernhard Weisshuhn
On Thu, Feb 23, 2006 at 03:34:36PM -0300, Rodrigo Sakai <[EMAIL PROTECTED]> 
wrote:

   
>   I'm focus on temporal databases (not temporary), and I want to know if 
> anyone here is studying this tecnologies too. So, we can exchange 
> knowlegment. Specifically, anyone who is trying to implement on postgresql 
> the aspect of time (temporal).
>   These researches are lead by Richard Snodgrass. So, anyone who have 
> something to share, please contact me!

Not sure if I understand the problem correctly, but the contrib/spi/timetravel
module does something which I think may be what you are talking about.

  
http://developer.postgresql.org/cvsweb.cgi/~checkout~/pgsql/contrib/spi/README.timetravel

The docs are a bit cryptic but you should be able to grasp if it suits
your needs. Basically you can go back to any point in tabe for a
timetravel table and make date based comparisons.

Hope this helps, forgive my ignorance if if doesn't.
  bkw


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [GENERAL] Using a 250GB RAID10 server for postgres

2005-12-06 Thread Bernhard Weisshuhn
On Tue, Dec 06, 2005 at 09:41:55AM +, Rory Campbell-Lange <[EMAIL 
PROTECTED]> wrote:

> Is it OK to use logical volume management to run an xfs partition
> hosting postgres data?

We use just that and it works splendid. It's very nice for adding space
and all that.

But I must admit that I haven't had any comments from the gurus wether
this is a wise choice performance wise.

Keep in mind that you might want devide your discs into two groups with
different physical discs so that you can make use of tablespaces. We use
them to seperate data and indexspace. Seperating the wal makes sense
only if there is nothing else accessing that disc.

just my two cents,
bkw

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster