Thursday, May 29, 2008

Re: [GENERAL] New MS patent: sounds like PG db rules

Martin wrote:
which is the reason why i think Design Patterns and Patterns are unpatentable..too many cooks created these meals to attribute to any one or group of individuals
That will never happen and it if it does it years away.  we must deal with the current problems in front of us not worry to much about what we want or could be the shape of laws in the future.
The real challenge is the submittal process where one must submit at least 50% of the patentable code..what do you submit?
Sense the Postgresql is open source there is no internal secretes that needs to be protected, submit the entire code that makes the specific patentable part work. 

I always thought PostGIS whose algorithms were unique enough and whose creators were from a sufficiently small population
to place PostGIS into 'patentable' code but apparently PostGIS is firmly declared under 'GPL' to quote
"To prevent this, we have made it clear that any patent must be licensed for everyone's free use .."
So there is no current obstructions to doing this as Postgresql is licensed today
Recalling an earlier year when a Lowell MA based company offered proprietary software which did'nt interoperate with other (GPL software..)
MS on the other hand seems to patent unique algorithms and or methodologies which are specific only to MS environments...
Only objective is to protect everyone from stupid and ridiculous lawsuits.  The entire blackberry lawsuit is example of things to come. Where another company had a patented that process of moving email to a phone for years but never used it.  This company waited in the background for years for the service to become popular then sued blackberry.  It cost millions of dollars to defend and it was nothing more than legal stealing. 

I can see MS or other company patenting a process that Postgresql  has used for some time or independently invented it gets sued over as a means to extract money from companies and others that used the tool.

I'm proposing a CYA that could be used to protect all open source projects not just postgresql.  Instead of complaining about how wrong the system is and the need to change it is.  Use the system to protect the project.

 
Interesting..
Martin
----- Original Message -----
From: Justin
Sent: Thursday, May 29, 2008 10:33 AM
Subject: Re: [GENERAL] New MS patent: sounds like PG db rules



Nikola Milutinovic wrote:
Still, this sounds dangerous. It should be, even legally, WRONG to patent something that already exist and was not invented by the patentee. I know we can laugh off MS in court, but what about new DBs or project even built on PG that have this functionality? Software patents are a menace, I'm afraid. And this is still just one portion. IBM is also into this line of "work".

Nix.

----- Original Message ----
From: Dave Page <dpage@pgadmin.org>
To: Justin Clift <justin@salasaga.org>
Cc: Jonathan Bond-Caron <jbondc@gmail.com>; A. Kretschmer <andreas.kretschmer@schollglas.com>; pgsql-general@postgresql.org
Sent: Tuesday, May 27, 2008 3:18:31 PM
Subject: Re: [GENERAL] New MS patent: sounds like PG db rules

HI Justin

On Tue, May 27, 2008 at 2:06 PM, Justin Clift <justin@salasaga.org> wrote:

> I'm trying to point out that - PG is a database system - and MS may have
> just been granted a patent for a fundamental part of it.
>
> Thinking it might need looking in to, and trying to bring it to the
> attention of some that can (or even cares?). ;>

I don't think it's a major issue. Even if MS do think we infringe on
the patent it would be laughable for them to try to do anything about
it given that our rules implementation has provably existed in a
leading FOSS project for a decade or more.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

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

Question???  Does the license that Postgresql works under allow for a foundation or non for profit entity be created  that would hold onto patents for original  ideas of the contributors so WE can protect the users and developers of postgresql

The idea start playing the game MS and other Software companies are playing where they keep applying for  patents/copyrights where there is prior art.  This would protect everyone  in the development chain from having defend stupid lawsuits that these companies could bring against the biggest offenders.

USPTO  only looks at existing patents and trademarks to see if they can issue a patent   So if a patent  makes claims on already existing art it puts the burden on the original inventor to get the patent revoke.  Doing the above would help put an end to this.

This is just a suggestion.

Re: [pgus-board] "State of" Lightning talk at OSCON

