Nabble - PostgreSQL

total execution time as reported by auto_explain

2009-11-10T22:08:28Z

Hi,

I was using auto_explain to log plans (with analyze option on) from
queries that take more than 500ms, something i found i little odd is
that the duration says 779ms but actual time says 269ms (almost 3
times lower), maybe some kind of instrumentation cleanup can explain
this?

2009-11-10 10:32:41 GMTLOG: duration: 779.938 ms plan:
Sort (cost=1943.99..1967.38 rows=9355 width=466) (actual
time=235.655..269.061 rows=4997 loops=1)

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

2009-11-10 10:32:41 GMTLOG: duration: 779.938 ms plan:
Sort (cost=1943.99..1967.38 rows=9355 width=466) (actual time=235.655..269.061 rows=4997 loops=1)
Sort Key: (upper(ltrim((b.nombre)::text)))
Sort Method: quicksort Memory: 3000kB
-> Hash Left Join (cost=8.18..1326.95 rows=9355 width=466) (actual time=0.516..161.361 rows=4997 loops=1)
Hash Cond: (CASE btrim((b.marca)::text) WHEN ''::text THEN NULL::bpchar ELSE b.marca END = c.codigo)
-> Seq Scan on fcproduc b (cost=0.00..1130.73 rows=9355 width=216) (actual time=0.194..65.821 rows=4997 loops=1)
Filter: (upper((nombre)::text) ~~ '%1%'::text)
-> Hash (cost=8.16..8.16 rows=2 width=261) (actual time=0.153..0.153 rows=1 loops=1)
-> Bitmap Heap Scan on dbtablas c (cost=3.27..8.16 rows=2 width=261) (actual time=0.125..0.129 rows=1 loops=1)
Recheck Cond: (tipo = 'MAR'::bpchar)
-> Bitmap Index Scan on dbtablas_pkey (cost=0.00..3.27 rows=2 width=0) (actual time=0.074..0.074 rows=1 loops=1)
Index Cond: (tipo = 'MAR'::bpchar)
2009-11-10 10:32:41 GMTSTATEMENT: select b.codigo,b.nombre,b.ubicacion,b.grupo,b.P_IVA,b.PRECIO,b.PRECIO_2,b.PRECIO_3,b.PRECIO_4,b.PRECIO_5,c.nombre AS marca,b.codigo_a
FROM fcproduc b
LEFT OUTER JOIN dbtablas c ON c.codigo = case TRIM(b.marca) when '' then null else b.marca end and c.tipo = 'MAR'
WHERE UPPER(b.NOMBRE) LIKE UPPER('%1%') order by UPPER(LTRIM(b.nombre))

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

From forum: PostgreSQL - hackers

Numeric Type and VB/ODBC

2009-11-10T22:07:16Z

This may not be the right group, if so, just let me know.

I have a table with a type [numeric].

When executing queries, I get the data which happens to
be (6.5) in this case, but my VB6 function which traps
for nulls (below) returns a null.

If I change it to type [real]. No problems

Function IsNothing(varToTest As Variant) As Integer
' Tests for a "logical" nothing based on data type
' Empty and Null = Nothing
' Number = 0 is Nothing
' Zero length string is Nothing
' Date/Time is never Nothing

IsNothing = True

Select Case VarType(varToTest)
Case vbEmpty
Exit Function
Case vbNull
Exit Function
Case vbBoolean
If varToTest Then IsNothing = False
Case vbByte, vbInteger, vbLong, vbSingle, vbDouble, vbCurrency
If varToTest <> 0 Then IsNothing = False
Case vbDate
IsNothing = False
Case vbString
If (Len(varToTest) <> 0 And varToTest <> " ") Then IsNothing =
False
End Select

End Function

Bret Stern

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

From forum: PostgreSQL - general

Patch committers

2009-11-10T21:06:22Z

Robert Haas wrote:
> The next CommitFest is scheduled to start in a week. So far, it
> doesn't look too bad, though a lot could change between now and then.
>
> I would personally prefer not to be involved in the management of the
> next CommitFest. Having done all of the July CommitFest and a good
> chunk of the September CommitFest, I am feeling a bit burned out.

This brings up a concern I have --- that the number of patch
committers/managers is decreasing while our patch volume is increasing.
Consider that Heikki is working mostly on Hot Standby and Streaming
Replication, Alvaro isn't as involved in applying patches, Neil Conway
isn't involved with Postgres anymore, I am in a 42-day travel period,
and Robert Haas is feeling burnt-out --- that is not a pretty sight.

