Thursday, May 29, 2008

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

On Thu, May 29, 2008 at 4:52 PM, Dave Page <dpage@pgadmin.org> wrote:
> On Thu, May 29, 2008 at 4:45 PM, Justin <justin@emproshunts.com> wrote:
>>
>> Then what is the purpose of shared buffers if nothing is being reused is it
>> only used to keep track locks, changes and what is to being spooled to the
>> kernel???
>
> It caches disk pages (and holds other data structures), not query results.

Oops, misread that. Shared *buffers* is disk pages. Shared memory
holds the buffers and other stuff as well.


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

--
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-advocacy] State of PostgreSQL, BOF at OSCON?

On Thu, May 29, 2008 at 8:55 AM, Robert Treat
<xzilla@users.sourceforge.net> wrote:
> On Wednesday 28 May 2008 22:58:41 Selena Deckelmann wrote:
>> On Wed, May 28, 2008 at 7:45 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> > Who should give these things? AFAIK, we will have lots of PostgreSQL
>> > luminaries there: me, Bruce, Nasby, JD, Selena, Fetter, Jeff, etc.
>>
>> I love lightning talks, and would enjoy giving the State Of Pg talk.
>> I defer to those who have being doing this for a while, though :)
>>
>> I'll, of course, be there for the BoF and can help out in any way.
>> I'll have some special tshirts to share.
>>
>
> I normally put in for a BOF as part of my regular OSCon prep, but has someone
> already put in for the booth? IIRC Drake usually handles that?

Oops! Sorry, Robert. I put the request in already. I mentioned all
the regular suspects by name, and I'll see if I can add a few of you
to the talk.

JD had requested the booth already. Gabrielle Roth was going to
manage volunteers and booth setup this year.

-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-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy

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

On Thu, May 29, 2008 at 4:48 PM, Douglas McNaught <doug@mcnaught.org> wrote:
> On Thu, May 29, 2008 at 11:46 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
>
>> The only question I have is... what does this give us that PITR doesn't
>> give us?
>
> I think the idea is that WAL records would be shipped (possibly via
> socket) and applied as they're generated, rather than on a
> file-by-file basis. At least that's what "real-time" implies to me...

Yes, we're talking real-time streaming (synchronous) log shipping.

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

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

[pgadmin-hackers] SVN Commit by dpage: r7325 - in branches/REL-1_8_0_EDB/pgadmin3: . pgadmin/dlg pgadmin/schema

Author: dpage

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

New Revision: 7325

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

Log:
Fix comments on EDB packages.


Modified:
branches/REL-1_8_0_EDB/pgadmin3/CHANGELOG
branches/REL-1_8_0_EDB/pgadmin3/pgadmin/dlg/dlgPackage.cpp
branches/REL-1_8_0_EDB/pgadmin3/pgadmin/schema/edbPackage.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: [HACKERS] Core team statement on replication in PostgreSQL

On Thursday 29 May 2008 09:54:03 am Marko Kreen wrote:
> 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.

+1 for lossless failover (ie, synchronous)

--
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

Josh Berkus wrote:
> Marko,
>
> > 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.
>
> That's incorrect. We're looking for a workable solution. If we could
> get one for 8.4, that would be brilliant but we think it's going to be
> harder than that.
>
> Publishing the XIDs back to the master is one possibility. We also
> looked at using "spillover segments" for vacuumed rows, but that seemed
> even less viable.
>
> I'm also thinking, for *async replication*, that we could simply halt
> replication on the slave whenever a transaction passes minxid on the
> master. However, the main focus will be on synchrounous hot standby.

Another idea I discussed with Tom is having the slave _delay_ applying
WAL files until all slave snapshots are ready.

--
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

[pgadmin-hackers] SVN Commit by dpage: r7324 - in branches/REL-1_8_0_PATCHES/pgadmin3: . pgadmin/dlg pgadmin/schema

Author: dpage

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