On Wed, 2008-05-28 at 22:53 -0400, Michael Alan Brewer wrote:
> Hey, y'all; should we submit a "State of USPgA" Lightning talk at
> OSCON (per Josh Berkus' CfP)?

You bet. State of US PostgreSQL?

Joshua D. Drake

>
> ---Michael Brewer
> mbrewer@gmail.com
>


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

Re: [HACKERS] Core team statement on replication in PostgreSQL

On 5/29/08, David Fetter <david@fetter.org> wrote:
> On Thu, May 29, 2008 at 10:12:55AM -0400, Tom Lane wrote:
> > Ideally this would be coupled with the ability to execute read-only
> > queries on the slave servers, but we see technical difficulties that
> > might prevent that from being completed before 8.5 or even further
> > out. (The big problem is that long-running slave-side queries might
> > still need tuples that are vacuumable on the master, and so
> > replication of vacuuming actions would cause the slave's queries to
> > deliver wrong answers.)
>
> This part is a deal-killer. It's a giant up-hill slog to sell warm
> standby to those in charge of making resources available because the
> warm standby machine consumes SA time, bandwidth, power, rack space,
> etc., but provides no tangible benefit, and this feature would have
> exactly the same problem.
>
> IMHO, without the ability to do read-only queries on slaves, it's not
> worth doing this feature at all.

I would not be so harsh - I'd like to have the lossless standby even
without read-only slaves.

But Tom's mail gave me impression core wants to wait until we get "perfect"
read-only slave implementation so we wait with it until 8.6, which does
not seem sensible. If we can do slightly inefficient (but simple)
implementation
right now, I see no reason to reject it, we can always improve it later.

Especially as it can be switchable. And we could also have
transaction_timeout paramenter on slaves so the hit on master is limited.

--
marko

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

[SQL] How long - Vacumm full - 10 million to 90,000

Good morning,

A question about VACUUM FULL. The docs say:

VACUUM FULL is recommended for cases where you know you have deleted the
majority of rows in a table, so that the steady-state size of the table
can be shrunk substantially with VACUUM FULL's more aggressive approach.
Use plain VACUUM, not VACUUM FULL, for routine vacuuming for space recovery.

I have a table from around 10 million to 90,000, after deletion, I tried
to use vacuum full, but it seems that it takes forever to finish. Could
anyone tell me how long it will take to finish the Recovering disk space
please?

Thanks a lot!

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

Re: [HACKERS] Upcoming back-branch update releases

On Thu, May 29, 2008 at 4:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> IIRC I made a few cosmetic cleanups along with the actual bug fix.
> I'll take a look this afternoon and put it in.

Thanks.

--
Guillaume

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

Re: [HACKERS] Proposal - Collation at database level

Radek Strnad napsal(a):

<snip>

>
> I'm thinking of dividing the problem into two parts - in beginning
> pg_collation will contain two functions. One will have hard-coded rules
> for these basic collations (SQL_CHARACTER, GRAPHIC_IRV, LATIN1, ISO8BIT,
> UCS_BASIC). It will compare each string character bitwise and guarantee
> that the implementation will meet the SQL standard implemented in
> PostgreSQL.
>
> Second one will allow the user to use installed system locales. The set
> of these collations will obviously vary between systems. Catalogs will
> contain encoding and collation for calling the system locale function.
> This will allow us to use collations such as en_US.utf8, cs_CZ.iso88592
> etc. if they will be availible.
>
> We will also need to change the way how strings are compared. Regarding
> the set database collation the right function will be used.
> http://doxygen.postgresql.org/varlena_8c.html#4c7af81f110f9be0bd8eb2bd99525675
>
> This design will make possible switch to ICU or any other implementation
> quite simple and will not cause any major rewriting of what I'm coding
> right now.


Collation function is main point here. How you mentioned one will be only
wrapper about strcmp and second one about strcoll. (maybe you need four -
char/wchar) Which function will be used it is defined in pg_collation catalog by
CREATE COLLATION command. But you need specify name of locale for system
locales. It means you need attribute for storing locale name.

<snip>

> CATALOG(pg_collations, ###)
> {
> NameData colname; /* collation name */
> Oid colschema; /* collation schema */
> bool colpadattribute; /* pad attribute */
> bool colcasesensitive; /* case sensitive */
> bool colaccent; /* accent sensitive */
> regproc colfunc; /* used collation function */
> Oid colrepertoire; /* collation repertoire */
>
> } FormData_pg_collations;
>

It would be good to send list of new and modified SQL commands (like CREATE
COLLATION) for wide discussion.


Zdenek

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

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 10:12:55AM -0400, Tom Lane wrote:
> The Postgres core team met at PGCon to discuss a few issues, the
> largest of which is the need for simple, built-in replication for
> PostgreSQL. Historically the project policy has been to avoid
> putting replication into core PostgreSQL, so as to leave room for
> development of competing solutions, recognizing that there is no
> "one size fits all" replication solution. However, it is becoming
> clear that this policy is hindering acceptance of PostgreSQL to too
> great an extent, compared to the benefit it offers to the add-on
> replication projects. Users who might consider PostgreSQL are
> choosing other database systems because our existing replication
> options are too complex to install and use for simple cases. In
> practice, simple asynchronous single-master-multiple-slave
> replication covers a respectable fraction of use cases, so we have
> concluded that we should allow such a feature to be included in the
> core project. We emphasize that this is not meant to prevent
> continued development of add-on replication projects that cover more
> complex use cases.
>
> We believe that the most appropriate base technology for this is
> probably real-time WAL log shipping, as was demoed by NTT OSS at
> PGCon. We hope that such a feature can be completed for 8.4.

> Ideally this would be coupled with the ability to execute read-only
> queries on the slave servers, but we see technical difficulties that
> might prevent that from being completed before 8.5 or even further
> out. (The big problem is that long-running slave-side queries might
> still need tuples that are vacuumable on the master, and so
> replication of vacuuming actions would cause the slave's queries to
> deliver wrong answers.)

This part is a deal-killer. It's a giant up-hill slog to sell warm
standby to those in charge of making resources available because the
warm standby machine consumes SA time, bandwidth, power, rack space,
etc., but provides no tangible benefit, and this feature would have
exactly the same problem.

IMHO, without the ability to do read-only queries on slaves, it's not
worth doing this feature at all.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

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

Re: [GENERAL] New MS patent: sounds like PG db rules

which is the reason why i think Design Patterns and Patterns are unpatentable..too many cooks created these meals to attribute to any one or group of individuals
The real challenge is the submittal process where one must submit at least 50% of the patentable code..what do you submit?

I always thought PostGIS whose algorithms were unique enough and whose creators were from a sufficiently small population
to place PostGIS into 'patentable' code but apparently PostGIS is firmly declared under 'GPL' to quote
"To prevent this, we have made it clear that any patent must be licensed for everyone's free use .."
Recalling an earlier year when a Lowell MA based company offered proprietary software which did'nt interoperate with other (GPL software..)
MS on the other hand seems to patent unique algorithms and or methodologies which are specific only to MS environments...
 
Interesting..
Martin
----- Original Message -----
From: Justin
Sent: Thursday, May 29, 2008 10:33 AM
Subject: Re: [GENERAL] New MS patent: sounds like PG db rules



Nikola Milutinovic wrote:
Still, this sounds dangerous. It should be, even legally, WRONG to patent something that already exist and was not invented by the patentee. I know we can laugh off MS in court, but what about new DBs or project even built on PG that have this functionality? Software patents are a menace, I'm afraid. And this is still just one portion. IBM is also into this line of "work".

Nix.

----- Original Message ----
From: Dave Page <dpage@pgadmin.org>
To: Justin Clift <justin@salasaga.org>
Cc: Jonathan Bond-Caron <jbondc@gmail.com>; A. Kretschmer <andreas.kretschmer@schollglas.com>; pgsql-general@postgresql.org
Sent: Tuesday, May 27, 2008 3:18:31 PM
Subject: Re: [GENERAL] New MS patent: sounds like PG db rules

HI Justin

On Tue, May 27, 2008 at 2:06 PM, Justin Clift <justin@salasaga.org> wrote:

> I'm trying to point out that - PG is a database system - and MS may have
> just been granted a patent for a fundamental part of it.
>
> Thinking it might need looking in to, and trying to bring it to the
> attention of some that can (or even cares?). ;>

I don't think it's a major issue. Even if MS do think we infringe on
the patent it would be laughable for them to try to do anything about
it given that our rules implementation has provably existed in a
leading FOSS project for a decade or more.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

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

Question???  Does the license that Postgresql works under allow for a foundation or non for profit entity be created  that would hold onto patents for original  ideas of the contributors so WE can protect the users and developers of postgresql

The idea start playing the game MS and other Software companies are playing where they keep applying for  patents/copyrights where there is prior art.  This would protect everyone  in the development chain from having defend stupid lawsuits that these companies could bring against the biggest offenders.

USPTO  only looks at existing patents and trademarks to see if they can issue a patent   So if a patent  makes claims on already existing art it puts the burden on the original inventor to get the patent revoke.  Doing the above would help put an end to this.

This is just a suggestion.

[pgadmin-hackers] SVN Commit by dpage: r7322 - in branches/REL-1_8_0_EDB/pgadmin3: . pgadmin/frm

Author: dpage

Date: 2008-05-29 16:16:55 +0100 (Thu, 29 May 2008)

New Revision: 7322

Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=7322&view=rev

Log:
Ensure the grant wizard works correctly with EDB stored procedures.


Modified:
branches/REL-1_8_0_EDB/pgadmin3/CHANGELOG
branches/REL-1_8_0_EDB/pgadmin3/pgadmin/frm/frmGrantWizard.cpp

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

[pgadmin-hackers] SVN Commit by dpage: r7321 - in branches/REL-1_8_0_PATCHES/pgadmin3: . pgadmin/frm

Author: dpage

Date: 2008-05-29 16:16:28 +0100 (Thu, 29 May 2008)

New Revision: 7321

Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=7321&view=rev

Log:
Ensure the grant wizard works correctly with EDB stored procedures.


Modified:
branches/REL-1_8_0_PATCHES/pgadmin3/CHANGELOG
branches/REL-1_8_0_PATCHES/pgadmin3/pgadmin/frm/frmGrantWizard.cpp

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

[pgadmin-hackers] SVN Commit by dpage: r7320 - in trunk/pgadmin3: . pgadmin/frm

Author: dpage

Date: 2008-05-29 16:16:02 +0100 (Thu, 29 May 2008)

New Revision: 7320

Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=7320&view=rev

Log:
Ensure the grant wizard works correctly with EDB stored procedures.


Modified:
trunk/pgadmin3/CHANGELOG
trunk/pgadmin3/pgadmin/frm/frmGrantWizard.cpp

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

Re: [BUGS] BUG #4208: Server crashes on insert into gist index

Tom,

Thanks for the quick response. No:

sp_hub_production=# select distinct cube_dim(attribute_vector) from
user_attribute_vectors;
cube_dim
----------
5
(1 row)

In the past we had a problem where runt vectors found their way into
the table, but we deleted them and try to detect them on their way in.

This happened once before and then stopped. That's when we started
capturing core files. I suspect that it happens when our user base
grows enough to force a split on insert with just the right record. We
will probably see a fallow period and it will happen again after we
get another couple thousand users.

Ron

Ron Mackley
Manager, Software Development
Signal Patterns
ronm@signalpatterns.com

==========================================================
The information contained in this email message may be privileged,
confidential and protected from disclosure. If you are not the
intended recipient, any distribution or copying is strictly
prohibited. If you think that you have received this email message in
error, please notify the sender by reply email and delete the message
and any attachments.


On 29 May 2008, at 10:54 AM, Tom Lane wrote:

> "Ron Mackley" <ronm@signalpatterns.com> writes:
>> We've been seeing infrequent crashes of the postgres. This is
>> version 8.2.6
>> running on Red Hat Enterprise 5.1 on x64 using redhat issued RPMs.
>
>> We captured a core file and here is the stack trace:
>
>> (gdb) bt
>> #0 0x0000000000615b5a in pfree (pointer=0x2aaaccaff318) at mcxt.c:
>> 585
>> #1 0x00002aaace72ab59 in cube_inter (fcinfo=0x7fff102205f0) at
>> cube.c:898
>> #2 0x0000000000602b14 in DirectFunctionCall2 (func=0x2aaace72aa00
>> <cube_inter>, arg1=46913066890008, arg2=5) at fmgr.c:888
>> #3 0x00002aaace72a73b in g_cube_picksplit (fcinfo=<value optimized
>> out>) at
>> cube.c:571
>
> Hmmm ... just looking at the code, I bet what is happening is that the
> "swap" path in cube_inter is taken, and then the comparisons in
> PG_FREE_IF_COPY get confused and try to pfree values that were not
> separately allocated. But if that's the story, why does cube_inter
> not
> show a crash rate approaching 50%? Maybe most people only use it on
> cubes of the same dimensionality. Does your gist index contain cubes
> of varying numbers of dimensions?
>
> regards, tom lane


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

Re: [HACKERS] Upcoming back-branch update releases

Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> No, nothing's been done about that AFAIK. What's the consensus,
>> do we want to change that behavior in 8.3.2?

> I think everyone but me wanted it backpatched, so let's do it. I have
> posted both patches but I am unable to apply your additions becuause I
> don't understand them well enough.

IIRC I made a few cosmetic cleanups along with the actual bug fix.
I'll take a look this afternoon and put it in.

regards, tom lane

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

Re: [BUGS] BUG #4208: Server crashes on insert into gist index

"Ron Mackley" <ronm@signalpatterns.com> writes:
> We've been seeing infrequent crashes of the postgres. This is version 8.2.6
> running on Red Hat Enterprise 5.1 on x64 using redhat issued RPMs.

> We captured a core file and here is the stack trace:

> (gdb) bt
> #0 0x0000000000615b5a in pfree (pointer=0x2aaaccaff318) at mcxt.c:585
> #1 0x00002aaace72ab59 in cube_inter (fcinfo=0x7fff102205f0) at cube.c:898
> #2 0x0000000000602b14 in DirectFunctionCall2 (func=0x2aaace72aa00
> <cube_inter>, arg1=46913066890008, arg2=5) at fmgr.c:888
> #3 0x00002aaace72a73b in g_cube_picksplit (fcinfo=<value optimized out>) at
> cube.c:571

Hmmm ... just looking at the code, I bet what is happening is that the
"swap" path in cube_inter is taken, and then the comparisons in
PG_FREE_IF_COPY get confused and try to pfree values that were not
separately allocated. But if that's the story, why does cube_inter not
show a crash rate approaching 50%? Maybe most people only use it on
cubes of the same dimensionality. Does your gist index contain cubes
of varying numbers of dimensions?

regards, tom lane

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

Re: [HACKERS] Core team statement on replication in PostgreSQL