Much of the patch burden is falling on Tom. Now, Tom isn't complaining,
but I am concerned about placing too much of a burden on him. I know we
are growing new patch reviewers who will eventually be able to review
_and_ apply patches on their own, but getting them to that point is
going to take time.

I have no real answers, but I am concerned. I have talked to many of
you privately about this to get your input.

On a brighter note, I was able to read three weeks of back-logged emails
(3k emails) in the past two days because our community is now very good
at resolving the greatly increased email volume of bug reports and
questions.

I can definitely say that the quality and volume of our email support to
users had advanced significantly in the past year. It seems that a
similar increase in patch application support is going to take longer to
materialize.

--
Bruce Momjian <bruce@...> 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@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From forum: PostgreSQL - hackers

Re: speakers mailing list

2009-11-10T20:57:51Z

On Tue, 2009-11-10 at 13:25 +0200, Peter Eisentraut wrote:
> On mån, 2009-11-09 at 15:10 -0800, Joshua D. Drake wrote:
> > I think advocacy is a bad idea for this. It should go to the
> > respective PUG or region list.
>
> It would depend on the scale of the conference, probably. The Wales
> Python User Group perhaps doesn't have to post to advocacy, but the
> South American ParrotCon perhaps could.

Even then, I wonder if it makes more sense to then just have a sa- list?

>

--

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

From forum: PostgreSQL - www

Re: ORDB and dot-notation query

2009-11-10T20:36:50Z

"ALLs.org" <info@...> writes:
> select * from clients WHERE
> address.country.tld = 'de'

> address and country are custom table and TYPE

> I receive error:
> ERROR: schema "adress" does not exist*

Yup, because the SQL standard says that a.b.c means column c in table b
in schema a. You need to write
(address.country).tld
to get the parser started in the right direction.

regards, tom lane

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

From forum: PostgreSQL - sql

Re: ORDB and dot-notation query

2009-11-10T20:27:06Z

This is tipfeler when writing mail, but in database it is 100% ok like below:
I'm also using Windows version, can this be reason of problem?

When exec query:

select * from clients WHERE
adress.country.tld = 'de'

adress and country are custom table and TYPE

I receive error:

SQL error:
ERROR: schema "adress" does not exist

Thanks

On Wed, Nov 11, 2009 at 5:15 AM, Richard Broersma <richard.broersma@...> wrote:

On Tue, Nov 10, 2009 at 8:11 PM, ALLs.org <info@...> wrote:

> I have problem with ORDB.
>
> When exec query:
>
> select * from clients WHERE
> address.country.tld = 'de'
>
> address and country are custom table and TYPE
>
> I receive error:
>
> SQL error:
> ERROR: schema "adress" does not exist
>
> Do somebody have some problem and how to fix this?

Are you sure that you didn't just misspell address?

--
Regards,
Richard Broersma Jr.

Visit the Los Angeles PostgreSQL Users Group (LAPUG)
http://pugs.postgresql.org/lapug

From forum: PostgreSQL - sql

Re: ORDB and dot-notation query

2009-11-10T20:15:48Z

On Tue, Nov 10, 2009 at 8:11 PM, ALLs.org <info@...> wrote:

> I have problem with ORDB.
>
> When exec query:
>
> select * from clients WHERE
> address.country.tld = 'de'
>
> address and country are custom table and TYPE
>
> I receive error:
>
> SQL error:
> ERROR: schema "adress" does not exist
>
> Do somebody have some problem and how to fix this?

Are you sure that you didn't just misspell address?

--
Regards,
Richard Broersma Jr.

Visit the Los Angeles PostgreSQL Users Group (LAPUG)
http://pugs.postgresql.org/lapug

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

From forum: PostgreSQL - sql

Re: Parsing config files in a directory

2009-11-10T20:14:45Z

On 11/10/09 5:59 AM, Bruce Momjian wrote:
> Simon Riggs wrote:
>> All of this *also* applies to shared_preload_libraries. We also need to
>> be able to specify new load libraries without editing the same darn
>> parameter.
>
> And to search_path, though that's even more complex because the order of
> the entries is significant.

Let's NOT start that discussion again.

--Josh Berkus

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