New Revision: 7324

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

Log:
Fix comments on EDB packages.


Modified:
branches/REL-1_8_0_PATCHES/pgadmin3/CHANGELOG
branches/REL-1_8_0_PATCHES/pgadmin3/pgadmin/dlg/dlgPackage.cpp
branches/REL-1_8_0_PATCHES/pgadmin3/pgadmin/schema/edbPackage.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: r7323 - in trunk/pgadmin3: . pgadmin/dlg pgadmin/schema

Author: dpage

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

New Revision: 7323

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

Log:
Fix comments on EDB packages.


Modified:
trunk/pgadmin3/CHANGELOG
trunk/pgadmin3/pgadmin/dlg/dlgPackage.cpp
trunk/pgadmin3/pgadmin/schema/edbPackage.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: [HACKERS] [PERFORM] Memory question on win32 systems

On Thu, 29 May 2008, Justin wrote:

> I'm confussed trying to figure out how caches are being use and being
> moving through postgresql backend.

The shared_buffers cache holds blocks from the database files. That's it.
If you want some more information about how that actually works head to

http://www.westnet.com/~gsmith/content/postgresql/ and read "Inside the
PostgreSQL Buffer Cache".

The work memory allocated for sorting is separate from that, and it
doesn't cache anything. It just provides working room for a query that's
being executed right now.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

--
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-advocacy] State of PostgreSQL, BOF at OSCON?

On Wednesday 28 May 2008 22:58:41 Selena Deckelmann wrote:
> On Wed, May 28, 2008 at 7:45 PM, Josh Berkus <josh@agliodbs.com> wrote:
> > Who should give these things? AFAIK, we will have lots of PostgreSQL
> > luminaries there: me, Bruce, Nasby, JD, Selena, Fetter, Jeff, etc.
>
> I love lightning talks, and would enjoy giving the State Of Pg talk.
> I defer to those who have being doing this for a while, though :)
>
> I'll, of course, be there for the BoF and can help out in any way.
> I'll have some special tshirts to share.
>

I normally put in for a BOF as part of my regular OSCon prep, but has someone
already put in for the booth? IIRC Drake usually handles that?

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

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

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

On Thu, May 29, 2008 at 08:46:22AM -0700, Joshua D. Drake wrote:
> On Thu, 2008-05-29 at 08:21 -0700, David Fetter wrote:
> > 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.
>
> The only question I have is... what does this give us that PITR
> doesn't give us?

It looks like a wrapper for PITR to me, so the gain would be ease of
use.

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: [HACKERS] [PERFORM] Memory question on win32 systems

On Thu, May 29, 2008 at 4:45 PM, Justin <justin@emproshunts.com> wrote:
>
> Then what is the purpose of shared buffers if nothing is being reused is it
> only used to keep track locks, changes and what is to being spooled to the
> kernel???

It caches disk pages (and holds other data structures), not query results.

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

--
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

Marko,

> 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.

That's incorrect. We're looking for a workable solution. If we could
get one for 8.4, that would be brilliant but we think it's going to be
harder than that.

Publishing the XIDs back to the master is one possibility. We also
looked at using "spillover segments" for vacuumed rows, but that seemed
even less viable.

I'm also thinking, for *async replication*, that we could simply halt
replication on the slave whenever a transaction passes minxid on the
master. However, the main focus will be on synchrounous hot standby.

--Josh


--
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 11:46 AM, Joshua D. Drake <jd@commandprompt.com> wrote:

> The only question I have is... what does this give us that PITR doesn't
> give us?

I think the idea is that WAL records would be shipped (possibly via
socket) and applied as they're generated, rather than on a
file-by-file basis. At least that's what "real-time" implies to me...

-Doug

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

[PERFORM] Adding "LIMIT 1" kills performance.

[Attn list-queue maintainers: Please drop the earlier version
of this email that I accidentally sent from an unsubscribed address. ]