On 5/29/08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The Postgres core team met at PGCon to discuss a few issues, the largest
> of which is the need for simple, built-in replication for PostgreSQL.
> Historically the project policy has been to avoid putting replication
> into core PostgreSQL, so as to leave room for development of competing
> solutions, recognizing that there is no "one size fits all" replication
> solution. However, it is becoming clear that this policy is hindering
> acceptance of PostgreSQL to too great an extent, compared to the benefit
> it offers to the add-on replication projects. Users who might consider
> PostgreSQL are choosing other database systems because our existing
> replication options are too complex to install and use for simple cases.
> In practice, simple asynchronous single-master-multiple-slave
> replication covers a respectable fraction of use cases, so we have
> concluded that we should allow such a feature to be included in the core
> project. We emphasize that this is not meant to prevent continued
> development of add-on replication projects that cover more complex use
> cases.
>
> We believe that the most appropriate base technology for this is
> probably real-time WAL log shipping, as was demoed by NTT OSS at PGCon.
> We hope that such a feature can be completed for 8.4.

+1

Although I would explain it more shortly - we do need a solution for
lossless failover servers and such solution needs to live in core backend.

> Ideally this
> would be coupled with the ability to execute read-only queries on the
> slave servers, but we see technical difficulties that might prevent that
> from being completed before 8.5 or even further out. (The big problem
> is that long-running slave-side queries might still need tuples that are
> vacuumable on the master, and so replication of vacuuming actions would
> cause the slave's queries to deliver wrong answers.)

Well, both Slony-I and upcoming Skytools 3 have the same problem when
cleaning events and have it solved simply by slaves reporting back their
lowest position on event stream. I cannot see why it cannot be applied
in this case too. So each slave just needs to report its own longest
open tx as "open" to master. Yes, it bloats master but no way around it.

Only problem could be the plan to vacuum tuples updated in between long
running tx and the regular ones, but such behaviour can be just turned off.

We could also have a option of "inaccessible slave", for those who
fear bloat on master.

--
marko

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

Re: [PATCHES] pg_lzcompress patch for 8.3, 8.2 branch

Tom Lane napsal(a):
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> Tom Lane napsal(a):
>>> On the other hand, I remain unconvinced that this problem is severe
>>> enough to justify much backporting work. AFAIK we've only seen one
>>> occurence of a problem to date.
>
>> I know about two occurrence. One was reported on -bug
>> (http://archives.postgresql.org/pgsql-bugs/2008-04/msg00206.php)
>> and second was reported from our customer.
>
> I'm still not impressed. Bear in mind that the patch you are so eager
> to backport has received *zero* field testing, which means there's a
> non-negligible risk that there's something wrong with it.

Our customers uses the patch (version 8.2) on 2TB heavy loaded table which
contains text field with average size ~10kB. He have used it for two months
without any problem. I think it is good field testing. It helped him to fix
corrupted data problems without any random crash or downtime.

> Add on the
> non-negligible risk of messing up something associated with back-porting
> the earlier patch, and consider that back-branch minor releases go out
> with no field testing to speak of (there's the build farm but that's
> about it). You have to seriously question whether the risk is worth
> what is surely an extremely marginal stability improvement.

I don't need it to backport to 8.1 and older. Yeah, It was my eager activity.
I'm happy with 8.3 and 8.2 backport.

thanks Zdenek


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

Re: [HACKERS] Upcoming back-branch update releases

On Thu, May 29, 2008 at 4:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> No, nothing's been done about that AFAIK. What's the consensus,
> do we want to change that behavior in 8.3.2?

IIRC, noone voted against backpatching it after Alvaro and you agreed
with doing so.

Archives link: http://archives.postgresql.org/pgsql-hackers/2008-05/msg00243.php

It would be nice to have it fixed in 8.3.2, even if it's not really
blocking for the release.

--
Guillaume

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

Re: [HACKERS] Upcoming back-branch update releases

Tom Lane wrote:
> "Guillaume Smet" <guillaume.smet@gmail.com> writes:
> > On Wed, May 28, 2008 at 4:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> If you've got any bug fixes you've been working on, now is a good time
> >> to get them finished up and sent in...
>
> > Has the s/\x09/ /g patch for psql from Bruce and you been
> > backported to 8.3? I didn't see it on pgsql-commiters.
>
> No, nothing's been done about that AFAIK. What's the consensus,
> do we want to change that behavior in 8.3.2?

I think everyone but me wanted it backpatched, so let's do it. I have
posted both patches but I am unable to apply your additions becuause I
don't understand them well enough.

--
Bruce Momjian <bruce@momjian.us>

http://momjian.us

EnterpriseDB

http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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

Re: [PATCHES] [HACKERS] Upcoming back-branch update releases

Index: src/bin/psql/mbprint.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/mbprint.c,v
retrieving revision 1.31
retrieving revision 1.32
diff -c -r1.31 -r1.32
*** src/bin/psql/mbprint.c 8 May 2008 17:04:26 -0000 1.31
--- src/bin/psql/mbprint.c 8 May 2008 19:11:36 -0000 1.32
***************
*** 3,9 ****
*
* Copyright (c) 2000-2008, PostgreSQL Global Development Group
*
! * $PostgreSQL: pgsql/src/bin/psql/mbprint.c,v 1.31 2008/05/08 17:04:26 momjian Exp $
*
* XXX this file does not really belong in psql/. Perhaps move to libpq?
* It also seems that the mbvalidate function is redundant with existing
--- 3,9 ----
*
* Copyright (c) 2000-2008, PostgreSQL Global Development Group
*
! * $PostgreSQL: pgsql/src/bin/psql/mbprint.c,v 1.32 2008/05/08 19:11:36 momjian Exp $
*
* XXX this file does not really belong in psql/. Perhaps move to libpq?
* It also seems that the mbvalidate function is redundant with existing
***************
*** 321,326 ****
--- 321,334 ----
linewidth += 2;
ptr += 2;
}
+ else if (*pwcs == '\t') /* Tab */
+ {
+ do
+ {
+ *ptr++ = ' ';
+ linewidth++;
+ } while (linewidth % 8 != 0);
+ }
else if (w < 0) /* Other control char */
{
sprintf((char *) ptr, "\\x%02X", *pwcs);
Index: src/test/regress/expected/prepare.out
===================================================================
RCS file: /cvsroot/pgsql/src/test/regress/expected/prepare.out,v
retrieving revision 1.15
retrieving revision 1.16
diff -c -r1.15 -r1.16
*** src/test/regress/expected/prepare.out 18 Jun 2007 21:40:58 -0000 1.15
--- src/test/regress/expected/prepare.out 8 May 2008 19:11:36 -0000 1.16
***************
*** 155,169 ****
name | statement | parameter_types
------+-----------------------------------------------------------------+--------------------------------------------------------
q2 | PREPARE q2(text) AS | {text}
! : \x09SELECT datname, datistemplate, datallowconn
! : \x09FROM pg_database WHERE datname = $1;
q3 | PREPARE q3(text, int, float, boolean, oid, smallint) AS | {text,integer,"double precision",boolean,oid,smallint}
! : \x09SELECT * FROM tenk1 WHERE string4 = $1 AND (four = $2 OR
! : \x09ten = $3::bigint OR true = $4 OR oid = $5 OR odd = $6::int)
! : \x09ORDER BY unique1;
q5 | PREPARE q5(int, text) AS | {integer,text}
! : \x09SELECT * FROM tenk1 WHERE unique1 = $1 OR stringu1 = $2
! : \x09ORDER BY unique1;
q6 | PREPARE q6 AS | {integer,name}
: SELECT * FROM tenk1 WHERE unique1 = $1 AND stringu1 = $2;
q7 | PREPARE q7(unknown) AS | {path}
--- 155,171 ----
name | statement | parameter_types
------+-----------------------------------------------------------------+--------------------------------------------------------
q2 | PREPARE q2(text) AS | {text}
! : SELECT datname, datistemplate, datallowconn
! : FROM pg_database WHERE datname = $1;
q3 | PREPARE q3(text, int, float, boolean, oid, smallint) AS | {text,integer,"double precision",boolean,oid,smallint}
! : SELECT * FROM tenk1 WHERE string4 = $1 AND (four = $2 O
! ; R
! : ten = $3::bigint OR true = $4 OR oid = $5 OR odd = $6::
! ; int)
! : ORDER BY unique1;
q5 | PREPARE q5(int, text) AS | {integer,text}
! : SELECT * FROM tenk1 WHERE unique1 = $1 OR stringu1 = $2
! : ORDER BY unique1;
q6 | PREPARE q6 AS | {integer,name}
: SELECT * FROM tenk1 WHERE unique1 = $1 AND stringu1 = $2;
q7 | PREPARE q7(unknown) AS | {path}
Index: src/bin/psql/mbprint.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/mbprint.c,v
retrieving revision 1.32
retrieving revision 1.33
diff -c -r1.32 -r1.33
*** src/bin/psql/mbprint.c 8 May 2008 19:11:36 -0000 1.32
--- src/bin/psql/mbprint.c 9 May 2008 05:25:04 -0000 1.33
***************
*** 3,9 ****
*
* Copyright (c) 2000-2008, PostgreSQL Global Development Group
*
! * $PostgreSQL: pgsql/src/bin/psql/mbprint.c,v 1.32 2008/05/08 19:11:36 momjian Exp $
*
* XXX this file does not really belong in psql/. Perhaps move to libpq?
* It also seems that the mbvalidate function is redundant with existing
--- 3,9 ----
*
* Copyright (c) 2000-2008, PostgreSQL Global Development Group
*
! * $PostgreSQL: pgsql/src/bin/psql/mbprint.c,v 1.33 2008/05/09 05:25:04 tgl Exp $
*
* XXX this file does not really belong in psql/. Perhaps move to libpq?
* It also seems that the mbvalidate function is redundant with existing
***************
*** 205,216 ****
* pg_wcssize takes the given string in the given encoding and returns three
* values:
* result_width: Width in display characters of the longest line in string
! * result_height: Number of newlines in display output
! * result_format_size: Number of bytes required to store formatted representation of string
*/
! int
! pg_wcssize(unsigned char *pwcs, size_t len, int encoding, int *result_width,
! int *result_height, int *result_format_size)
{
int w,
chlen = 0,
--- 205,219 ----
* pg_wcssize takes the given string in the given encoding and returns three
* values:
* result_width: Width in display characters of the longest line in string
! * result_height: Number of lines in display output
! * result_format_size: Number of bytes required to store formatted
! * representation of string
! *
! * This MUST be kept in sync with pg_wcsformat!
*/
! void
! pg_wcssize(unsigned char *pwcs, size_t len, int encoding,
! int *result_width, int *result_height, int *result_format_size)
{
int w,
chlen = 0,
***************
*** 241,246 ****
--- 244,257 ----
linewidth += 2;
format_size += 2;
}
+ else if (*pwcs == '\t') /* Tab */
+ {
+ do
+ {
+ linewidth++;
+ format_size++;
+ } while (linewidth % 8 != 0);
+ }
else if (w < 0) /* Other control char */
{
linewidth += 4;
***************
*** 266,272 ****
}
if (linewidth > width)
width = linewidth;
! format_size += 1;

/* Set results */
if (result_width)
--- 277,283 ----
}
if (linewidth > width)
width = linewidth;
! format_size += 1; /* For NUL char */

/* Set results */
if (result_width)
***************
*** 275,288 ****
*result_height = height;
if (result_format_size)
*result_format_size = format_size;
-
- return width;
}

/*
! * Filter out unprintable characters, companion to wcs_size.
! * Break input into lines based on \n. lineptr[i].ptr == NULL
! * indicates the end of the array.
*/
void
pg_wcsformat(unsigned char *pwcs, size_t len, int encoding,
--- 286,298 ----
*result_height = height;
if (result_format_size)
*result_format_size = format_size;
}

/*
! * Format a string into one or more "struct lineptr" lines.
! * lines[i].ptr == NULL indicates the end of the array.
! *
! * This MUST be kept in sync with pg_wcssize!
*/
void
pg_wcsformat(unsigned char *pwcs, size_t len, int encoding,
***************
*** 309,315 ****
linewidth = 0;
lines++;
count--;
! if (count == 0)
exit(1); /* Screwup */

/* make next line point to remaining memory */
--- 319,325 ----
linewidth = 0;
lines++;
count--;
! if (count <= 0)
exit(1); /* Screwup */

/* make next line point to remaining memory */
***************
*** 346,359 ****
if (encoding == PG_UTF8)
sprintf((char *) ptr, "\\u%04X", utf2ucs(pwcs));
else
!
/*
* This case cannot happen in the current code because only
* UTF-8 signals multibyte control characters. But we may need
* to support it at some stage
*/
sprintf((char *) ptr, "\\u????");
!
ptr += 6;
linewidth += 6;
}
--- 356,369 ----
if (encoding == PG_UTF8)
sprintf((char *) ptr, "\\u%04X", utf2ucs(pwcs));
else
! {
/*
* This case cannot happen in the current code because only
* UTF-8 signals multibyte control characters. But we may need
* to support it at some stage
*/
sprintf((char *) ptr, "\\u????");
! }
ptr += 6;
linewidth += 6;
}
***************
*** 370,376 ****
lines->width = linewidth;
*ptr++ = '\0'; /* Terminate formatted string */