From forum: PostgreSQL - hackers

ORDB and dot-notation query

2009-11-10T20:11:24Z

Hi,

I have problem with ORDB.

When exec query:

select * from clients WHERE
address.country.tld = 'de'

address and country are custom table and TYPE

I receive error:

SQL error:
ERROR: schema "adress" does not exist

Do somebody have some problem and how to fix this?

Thanks

From forum: PostgreSQL - sql

Deadlock on the same object?

2009-11-10T19:03:13Z

I encountered the following log in 8.4.1 and HEAD. The deadlock occured
on the same object (relation 17498 of database 17497). Is it reasonable?

ERROR: deadlock detected
DETAIL: Process 6313 waits for ExclusiveLock on relation 17498 of database 17497; blocked by process 6312.
Process 6312 waits for ExclusiveLock on relation 17498 of database 17497; blocked by process 6313.
Process 6313: SELECT test()
Process 6312: SELECT test()
HINT: See server log for query details.
CONTEXT: SQL function "test" statement 1
STATEMENT: SELECT test()

(relation 17498 is table 'a')

A reproducible test set is:
----
CREATE TABLE a (i integer PRIMARY KEY);
CREATE TABLE b (i integer REFERENCES a(i));

CREATE FUNCTION test() RETURNS VOID AS
$$
LOCK a IN EXCLUSIVE MODE;
LOCK b IN EXCLUSIVE MODE;
DELETE FROM a;
$$
LANGUAGE sql STRICT;
----

# Repeat the following commands in shell.
psql -c "SELECT test()" &
psql -c "SELECT test()" &
psql -c "SELECT test()" &
wait

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

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

From forum: PostgreSQL - hackers

Re: pg_dump native format will not restore correctly

2009-11-10T18:18:30Z

I'm still not buying the theory that the dump/restore method has
something to do with it. You might try the test yourself: run
pg_restore's output into a text file and compare with the text dump.

regards, tom lane

Haven't figured out exactly why yet, but I did find the difference as to
why text based restore works for me but native format doesn't. In the
text based restore permissions are granted to all restored tables and
the schema itself. Using the native format permissions are granted to
restored tables, but NOT the schema, which makes all the tables in the
restored schema inaccessible to all but the postgres user. This is of
course when restoring only the schema and its contents, not the entire
database.

My text based method does a dump to a file from the production database
immediately prior to the restore, then cats the file to psql for the
restore. My native format restore I'm simply restoring from last nights
native format backup of the database and using the schema only switch to
pg_restore. Not sure if that makes the difference or not.

Thanks for the help in trying to figure this out. I'm still looking
into it.

Scot Kreienkamp

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

From forum: PostgreSQL - general

libpqtypes - libpqtypes: Update changelog

2009-11-10T17:57:56Z

Log Message:
-----------
Update changelog

Modified Files:
--------------
libpqtypes:
ChangeLog (r1.43 -> r1.44)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/libpqtypes/libpqtypes/ChangeLog?r1=1.43&r2=1.44)

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

From forum: PostgreSQL - committers

libpqtypes - libpqtypes: Leaking type handlers in events.c during

2009-11-10T17:55:44Z

Log Message:
-----------
Leaking type handlers in events.c during PGEVT_CONNRESET error case.

Modified Files:
--------------
libpqtypes/src:
events.c (r1.11 -> r1.12)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/libpqtypes/libpqtypes/src/events.c?r1=1.11&r2=1.12)

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

From forum: PostgreSQL - committers

Re: I need information about PG-Day

2009-11-10T17:04:21Z

Josh Berkus escribió:
>
> > Really? Then I'll be contacting our SPI liaison. The Cuba guys are
> > taking care of the lodging and such, so that's not a problem for me, but
> > the airplane fares are a different story.
>
> SPI or pgUS would need to talk to attorneys about that.

Please do.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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

From forum: PostgreSQL - advocacy

Re: I need information about PG-Day

2009-11-10T16:48:11Z

On Tue, Nov 10, 2009 at 11:21 AM, Bruce Momjian <bruce@...> wrote:

> I would be glad to speak in Cuba if asked.

Me too!

Thanks for sharing the research, Bruce!

-selena

--
http://chesnok.com/daily - me
http://endpoint.com - work

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

From forum: PostgreSQL - advocacy

Database tuning at Duke