Hi,

I'm having a strange problem with a slow-running select query. The
query I use in production ends in "LIMIT 1", and it runs very slowly.
But when I remove the "LIMIT 1", the query runs quite quickly. This
behavior has stumped a couple smart DBAs.

The full queries and EXPLAIN ANALYZE plans are included below, but by
way of explanation/observation:

1) The "LIMIT 1" case will sometimes be quicker (but still much slower
than the non-"LIMIT 1" case) for different values of
calendar_group_id.

2) The query below is a slightly simplified version of the one I
actually use. The real one includes more conditions which explain why
each table is joined. For reference, the original query is quoted at
the end [1]. The original query exhibits the same behavior as the
simplified versions w.r.t. the "LIMIT 1" case taking _much_ longer
(even longer than the simplified version) than the non-"LIMIT 1" case,
and uses the same plans.


Can anyone explain why such a slow plan is chosen when the "LIMIT 1"
is present? Is there anything I can do to speed this query up?
Thanks.

-chris


production=> select version();
version
------------------------------------------------------------------------------
PostgreSQL 8.2.6 on x86_64-pc-linux-gnu, compiled by GCC x86_64-pc-linux-gnu-gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.2)
(1 row)

production=> analyze calendar_groups;
ANALYZE
production=> analyze calendar_links;
ANALYZE
production=> analyze calendars;
ANALYZE
production=> analyze event_updates;
ANALYZE
production=> EXPLAIN ANALYZE SELECT event_updates.*
FROM event_updates
INNER JOIN calendars ON event_updates.feed_id = calendars.id
INNER JOIN calendar_links ON calendars.id = calendar_links.source_tracker_id
WHERE (calendar_links.calendar_group_id = 3640)
ORDER BY event_updates.id DESC
LIMIT 1;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------
Limit (cost=16.55..91.73 rows=1 width=2752) (actual time=27810.058..27810.059 rows=1 loops=1)
-> Nested Loop (cost=16.55..695694.18 rows=9254 width=2752) (actual time=27810.054..27810.054 rows=1 loops=1)
Join Filter: (event_updates.feed_id = calendars.id)
-> Index Scan Backward using event_updates_pkey on event_updates (cost=0.00..494429.30 rows=8944370 width=2752) (actual time=0.030..7452.142 rows=5135706 loops=1)
-> Materialize (cost=16.55..16.56 rows=1 width=8) (actual time=0.001..0.002 rows=1 loops=5135706)
-> Nested Loop (cost=0.00..16.55 rows=1 width=8) (actual time=0.029..0.034 rows=1 loops=1)
-> Index Scan using index_calendar_links_on_calendar_group_id_and_source_tracker_id on calendar_links (cost=0.00..8.27 rows=1 width=4) (actual time=0.012..0.013 rows=1 loops=1)
Index Cond: (calendar_group_id = 3640)
-> Index Scan using harvest_trackers_pkey on calendars (cost=0.00..8.27 rows=1 width=4) (actual time=0.012..0.013 rows=1 loops=1)
Index Cond: (calendars.id = calendar_links.source_tracker_id)
Total runtime: 27810.161 ms
(11 rows)