! if (count == 0)
exit(1); /* Screwup */

(lines+1)->ptr = NULL; /* terminate line array */
--- 380,386 ----
lines->width = linewidth;
*ptr++ = '\0'; /* Terminate formatted string */

! if (count <= 0)
exit(1); /* Screwup */

(lines+1)->ptr = NULL; /* terminate line array */
Index: src/bin/psql/mbprint.h
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/mbprint.h,v
retrieving revision 1.11
retrieving revision 1.12
diff -c -r1.11 -r1.12
*** src/bin/psql/mbprint.h 4 Oct 2006 00:30:06 -0000 1.11
--- src/bin/psql/mbprint.h 9 May 2008 05:25:04 -0000 1.12
***************
*** 1,4 ****
! /* $PostgreSQL: pgsql/src/bin/psql/mbprint.h,v 1.11 2006/10/04 00:30:06 momjian Exp $ */
#ifndef MBPRINT_H
#define MBPRINT_H

--- 1,4 ----
! /* $PostgreSQL: pgsql/src/bin/psql/mbprint.h,v 1.12 2008/05/09 05:25:04 tgl Exp $ */
#ifndef MBPRINT_H
#define MBPRINT_H

***************
*** 13,18 ****

extern int pg_wcswidth(const unsigned char *pwcs, size_t len, int encoding);
extern void pg_wcsformat(unsigned char *pwcs, size_t len, int encoding, struct lineptr * lines, int count);
! extern int pg_wcssize(unsigned char *pwcs, size_t len, int encoding, int *width, int *height, int *format_size);

#endif /* MBPRINT_H */
--- 13,19 ----

extern int pg_wcswidth(const unsigned char *pwcs, size_t len, int encoding);
extern void pg_wcsformat(unsigned char *pwcs, size_t len, int encoding, struct lineptr * lines, int count);
! extern void pg_wcssize(unsigned char *pwcs, size_t len, int encoding,
! int *width, int *height, int *format_size);

#endif /* MBPRINT_H */
Index: src/test/regress/expected/prepare.out
===================================================================
RCS file: /cvsroot/pgsql/src/test/regress/expected/prepare.out,v
retrieving revision 1.16
retrieving revision 1.17
diff -c -r1.16 -r1.17
*** src/test/regress/expected/prepare.out 8 May 2008 19:11:36 -0000 1.16
--- src/test/regress/expected/prepare.out 9 May 2008 05:25:54 -0000 1.17
***************
*** 16,22 ****
SELECT name, statement, parameter_types FROM pg_prepared_statements;
name | statement | parameter_types
------+------------------------------+-----------------
! q1 | PREPARE q1 AS SELECT 1 AS a; | {}
(1 row)

-- should fail
--- 16,22 ----
SELECT name, statement, parameter_types FROM pg_prepared_statements;
name | statement | parameter_types
------+------------------------------+-----------------
! q1 | PREPARE q1 AS SELECT 1 AS a; | {}
(1 row)

-- should fail
***************
*** 35,42 ****
SELECT name, statement, parameter_types FROM pg_prepared_statements;
name | statement | parameter_types
------+------------------------------+-----------------
! q1 | PREPARE q1 AS SELECT 2; | {}
! q2 | PREPARE q2 AS SELECT 2 AS b; | {}
(2 rows)

-- sql92 syntax
--- 35,42 ----
SELECT name, statement, parameter_types FROM pg_prepared_statements;
name | statement | parameter_types
------+------------------------------+-----------------
! q1 | PREPARE q1 AS SELECT 2; | {}
! q2 | PREPARE q2 AS SELECT 2 AS b; | {}
(2 rows)

-- sql92 syntax
***************
*** 44,50 ****
SELECT name, statement, parameter_types FROM pg_prepared_statements;
name | statement | parameter_types
------+------------------------------+-----------------
! q2 | PREPARE q2 AS SELECT 2 AS b; | {}
(1 row)

DEALLOCATE PREPARE q2;
--- 44,50 ----
SELECT name, statement, parameter_types FROM pg_prepared_statements;
name | statement | parameter_types
------+------------------------------+-----------------
! q2 | PREPARE q2 AS SELECT 2 AS b; | {}
(1 row)

DEALLOCATE PREPARE q2;
***************
*** 61,67 ****
EXECUTE q2('regression');
datname | datistemplate | datallowconn
------------+---------------+--------------
! regression | f | t
(1 row)

PREPARE q3(text, int, float, boolean, oid, smallint) AS
--- 61,67 ----
EXECUTE q2('regression');
datname | datistemplate | datallowconn
------------+---------------+--------------
! regression | f | t
(1 row)