2009-11-10T16:31:48Z

There's two papers published recently at Duke that I just found, both of
which use PostgreSQL as part of their research:

Automated SQL Tuning through Trial and (Sometimes) Error:
http://www.cs.duke.edu/~shivnath/papers/dbtest09z.pdf
Tuning Database Configuration Parameters with iTuned:
http://www.cs.duke.edu/~shivnath/papers/ituned.pdf

The second has a number of interesting graphs showing how changing two
postgresql.conf parameters at a time interact with one another. There's
also a set of graphs comparing the default postgresql.conf performance
with what you get using the guidelines suggested by an earlier version
of http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server and
some of the documents on that section of the wiki. Check out page 10,
the "M" column represents that manual tuning against the leftmost "D"
which is the stock postgresql.conf settings.

I was a bit confused at first about the environment because of how the
paper is organized, here's the bit that clarifies it: "The database
size with indexes is around 4GB. The physical memory (RAM) given to the
database is 1GB to create a realistic scenario where the database is 4x
the amount of RAM." That RAM limit was constrained with a Solaris
zone. They multiplied the 1GB x 20% to get a standard "rule-based"
setting of shared_buffers of 200MB (based on the guidelines on the wiki
at the time--that suggestion is now 25%).

Note that much of the improvement shown in their better tuned versions
there results from increases to shared_buffers (peaking at 40%=400MB)
and work_mem beyond the recommendations given in the tuning guide. That
is unsurprising as those are aimed more to be reasonable starting values
rather than suggested as truly optimal. work_mem is particular is
dangerous to suggest raising really high without knowing what types of
queries are going to be run. There's been plenty of commentary on this
list suggesting optimal shared_buffers is closer to 50% of RAM than 25%
for some workloads, so their results showing peak performance at 40% fit
right in the middle of community lore.

I'm now in contact with the authors and asked them to let me know whey
publish the entire post-optimization postgresql.conf, I'll let the list
know when that's available. I'm quite curious to see what the final
settings that gave the best results looked like.

--
Greg Smith greg@... Baltimore, MD

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

From forum: PostgreSQL - performance

Re: Pros / cons for indexing a small table

2009-11-10T16:26:29Z

On point 2.

When adding an index u need to consider how u will be querying the
table.

In the example provided indicating that column Id was added for best
practice is in my opinion incorrect.

Index is added to avoid full sequential table scan. Could be wrong but
Id as you have defined its use is going to have 0 positive impact
unless u plan to reference it in where clause.

Thanks
Kris

On 10-Nov-09, at 6:25, Rikard Bosnjakovic
<rikard.bosnjakovic@...> wrote:

> I'm having a simple table for managing hit counts on WWW. The table
> was setup some year ago using this:
>
> CREATE TABLE hit_counts (
> page varchar(255),
> hits integer,
> last_visit timestamp,
> id serial primary key
> );
>
> When updating a hit, I use this PHP-code:
>
> $q = "SELECT hits FROM hit_counters WHERE page='$this_uri'";
> $res = pg_query($db, $q);
> if (pg_num_rows($res) == 0) {
> $q = "INSERT INTO hit_counters (page) VALUES ('$this_uri')";
> } else {
> $row = pg_fetch_object($res);
> $hits = $row->hits;
> $hits++;
> $q = "UPDATE hit_counters SET last_visit = (SELECT
> localtimestamp(0)), hits = $hits WHERE page='$this_uri'";
> }
> pg_query($db, $q);
>
> In other words, if the actual page is not in the table it is inserted.
> Otherwise the "hits" is increased by one. The id-column is never used,
> I simply appended it because of "good practise" using a primary key
> for all my tables.
>
> Now, my questions are:
>
> 1. Since the id-column is never used, I will probably drop it to save
> some space. Or, is there any point in keeping it?
>
> 2. From what I've read in the manual and what other people have told
> me, creating an index can speed up table accessing. I tried by adding
> an index to the page-column in the above table. Then by using ANALYZE
> and EXPLAIN, the cost got reduced from 259 to 6 which I guess is a
> pretty big save although I'm not sure what the value really is. Is
> creating an index on 'page' the best way to speed up this particular
> table?
>
> 3. The page-column is queried using full length strings (no regexps or
> wildcards). Will there be any performance issues if I have the
> page-column indexed and then run wildcard-queries on it? What I mean
> is, if I run wildcard-queries on this indexed column, will the index
> be of any use at all?
>
>
> --
> - Rikard
>
> --
> Sent via pgsql-novice mailing list (pgsql-novice@...)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-novice

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

