Re: [GENERAL] Building an home computer for best Poker Tracker performance

[Greg Smith]

On 07/17/2011 09:37 PM, mdxxd wrote:

My DB is big, around 5M hands(big is relative of course), I use complex
HUD(if you know what it is), run complex reports and play 12+ tables.
Complex is relatively complex to other PT users, I don't know how it
compared to other tasks.
   


That is pretty crazy.  Back when I was using Poker Tracker, I was hard 
pressed to play 3 tables at once, and after a year of regular play only 
had 25K hands of history.


To provide some more context for what this looks like to the rest of the 
list here, updates to the hand history come in at a rate that's measured 
in hands per hour, with 50 to 100 being a pretty fast table; let's call 
it 2 hands per minute.  That may not seem like too much, but there's 
actually a lot of records being written each time--the data behind a 
single hand of play is probably touching 50-ish rows.


And if you update player statistics after each hand, there can easily be 
a half dozen queries you have to run all over again to update the 
heads-up display.  And those fire for every player sitting at the table, 
potentially as many as 10.  So with 12 tables going at once, 2 hands per 
minute at each, 10 players at each table, and 6 HUD queries per player 
per hand, that works out to 24 queries per second.  Do not scoff at this 
workload assuming it will only take a core or two to keep with; if the 
HUD data really is complicated, this can add up fast.


And they look like OLAP queries; the only thing that keeps the whole 
thing managable is that only a single player is involved in each of 
them, so you're usually hitting an index.  And the data about the 
players currently active tends to get pulled into cache and stay there, 
so the working data set at any time isn't too large.



*Will PostgreSQL benefit from using hyperthreading in i7 2600k CPU? Or will
there be no noticeable performance change if I use i5 2500K CPU(i.e no HT,
just 4 cores)?
*Will there be noticeable performance improvements if I OC my CPU from
3.3ghz/3.4ghz(with turbo bust to 3.7ghz/3.8ghz) to 4.5ghz?
   


Even with 12 tables going, I don't think that a large number of cores is 
really necessary here.  You want individual cores to be as fast as 
possible for this type of application, but it's not too likely you'll be 
able to use more than 4 at once usefully.  I would guess that using a 
smaller number of cores and aiming at a really high clock speed on them 
is the better strategy for you.



RAM:
*Will there be noticeable performance improvements if I will use 16GB RAM
over 8GB RAM? I know big servers uses at least 16GB(often 32GB).
*Will there be noticeable change between CAS 9 and CAS 8/7? 1333mhz/1600mgz
ddr3 ram?
   


You want to use the fastest RAM possible here, that really matters for 
what you're doing.  I doubt the amount of data being processed at any 
time will exceed 8GB; the "hot" set here is only the hand histories for 
players who are currently sitting at tables with you.  Also, I've found 
the 4GB modules normally used reach 16GB total on a desktop system tend 
not to be quite as fast as the similar 2GB ones.


You should aim at DDR3/1600 and the lowest CAS you can find.  Your 
complex HUD updates are for the most part going to be limited by how 
fast your CPU can chew through information that's in memory, so this may 
end up being the most critical factor to your system performance.




SSD:
Different SSD excel in different areas. I know that for general PC usage, 4K
Q1 random read/write is the most important.
What is the most important for PT3(and PostgreSQL)  usage? Random? sequel?
4K/8K/16K / 32K/ +? 4K-64Thrd? 4K QD4/QD16/QD32 ? etc ...
   


Databases have a mix of sequential and random access for what you're 
doing, so you're going to want a balanced drive; no one of these factors 
is the obvious important one, they all are.


Note that most inexpensive SSD units can result in database corruption 
if your system crashes.  See 
http://wiki.postgresql.org/wiki/Reliable_Writes for more details.  This 
is much more important to get right than to worry about the drive 
benchmarks.  The only inexpensive SSD consumer drive I'm aware of that 
works well for PostgreSQL are Intel's recent 320 series.  See 
http://blog.2ndquadrant.com/en/2011/04/intel-ssd-now-off-the-sherr-sh.html 
for details.  Putting your main hand histories on one of those would 
make it very unlikely that drive I/O speed was ever a limiting factor 
for you.  Much more likely that you'll have trouble with memory maxing out.


To summarize how I would spec out this sort of system:

-Pick a reasonably priced SSD that's big enough to hold your data.  
Consider if you can justify buying 2 and using a RAID-1 to survive a 
drive failure.

-Price out the fastest DDR you can find, with 8GB probably being plenty.
-Use your remaining budget to get the fastest individual cores you can 
justify, shooting for 4 to 8 of them probably.


Two final notes:

-Make sure to follow the basic database tuning guide

[GENERAL] Rename

[salah jubeh]

Hello,

I would like to know the effect of alter table rename, I know that the some 
things are changed automatcally such as  views dependencies and forign keys and 
some things remain the same such as function defenesions.

Is there is a place where can I find the exact effect of rename 

Regards

[GENERAL] Detecting memory leaks with libpq?

[Antonio Vieiro]

Hi all,

I'm building a small C application that uses libpq and I was wondering
if there's an easy way to detect memory leaks in my code.

I think I'm calling PQclear and friends correctly, but I'd like to
double-check it. I was wondering if there's a function in libpq to
check memory-use usage/internals, or something like that.

Thanks in advance,
Antonio

P.S.: I assume this is the proper list for these sort of questions, right?

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Identify release contents

[Abraham, Danny]

Hi,

We are on 8.3.7 and interested on upgrading to the 9.0.4.

How can I verify that the bug below is fixed for 9.0.4?
( Fix Windows shared-memory allocation code (Tsutomu Yamada, Magnus) This bug 
led to the often-reported "could not reattach to shared memory" error message.)

I can tell for sure, reading the release notes that it is fixed for 8.2.18, 
8.3.8 and 8.4.1.
What about the 9.X ?

Thanks a lot

Danny

Re: [GENERAL] Identify release contents

[Craig Ringer]

On 19/07/2011 6:48 PM, Abraham, Danny wrote:


I can tell for sure, reading the release notes that it is fixed for
8.2.18, 8.3.8 and 8.4.1.


The fix should be in 9.0 too. It might not appear in the 9.0 release 
notes explicitly if 9.0 was branched off after the 8.4.1 release, 
because then 9.0 would inherit all changes from 8.4.1.


I haven't verified if that's the case, but I haven't seen any "cannot 
reattach to shared memory" errors reported here for some time, nor have 
I had any on 9.0 during any of my Windows-based testing.


If you want to be totally 100% certain you can trace the fix to exactly 
where it was applied in 9.0, check the revision history in git. See 
http://git.postgresql.org/ .