PREPARE q3(text, int, float, boolean, oid, smallint) AS
***************
*** 71,105 ****
EXECUTE q3('AAAAxx', 5::smallint, 10.5::float, false, 500::oid, 4::bigint);
unique1 | unique2 | two | four | ten | twenty | hundred | thousand | twothousand | fivethous | tenthous | odd | even | stringu1 | stringu2 | string4
---------+---------+-----+------+-----+--------+---------+----------+-------------+-----------+----------+-----+------+----------+----------+---------
! 2 | 2716 | 0 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 4 | 5 | CAAAAA | MAEAAA | AAAAxx
! 102 | 612 | 0 | 2 | 2 | 2 | 2 | 102 | 102 | 102 | 102 | 4 | 5 | YDAAAA | OXAAAA | AAAAxx
! 802 | 2908 | 0 | 2 | 2 | 2 | 2 | 802 | 802 | 802 | 802 | 4 | 5 | WEAAAA | WHEAAA | AAAAxx
! 902 | 1104 | 0 | 2 | 2 | 2 | 2 | 902 | 902 | 902 | 902 | 4 | 5 | SIAAAA | MQBAAA | AAAAxx
! 1002 | 2580 | 0 | 2 | 2 | 2 | 2 | 2 | 1002 | 1002 | 1002 | 4 | 5 | OMAAAA | GVDAAA | AAAAxx
! 1602 | 8148 | 0 | 2 | 2 | 2 | 2 | 602 | 1602 | 1602 | 1602 | 4 | 5 | QJAAAA | KBMAAA | AAAAxx
! 1702 | 7940 | 0 | 2 | 2 | 2 | 2 | 702 | 1702 | 1702 | 1702 | 4 | 5 | MNAAAA | KTLAAA | AAAAxx
! 2102 | 6184 | 0 | 2 | 2 | 2 | 2 | 102 | 102 | 2102 | 2102 | 4 | 5 | WCAAAA | WDJAAA | AAAAxx
! 2202 | 8028 | 0 | 2 | 2 | 2 | 2 | 202 | 202 | 2202 | 2202 | 4 | 5 | SGAAAA | UWLAAA | AAAAxx
! 2302 | 7112 | 0 | 2 | 2 | 2 | 2 | 302 | 302 | 2302 | 2302 | 4 | 5 | OKAAAA | ONKAAA | AAAAxx
! 2902 | 6816 | 0 | 2 | 2 | 2 | 2 | 902 | 902 | 2902 | 2902 | 4 | 5 | QHAAAA | ECKAAA | AAAAxx
! 3202 | 7128 | 0 | 2 | 2 | 2 | 2 | 202 | 1202 | 3202 | 3202 | 4 | 5 | ETAAAA | EOKAAA | AAAAxx
! 3902 | 9224 | 0 | 2 | 2 | 2 | 2 | 902 | 1902 | 3902 | 3902 | 4 | 5 | CUAAAA | UQNAAA | AAAAxx
! 4102 | 7676 | 0 | 2 | 2 | 2 | 2 | 102 | 102 | 4102 | 4102 | 4 | 5 | UBAAAA | GJLAAA | AAAAxx
! 4202 | 6628 | 0 | 2 | 2 | 2 | 2 | 202 | 202 | 4202 | 4202 | 4 | 5 | QFAAAA | YUJAAA | AAAAxx
! 4502 | 412 | 0 | 2 | 2 | 2 | 2 | 502 | 502 | 4502 | 4502 | 4 | 5 | ERAAAA | WPAAAA | AAAAxx
! 4702 | 2520 | 0 | 2 | 2 | 2 | 2 | 702 | 702 | 4702 | 4702 | 4 | 5 | WYAAAA | YSDAAA | AAAAxx
! 4902 | 1600 | 0 | 2 | 2 | 2 | 2 | 902 | 902 | 4902 | 4902 | 4 | 5 | OGAAAA | OJCAAA | AAAAxx
! 5602 | 8796 | 0 | 2 | 2 | 2 | 2 | 602 | 1602 | 602 | 5602 | 4 | 5 | MHAAAA | IANAAA | AAAAxx
! 6002 | 8932 | 0 | 2 | 2 | 2 | 2 | 2 | 2 | 1002 | 6002 | 4 | 5 | WWAAAA | OFNAAA | AAAAxx
! 6402 | 3808 | 0 | 2 | 2 | 2 | 2 | 402 | 402 | 1402 | 6402 | 4 | 5 | GMAAAA | MQFAAA | AAAAxx
! 7602 | 1040 | 0 | 2 | 2 | 2 | 2 | 602 | 1602 | 2602 | 7602 | 4 | 5 | KGAAAA | AOBAAA | AAAAxx
! 7802 | 7508 | 0 | 2 | 2 | 2 | 2 | 802 | 1802 | 2802 | 7802 | 4 | 5 | COAAAA | UCLAAA | AAAAxx
! 8002 | 9980 | 0 | 2 | 2 | 2 | 2 | 2 | 2 | 3002 | 8002 | 4 | 5 | UVAAAA | WTOAAA | AAAAxx
! 8302 | 7800 | 0 | 2 | 2 | 2 | 2 | 302 | 302 | 3302 | 8302 | 4 | 5 | IHAAAA | AOLAAA | AAAAxx
! 8402 | 5708 | 0 | 2 | 2 | 2 | 2 | 402 | 402 | 3402 | 8402 | 4 | 5 | ELAAAA | OLIAAA | AAAAxx
! 8602 | 5440 | 0 | 2 | 2 | 2 | 2 | 602 | 602 | 3602 | 8602 | 4 | 5 | WSAAAA | GBIAAA | AAAAxx
! 9502 | 1812 | 0 | 2 | 2 | 2 | 2 | 502 | 1502 | 4502 | 9502 | 4 | 5 | MBAAAA | SRCAAA | AAAAxx
! 9602 | 9972 | 0 | 2 | 2 | 2 | 2 | 602 | 1602 | 4602 | 9602 | 4 | 5 | IFAAAA | OTOAAA | AAAAxx
(29 rows)

-- too few params
--- 71,105 ----
EXECUTE q3('AAAAxx', 5::smallint, 10.5::float, false, 500::oid, 4::bigint);
unique1 | unique2 | two | four | ten | twenty | hundred | thousand | twothousand | fivethous | tenthous | odd | even | stringu1 | stringu2 | string4
---------+---------+-----+------+-----+--------+---------+----------+-------------+-----------+----------+-----+------+----------+----------+---------
! 2 | 2716 | 0 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 4 | 5 | CAAAAA | MAEAAA | AAAAxx
! 102 | 612 | 0 | 2 | 2 | 2 | 2 | 102 | 102 | 102 | 102 | 4 | 5 | YDAAAA | OXAAAA | AAAAxx
! 802 | 2908 | 0 | 2 | 2 | 2 | 2 | 802 | 802 | 802 | 802 | 4 | 5 | WEAAAA | WHEAAA | AAAAxx
! 902 | 1104 | 0 | 2 | 2 | 2 | 2 | 902 | 902 | 902 | 902 | 4 | 5 | SIAAAA | MQBAAA | AAAAxx
! 1002 | 2580 | 0 | 2 | 2 | 2 | 2 | 2 | 1002 | 1002 | 1002 | 4 | 5 | OMAAAA | GVDAAA | AAAAxx
! 1602 | 8148 | 0 | 2 | 2 | 2 | 2 | 602 | 1602 | 1602 | 1602 | 4 | 5 | QJAAAA | KBMAAA | AAAAxx
! 1702 | 7940 | 0 | 2 | 2 | 2 | 2 | 702 | 1702 | 1702 | 1702 | 4 | 5 | MNAAAA | KTLAAA | AAAAxx
! 2102 | 6184 | 0 | 2 | 2 | 2 | 2 | 102 | 102 | 2102 | 2102 | 4 | 5 | WCAAAA | WDJAAA | AAAAxx
! 2202 | 8028 | 0 | 2 | 2 | 2 | 2 | 202 | 202 | 2202 | 2202 | 4 | 5 | SGAAAA | UWLAAA | AAAAxx
! 2302 | 7112 | 0 | 2 | 2 | 2 | 2 | 302 | 302 | 2302 | 2302 | 4 | 5 | OKAAAA | ONKAAA | AAAAxx
! 2902 | 6816 | 0 | 2 | 2 | 2 | 2 | 902 | 902 | 2902 | 2902 | 4 | 5 | QHAAAA | ECKAAA | AAAAxx
! 3202 | 7128 | 0 | 2 | 2 | 2 | 2 | 202 | 1202 | 3202 | 3202 | 4 | 5 | ETAAAA | EOKAAA | AAAAxx
! 3902 | 9224 | 0 | 2 | 2 | 2 | 2 | 902 | 1902 | 3902 | 3902 | 4 | 5 | CUAAAA | UQNAAA | AAAAxx
! 4102 | 7676 | 0 | 2 | 2 | 2 | 2 | 102 | 102 | 4102 | 4102 | 4 | 5 | UBAAAA | GJLAAA | AAAAxx
! 4202 | 6628 | 0 | 2 | 2 | 2 | 2 | 202 | 202 | 4202 | 4202 | 4 | 5 | QFAAAA | YUJAAA | AAAAxx
! 4502 | 412 | 0 | 2 | 2 | 2 | 2 | 502 | 502 | 4502 | 4502 | 4 | 5 | ERAAAA | WPAAAA | AAAAxx
! 4702 | 2520 | 0 | 2 | 2 | 2 | 2 | 702 | 702 | 4702 | 4702 | 4 | 5 | WYAAAA | YSDAAA | AAAAxx
! 4902 | 1600 | 0 | 2 | 2 | 2 | 2 | 902 | 902 | 4902 | 4902 | 4 | 5 | OGAAAA | OJCAAA | AAAAxx
! 5602 | 8796 | 0 | 2 | 2 | 2 | 2 | 602 | 1602 | 602 | 5602 | 4 | 5 | MHAAAA | IANAAA | AAAAxx
! 6002 | 8932 | 0 | 2 | 2 | 2 | 2 | 2 | 2 | 1002 | 6002 | 4 | 5 | WWAAAA | OFNAAA | AAAAxx
! 6402 | 3808 | 0 | 2 | 2 | 2 | 2 | 402 | 402 | 1402 | 6402 | 4 | 5 | GMAAAA | MQFAAA | AAAAxx
! 7602 | 1040 | 0 | 2 | 2 | 2 | 2 | 602 | 1602 | 2602 | 7602 | 4 | 5 | KGAAAA | AOBAAA | AAAAxx
! 7802 | 7508 | 0 | 2 | 2 | 2 | 2 | 802 | 1802 | 2802 | 7802 | 4 | 5 | COAAAA | UCLAAA | AAAAxx
! 8002 | 9980 | 0 | 2 | 2 | 2 | 2 | 2 | 2 | 3002 | 8002 | 4 | 5 | UVAAAA | WTOAAA | AAAAxx
! 8302 | 7800 | 0 | 2 | 2 | 2 | 2 | 302 | 302 | 3302 | 8302 | 4 | 5 | IHAAAA | AOLAAA | AAAAxx
! 8402 | 5708 | 0 | 2 | 2 | 2 | 2 | 402 | 402 | 3402 | 8402 | 4 | 5 | ELAAAA | OLIAAA | AAAAxx
! 8602 | 5440 | 0 | 2 | 2 | 2 | 2 | 602 | 602 | 3602 | 8602 | 4 | 5 | WSAAAA | GBIAAA | AAAAxx
! 9502 | 1812 | 0 | 2 | 2 | 2 | 2 | 502 | 1502 | 4502 | 9502 | 4 | 5 | MBAAAA | SRCAAA | AAAAxx
! 9602 | 9972 | 0 | 2 | 2 | 2 | 2 | 602 | 1602 | 4602 | 9602 | 4 | 5 | IFAAAA | OTOAAA | AAAAxx
(29 rows)