From forum: PostgreSQL - novice

Re: I need information about PG-Day

2009-11-10T16:24:37Z

> Really? Then I'll be contacting our SPI liaison. The Cuba guys are
> taking care of the lodging and such, so that's not a problem for me, but
> the airplane fares are a different story.

SPI or pgUS would need to talk to attorneys about that.

--Josh Berkus

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

From forum: PostgreSQL - advocacy

Re: [GENERAL] PostgreSQL 8.3.8 on AIX5.3 : compilation failed

2009-11-10T15:15:19Z

"Albe Laurenz" <laurenz.albe@...> writes:
> The problem is that both _LARGE_FILES and _LARGE_FILE_API are #defined
> in this case, which makes #include <unistd.h> fail.
> Does anyone have an idea how to best fix this problem in the
> source tree? I'm willing to implement and test.

I've committed changes for this in CVS, please verify it fixes your
problem.

regards, tom lane

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

From forum: PostgreSQL - hackers

Re: [HACKERS] PostgreSQL 8.3.8 on AIX5.3 : compilation failed

2009-11-10T15:15:19Z

"Albe Laurenz" <laurenz.albe@...> writes:
> The problem is that both _LARGE_FILES and _LARGE_FILE_API are #defined
> in this case, which makes #include <unistd.h> fail.
> Does anyone have an idea how to best fix this problem in the
> source tree? I'm willing to implement and test.

I've committed changes for this in CVS, please verify it fixes your
problem.

regards, tom lane

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

From forum: PostgreSQL - general

pgsql: Do not build psql's flex module on its own, but instead include

2009-11-10T15:12:52Z

Log Message:
-----------
Do not build psql's flex module on its own, but instead include it in
mainloop.c. This ensures that postgres_fe.h is read before including
any system headers, which is necessary to avoid problems on some platforms
where we make nondefault selections of feature macros for stdio.h or
other headers. We have had this policy for flex modules in the backend
for many years, but for some reason it was not applied to psql.
Per trouble report from Alexandra Roy and diagnosis by Albe Laurenz.

Tags:
----
REL8_0_STABLE

Modified Files:
--------------
pgsql/src/bin/psql:
Makefile (r1.52.4.1 -> r1.52.4.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/Makefile?r1=1.52.4.1&r2=1.52.4.2)
mainloop.c (r1.66 -> r1.66.4.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/mainloop.c?r1=1.66&r2=1.66.4.1)

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

From forum: PostgreSQL - committers

pgsql: Do not build psql's flex module on its own, but instead include

2009-11-10T15:12:44Z

Log Message:
-----------
Do not build psql's flex module on its own, but instead include it in
mainloop.c. This ensures that postgres_fe.h is read before including
any system headers, which is necessary to avoid problems on some platforms
where we make nondefault selections of feature macros for stdio.h or
other headers. We have had this policy for flex modules in the backend
for many years, but for some reason it was not applied to psql.
Per trouble report from Alexandra Roy and diagnosis by Albe Laurenz.

Tags:
----
REL8_1_STABLE

Modified Files:
--------------
pgsql/src/bin/psql:
Makefile (r1.54 -> r1.54.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/Makefile?r1=1.54&r2=1.54.2.1)
mainloop.c (r1.68 -> r1.68.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/mainloop.c?r1=1.68&r2=1.68.2.1)

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

From forum: PostgreSQL - committers

pgsql: Do not build psql's flex module on its own, but instead include

2009-11-10T15:12:37Z

Log Message:
-----------
Do not build psql's flex module on its own, but instead include it in
mainloop.c. This ensures that postgres_fe.h is read before including
any system headers, which is necessary to avoid problems on some platforms
where we make nondefault selections of feature macros for stdio.h or
other headers. We have had this policy for flex modules in the backend
for many years, but for some reason it was not applied to psql.
Per trouble report from Alexandra Roy and diagnosis by Albe Laurenz.

Tags:
----
REL8_2_STABLE

Modified Files:
--------------
pgsql/src/bin/psql:
Makefile (r1.57 -> r1.57.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/Makefile?r1=1.57&r2=1.57.2.1)
mainloop.c (r1.84 -> r1.84.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/mainloop.c?r1=1.84&r2=1.84.2.1)

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