--
Craig Ringer


POST Newspapers
276 Onslow Rd, Shenton Park
Ph: 08 9381 3088 Fax: 08 9388 2258
ABN: 50 008 917 717
http://www.postnewspapers.com.au/

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Detecting memory leaks with libpq?

[dennis jenkins]

On Tue, Jul 19, 2011 at 5:41 AM, Antonio Vieiro wrote:

> Hi all,
>
> I'm building a small C application that uses libpq and I was wondering
> if there's an easy way to detect memory leaks in my code.
>
> I think I'm calling PQclear and friends correctly, but I'd like to
> double-check it. I was wondering if there's a function in libpq to
> check memory-use usage/internals, or something like that.
>

Wrap your main logic in a loop that runs it 100,000 or more times.  However,
the process itself should never exit (eg, only ever exist as one pid).  As
the process runs, monitor it with top, htop (really nice util for Linux),
vmstat, etc...  Does the memory usage go up and up, generally linearly with
time?

Run the same process using "electronic fence" [1] or "valgrind" [2].

[1] http://linux.die.net/man/3/efence  (not for finding memory leaks per se,
but useful for finding memory mis-usage.
[2] http://valgrind.org/

[GENERAL] Database Restore Fail - No liblwgeom.so

[Rebecca Clarke]

Hi there

I'm transferring a database from 8.2 to 8.4 and I have some triggers that
reference liblwgeom.so within the database.

When I restore a dump of the 8.2 database into my 8.4 database it says
that liblwgeom.so does not exist. From various forums on the internet I have
discovered that this has been replaced with the file postgis-1.5.so. Does
anyone have any recommendations on how I should proceed? I am really aiming
for the pg_restore to restore everything to the same state as the 8.2
database but seeing these trigger creations are erroring during the
restoration they are not being generated and I want to avoid having to go in
after the restore and generate them myself.

Many thanks in advance.

Rebecca

Re: [GENERAL] Detecting memory leaks with libpq?

[Craig Ringer]

On 19/07/2011 6:41 PM, Antonio Vieiro wrote:

Hi all,

I'm building a small C application that uses libpq and I was wondering
if there's an easy way to detect memory leaks in my code.

I think I'm calling PQclear and friends correctly, but I'd like to
double-check it. I was wondering if there's a function in libpq to
check memory-use usage/internals, or something like that.

If I genuinely suspected a leak and running the code in a loop showed 
continually increasing memory use, I'd use valgrind to try to track it 
down. Just like for any other kind of leak checking.


Note that some "leaks" that are reported are _normal_ in most software. 
There is absolutely no harm in not free()ing a structure that's 
allocated only once during init and never messed with afterwards. The OS 
clears the memory anyway, so free()ing it is just a waste of CPU cycles.


What you need to look for is patterns where memory is _repeatedly_ 
allocated and not free()'d . For that, you need to run quite a few 
repetitions within one process so you can tell the difference between 
the one-offs and genuine leaks.


--
Craig Ringer

POST Newspapers
276 Onslow Rd, Shenton Park
Ph: 08 9381 3088 Fax: 08 9388 2258
ABN: 50 008 917 717
http://www.postnewspapers.com.au/

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Identify release contents

[Abraham, Danny]

Thanks Craig

Yes, I am trying to get to a full confidence level.

How can I tell which version was 9.0 branched off?

Any git 101 document?


From: Abraham, Danny
Sent: Tuesday, July 19, 2011 1:49 PM
To: pgsql-general@postgresql.org
Cc: Abraham, Danny
Subject: Identify release contents

Hi,

We are on 8.3.7 and interested on upgrading to the 9.0.4.

How can I verify that the bug below is fixed for 9.0.4?
( Fix Windows shared-memory allocation code (Tsutomu Yamada, Magnus) This bug 
led to the often-reported "could not reattach to shared memory" error message.)

I can tell for sure, reading the release notes that it is fixed for 8.2.18, 
8.3.8 and 8.4.1.
What about the 9.X ?

Thanks a lot

Danny

Re: [GENERAL] [ANNOUNCE] PostgreSQL conference China 2011 Announced!

[galy lee]

Thanks.



I wanted to share some information with you all. There were nearly 80
attendees had attend this conference, most of them are PG relative engineers
from about 20 enterprises. Though there is still a lot of space to be
improved, but this is a first step of our community.



I would like to give my special thanks to Mr. Ishii and David Fetter, their
attendance give us a great encourage to push CPUG forward, also Bruce had
gave a great welcoming words by video. Thank you again.



And most of the attendees hope CPUG can have regular communication in the
conference with people from PostgreSQL community, so please do join our
conference in China next time!



Best Regards

Galy


2011/7/19 Tatsuo Ishii 

> Galy Lee,
>
> Congratulations to the huge success of CPUG 2011!  The conference was
> extremely well organized and attenders were very enthusiastic to learn
> PostgreSQL. And food was very good of course:-)
>
> I hope the Chinese PostgreSQL community is growing up taking advantage
> of the conference.
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese: http://www.sraoss.co.jp
>
> > PostgreSQL conferenceChina 2011 will be hold in July 15-16 in Guangzhou,
> > China.
> >
> >
> > Though PostgreSQL is enterprise-ready for a long time and the user
> > communities around the world are growing, but there is no formal user
> group
> > in China, the users is difficult to get support, books and technical
> > material is not sufficient. This conference is an effort to help the
> users
> > in China to deploy PostgreSQL with less pain, and try to cultivate a
> > PostgreSQL user community in China.
> >
> > The conference covers topics related to PostgreSQL:
> >
> >   * Ways in which PostgreSQL is used
> >
> >   * Case studies
> >
> >   * Performance tuning, database monitoring, disaster recovery
> >
> >   * PostgreSQL HA and clustering solutions
> >
> >   * PostGis
> >
> >   * DWH systems based on PostgreSQL
> >
> >   * hacking PostgreSQL code
> >
> >   * Migration of production systems from another database
> >
> >   * Data processing new technologies(Hadoop, NoSQL etc. )
> >
> >   * PostgreSQL 9.1 and 9.2 features in development
> >
> >
> >
> > Please join us to make this Conference as a milestone PostgreSQL
> conference
> > in China!
> >
> >
> > This conference is organized by Galy Lee(galylee((at)gmail(dot)com), if
> you
> > have any question, please contact him .
> >
> >
> > For detail please refer to the conference page:
> >
> >http://wiki.postgresql.org/wiki/Pgconchina2011
>

Re: [GENERAL] Programmer ( Postgres), Milwaukee - offsite-Remote - onsite

[Gavin Flower]

On 19/07/11 09:58, MS Rao wrote:


*Programmer ( Postgres), Milwaukee -- offsite-Remote - onsite*

We are looking for Postgres skilled programmer with the following skills:

Skills:
Strong in Postgres SQl ,
Set up of database,
Linux
RDBMS expert and strong in design

Possible to work onsite /offsite - Remote
Interested candidates please send their resumes in word format with, 
availability date, expected compensation and two references ASAP.


About Symphony

Symphony Corporation is a global technology consulting and Business 
process outsourcing company based in Madison, WI. Symphony*s process 
maturity is assessed at CMMi level IV and ISO 9001:2000 certified. 
Symphony employs over 300 people globally and has relationships with 
the world's leading companies and, fed and state agencies. Symphony 
have established a reputation as a low risk partner with our blend of 
industry experience, proven methodology expertise, and track record of 
delivering high quality services to its clients. Symphony offers very 
attractive compensation package with benefits for the right candidates.


Thanks

M.S. Rao |Director

0: 608.661.7604 I ms@symphonycorp.com 

Symphony Corporation  A SEI-CMMI Level 4 
Company


We synchronize business, technology and people

I suspect that if you want strong Linux people, you should accept CV's 
in OpenDocument format (files with an '.odt' suffix), otherwise known as 
ISO26300.


I use Linux and don't have Microsoft software, but I do have LibreOffice.

I have skills in PostgreSQL, and experience in various databases going 
back over 20 years on a variety of platforms.  However, I live in New 
Zealand, and can only provide up to about 20 hours a week.  So you are 
probably not interested in me! :-)