-- too few params
***************
*** 127,148 ****
SELECT * FROM q5_prep_results;
unique1 | unique2 | two | four | ten | twenty | hundred | thousand | twothousand | fivethous | tenthous | odd | even | stringu1 | stringu2 | string4
---------+---------+-----+------+-----+--------+---------+----------+-------------+-----------+----------+-----+------+----------+----------+---------
! 200 | 9441 | 0 | 0 | 0 | 0 | 0 | 200 | 200 | 200 | 200 | 0 | 1 | SHAAAA | DZNAAA | HHHHxx
! 497 | 9092 | 1 | 1 | 7 | 17 | 97 | 497 | 497 | 497 | 497 | 194 | 195 | DTAAAA | SLNAAA | AAAAxx
! 1173 | 6699 | 1 | 1 | 3 | 13 | 73 | 173 | 1173 | 1173 | 1173 | 146 | 147 | DTAAAA | RXJAAA | VVVVxx
! 1849 | 8143 | 1 | 1 | 9 | 9 | 49 | 849 | 1849 | 1849 | 1849 | 98 | 99 | DTAAAA | FBMAAA | VVVVxx
! 2525 | 64 | 1 | 1 | 5 | 5 | 25 | 525 | 525 | 2525 | 2525 | 50 | 51 | DTAAAA | MCAAAA | AAAAxx
! 3201 | 7309 | 1 | 1 | 1 | 1 | 1 | 201 | 1201 | 3201 | 3201 | 2 | 3 | DTAAAA | DVKAAA | HHHHxx
! 3877 | 4060 | 1 | 1 | 7 | 17 | 77 | 877 | 1877 | 3877 | 3877 | 154 | 155 | DTAAAA | EAGAAA | AAAAxx
! 4553 | 4113 | 1 | 1 | 3 | 13 | 53 | 553 | 553 | 4553 | 4553 | 106 | 107 | DTAAAA | FCGAAA | HHHHxx
! 5229 | 6407 | 1 | 1 | 9 | 9 | 29 | 229 | 1229 | 229 | 5229 | 58 | 59 | DTAAAA | LMJAAA | VVVVxx
! 5905 | 9537 | 1 | 1 | 5 | 5 | 5 | 905 | 1905 | 905 | 5905 | 10 | 11 | DTAAAA | VCOAAA | HHHHxx
! 6581 | 4686 | 1 | 1 | 1 | 1 | 81 | 581 | 581 | 1581 | 6581 | 162 | 163 | DTAAAA | GYGAAA | OOOOxx
! 7257 | 1895 | 1 | 1 | 7 | 17 | 57 | 257 | 1257 | 2257 | 7257 | 114 | 115 | DTAAAA | XUCAAA | VVVVxx
! 7933 | 4514 | 1 | 1 | 3 | 13 | 33 | 933 | 1933 | 2933 | 7933 | 66 | 67 | DTAAAA | QRGAAA | OOOOxx
! 8609 | 5918 | 1 | 1 | 9 | 9 | 9 | 609 | 609 | 3609 | 8609 | 18 | 19 | DTAAAA | QTIAAA | OOOOxx
! 9285 | 8469 | 1 | 1 | 5 | 5 | 85 | 285 | 1285 | 4285 | 9285 | 170 | 171 | DTAAAA | TNMAAA | HHHHxx
! 9961 | 2058 | 1 | 1 | 1 | 1 | 61 | 961 | 1961 | 4961 | 9961 | 122 | 123 | DTAAAA | EBDAAA | OOOOxx
(16 rows)

-- unknown or unspecified parameter types: should succeed
--- 127,148 ----
SELECT * FROM q5_prep_results;
unique1 | unique2 | two | four | ten | twenty | hundred | thousand | twothousand | fivethous | tenthous | odd | even | stringu1 | stringu2 | string4
---------+---------+-----+------+-----+--------+---------+----------+-------------+-----------+----------+-----+------+----------+----------+---------
! 200 | 9441 | 0 | 0 | 0 | 0 | 0 | 200 | 200 | 200 | 200 | 0 | 1 | SHAAAA | DZNAAA | HHHHxx
! 497 | 9092 | 1 | 1 | 7 | 17 | 97 | 497 | 497 | 497 | 497 | 194 | 195 | DTAAAA | SLNAAA | AAAAxx
! 1173 | 6699 | 1 | 1 | 3 | 13 | 73 | 173 | 1173 | 1173 | 1173 | 146 | 147 | DTAAAA | RXJAAA | VVVVxx
! 1849 | 8143 | 1 | 1 | 9 | 9 | 49 | 849 | 1849 | 1849 | 1849 | 98 | 99 | DTAAAA | FBMAAA | VVVVxx
! 2525 | 64 | 1 | 1 | 5 | 5 | 25 | 525 | 525 | 2525 | 2525 | 50 | 51 | DTAAAA | MCAAAA | AAAAxx
! 3201 | 7309 | 1 | 1 | 1 | 1 | 1 | 201 | 1201 | 3201 | 3201 | 2 | 3 | DTAAAA | DVKAAA | HHHHxx
! 3877 | 4060 | 1 | 1 | 7 | 17 | 77 | 877 | 1877 | 3877 | 3877 | 154 | 155 | DTAAAA | EAGAAA | AAAAxx
! 4553 | 4113 | 1 | 1 | 3 | 13 | 53 | 553 | 553 | 4553 | 4553 | 106 | 107 | DTAAAA | FCGAAA | HHHHxx
! 5229 | 6407 | 1 | 1 | 9 | 9 | 29 | 229 | 1229 | 229 | 5229 | 58 | 59 | DTAAAA | LMJAAA | VVVVxx
! 5905 | 9537 | 1 | 1 | 5 | 5 | 5 | 905 | 1905 | 905 | 5905 | 10 | 11 | DTAAAA | VCOAAA | HHHHxx
! 6581 | 4686 | 1 | 1 | 1 | 1 | 81 | 581 | 581 | 1581 | 6581 | 162 | 163 | DTAAAA | GYGAAA | OOOOxx
! 7257 | 1895 | 1 | 1 | 7 | 17 | 57 | 257 | 1257 | 2257 | 7257 | 114 | 115 | DTAAAA | XUCAAA | VVVVxx
! 7933 | 4514 | 1 | 1 | 3 | 13 | 33 | 933 | 1933 | 2933 | 7933 | 66 | 67 | DTAAAA | QRGAAA | OOOOxx
! 8609 | 5918 | 1 | 1 | 9 | 9 | 9 | 609 | 609 | 3609 | 8609 | 18 | 19 | DTAAAA | QTIAAA | OOOOxx
! 9285 | 8469 | 1 | 1 | 5 | 5 | 85 | 285 | 1285 | 4285 | 9285 | 170 | 171 | DTAAAA | TNMAAA | HHHHxx
! 9961 | 2058 | 1 | 1 | 1 | 1 | 61 | 961 | 1961 | 4961 | 9961 | 122 | 123 | DTAAAA | EBDAAA | OOOOxx
(16 rows)

-- unknown or unspecified parameter types: should succeed
***************
*** 152,175 ****
SELECT * FROM road WHERE thepath = $1;
SELECT name, statement, parameter_types FROM pg_prepared_statements
ORDER BY name;
! name | statement | parameter_types
! ------+-----------------------------------------------------------------+--------------------------------------------------------
! q2 | PREPARE q2(text) AS | {text}
! : SELECT datname, datistemplate, datallowconn
! : FROM pg_database WHERE datname = $1;
! q3 | PREPARE q3(text, int, float, boolean, oid, smallint) AS | {text,integer,"double precision",boolean,oid,smallint}
! : SELECT * FROM tenk1 WHERE string4 = $1 AND (four = $2 O
! ; R
! : ten = $3::bigint OR true = $4 OR oid = $5 OR odd = $6::
! ; int)
! : ORDER BY unique1;
! q5 | PREPARE q5(int, text) AS | {integer,text}
! : SELECT * FROM tenk1 WHERE unique1 = $1 OR stringu1 = $2
! : ORDER BY unique1;
! q6 | PREPARE q6 AS | {integer,name}
! : SELECT * FROM tenk1 WHERE unique1 = $1 AND stringu1 = $2;
! q7 | PREPARE q7(unknown) AS | {path}
! : SELECT * FROM road WHERE thepath = $1;
(5 rows)