From forum: PostgreSQL - committers

pgsql: Do not build psql's flex module on its own, but instead include

2009-11-10T15:12:29Z

Log Message:
-----------
Do not build psql's flex module on its own, but instead include it in
mainloop.c. This ensures that postgres_fe.h is read before including
any system headers, which is necessary to avoid problems on some platforms
where we make nondefault selections of feature macros for stdio.h or
other headers. We have had this policy for flex modules in the backend
for many years, but for some reason it was not applied to psql.
Per trouble report from Alexandra Roy and diagnosis by Albe Laurenz.

Tags:
----
REL8_3_STABLE

Modified Files:
--------------
pgsql/src/bin/psql:
Makefile (r1.60 -> r1.60.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/Makefile?r1=1.60&r2=1.60.2.1)
mainloop.c (r1.87 -> r1.87.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/mainloop.c?r1=1.87&r2=1.87.2.1)

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

From forum: PostgreSQL - committers

pgsql: Do not build psql's flex module on its own, but instead include

2009-11-10T15:12:21Z

Log Message:
-----------
Do not build psql's flex module on its own, but instead include it in
mainloop.c. This ensures that postgres_fe.h is read before including
any system headers, which is necessary to avoid problems on some platforms
where we make nondefault selections of feature macros for stdio.h or
other headers. We have had this policy for flex modules in the backend
for many years, but for some reason it was not applied to psql.
Per trouble report from Alexandra Roy and diagnosis by Albe Laurenz.

Tags:
----
REL8_4_STABLE

Modified Files:
--------------
pgsql/src/bin/psql:
Makefile (r1.63 -> r1.63.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/Makefile?r1=1.63&r2=1.63.2.1)
mainloop.c (r1.95 -> r1.95.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/mainloop.c?r1=1.95&r2=1.95.2.1)

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

From forum: PostgreSQL - committers

pgsql: Do not build psql's flex module on its own, but instead include

2009-11-10T15:12:13Z

Log Message:
-----------
Do not build psql's flex module on its own, but instead include it in
mainloop.c. This ensures that postgres_fe.h is read before including
any system headers, which is necessary to avoid problems on some platforms
where we make nondefault selections of feature macros for stdio.h or
other headers. We have had this policy for flex modules in the backend
for many years, but for some reason it was not applied to psql.
Per trouble report from Alexandra Roy and diagnosis by Albe Laurenz.

Modified Files:
--------------
pgsql/src/bin/psql:
Makefile (r1.66 -> r1.67)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/Makefile?r1=1.66&r2=1.67)
mainloop.c (r1.95 -> r1.96)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/mainloop.c?r1=1.95&r2=1.96)

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

From forum: PostgreSQL - committers

Missing pgagent on 1.10.0 FreeBSD port?

2009-11-10T14:40:12Z

It appears that pgagent is missing from the FreeBSD port of pgAdmin3 1.10.0.

Can someone confirm this?

I just built a new test environment and unfortunately pgagent does not appear to be installed when installing pgAdmin.

TIA

From forum: PostgreSQL - pgadmin support

Re: [GENERAL] PostgreSQL 8.3.8 on AIX5.3 : compilation failed

2009-11-10T14:36:50Z

Alvaro Herrera <alvherre@...> writes:
> Tom Lane wrote:
>> In most of the other cases the #include is done in an associated .y
>> file, but there is none in psql. Anyone have a thought which of
>> psql's .c files would be the most appropriate host?

> mainloop.c?

Yeah, that's about the same conclusion I had come to --- that's
the principal caller so it's the closest analog to what we do
elsewhere.

Will fix.

regards, tom lane

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

From forum: PostgreSQL - hackers

Re: [HACKERS] PostgreSQL 8.3.8 on AIX5.3 : compilation failed

2009-11-10T14:36:50Z

Alvaro Herrera <alvherre@...> writes:
> Tom Lane wrote:
>> In most of the other cases the #include is done in an associated .y
>> file, but there is none in psql. Anyone have a thought which of
>> psql's .c files would be the most appropriate host?

> mainloop.c?

Yeah, that's about the same conclusion I had come to --- that's
the principal caller so it's the closest analog to what we do
elsewhere.

Will fix.

regards, tom lane

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

From forum: PostgreSQL - general