Cheers,
Gavin

Re: [GENERAL] Identify release contents

[Adrian Klaver]

On Tuesday, July 19, 2011 6:36:02 am Abraham, Danny wrote:
> Thanks Craig
> 
> Yes, I am trying to get to a full confidence level.
> 
> How can I tell which version was 9.0 branched off?
> 
> Any git 101 document?
> 

There is a browse-able Web site for the Postgres Git repository:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=summary

To make things easier the commit you are looking for is:

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a7e587863cab80b8896593f20b41e53d65155932

If you browse through the branch tagged 9.04(click on the tag name and then 
tree) to the files mentioned in the above commit you will see it is present in 
9.04.

-- 
Adrian Klaver
adrian.kla...@gmail.com

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] C function returns null values

[Gregor Trefs]

Finally I got it working. You were right Tom Lane. I actually did not copy the 
corrected source file onto the server and thus still had this "mysterious" 
failure. So, palloc0 is the solution. Thanks again.

Regards,
Gregor Trefs

-Ursprüngliche Nachricht-
Von: pgsql-general-ow...@postgresql.org 
[mailto:pgsql-general-ow...@postgresql.org] Im Auftrag von Gregor Trefs
Gesendet: Montag, 18. Juli 2011 17:20
Cc: pgsql-general@postgresql.org
Betreff: Re: [GENERAL] C function returns null values 

Well, yes. I wrote a little make file which takes care of this part (except 
restarting the session):

INCLUDEDIRS += -I$(shell pg_config --includedir-server) LIBDIR = -L$(shell 
pg_config --libdir) LIBINSTALL = $(shell pg_config --pkglibdir)

integrated_c.so: integrated_c.c Makefile
gcc -fpic -o integrated_c.o -c integrated_c.c 
$(INCLUDEDIRS)
gcc -shared -o integrated_c.so integrated_c.o $(LIBDIR) 
-lmpfr -lgmp 
cp integrated_c.so $(LIBINSTALL)

-Ursprüngliche Nachricht-
Von: Tom Lane [mailto:t...@sss.pgh.pa.us]
Gesendet: Montag, 18. Juli 2011 16:33
An: Gregor Trefs
Cc: pgsql-general@postgresql.org
Betreff: Re: [GENERAL] C function returns null values 

Gregor Trefs  writes:
> Thanks for your answer. I edited my code, but still get these random null 
> values. What else can I do ?

Mph ... you're aware that you have to start a fresh session to load a new 
version of a .so into the backend?

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make 
changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Identify release contents

[Albe Laurenz]

Abraham, Danny wrote:
> How can I verify that the bug below is fixed for 9.0.4?
>
> ( Fix Windows shared-memory allocation code (Tsutomu Yamada, Magnus)
This bug led to the often-
> reported "could not reattach to shared memory" error message.)
>
> I can tell for sure, reading the release notes that it is fixed for
8.2.18, 8.3.8 and 8.4.1.
>
> What about the 9.X ?

It is fixed in every release from 8.3 on.

You can tell by looking for a message like the following in
the archives of the pgsql-committers mailing list:

http://archives.postgresql.org/pgsql-committers/2009-07/msg00220.php

Yours,
Laurenz Albe

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Programmer ( Postgres), Milwaukee - offsite-Remote - onsite

[Martin Gainty]

Hi Gavin

I do'nt believe Rao would discriminate against anyone that speaks the Kings 
English.
If you want to stay in NZ Did you try sending a resume to den...@sosnoski.com
http://www.sosnoski.co.nz
Dennis' expertise is web-servicesHTH,
Martin Gainty 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.


Date: Tue, 19 Jul 2011 21:59:19 +1200
From: gavinflo...@archidevsys.co.nz
To: ms@symphonycorp.com
CC: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Programmer ( Postgres), Milwaukee - offsite-Remote - 
onsite



  



  
  
On 19/07/11 09:58, MS Rao wrote:

  
  
  
  
Programmer ( Postgres), Milwaukee –
  offsite-Remote - onsite
We
are looking for Postgres skilled programmer with the
following skills:



Skills: 

Strong in Postgres SQl , 

Set up of database, 

Linux 

RDBMS expert and strong in design
 
Possible
to work onsite /offsite - Remote

Interested candidates please send their resumes in word
format with, availability date, expected compensation and
two references ASAP.



About Symphony



Symphony Corporation is a global technology consulting and
Business process outsourcing company based in Madison, WI.
Symphony*s process maturity is assessed at CMMi level IV and
ISO 9001:2000 certified. Symphony employs over 300 people
globally and has relationships with the world's leading
companies and, fed and state agencies. Symphony have
established a reputation as a low risk partner with our
blend of industry experience, proven methodology expertise,
and track record of delivering high quality services to its
clients. Symphony offers very attractive compensation
package with benefits for the right candidates.



Thanks
 
 
 
M.S.
Rao   | Director 
0:
608.661.7604 I ms@symphonycorp.com
Symphony Corporation A
SEI-CMMI Level 4 Company  
We
synchronize business, technology and people
 
  