production=> EXPLAIN ANALYZE SELECT event_updates.* FROM event_updates
INNER JOIN calendars ON event_updates.feed_id = calendars.id
INNER JOIN calendar_links ON calendars.id = calendar_links.source_tracker_id
WHERE (calendar_links.calendar_group_id = 3640)
ORDER BY event_updates.id DESC;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------
Sort (cost=43376.36..43399.50 rows=9256 width=2752) (actual time=10.178..10.205 rows=36 loops=1)
Sort Key: event_updates.id
-> Nested Loop (cost=249.86..31755.56 rows=9256 width=2752) (actual time=9.957..10.098 rows=36 loops=1)
-> Nested Loop (cost=0.00..16.55 rows=1 width=8) (actual time=9.868..9.873 rows=1 loops=1)
-> Index Scan using index_calendar_links_on_calendar_group_id_and_source_tracker_id on calendar_links (cost=0.00..8.27 rows=1 width=4) (actual time=9.824..9.825 rows=1 loops=1)
Index Cond: (calendar_group_id = 3640)
-> Index Scan using harvest_trackers_pkey on calendars (cost=0.00..8.27 rows=1 width=4) (actual time=0.034..0.036 rows=1 loops=1)
Index Cond: (calendars.id = calendar_links.source_tracker_id)
-> Bitmap Heap Scan on event_updates (cost=249.86..31623.01 rows=9280 width=2752) (actual time=0.080..0.138 rows=36 loops=1)
Recheck Cond: (event_updates.feed_id = calendars.id)
-> Bitmap Index Scan on index_event_updates_on_feed_id_and_feed_type (cost=0.00..247.54 rows=9280 width=0) (actual time=0.056..0.056 rows=36 loops=1)
Index Cond: (event_updates.feed_id = calendars.id)
Total runtime: 10.337 ms
(13 rows)

---------
[1] The original, unsimplified query:
SELECT event_updates.* FROM event_updates
INNER JOIN calendars ON (event_updates.feed_id = calendars.id AND event_updates.feed_type = E'Calendar')
INNER JOIN calendar_links ON (calendars.id = calendar_links.source_tracker_id AND calendars.type = E'SourceTracker')
WHERE (calendar_links.calendar_group_id = 3640 AND calendars.deactivated_at IS NULL)
ORDER BY event_updates.id DESC
LIMIT 1

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

[PATCHES] minor change to replace function comment

Index: pg_proc.h
===================================================================
RCS file: /projects/cvsroot/pgsql/src/include/catalog/pg_proc.h,v
retrieving revision 1.501
diff -c -r1.501 pg_proc.h
*** pg_proc.h 27 May 2008 00:13:09 -0000 1.501
--- pg_proc.h 29 May 2008 15:35:32 -0000
***************
*** 2202,2208 ****
DATA(insert OID = 937 ( substring PGNSP PGUID 12 1 0 f f t f i 2 25 "25 23" _null_ _null_ _null_ text_substr_no_len - _null_ _null_ ));
DESCR("return portion of string");
DATA(insert OID = 2087 ( replace PGNSP PGUID 12 1 0 f f t f i 3 25 "25 25 25" _null_ _null_ _null_ replace_text - _null_ _null_ ));
! DESCR("replace all occurrences of old_substr with new_substr in string");
DATA(insert OID = 2284 ( regexp_replace PGNSP PGUID 12 1 0 f f t f i 3 25 "25 25 25" _null_ _null_ _null_ textregexreplace_noopt - _null_ _null_ ));
DESCR("replace text using regexp");
DATA(insert OID = 2285 ( regexp_replace PGNSP PGUID 12 1 0 f f t f i 4 25 "25 25 25 25" _null_ _null_ _null_ textregexreplace - _null_ _null_ ));
--- 2202,2208 ----
DATA(insert OID = 937 ( substring PGNSP PGUID 12 1 0 f f t f i 2 25 "25 23" _null_ _null_ _null_ text_substr_no_len - _null_ _null_ ));
DESCR("return portion of string");
DATA(insert OID = 2087 ( replace PGNSP PGUID 12 1 0 f f t f i 3 25 "25 25 25" _null_ _null_ _null_ replace_text - _null_ _null_ ));
! DESCR("replace all occurrences in string of old_substr with new_substr");
DATA(insert OID = 2284 ( regexp_replace PGNSP PGUID 12 1 0 f f t f i 3 25 "25 25 25" _null_ _null_ _null_ textregexreplace_noopt - _null_ _null_ ));
DESCR("replace text using regexp");
DATA(insert OID = 2285 ( regexp_replace PGNSP PGUID 12 1 0 f f t f i 4 25 "25 25 25 25" _null_ _null_ _null_ textregexreplace - _null_ _null_ ));
The current wording implies that you replace arg1 with arg2 in arg3, but
replace actually replaces occurences of arg2 with arg3 in arg1. Attached
patch makes the function comment more closely resemble that, and is more
in-line with the docs wording as well.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

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