Re: Incremental Backups in postgres

2009-11-10T14:25:15Z

I have set up the replication using Bucardo. This is just an additional set up

regards

On Tue, Nov 10, 2009 at 5:09 PM, silly8888 <silly8888@...> wrote:

How about using replication instead of incremental backups?

On Tue, Nov 10, 2009 at 4:56 PM, Alan Hodgson <ahodgson@...> wrote:
> On Tuesday 10 November 2009, akp geek <akpgeek@...> wrote:
>> So Is it always good to have the backup using PG_dump instead of PITR or
>> a combination of both
>>
>
> I like to do both. Ongoing PITR, daily base backups (by updating an rsync
> copy), and weekly pg_dumps that in turn go to tape.
>
> PITR gives a very recent restore point in the event of server loss. As
> previously mentioned, the full (custom) backups let you restore individual
> tables. They're also a lot smaller than base backups + WAL logs.
>
> --
> "No animals were harmed in the recording of this episode. We tried but that
> damn monkey was just too fast."
>
> --
> Sent via pgsql-general mailing list (pgsql-general@...)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

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

From forum: PostgreSQL - general

Re: BUG #5178: make check fails because of locale en_AU.US-ASCII

2009-11-10T14:15:34Z

Peter Eisentraut <peter_e@...> writes:
> On tis, 2009-11-10 at 20:45 +0000, Boh Yap wrote:
>> could not determine encoding for locale "en_AU.US-ASCII": codeset is
>> "US-ASCII"

> Try using a different locale.

Or specify an encoding explicitly.

I was wondering what we ought to do about this. I can't find any clear
documentation about these locales on my Mac, but it sure looks like they
are effectively encoding-agnostic, which means that it might be
reasonable to default to SQL_ASCII --- anyway there is certainly not any
basis for selecting a different default. However, if we want to do that
it's not a one-liner change, because the API for
pg_get_encoding_from_locale isn't designed to allow for this.

regards, tom lane

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

From forum: PostgreSQL - bugs

Re: Editor for sgml files

2009-11-10T14:10:31Z

On Tue, Nov 10, 2009 at 2:04 PM, Peter Eisentraut <peter_e@...> wrote:

> Well, a lot of hard work. ;-) Just like there are coding standards and
> best practices, there are standards and customs in writing and
> publishing.

Are these published anywhere?

--
Regards,
Richard Broersma Jr.

Visit the Los Angeles PostgreSQL Users Group (LAPUG)
http://pugs.postgresql.org/lapug

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

From forum: PostgreSQL - general

Re: Incremental Backups in postgres

2009-11-10T14:09:55Z

How about using replication instead of incremental backups?

On Tue, Nov 10, 2009 at 4:56 PM, Alan Hodgson <ahodgson@...> wrote:

> On Tuesday 10 November 2009, akp geek <akpgeek@...> wrote:
>> So Is it always good to have the backup using PG_dump instead of PITR or
>> a combination of both
>>
>
> I like to do both. Ongoing PITR, daily base backups (by updating an rsync
> copy), and weekly pg_dumps that in turn go to tape.
>
> PITR gives a very recent restore point in the event of server loss. As
> previously mentioned, the full (custom) backups let you restore individual
> tables. They're also a lot smaller than base backups + WAL logs.
>
> --
> "No animals were harmed in the recording of this episode. We tried but that
> damn monkey was just too fast."
>
> --
> Sent via pgsql-general mailing list (pgsql-general@...)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

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

From forum: PostgreSQL - general

Re: BUG #5178: make check fails because of locale en_AU.US-ASCII

2009-11-10T14:08:16Z

On tis, 2009-11-10 at 20:45 +0000, Boh Yap wrote:
> make check
> failed, when trying to initdb, with this message in log:
>
> could not determine encoding for locale "en_AU.US-ASCII": codeset is
> "US-ASCII"

Try using a different locale.

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

From forum: PostgreSQL - bugs

Re: Editor for sgml files

2009-11-10T14:04:55Z

On tis, 2009-11-10 at 07:00 -0800, David Fetter wrote:
> Well, there's the whole Docbook thing, which was pretty well thought
> out. Apart from that, I don't know. Peter?

Well, a lot of hard work. ;-) Just like there are coding standards and
best practices, there are standards and customs in writing and
publishing.

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

From forum: PostgreSQL - general