I suspect that if you want strong Linux people, you should accept
CV's in OpenDocument format (files with an '.odt' suffix), otherwise
known as ISO26300.



I use Linux and don't have Microsoft software, but I do have
LibreOffice.



I have skills in PostgreSQL, and experience in various databases
going back over 20 years on a variety of platforms.  However, I live
in New Zealand, and can only provide up to about 20 hours a week. 
So you are probably not interested in me! :-)





Cheers,

Gavin




  

Re: [GENERAL] Programmer ( Postgres), Milwaukee - offsite-Remote - onsite

[Scott Ribe]

On Jul 19, 2011, at 9:27 AM, Martin Gainty wrote:

> I do'nt believe Rao would discriminate against anyone that speaks the Kings 
> English.

So, what makes you think they won't hire us Americans?

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] announcements regarding tools

[Scott Ribe]

I'm not sure to whom this specifically should be addressed, but something 
that's been bugging me for a while: announcements like this morning's "AnySQL 
Maestro 11.7 released", where the announcement mentions nothing about platform 
support. And it's not just the lack of that info in announcements; on many web 
sites you have to dig for a while to find info about platform support, and I do 
not enjoy finding what looks like a nice tool, only to have to spend 5-10 
minutes to figure out that it is Windows only.

My suggestion: all such announcements should include information about 
supported platforms. Any announcement submitted without that info should be 
rejected, and the vendor instructed to add it before re-submission.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Detecting memory leaks with libpq?

[Ben Chobot]

On Jul 19, 2011, at 6:28 AM, Craig Ringer wrote:

> Note that some "leaks" that are reported are _normal_ in most software. There 
> is absolutely no harm in not free()ing a structure that's allocated only once 
> during init and never messed with afterwards. The OS clears the memory 
> anyway, so free()ing it is just a waste of CPU cycles.

Getting off topic here but "normal" isn't always "desirable." Some might say 
that allocating singletons and never freeing them - even after they're no 
longer valid - is just sloppy code. By the same logic, dangling pointers are 
A-OK, so long as you never use them. So yes, it might be an extra cycle or two 
to free it now, but that's a cycle or two the OS won't have to do later, and 
it's almost certainly better to have a cleaner codebase that's 0.01% slower.

Or so some might argue. :)
-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] announcements regarding tools

[Leif Biberg Kristensen]

On Tuesday 19. July 2011 18.44.46 Scott Ribe wrote:
> I'm not sure to whom this specifically should be addressed, but something
> that's been bugging me for a while: announcements like this morning's
> "AnySQL Maestro 11.7 released", where the announcement mentions nothing
> about platform support. And it's not just the lack of that info in
> announcements; on many web sites you have to dig for a while to find info
> about platform support, and I do not enjoy finding what looks like a nice
> tool, only to have to spend 5-10 minutes to figure out that it is Windows
> only.
> 
> My suggestion: all such announcements should include information about
> supported platforms. Any announcement submitted without that info should
> be rejected, and the vendor instructed to add it before re-submission.

I totally agree. In particular, Windows users seems to think that everybody 
else is using their platform, much as right-handers seem to unconsciously deny 
the existence of left-handers.

The corollary being that if the announcement doesn't explicitly say otherwise, 
you can assume with about 99% confidence that the touted product is Windoze 
only.

regards, Leif

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] timezone help?

[David Salisbury]

I'm a bit new to PG, and having troubles with timestamps.  The docs list:

timestamp [ (p) ] [ without time zone ] 8 bytes both date and time  4713 BC 
5874897 AD  1 microsecond / 14 digits
timestamp [ (p) ] with time zone8 bytes both date and time, with time 
zone  4713 BC 5874897 AD  1 microsecond / 14 digits

But an example of how to call to_timestamp either with or without a TZ would 
help.



My immediate problem is below..

create or replace function get_thermom_type(siteid integer, observationtime 
timestamp)

select get_thermom_type(1,to_timestamp('01-JAN-2011','DD-MON-') );
ERROR:  function get_thermom_type(integer, timestamp with time zone) does not 
exist
LINE 1: select get_thermom_type(1,to_timestamp('01-JAN-2011','DD-MON...
   ^
HINT:  No function matches the given name and argument types. You might need to 
add explicit type casts.


How do I tell to_timestamp to forget the about time zones?  this didn't work 
either:

get_thermom_type(1,to_timestamp('01-JAN-2011 HH24:MI','DD-MON- 13:01') 
without time zone);
nor a bunch of other attempts.


Thanks for any help,

-Dave

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] timezone help?

[Adrian Klaver]

On Tuesday, July 19, 2011 12:01:19 pm David Salisbury wrote:
> I'm a bit new to PG, and having troubles with timestamps.  The docs list:
> 
> timestamp [ (p) ] [ without time zone ]   8 bytes both date and time  
> 4713
> BC5874897 AD  1 microsecond / 14 digits timestamp [ (p) ] with time 
> zone  
8
> bytes both date and time, with time zone  4713 BC 5874897 AD  1 
> microsecond
> / 14 digits
> 
> But an example of how to call to_timestamp either with or without a TZ
> would help.
> 
> 
> 
> My immediate problem is below..
> 
> create or replace function get_thermom_type(siteid integer, observationtime
> timestamp)
> 
> select get_thermom_type(1,to_timestamp('01-JAN-2011','DD-MON-') );
> ERROR:  function get_thermom_type(integer, timestamp with time zone) does
> not exist LINE 1: select
> get_thermom_type(1,to_timestamp('01-JAN-2011','DD-MON... ^
> HINT:  No function matches the given name and argument types. You might
> need to add explicit type casts.
> 
> 
> How do I tell to_timestamp to forget the about time zones?  this didn't
> work either:
> 
> get_thermom_type(1,to_timestamp('01-JAN-2011 HH24:MI','DD-MON- 13:01')
> without time zone); nor a bunch of other attempts.

How about:
test(5432)aklaver=>SELECT to_timestamp('01-JAN-2011','DD-MON-')::timestamp;
to_timestamp 
-
 2011-01-01 00:00:00


> 
> 
> Thanks for any help,
> 
> -Dave

-- 
Adrian Klaver
adrian.kla...@gmail.com

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] A few user-level questions on Streaming Replication and pg_upgrade

[Gurjeet Singh]

Hi,

Here are a few questions that were asked by a customer, who are trying
to assess the pros and cons of using Postgres and its SR feature. I would
like to get an opinion of someone more involved with the community than me.

.) Will Postgres support Streaming Replication from 9.0.x to 9.1.x; i.e.
across major releases.

I am pretty sure the answer is "no, it won't", but just double-checking
with the community.

.) Is Streaming Replication supported across minor releases, in reverse
direction; e.g. 9.0.3 to 9.0.1