On Thu, 2008-05-29 at 08:21 -0700, David Fetter wrote:
> On Thu, May 29, 2008 at 10:12:55AM -0400, Tom Lane wrote:

> 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.

The only question I have is... what does this give us that PITR doesn't
give us?

Sincerely,

Joshua D. Drake

--
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] [PERFORM] Memory question on win32 systems



Merlin Moncure wrote:
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    
This is not meant to be argumentative i'm trying to clearify what is going because documentation for different sources seem to be in conflict  or confusing. 
---------------------------------------------------
From Postgresql Second Edition:
    Shared_Buffers: This cache is shared by all clients connected to a single cluster. DISK I?) (and cache I/O) is performed in 8KB chunks.  The shared_buffers parameter determines how many 8KB will be created in the shared cache.

from here explanation is different
http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html  it referrs to queries which means to me the SQL command and the result sets (but that is wrong)

We have sort_mem aka work_mem
---------------------------------------------------
From Postgresql Second Edition:
     where postgresql processes query it transforms the query from string form into an execution plan. An execution plan is a sequence of operations that must be performed in order satisfy the query.   

(This specific to the client  connection and when the client is closed out this is cleared my thinking.)
----------------------------------------------------
From postgresql Documentation
work_mem (integer)

Specifies the amount of memory to be used by internal sort operations and hash tables before switching to temporary disk files. The value is defaults to one megabyte (1MB). Note that for a complex query, several sort or hash operations might be running in parallel; each one will be allowed to use as much memory as this value specifies before it starts to put data into temporary files. Also, several running sessions could be doing such operations concurrently. So the total memory used could be many times the value of work_mem; it is necessary to keep this fact in mind when choosing the value. Sort operations are used for ORDER BY, DISTINCT, and merge joins. Hash tables are used in hash joins, hash-based aggregation, and hash-based processing of IN subqueries

---------------------------------------------------------
Quoting You "Also, postgresql doesn't as a rule cache 'results and queries'.

Then what is the purpose of shared buffers if nothing is being reused  is it only used to keep track locks, changes and what is to being spooled to the kernel???

I'm confussed trying to figure out how caches are being use and being moving through postgresql backend.   As many have stated that small database can fit completely in the caches How does that really work.








Re: [PERFORM] 2GB or not 2GB

On Wed, 2008-05-28 at 16:59 -0700, Josh Berkus wrote:
> Folks,

> shared_buffers: according to witnesses, Greg Smith presented at East that
> based on PostgreSQL's buffer algorithms, buffers above 2GB would not
> really receive significant use. However, Jignesh Shah has tested that on
> workloads with large numbers of connections, allocating up to 10GB
> improves performance.

I have seen multiple production systems where upping the buffers up to
6-8GB helps. What I don't know, and what I am guessing Greg is referring
to is if it helps as much as say upping to 2GB. E.g; the scale of
performance increase goes down while the actual performance goes up
(like adding more CPUs).


>
> sort_mem: My tests with 8.2 and DBT3 seemed to show that, due to
> limitations of our tape sort algorithm, allocating over 2GB for a single
> sort had no benefit. However, Magnus and others have claimed otherwise.
> Has this improved in 8.3?

I have never see work_mem (there is no sort_mem Josh) do any good above
1GB. Of course, I would never willingly use that much work_mem unless
there was a really good reason that involved a guarantee of not calling
me at 3:00am.

>
> So, can we have some test evidence here? And workload descriptions?
>

Its all, tune now buddy :P

Sinceerely,

Joshua D. Drake


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

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. +