-- test DEALLOCATE ALL;
--- 152,173 ----
SELECT * FROM road WHERE thepath = $1;
SELECT name, statement, parameter_types FROM pg_prepared_statements
ORDER BY name;
! name | statement | parameter_types
! ------+---------------------------------------------------------------------+--------------------------------------------------------
! q2 | PREPARE q2(text) AS | {text}
! : SELECT datname, datistemplate, datallowconn
! : FROM pg_database WHERE datname = $1;
! q3 | PREPARE q3(text, int, float, boolean, oid, smallint) AS | {text,integer,"double precision",boolean,oid,smallint}
! : SELECT * FROM tenk1 WHERE string4 = $1 AND (four = $2 OR
! : ten = $3::bigint OR true = $4 OR oid = $5 OR odd = $6::int)
! : ORDER BY unique1;
! q5 | PREPARE q5(int, text) AS | {integer,text}
! : SELECT * FROM tenk1 WHERE unique1 = $1 OR stringu1 = $2
! : ORDER BY unique1;
! q6 | PREPARE q6 AS | {integer,name}
! : SELECT * FROM tenk1 WHERE unique1 = $1 AND stringu1 = $2;
! q7 | PREPARE q7(unknown) AS | {path}
! : SELECT * FROM road WHERE thepath = $1;
(5 rows)

-- test DEALLOCATE ALL;
Guillaume Smet wrote:
> On Wed, May 28, 2008 at 4:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > If you've got any bug fixes you've been working on, now is a good time
> > to get them finished up and sent in...
>
> Has the s/\x09/ /g patch for psql from Bruce and you been
> backported to 8.3? I didn't see it on pgsql-commiters.

No. I have not backpatched it because Tom found a problem with my
applied patch and did a second patch.

I am attaching both patches. The second one is Tom's and I don't
understand it well enough to backpatch it.

--
Bruce Momjian <bruce@momjian.us>

http://momjian.us

EnterpriseDB

http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Re: [pgsql-www] replace training blurb with upcoming pug meetings?

On Thu, May 29, 2008 at 7:35 AM, Dave Page <dpage@pgadmin.org> wrote:
> On Thu, May 29, 2008 at 3:31 PM, Selena Deckelmann
> <selenamarie@gmail.com> wrote:
>
>> I think UKPUG is
>> the only group ambitious enough to suggest a weekly pub night, but I
>> would love to be proved wrong.
>
> Weekly is not strictly accurate - that's just Greg and I trying to
> escape from the office on a Friday :-p. We were thinking of every few
> months.

To be honest, I think that's the best reason to have a meeting "about"
PostgreSQL I've heard. ;)

Some other group, then, will need to take up the Weekly Pub Challenge.
Sweden, perhaps?

-selena

--
Selena Deckelmann
United States PostgreSQL Association - http://www.postgresql.us
PDXPUG - http://pugs.postgresql.org/pdx
Me - http://www.chesnok.com/daily

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

Re: [pgsql-www] replace training blurb with upcoming pug meetings?

On Thu, May 29, 2008 at 3:31 PM, Selena Deckelmann
<selenamarie@gmail.com> wrote:

> I think UKPUG is
> the only group ambitious enough to suggest a weekly pub night, but I
> would love to be proved wrong.

Weekly is not strictly accurate - that's just Greg and I trying to
escape from the office on a Friday :-p. We were thinking of every few
months.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

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

Re: [GENERAL] New MS patent: sounds like PG db rules



Nikola Milutinovic wrote:
Still, this sounds dangerous. It should be, even legally, WRONG to patent something that already exist and was not invented by the patentee. I know we can laugh off MS in court, but what about new DBs or project even built on PG that have this functionality? Software patents are a menace, I'm afraid. And this is still just one portion. IBM is also into this line of "work".

Nix.

----- Original Message ----
From: Dave Page <dpage@pgadmin.org>
To: Justin Clift <justin@salasaga.org>
Cc: Jonathan Bond-Caron <jbondc@gmail.com>; A. Kretschmer <andreas.kretschmer@schollglas.com>; pgsql-general@postgresql.org
Sent: Tuesday, May 27, 2008 3:18:31 PM
Subject: Re: [GENERAL] New MS patent: sounds like PG db rules

HI Justin

On Tue, May 27, 2008 at 2:06 PM, Justin Clift <justin@salasaga.org> wrote:

> I'm trying to point out that - PG is a database system - and MS may have
> just been granted a patent for a fundamental part of it.
>
> Thinking it might need looking in to, and trying to bring it to the
> attention of some that can (or even cares?). ;>

I don't think it's a major issue. Even if MS do think we infringe on
the patent it would be laughable for them to try to do anything about
it given that our rules implementation has provably existed in a
leading FOSS project for a decade or more.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

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

Question???  Does the license that Postgresql works under allow for a foundation or non for profit entity be created  that would hold onto patents for original  ideas of the contributors so WE can protect the users and developers of postgresql

The idea start playing the game MS and other Software companies are playing where they keep applying for  patents/copyrights where there is prior art.  This would protect everyone  in the development chain from having defend stupid lawsuits that these companies could bring against the biggest offenders.

USPTO  only looks at existing patents and trademarks to see if they can issue a patent .  So if a patent  makes claims on already existing art it puts the burden on the original inventor to get the patent revoke.  Doing the above would help put an end to this.

This is just a suggestion.

Re: [HACKERS] [PERFORM] Memory question on win32 systems

On Thu, May 29, 2008 at 10:19 AM, Justin <justin@emproshunts.com> wrote:
> To my understanding Postgresql only caches queries and results in memory for
> that specific connection. So when that connection is closed those cached
> results are cleared out. So cached indexs and queries are for that
> connection only. I hope my understanding is correct.

completely wrong.

They are called 'shared' buffers for a reason. Also you are missing
the point of the o/s file cache which lies under that. If you have a
computer with 4gb ram that is addressable, all its memory is used for
caching at all times, period, less what operating system needs or what
is used by running programs or temporary demands (sorting, etc).

Also, postgresql doesn't as a rule cache 'results and queries'.

shared buffers setting reserves memory for postgresql's internal cache
(plus some housekeeping things like locks)...which can be faster than
the o/s cache because it is more tightly integrated with the backend.
However a page fault to disk is much more interesting in performance
terms than the performance differences between shared buffers and o/s
cache.

merlin

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

Re: [pgsql-www] replace training blurb with upcoming pug meetings?

Hi Peter,

I imagine you're fully recovered from your race at this point! :)
Nice to meet you at PgCon.

On Thu, May 29, 2008 at 3:14 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> Robert Treat wrote:
>> In an effort to give more visibility to the pugs, one idea that was floated
>> around was replacing the training blurb on the main site with an "upcoming
>> pugs" section, modeled after the upcoming events.
>
> I think this would probably be a very skewed listing. Some user groups never
> have real meetings, at least not outside of yearly events that are listed
> anyway. Others might meet weekly for pub night. There would need to be a
> fair amount of researching and policy making before such a listing could be
> produced in a fair manner.

The policy is simple: list events from groups that are having upcoming
meetings. PgDays and conferences should still be listed under Events,
rather than under PUGs.

The primary goal in presenting PUGs on the front page is to show to
outsiders how much growth there has been in user group activity. It's
an indicator that "people like me" use PostgreSQL. Listing these on
the front page is also a not-so-subtle encouragement to PUGs that we'd
like more regular meetings.

Here's a rough indication of events:

There are five groups in the US that are having monthly meetings. Last
I heard, the Moscow group was meeting monthly. Several groups have
just had their first meeting in the last two months. I think UKPUG is
the only group ambitious enough to suggest a weekly pub night, but I
would love to be proved wrong. The other groups, I will contact and
find out how frequently they meet.

-selena

--
Selena Deckelmann
United States PostgreSQL Association - http://www.postgresql.us
PDXPUG - http://pugs.postgresql.org/pdx
Me - http://www.chesnok.com/daily

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

Re: [HACKERS] [PERFORM] Memory question on win32 systems

On Thu, May 29, 2008 at 10:19:46AM -0400, Justin wrote:
> To my understanding Postgresql only caches queries and results in memory
> for that specific connection. So when that connection is closed those
> cached results are cleared out. So cached indexs and queries are for
> that connection only. I hope my understanding is correct.

Incorrect, the shared buffer cache is shared between all running
postgresql processes and between connections. Also the OS cache is
shared between all programs on the system.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org>

http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

Re: [BUGS] BUG #4186: set lc_messages does not work

Magnus Hagander <magnus@hagander.net> writes:
> Thomas H. wrote:
>> so at least that explains the "changed" behaviour. nevertheless,
>> LC_MESSAGES seems to be defunct - with the "locale" folder present,
>> pg always picks the os' language and ignores the lc_message value.

> This looks like I can reproduce though, at least on cvs head. Did this
> work for you in previous versions?

Maybe we were using a different build of gettext in the previous
releases, one that didn't look at the same info as the current code?

Anyway the patch mentioned at the start of the thread
http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php
purports to fix this. It doesn't seem to have gotten reviewed
though.

regards, tom lane

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

[BUGS] BUG #4208: Server crashes on insert into gist index

The following bug has been logged online:

Bug reference: 4208
Logged by: Ron Mackley
Email address: ronm@signalpatterns.com
PostgreSQL version: 8.2.6
Operating system: Linux {hostname removed} 2.6.18-53.1.13.el5 #1 SMP Mon
Feb 11 13:27:27 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
Description: Server crashes on insert into gist index
Details:

We've been seeing infrequent crashes of the postgres. This is version 8.2.6
running on Red Hat Enterprise 5.1 on x64 using redhat issued RPMs.

We captured a core file and here is the stack trace:

(gdb) bt
#0 0x0000000000615b5a in pfree (pointer=0x2aaaccaff318) at mcxt.c:585
#1 0x00002aaace72ab59 in cube_inter (fcinfo=0x7fff102205f0) at cube.c:898
#2 0x0000000000602b14 in DirectFunctionCall2 (func=0x2aaace72aa00
<cube_inter>, arg1=46913066890008, arg2=5) at fmgr.c:888
#3 0x00002aaace72a73b in g_cube_picksplit (fcinfo=<value optimized out>) at
cube.c:571
#4 0x000000000060224f in FunctionCall2 (flinfo=0x2aaaccaff318,
arg1=46913066890008, arg2=5) at fmgr.c:1162
#5 0x000000000044d6e6 in gistSplitByKey (r=0x2aaace6b6d40,
page=0x2aaaccafe8a0 "\017", itup=0x3628200, len=83,
giststate=0x7fff10221800, v=0x7fff10221420,
entryvec=0x36269e0, attno=0) at gistsplit.c:306
#6 0x0000000000444b15 in gistSplit (r=0x2aaace6b6d40, page=0x2aaaccafe8a0
"\017", itup=0x3628200, len=83, giststate=0x7fff10221800) at gist.c:943
#7 0x00000000004454ff in gistmakedeal (state=0x7fff10221780,
giststate=0x7fff10221800) at gist.c:329
#8 0x0000000000445d4b in gistdoinsert (r=0x2aaace6b6d40, itup=0x362aa90,
freespace=0, giststate=0x7fff10221800) at gist.c:278
#9 0x0000000000446115 in gistinsert (fcinfo=<value optimized out>) at
gist.c:242
#10 0x0000000000601eec in FunctionCall6 (flinfo=0x75000,
arg1=46913066890008, arg2=5, arg3=5, arg4=0, arg5=4, arg6=0) at fmgr.c:1275
#11 0x000000000045a03f in index_insert (indexRelation=0x2aaace6b6d40,
values=0x7fff10223f90, isnull=0x7fff10224090 "", heap_t_ctid=0x360256c,
heapRelation=0x2aaace6af020, check_uniqueness=0 '\0') at indexam.c:196
#12 0x00000000005082bf in ExecInsertIndexTuples (slot=0x36011b8,
tupleid=0x360256c, estate=0x3600d10, is_vacuum=0 '\0') at execUtils.c:1116
#13 0x00000000005006f1 in ExecutorRun (queryDesc=<value optimized out>,
direction=<value optimized out>, count=0) at execMain.c:1401
#14 0x00000000005880d7 in ProcessQuery (parsetree=<value optimized out>,
plan=0x35b2ff8, params=0x0, dest=0x35b36d0, completionTag=0x7fff10224440 "")
at pquery.c:157
#15 0x0000000000588311 in PortalRunMulti (portal=0x35f63e0, dest=0x35b36d0,
altdest=0x35b36d0, completionTag=0x7fff10224440 "") at pquery.c:1150
#16 0x0000000000588b74 in PortalRun (portal=0x35f63e0,
count=9223372036854775807, dest=0x35b36d0, altdest=0x35b36d0,
completionTag=0x7fff10224440 "") at pquery.c:700
#17 0x0000000000584a9f in exec_simple_query (
query_string=0x35b2650 "INSERT INTO user_attribute_vectors
(\"client_id\", \"survey_id\", \"user_id\", \"attribute_vector\") VALUES(1,
1, 9180,
E'(0.924332429795696,0.568812924744321,0.568812924744321,-0.599309532325997,
-1.462648746"...) at postgres.c:939
#18 0x0000000000585f22 in PostgresMain (argc=4, argv=<value optimized out>,
username=0x35396f0 "signalmatch-production") at postgres.c:3424
#19 0x000000000055f1c7 in ServerLoop () at postmaster.c:2934
#20 0x000000000055fdda in PostmasterMain (argc=5, argv=0x3519bb0) at
postmaster.c:966
#21 0x00000000005208e3 in main (argc=5, argv=<value optimized out>) at
main.c:188
(gdb)

And more information about the table:
sp_hub_production=# select count(*) from user_attribute_vectors;
count
-------
6057
(1 row)

sp_hub_production=# \d user_attribute_vectors
Table "public.user_attribute_vectors"
Column | Type | Modifiers

------------------+---------+-----------------------------------------------
----------------------
id | integer | not null default
nextval('user_attribute_vectors_id_seq'::regclass)
user_id | integer |
client_id | integer |
survey_id | integer |
attribute_vector | cube |
Indexes:
"user_attribute_vectors_pkey" PRIMARY KEY, btree (id)
"index_user_attribute_vectors_on_attribute_vector_gist" gist
(attribute_vector)
"index_user_attribute_vectors_on_user_id" btree (user_id)

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

Re: [HACKERS] [PERFORM] Memory question on win32 systems



Sabbiolina wrote:
On Thu, May 29, 2008 at 2:11 AM, Douglas McNaught <doug@mcnaught.org> wrote:
On Wed, May 28, 2008 at 7:05 PM, Sabbiolina <sabbiolina@gmail.com> wrote:
> Hello, in my particular case I need to configure Postgres to handle only a
> few concurrent connections, but I need it to be blazingly fast, so I need it
> to cache everything possible. I've changed the config file and multiplied
> all memory-related values by 10, still Postgres uses only less than 50 Mb of
> my RAM.

How are you measuring this?

Task Manager



> I have 4 Gigs of RAM, how do I force Postgres to use a higher part of such
> memory in order to cache more indexes, queries and so on?

Post the settings values you're using and people will be better able
to help you.

-Doug



config:
port = 5432                # (change requires restart)
max_connections = 50                    # (change requires restart)

shared_buffers = 320MB            # min 128kB or max_connections*16kB
temp_buffers = 80MB            # min 800kB
max_prepared_transactions = 10        # can be 0 or more
work_mem = 10MB                # min 64kB
maintenance_work_mem = 160MB        # min 1MB
Max_stack_depth = 20MB            # min 100kB
max_fsm_pages = 2048000            # min max_fsm_relations*16, 6 bytes each
max_fsm_relations = 10000        # min 100, ~70 bytes each
shared_preload_libraries = '$libdir/plugins/plugin
_debugger.dll'        # (change requires restart)
wal_buffers = 640kB            # min 32kB

log_destination = 'stderr'        # Valid values are combinations of
logging_collector = on        # Enable capturing of stderr and csvlog
log_line_prefix = '%t '            # special values:

datestyle = 'iso, dmy'
lc_messages = 'Italian_Italy.1252'            # locale for system error message
lc_monetary = 'Italian_Italy.1252'            # locale for monetary formatting
lc_numeric = 'Italian_Italy.1252'            # locale for number formatting
lc_time = 'Italian_Italy.1252'                # locale for time formatting
default_text_search_config = 'pg_catalog.italian'
Need to Use Performance monitor and Process Explorer to track down the caching on windows machines and performance.

Postgresql does not work like MS SQL where when it start ups grabs a large chuck memory that it uses to keep  last  X number of queries along with the indexes and tables in memory then its pushed out only when new queries that completely different need the memory.

To my understanding Postgresql only caches queries and results in memory for that specific connection.  So when that connection is closed those cached results are cleared out.    So cached indexs and queries are for that connection only.   I hope my understanding is correct.

Re: [pgsql-es-ayuda] PostgreSQL en Chile, jornadas

Guido Barosio escribió:
> Desconozco, sinceramente me llego la nota y la comparti con el grupo.
>
> Quizas Alvaro o alguno de los chicos de Chile nos pueda dar una idea

La verdad es que no había oído hablar de este evento, ni tengo idea
quién daba la charla de Slony.

¿Quizás alguien nos puede contar cómo estuvo?


--
Alvaro Herrera

http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)

Re: [HACKERS] Upcoming back-branch update releases

"Guillaume Smet" <guillaume.smet@gmail.com> writes:
> On Wed, May 28, 2008 at 4:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> If you've got any bug fixes you've been working on, now is a good time
>> to get them finished up and sent in...

> Has the s/\x09/ /g patch for psql from Bruce and you been
> backported to 8.3? I didn't see it on pgsql-commiters.

No, nothing's been done about that AFAIK. What's the consensus,
do we want to change that behavior in 8.3.2?

regards, tom lane

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

[HACKERS] Core team statement on replication in PostgreSQL

The Postgres core team met at PGCon to discuss a few issues, the largest
of which is the need for simple, built-in replication for PostgreSQL.
Historically the project policy has been to avoid putting replication
into core PostgreSQL, so as to leave room for development of competing
solutions, recognizing that there is no "one size fits all" replication
solution. However, it is becoming clear that this policy is hindering
acceptance of PostgreSQL to too great an extent, compared to the benefit
it offers to the add-on replication projects. Users who might consider
PostgreSQL are choosing other database systems because our existing
replication options are too complex to install and use for simple cases.
In practice, simple asynchronous single-master-multiple-slave
replication covers a respectable fraction of use cases, so we have
concluded that we should allow such a feature to be included in the core
project. We emphasize that this is not meant to prevent continued
development of add-on replication projects that cover more complex use
cases.

We believe that the most appropriate base technology for this is
probably real-time WAL log shipping, as was demoed by NTT OSS at PGCon.
We hope that such a feature can be completed for 8.4. Ideally this
would be coupled with the ability to execute read-only queries on the
slave servers, but we see technical difficulties that might prevent that
from being completed before 8.5 or even further out. (The big problem
is that long-running slave-side queries might still need tuples that are
vacuumable on the master, and so replication of vacuuming actions would
cause the slave's queries to deliver wrong answers.)

Again, this will not replace Slony, pgPool, Continuent, Londiste, or
other systems for many users, as it will be not be highly scalable nor
support long-distance replication nor replicating less than an entire
installation. But it is time to include a simple, reliable basic
replication feature in the core system.

regards, tom lane

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