I think the answer is "it depends", since it would depend upon whether
any SR related bug has been fixed in the 'greater' of the minor releases.

I am assuming that smaller minor release to bigger minor release will
always be supported (e.g. 9.0.1 to 9.0.3)

.) How reliable is `pg_upgrade -c` (dry run) currently; that is, how
accurate is pg_upgrade at predicting any potential problem with the eventual
in-place upgrade.

I'd say it is as reliable as it gets since this is the official tool
supported by the project, and it should not contain any known bugs. One has
to use the latest and greatest 'minor' version of the tool for the major
release they are upgrading to, though.

I'd also like to mention a piece of information that may be surprising
to some. Per Tom at a PGCon dinner, Postgres project does not promise
continued guarantee of in-place upgrades across future major releases.
Although the project will try hard to avoid having to make any changes that
may affect in-place upgrade capability, but if a case can be made that a
feature would give a significant improvement at the cost of compromising
this capability, then the in-place upgrade capability may be forgone for
that release.

Thanks in advance,
-- 
Gurjeet Singh
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Re: [GENERAL] timezone help?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Jul 19, 2011 at 12:15:54PM -0700, Adrian Klaver wrote:
> On Tuesday, July 19, 2011 12:01:19 pm David Salisbury wrote:
> > I'm a bit new to PG, and having troubles with timestamps.  The docs list:

[...]

> > My immediate problem is below..
> > 
> > create or replace function get_thermom_type(siteid integer, observationtime
> > timestamp)

[...]

> How about:
> test(5432)aklaver=>SELECT 
> to_timestamp('01-JAN-2011','DD-MON-')::timestamp;
> to_timestamp 
> -
>  2011-01-01 00:00:00

Simply TIMESTAMP '01-JAN-2011' should work too:

 | test=# create or replace function fu(t timestamp) returns timestamp as
 | $$
 | begin
 |   return $1;
 | end $$ language plpgsql;
 | CREATE FUNCTION
 | test=# select fu(TIMESTAMP '01-JAN-2011');
 |  fu  
 | -
 |  2011-01-01 00:00:00
 | (1 row)

Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFOJeNvBcgs9XrR2kYRAm9yAJ9EgZ3IN9Y1WrsQ9ke4rNXVGLEF6gCeI8/L
Ii66It4LvdL/6reVNti9ZBo=
=8fUi
-END PGP SIGNATURE-

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] timezone help?

[Steve Crawford]

On 07/19/2011 12:01 PM, David Salisbury wrote:


I'm a bit new to PG, and having troubles with timestamps.  The docs list:

timestamp [ (p) ] [ without time zone ]8 bytesboth date and 
time4713 BC5874897 AD1 microsecond / 14 digits
timestamp [ (p) ] with time zone8 bytesboth date and time, 
with time zone4713 BC5874897 AD1 microsecond / 14 digits


But an example of how to call to_timestamp either with or without a TZ 
would help.




My immediate problem is below..

create or replace function get_thermom_type(siteid integer, 
observationtime timestamp)


select get_thermom_type(1,to_timestamp('01-JAN-2011','DD-MON-') );
ERROR:  function get_thermom_type(integer, timestamp with time zone) 
does not exist

LINE 1: select get_thermom_type(1,to_timestamp('01-JAN-2011','DD-MON...
   ^
HINT:  No function matches the given name and argument types. You 
might need to add explicit type casts.



How do I tell to_timestamp to forget the about time zones?  this 
didn't work either:


get_thermom_type(1,to_timestamp('01-JAN-2011 HH24:MI','DD-MON- 
13:01') without time zone);

nor a bunch of other attempts.


As an aside to the other comments, if you are logging data observations 
I would use timestamp with time zone (timestamptz). Despite the name, a 
timestamp with time zone does not contain any time zone information and 
is better referred to as a "point in time". You can input or output that 
"point in time" as UTC, Antarctica/Vostok, America/Phoenix or whatever 
location is appropriate for your situation and can change the display of 
your stored points-in-time as you desire. But whether displayed as  
2011-07-19 12:00 PDT or 2011-07-19 15:00 EDT the data represents a 
distinct point in time.


If you use a basic timestamp without time zone and daylight saving time 
is in any way involved you will have ambiguity when the clock falls back 
and you have no way to accurately determine when 2011-11-06 01:30 really 
was. With a timestamp with time zone you can tell, for example, that it 
was 2011-11-06 01:30 PDT or 2011-11-06 01:30 PST.


Cheers,
Steve


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Detecting memory leaks with libpq?

[Antonio Vieiro]

Hi all,

Well, thanks for the ideas. I also prefer cleaning things up myself
before exiting.

I was expecting some small statistics from the library (connections
opened/closed, PGresults returned/freed, etc.) but I can do it myself,
before trying out  more heavyweight tools such as valgrind.

Cheers,
Antonio

2011/7/19 Ben Chobot :
> On Jul 19, 2011, at 6:28 AM, Craig Ringer wrote:
>
>> Note that some "leaks" that are reported are _normal_ in most software. 
>> There is absolutely no harm in not free()ing a structure that's allocated 
>> only once during init and never messed with afterwards. The OS clears the 
>> memory anyway, so free()ing it is just a waste of CPU cycles.
>
> Getting off topic here but "normal" isn't always "desirable." Some might say 
> that allocating singletons and never freeing them - even after they're no 
> longer valid - is just sloppy code. By the same logic, dangling pointers are 
> A-OK, so long as you never use them. So yes, it might be an extra cycle or 
> two to free it now, but that's a cycle or two the OS won't have to do later, 
> and it's almost certainly better to have a cleaner codebase that's 0.01% 
> slower.
>
> Or so some might argue. :)

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Question on utility statements and parameterization

[Chris Travers]

Hi all;

As I understand, utility statements are not generally parameterized, so:

postgres=# alter user test123 with password 'foo' valid until now() +
'1 day'::interval;
ERROR:  syntax error at or near "now"
LINE 1: ...lter user test123 with password 'foo' valid until now() + '1...

Is this by design?  If so, what is the reason?  If not, what would
have to be done to change this?

Best Wishes,
Chris Travers

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Question on utility statements and parameterization

[Pavel Stehule]

Hello

2011/7/19 Chris Travers :
> Hi all;
>
> As I understand, utility statements are not generally parameterized, so:
>
> postgres=# alter user test123 with password 'foo' valid until now() +
> '1 day'::interval;
> ERROR:  syntax error at or near "now"
> LINE 1: ...lter user test123 with password 'foo' valid until now() + '1...
>
> Is this by design?  If so, what is the reason?  If not, what would
> have to be done to change this?
>
> Best Wishes,
> Chris Travers
>

If I understand well , a utility has no plan, and a parameters are
implemented as plan's parameters.

you can use a dynamic sql in plpgql

DO $$
BEGIN
  EXECUTE 'ALTER USER test123 WITH PASSWORD 'foo' VALID UNTIL ' ||
to_char(CURRENT_DATE + 1, '-MM-DD');
END;
$$;

Regards

Pavel

> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Question on utility statements and parameterization

[Chris Travers]

On Tue, Jul 19, 2011 at 2:40 PM, Pavel Stehule  wrote:

>>
>
> If I understand well , a utility has no plan, and a parameters are
> implemented as plan's parameters.
>
> you can use a dynamic sql in plpgql
>
> DO $$
> BEGIN
>  EXECUTE 'ALTER USER test123 WITH PASSWORD 'foo' VALID UNTIL ' ||
> to_char(CURRENT_DATE + 1, '-MM-DD');
> END;
> $$;


That's currently what I do.  and if you are correct that answers my question.

The reason I was asking is that currently I maintain applications
which use pg roles as application users.  Users are allowed to change
their passwords through the sorts of dynamic SQL you mention (with
liberal uses of quote_literal and quote_ident).  These of course have
to run as security definer.

However, what this means is that frequently we have to review the code
in a detailed way to ensure that the quoting functions haven't been
omitted.  If they are omitted, well, I am sure you can appreciate the
issues that could result from sql injection in a security definer
function.  Parameterized statements would certainly make things more
robust on this side and less error prone, esp. where the error could
cause serious security problems.

Not that such code reviews are bad, but just that it wold be nice to
have the warning signs be a little more obvious.

Of course, if it can't change without major intrusive changes, it
can't change.  I've been living with it for quite a while.  Even with
the additional hassle this method of managing users still seems well
worth it.

Best Wishes,
Chris Travers

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] PgWest CFP closes in two weeks

[Joshua D. Drake]

Hey folks,

As a reminder, PgWest is in a few months and the CFP closes in two 
weeks. Get those talks in!


https://www.postgresqlconference.org/talk_types

Sincerely,

Joshua D. Drake
--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
The PostgreSQL Conference - http://www.postgresqlconference.org/
@cmdpromptinc - @postgresconf - 509-416-6579

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Another unexpected behaviour

[Shianmiin]

Shianmiin wrote:
> 
> I thought the Atomic should be at statement level, could anyone tell me
> why PostgreSQL behaves differently?
> 

re-state for clarification purpose.

Since SQL is a set language, there is no concept of row order. I thought the
checking should be on a per set operation (i.e. per statement), not per
micro operation basis (e.g. in this case, the order of operations could
result in success/failure). I don't know how strict the standard defines
here and it could be implementation specific. Still wondering why PostgreSQL
does it differently from other major DBMS?

--
View this message in context: 
http://postgresql.1045698.n5.nabble.com/Another-unexpected-behaviour-tp4610242p4612763.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Building an home computer for best Poker Tracker performance

[Bruce Momjian]

OK, did I just read Poker Tracker and SSDs in the same email --- my head
is going to explode!

Greg, tell me you didn't get involved with Postgres because of Poker
Tracker.  :-O  :-)

---

Greg Smith wrote:
> On 07/17/2011 09:37 PM, mdxxd wrote:
> > My DB is big, around 5M hands(big is relative of course), I use complex
> > HUD(if you know what it is), run complex reports and play 12+ tables.
> > Complex is relatively complex to other PT users, I don't know how it
> > compared to other tasks.
> >
> 
> That is pretty crazy.  Back when I was using Poker Tracker, I was hard 
> pressed to play 3 tables at once, and after a year of regular play only 
> had 25K hands of history.
> 
> To provide some more context for what this looks like to the rest of the 
> list here, updates to the hand history come in at a rate that's measured 
> in hands per hour, with 50 to 100 being a pretty fast table; let's call 
> it 2 hands per minute.  That may not seem like too much, but there's 
> actually a lot of records being written each time--the data behind a 
> single hand of play is probably touching 50-ish rows.
> 
> And if you update player statistics after each hand, there can easily be 
> a half dozen queries you have to run all over again to update the 
> heads-up display.  And those fire for every player sitting at the table, 
> potentially as many as 10.  So with 12 tables going at once, 2 hands per 
> minute at each, 10 players at each table, and 6 HUD queries per player 
> per hand, that works out to 24 queries per second.  Do not scoff at this 
> workload assuming it will only take a core or two to keep with; if the 
> HUD data really is complicated, this can add up fast.
> 
> And they look like OLAP queries; the only thing that keeps the whole 
> thing managable is that only a single player is involved in each of 
> them, so you're usually hitting an index.  And the data about the 
> players currently active tends to get pulled into cache and stay there, 
> so the working data set at any time isn't too large.
> 
> > *Will PostgreSQL benefit from using hyperthreading in i7 2600k CPU? Or will
> > there be no noticeable performance change if I use i5 2500K CPU(i.e no HT,
> > just 4 cores)?
> > *Will there be noticeable performance improvements if I OC my CPU from
> > 3.3ghz/3.4ghz(with turbo bust to 3.7ghz/3.8ghz) to 4.5ghz?
> >
> 
> Even with 12 tables going, I don't think that a large number of cores is 
> really necessary here.  You want individual cores to be as fast as 
> possible for this type of application, but it's not too likely you'll be 
> able to use more than 4 at once usefully.  I would guess that using a 
> smaller number of cores and aiming at a really high clock speed on them 
> is the better strategy for you.
> 
> > RAM:
> > *Will there be noticeable performance improvements if I will use 16GB RAM
> > over 8GB RAM? I know big servers uses at least 16GB(often 32GB).
> > *Will there be noticeable change between CAS 9 and CAS 8/7? 1333mhz/1600mgz
> > ddr3 ram?
> >
> 
> You want to use the fastest RAM possible here, that really matters for 
> what you're doing.  I doubt the amount of data being processed at any 
> time will exceed 8GB; the "hot" set here is only the hand histories for 
> players who are currently sitting at tables with you.  Also, I've found 
> the 4GB modules normally used reach 16GB total on a desktop system tend 
> not to be quite as fast as the similar 2GB ones.
> 
> You should aim at DDR3/1600 and the lowest CAS you can find.  Your 
> complex HUD updates are for the most part going to be limited by how 
> fast your CPU can chew through information that's in memory, so this may 
> end up being the most critical factor to your system performance.
> 
> 
> > SSD:
> > Different SSD excel in different areas. I know that for general PC usage, 4K
> > Q1 random read/write is the most important.
> > What is the most important for PT3(and PostgreSQL)  usage? Random? sequel?
> > 4K/8K/16K / 32K/ +? 4K-64Thrd? 4K QD4/QD16/QD32 ? etc ...
> >
> 
> Databases have a mix of sequential and random access for what you're 
> doing, so you're going to want a balanced drive; no one of these factors 
> is the obvious important one, they all are.
> 
> Note that most inexpensive SSD units can result in database corruption 
> if your system crashes.  See 
> http://wiki.postgresql.org/wiki/Reliable_Writes for more details.  This 
> is much more important to get right than to worry about the drive 
> benchmarks.  The only inexpensive SSD consumer drive I'm aware of that 
> works well for PostgreSQL are Intel's recent 320 series.  See 
> http://blog.2ndquadrant.com/en/2011/04/intel-ssd-now-off-the-sherr-sh.html 
> for details.  Putting your main hand histories on one of those would 
> make it very unlikely that drive I/O speed was ever a limiting factor 
> for you.  Much more likely that you'll have trouble with memory maxi

Re: [GENERAL] announcements regarding tools

[Bruce Momjian]

Leif Biberg Kristensen wrote:
> On Tuesday 19. July 2011 18.44.46 Scott Ribe wrote:
> > I'm not sure to whom this specifically should be addressed, but something
> > that's been bugging me for a while: announcements like this morning's
> > "AnySQL Maestro 11.7 released", where the announcement mentions nothing
> > about platform support. And it's not just the lack of that info in
> > announcements; on many web sites you have to dig for a while to find info
> > about platform support, and I do not enjoy finding what looks like a nice
> > tool, only to have to spend 5-10 minutes to figure out that it is Windows
> > only.
> > 
> > My suggestion: all such announcements should include information about
> > supported platforms. Any announcement submitted without that info should
> > be rejected, and the vendor instructed to add it before re-submission.
> 
> I totally agree. In particular, Windows users seems to think that everybody 
> else is using their platform, much as right-handers seem to unconsciously 
> deny 
> the existence of left-handers.
> 
> The corollary being that if the announcement doesn't explicitly say 
> otherwise, 
> you can assume with about 99% confidence that the touted product is Windoze 
> only.

We have the same problem with people posting to pgsql-jobs where they
don't mention the location of the job.  I usually email the people
privately about this.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] spacewalk and postgres

[John R Pierce]

I'm just starting to take a look at Spacewalk as a potential solution 
for managing an internal cloud of linux servers...   this is the 
opensource version of Redhat's Satellite. Traditionally its been 
hosted on an Oracle database, but they now also support PostgreSQL, but 
with this caveat...



   PostgreSQL Pre-Requisites

   In order to get Spacewalk ro run with PostgreSQL database backend,
   you need PostgreSQL 8.4 server installed on the same or different
   machine. UsePostgreSQLServerSetup
   as a
   guide to get the server installed and setup.

   Please note that the functionality of Spacewalk on PostgreSQL is
   limited and sooner than later you may hit Internal Server Error.

(from https://fedorahosted.org/spacewalk/wiki/HowToInstall)

not real thrilled with that last line, although I haven't even fired it 
up yet to know just how rough it is.


anyways, wondering if anyone in the postgres community is working with 
this project to help smooth things out?



--
john r pierceN 37, W 122
santa cruz ca mid-left coast


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] spacewalk and postgres

[Tom Lane]

John R Pierce  writes:
> I'm just starting to take a look at Spacewalk as a potential solution 
> for managing an internal cloud of linux servers...   this is the 
> opensource version of Redhat's Satellite. Traditionally its been 
> hosted on an Oracle database, but they now also support PostgreSQL, but 
> with this caveat...

> Please note that the functionality of Spacewalk on PostgreSQL is
> limited and sooner than later you may hit Internal Server Error.

> anyways, wondering if anyone in the postgres community is working with 
> this project to help smooth things out?

I'm keeping an eye on it internally to Red Hat, but not really
contributing any significant number of cycles ATM.  My understanding of
the status is that the core stuff works but there are still a lot of
Oracle dependencies in lesser-used nooks and crannies of the software.
They could really use help from people in finding, and even more
importantly patching, those Oracle-isms.  Satellite/Spacewalk is a
remarkably large code base, so it's going to be awhile before the last
such bug is gone.  If you want some kind of promise that you won't hit
any gotchas, you shouldn't use it ... but if you're willing to help fix
whatever you hit, I believe it's usable.

You might want to scan the list archives at
http://www.redhat.com/mailman/listinfo/spacewalk-list
http://www.redhat.com/mailman/listinfo/spacewalk-devel

if you'd like a deeper dive into what's happening.  The latter list
is where to send any fixes you come up with.

regards, tom lane

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] announcements regarding tools

[Greg Smith]

On 07/19/2011 09:00 PM, Bruce Momjian wrote:

We have the same problem with people posting to pgsql-jobs where they
don't mention the location of the job.  I usually email the people
privately about this.
   


Used to have.  pgsql-jobs is now moderated because the junk posts were 
starting to outnumber the real ones.  I just ejected an off-topic J2EE 
job posting earlier today that would have made it through until this 
recent change.  Jobs that are too vague on details to be useful should 
get similarly bounced back to the poster, to be reworked before they'll 
be accepted.


It's impractical to do the same thing for something as complicated as 
platform support, at least using negative reinforcement, on the more 
controversial and popular announce list.  The list of rules at 
http://wiki.postgresql.org/wiki/NewsEventsApproval is already too big 
for moderators to be expected to enforce them all correctly in every 
case; adding more isn't likely to do anything useful.  The best I think 
we could do here is update that page to encourage people to list this 
information for their own benefit, and then have some regular announcers 
lead by example, by including the sort of info Scott is asking for into 
their messages.


--
Greg Smith   2ndQuadrant USg...@2ndquadrant.com   Baltimore, MD



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Programmer ( Postgres), Milwaukee - offsite-Remote - onsite

[Greg Smith]

On 07/18/2011 05:58 PM, MS Rao wrote:


*Programmer ( Postgres), Milwaukee -- offsite-Remote - onsite*

We are looking for Postgres skilled programmer with the following skills:



Job listings are not appropriate for the pgsql-general mailing list.  
Please direct them to the pgsql-jobs list in the future instead:  
http://archives.postgresql.org/pgsql-jobs/


In addition to that being the policy here, using that list instead means 
that we can block people replying to the whole list with their resumes 
and similar details they didn't mean to make public (which does happen).


--
Greg Smith   2ndQuadrant USg...@2ndquadrant.com   Baltimore, MD

Re: [GENERAL] Another unexpected behaviour

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Jul 18, 2011 at 03:18:43PM -0700, Shianmiin wrote:
> setup:
> 
> drop table if exists t1;
> create table t1 (f1 int);
> create unique index uix_t1 on t1(f1) ;
> insert into t1(f1) values (1), (2), (3);
> select * from t1;
> 
> f1
> ---
> 1
> 2
> 3
> 
> test statement:
> 
> update t1 set f1 = f1 + 1;
> 
> In PostgreSQL I got,
> ERROR:  duplicate key value violates unique constraint "uix_t1"
> DETAIL:  Key (f1)=(2) already exists.

If you look at the result, nothing changed. So it's still atomic.

The question is at which point in the transaction the constraint will be
checked (whether it's DEFERRED or IMMEDIATE in SQL talk).

PostgreSQL version < 9 can't do deferred constraint checking for unique
constraints, this is a limitation wrt SQL standard (see [1]). It seems
that it's possible for versions >= 9.0 (see [2]).

[1] 
[2] 

Hope that helps
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD4DBQFOJmpuBcgs9XrR2kYRAntiAJ90hHBs2Vz9u6u1KJLyqY1k7Pz5KwCYnMuF
gIZPVyHk883zHCfCKjcZhw==
=9ENo
-END PGP SIGNATURE-

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Another unexpected behaviour

[Chris Travers]

On Tue, Jul 19, 2011 at 10:41 PM,   wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mon, Jul 18, 2011 at 03:18:43PM -0700, Shianmiin wrote:
>> setup:
>> 
>> drop table if exists t1;
>> create table t1 (f1 int);
>> create unique index uix_t1 on t1(f1) ;
>> insert into t1(f1) values (1), (2), (3);
>> select * from t1;
>>
>> f1

If you are trying to make this work, you can add an order by to the
update and that allows you to avoid this problem.

 Best Wishes,
Chris Travers

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Building an home computer for best Poker Tracker performance

[Greg Smith]

Bruce Momjian wrote:

Greg, tell me you didn't get involved with Postgres because of Poker
Tracker.  :-O  :-)
  


Nah, both came out of my working on stock trading systems.  I just wrote 
a bit more about this whole subject at 
http://blog.2ndquadrant.com/en/2011/07/pushing-allin-with-postgresql.html 
if anyone would like to see what the actual queries look like against 
the Poker Tracker database.


One of the things you have to come to grips with when writing a trading 
system is that you can never assume something won't happen just because 
it's really unlikely.  Traders have adopted the term "black swan" to 
talk about these sort of completely unexpected things that destroy their 
bankroll.  On-line poker is quite good at teaching you this lesson 
quickly, whereas traders might go a decade or more before encountering a 
similarly unlikely event.


Lose an ace-high flush to a straight flush; lose 4 of a kind to a higher 
4 of a kind; rare, but I watched them both happen to me on multiple 
times when playing.  If I'd bet so much that I'd have been wiped out by 
either event, even though I was *sure* I would win that hand, I'd have 
been done for.  And a couple of times, I've seen the most rare thing of 
all:  the initial 3 cards come out, and I have a hand where I can only 
lose if the other player gets the exact two cards they need.  For example:


Greg:  KK
LuckyBum:  QQ
Flop:  K82

The only way the other player can win here is if the remaining cards are 
QQ, giving them 4 of a kind over my full house at the end of the hand.   
Assuming no other players are involved, that's 45 cards left in the 
deck, and the odds of them getting one of those two followed by the 
other are 2/45 * 1/44.  And yet I've lost this sort of 990:1 long shot 
multiple times.  It definitely gives you a better gut feel for 
"gambler's ruin", one that translates back into stock trading--and into 
thinking about how to really achieve high-availability for a computing 
system, too.


--
Greg Smith   2ndQuadrant USg...@2ndquadrant.com   Baltimore, MD



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Building an home computer for best Poker Tracker performance

[Stuart Cooper]

Nice to see some poker being discussed on this list. Much more
reputable than Stock Trading.

I was once on the LuckyBum side of this in a Casino Limit game.

Opponent: AT
Stuart the LuckyBum: 88
Flop: ATT

Myself and opponent checked that flop, I bet the turn 8 and was
raised, the river 8 saw
the betting go up and up and up and up (it's limit remember but
unlimited limit sized raises are allowed on the river if the action is
heads up).
Opponent was pretty surprised to lose, after his third river raise I
began to consider he might even have hold TT for better quads
than mine.

It's nice to get Perfect/Perfect once in your life.

We've all got a lot more time for stock trading, PostgreSQL and other
pursuits after the last two months in the Poker world.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] spacewalk and postgres

[John R Pierce]

On 07/19/11 7:58 PM, Tom Lane wrote:

I'm keeping an eye on it internally to Red Hat, but not really
contributing any significant number of cycles ATM.  My understanding of
the status is that the core stuff works but there are still a lot of
Oracle dependencies in lesser-used nooks and crannies of the software.
They could really use help from people in finding, and even more
importantly patching, those Oracle-isms.  Satellite/Spacewalk is a
remarkably large code base, so it's going to be awhile before the last
such bug is gone.  If you want some kind of promise that you won't hit
any gotchas, you shouldn't use it ... but if you're willing to help fix
whatever you hit, I believe it's usable.



great, thats what I wanted to hear.while work is an oracle shop, I 
personally hate dealing with oracle and I know we're trying to get away 
from it as much as possible, and I'm definately much happier working 
with postgres.I've sort out a few mysql->pg issues in a couple php 
projects (drupal, mybb) in the past and submitted bug reports with 
proposed fixes...



You might want to scan the list archives at
http://www.redhat.com/mailman/listinfo/spacewalk-list
http://www.redhat.com/mailman/listinfo/spacewalk-devel

if you'd like a deeper dive into what's happening.  The latter list
is where to send any fixes you come up with.


I'll remember that.   first, I think I'll install it and figure out how 
it all plays, as of right now, I've only spent about 45 minutes browsing 
the wiki and such and haven't even had the time to attempt a trial 
install.   I'm getting a couple new servers in my lab at work in a 
couple weeks, and hope to be able to start using a deployment tool 
instead of hand installing everything.


--
john r pierceN 37, W 122
santa cruz ca mid-left coast


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general