Friday, September 26, 2008

Re: [HACKERS] lock contention on parallel COPY ?

On Fri, 2008-09-26 at 12:38 -0400, Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> > heh no log archiving - I actually said that I'm now playing with
> > --truncate-before-load which seems to cause a noticeable performance (as
> > in IO generated) increase but I still see >130000 context switches/s and
> > a profile that looks like:
>
> > samples % symbol name
> > 55526 16.5614 LWLockAcquire
> > 29721 8.8647 DoCopy
> > 26581 7.9281 CopyReadLine
> > 25105 7.4879 LWLockRelease
> > 15743 4.6956 PinBuffer
> > 14725 4.3919 heap_formtuple
>
> Still a lot of contention for something, then. You might try turning on
> LWLOCK_STATS (this only requires recompiling storage/lmgr/lwlock.c) to
> get some evidence about what.

Probably loading a table with a generated PK or loading data in
ascending sequence, so its contending heavily for the rightmost edge of
the index.

We need to load data a block at a time and buffer the inserts into the
index also, so we don't need to lock/unlock per row.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support


--
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] lock contention on parallel COPY ?

Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>> that one generates a huge amount of logs - output for ~60s into the load
>> is available here:
>> http://www.kaltenbrunner.cc/files/lwstats.txt (21MB!)
>
> Huh ... essentially all the contention is for OidGenLock. I take it
> you're loading into a table that has OIDs?

hmm that particular database has its ancient roots on 7.3 (or 7.4) and
indeed it seems that some tables in the dump are preceeded by a SET
default_with_oids = true;

Will go and elimited those and try again.


Stefan

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

Re: [Probablemente Spam] Re: [pgsql-es-ayuda] PostgreSQL Spanish Documentation Project and Developmented create od Event next Year for Latin America for Country Regional

Ernesto:

Por nuestra parte estoy esperando el acceso los fuentes del
Webtrasletion ... y demás para comenzar con los trabajos de rescate del
proyecto.

En Cuba estamos listo para crear las comisiones que necesitemos para
seguir adelante con los trabajos.

Saludos,
Gilberto.

El vie, 26-09-2008 a las 11:27 -0430, Ernesto Lozano escribió:
> Estimados Amigos de la Comunidad
>
> Placer saludarlos nuestra organizacion esta presta para apoyar la
> traduccion estoy copiando a nuestro responsable que hemos designado a
> Alfonso Lopez para este proyecto a integrarse con ustedes para llevar
> a cabo este projecto
>
> Espero que podamos lograr los objetivos propuestos y sigue en Pie la
> propuesta de organizar Talleres Regionales o Tutoriales para Postgres
> en nuestra America Latina vamos a crear el comite de la Region Global
> para crear comiteb en cada Pais para lograr el impulso esperado
>
> Mis Saludos y Respetos
>
> Ernesto Lozano
> Director General
> HIA TECHNOLOGY DE VENEZUELA
> Telefono Master 00582418672023
> Email elozano@hiatechnology.com.ve
>
> 2008/9/26, postgres Emanuel CALVO FRANCO <postgres.arg@gmail.com>:
> > En que quedo el tema de la traduccion??
> > --
> > TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo
> > agradecerán
> >
> --
> TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
> http://archives.postgresql.org/pgsql-es-ayuda
>

--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podr� leerlo

Re: [HACKERS] PostgreSQL future ideas

On Fri, Sep 26, 2008 at 11:52 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> Speaking of language choice, no one said that _all_ the source code would
>> need to be rewritten. It would be nice, for example, if PostgreSQL rewrote
>> the current GUC system with a glue language like Lua (which is also very
>> C-like).
>
> No it wouldn't. All it would mean is that you'd need developers fluent in
> both languages.

Having done quite a bit of internals work with SAP DB (which is an
amalgamation of C, C++, and Pascal), I completely agree. The entire
system, if possible, should be in a single language.

--
Jonah H. Harris, Senior DBA
myYearbook.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] lock contention on parallel COPY ?

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> that one generates a huge amount of logs - output for ~60s into the load
> is available here:
> http://www.kaltenbrunner.cc/files/lwstats.txt (21MB!)

Huh ... essentially all the contention is for OidGenLock. I take it
you're loading into a table that has OIDs?

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

[SQL] Finding sequential records

Hi,

I've been kicking this around today and I can't think of a way to solve
my problem in "pure SQL" (i.e. I can only do it with a
looping/cursor-type solution and some variables).

Given a table with this DDL/data script:

drop table if exists dummy;
create table dummy (
id integer primary key,
name varchar(255),
fkey_id integer
)
;
insert into dummy (id, name, fkey_id) values (502163,'3Br/3Ba Pool
Villa in Westin St. John, USVI- Summer 2008',500100);
insert into dummy (id, name, fkey_id) values (502164,'3Br/3Ba Pool
Villa in Westin St. John, USVI- Summer 2008',500100);
insert into dummy (id, name, fkey_id) values (502169,'Lazy Bear
Lodge',105);
-- not sequential id to previous
insert into dummy (id, name, fkey_id) values (502199,'Lazy Bear
Lodge',105);
insert into dummy (id, name, fkey_id) values (502170,'3 Bed, 1 Bath
Cottage Less Than a Mile from West Dennis Beach',500089);
insert into dummy (id, name, fkey_id) values (502171,'3 Bed, 1 Bath
Cottage Less Than a Mile from West Dennis Beach',500089);
-- not sequential id nor duplicate fkey_id to previous
insert into dummy (id, name, fkey_id) values (502175,'3 Bed, 1 Bath
Cottage Less Than a Mile from West Dennis Beach',500102);
insert into dummy (id, name, fkey_id) values (502213,'Sea
Watch',500128);
-- not duplicate fkey_id to previous
insert into dummy (id, name, fkey_id) values (502214,'Sea
Watch',500130);

Find all instances where
* name is duplicated
* fkey_id is the same (for the any set of duplicated name fields)
* id is sequential (for any set of duplicated name fields)

The system should return

502163
502164
502170
502171

Here's as far as I got:

select id
from dummy
where
name in (
select name from dummy
group by name
having count(name)>1
)
order by id

I can't figure out how to test for duplicate fkey_id when name is the
same, nor to test for sequential id's when name is the same.

Having a method for either would be great, and both would be a bonus!

It seems like there's a clever way to do this without cursors but I
can't figure it out!

Thanks for any help!

Steve


--
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] Meridiem markers (was: [BUGS] Incorrect "invalid AM/PM string" error from to_timestamp)

"Brendan Jurd" <direvus@gmail.com> writes:
> One way to tidy this up would be to re-implement the meridiem markers
> using the seq_search functions, i.e., make it work like the day and
> month names. This would make it easy to accept any flavour of marker,
> and the error messages thrown for bogus input would then be the same
> as those for bogus day and month names.

> Note that all of the above applies equally to the era markers B.C. and A.D.

+1 ... making these work like month names makes sense to me.

regards, tom lane

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

[HACKERS] Meridiem markers (was: [BUGS] Incorrect "invalid AM/PM string" error from to_timestamp)

Hey folks,

Tom pointed out in the parent thread [1] that the error message for
bogus AM/PM markers in to_timestamp is pretty lame:

ERROR: invalid AM/PM string

I agree, and once I started thinking about this, I came up with other
gripes concerning the treatment of 12-hour time in to_timestamp, the
use of the meridiem markers (AM/PM) in particular.

Currently, Postgres accepts four separate flavours for specifying
meridiem markers, given by uppercase/lowercase and with/without
periods:

* am/pm
* AM/PM
* a.m./p.m.
* A.M./P.M.

What I find surprising about the implementation is that you must
specify the correct formatting pattern for the particular flavour of
meridiem marker in your input string, or you get the aforementioned
lame error message. Consider:

postgres=# select to_timestamp('11:47 pm 27 Sep 2008', 'HH:MI PM DD Mon YYYY');
ERROR: invalid AM/PM string

Here it seems to me that Postgres is being unnecessarily pedantic.
Yes, the case of the marker differs from the case of the formatting
keyword, but is that really grounds for an ERROR? The user's
intention is perfectly unambiguous, so why not just accept the input?

I would go so far as to say that we should accept any of the 8 valid
meridiem markers, regardless of which flavour is indicated by the
formatting keyword.

Day and month names already work this way. We don't throw an error if
a user specifies a mixed-case month name like "Sep" but uses the
uppercase formatting keyword "MON".

I suspect that the current behaviour isn't so much a deliberate choice
to be draconian as it is a consequence of the way the code was
developed; as the inverse of to_char().

One way to tidy this up would be to re-implement the meridiem markers
using the seq_search functions, i.e., make it work like the day and
month names. This would make it easy to accept any flavour of marker,
and the error messages thrown for bogus input would then be the same
as those for bogus day and month names.

Note that all of the above applies equally to the era markers B.C. and A.D.

Comments?

Cheers,
BJ

[1] http://archives.postgresql.org/message-id/8148.1222359751@sss.pgh.pa.us

--
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] Stroring html form settings

Would an EAV model work? I'm thinking something like <form,field,value>. For example:
formA,ckbox1,true
formA,input1,initial value
formB,textarea1,enter your long comment here

You could easily extend this to <user,form,field,value>, or normalize it as you see fit.

This would work great too. If we go this route, we'll keep it simple and use the <user_id, report_id, field, value>, as you suggested, where user_id and report_id are foreign key references.

Another possibility is to use hstore hashes for form fields/values. See
http://www.postgresql.org/docs/8.3/static/hstore.html

I will look into this too. But we'll have to upgrade to 8.3 which is not a problem.

Thank you Reece.

Dianne

Re: [SQL] Problem with pg_connect() in PHP

Can I assume the missing '."' From the end of PG_PASSWORD is a cut and paste error?

 

Edward W. Rouse

 

From: pgsql-sql-owner@postgresql.org [mailto:pgsql-sql-owner@postgresql.org] On Behalf Of James Kitambara
Sent: Friday, September 26, 2008 1:22 AM
To: pgsql-sql
Cc: Kenichiro Arakaki; Ken Arakaki
Subject: [SQL] Problem with pg_connect() in PHP

 

Dear Members of

I have installed the Apache 2.0.61,  PHP 5.2.4 and PostgreSQL 8.1 on my local computer.

All three software were successfully tested. I changed ";extension=php_pgsql.dll"  to

"extension=php_pgsql.dll"    in the php.ini file in order to enable PostgreSQL in PHP.

The problem comes when I try to connect to the PostgreSQL Database using php function pg_connect

$dbconn = pg_connect("host=".PG_HOST_NAME." port=".PG_PORT_NUM."  dbname=".PG_DB_NAME." user=".PG_USER." password=".PG_PASSWORD);

All the arguments in the function pg_connect() are defined.

Unfortunately I am getting the Fatal error: "Call to undefined function pg_connect() in C:\Web\html\Staff_Management\example1.php on line 23"

C:\Web\html is my document root.

What could be the possible mistake?

Anyone to assist me!

Best regards,

James Kitambara

 

[GENERAL] Slony Problem

Hi,
i have 1 master and one slave db.

when in the master i run this sql : update wspet00 set datamf=20080925
where numcar = 7123123123
in the slave slon process i have an error with this log:


update only "public"."wspet00" set datamf='20080925' where ;
" ERROR: syntax error at or near ";"
LINE 1: update only "public"."wspet00" set datamf='20080925' where ;


it's seem like the sql was truncate..any idea?

Postgres version 8.2.5 and slony 1.2.13 on windows 2003 server.

Thanks,
Francesco

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

Re: [HACKERS] lock contention on parallel COPY ?

Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>> heh no log archiving - I actually said that I'm now playing with
>> --truncate-before-load which seems to cause a noticeable performance (as
>> in IO generated) increase but I still see >130000 context switches/s and
>> a profile that looks like:
>
>> samples % symbol name
>> 55526 16.5614 LWLockAcquire
>> 29721 8.8647 DoCopy
>> 26581 7.9281 CopyReadLine
>> 25105 7.4879 LWLockRelease
>> 15743 4.6956 PinBuffer
>> 14725 4.3919 heap_formtuple
>
> Still a lot of contention for something, then. You might try turning on
> LWLOCK_STATS (this only requires recompiling storage/lmgr/lwlock.c) to
> get some evidence about what.

that one generates a huge amount of logs - output for ~60s into the load
is available here:

http://www.kaltenbrunner.cc/files/lwstats.txt (21MB!)


Stefan

--
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] Stroring html form settings

On Fri, 2008-09-26 at 09:23 -0700, Dianne Yumul wrote:
If the structure of each report did not differ this would work great 
but unfortunately it does.

Diane-

Would an EAV model work? I'm thinking something like <form,field,value>. For example:
formA,ckbox1,true
formA,input1,initial value
formB,textarea1,enter your long comment here

You could easily extend this to <user,form,field,value>, or normalize it as you see fit.

Another possibility is to use hstore hashes for form fields/values. See
http://www.postgresql.org/docs/8.3/static/hstore.html

Do either of those suffice?

-Reece

 --  Reece Hart, http://harts.net/reece/, GPG:0x25EC91A0 

Re: [GENERAL] Stroring html form settings

I would suggest trying to keep architecture simple with a one-to-one correspondence between
Architecture classes and the class attributes and DB Tables and the DB table's columns
This will come in handy when and if you want to look at ORM tools to persist the class attributes
to DB tables and columns via Hibernate or IBatis
here is a great example which details a Table called Honey and a class called Honey which will persist class contents to the PostGRES DB by utilising the methods available from InitSessionFactory

http://www.laliluna.de/first-hibernate-example-tutorial.html

HTH
Martin
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.


> From: dianne@wellsgaming.com
> Subject: Re: [GENERAL] Stroring html form settings
> Date: Fri, 26 Sep 2008 09:23:21 -0700
> To: pgsql-general@postgresql.org
>
> First, I want to thank you for your help. You have made great points
> and I just want to respond to some of your questions.
>
> > My first thought is that if you use a combined "info" field, you'll
> > lose the ability to easily do any kind of meaningful data analysis
> > based on which boxes are checked. If you just want to record what a
> > given user said at a certain time, but don't need it for any other,
> > more interesting evaluation of the data, then why bother with a
> > database?
>
> You are right that I don't really need to do any evaluation of the
> data, I just need to be able to get the default values of a form
> every time the user logs on. Each user may have their own default
> value for a form, and each form will have different components. A
> database was the first (may be not the best?) thing I thought of.
> Would you have other suggestions of how I should store them?
>
> > If it were me, I would probably store the form values in the database
> > fields, so that the table's columns matched the various data inputs in
> > the form.
>
> If the structure of each report did not differ this would work great
> but unfortunately it does.
>
> Thank you again.
>
> Dianne
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general


Get more out of the Web. Learn 10 hidden secrets of Windows Live. Learn Now

[pgadmin-support] [Fwd: Re: sudden program termination: no warning, error, or crash]

Hi Kev!

Please send this to the list, not to my private email account:

pgadmin-support@postgresql.org

Regards
Erwin

-------- Original Message --------
Subject: Re: sudden program termination: no warning, error, or crash
Date: Wed, 24 Sep 2008 10:45:45 -0700 (PDT)
From: Kev <kevinjamesfield@gmail.com>
To: Erwin Brandstetter <brsaweda@gmail.com>
References:
<053d692a-a486-4106-a45f-ec3daed63fa4@2g2000hsn.googlegroups.com>
<1218071e-ddd1-4abc-b46e-e64cf3d9751f@m73g2000hsh.googlegroups.com>

On Jun 4, 6:11 pm, Erwin Brandstetter <brsaw...@gmail.com> wrote:
> Hi Kev!
>
> On May 28, 2:27 pm, Kev <kevinjamesfi...@gmail.com> wrote:> Hi everyone,
>
> > I've had this problem maybe three times in the past few months and
> > didn't think much of it, but since it happened again yesterday I
> > thought I'd report it. Unfortunately I can't remember what I was
> > doing at the time, I think just interacting with the main window
> > somehow, like clicking on a tree node, possibly. Whatever it was, it
> > was a routine action and I was in the middle of just using the program
> > normally, when all of the sudden, the pgAdmin window disappears
> > completely, along with its taskbar entry, and is no longer running at
> > all. In the Task Manager it is not listed. Just instantaneously no
> > longer running with no other indication that anything went wrong.
>
> > This is under Windows Server 2003 Standard SP2.
>
> (...)
>
> It is hard to comment on that at all if you don't remember what you
> did to trigger the crash. Even harder if you don't mention your
> version of pgadmin. (!)
> A couple bugs causing crashes like that have been fixed in the past. A
> few more for the upcoming release 1.8.4. An upgrade might help.
>
> Regards
> Erwin

Sorry, I forgot about this thread, but it just happened again, this
time, the 1.8.4 rev from June 4th.

And this time, it was that I had just dropped a db that I had open in
the browser. It normally complains with the same popup five times,
then asks if I want to close the browser, which it did, I think I hit
Enter on the default by accident, whatever that is. Then it just sat
there for a few moments, and disappeared. Normally I can do this drop
operation with pgAdmin in the middle of browsing it, no problem,
although it is easier if I remember to just close that part of the
browse tree, refresh on the server entry after drop+recreate, and only
then drill down again.

Is there something in Windows that kills processes if they seem to be
in an infinite loop? Maybe it's doing that.
Another thing, the Application Log in Event Viewer said this after
this time (not sure about before):

"Faulting application pgadmin3.exe, version 1.8.4.99, faulting module
comctl32.dll, version 6.0.3790.3959, fault address 0x0003a88c."


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

Thursday, September 25, 2008

Re: [GENERAL] problem with custom_variable_classes

Taras Kopets wrote:
> now you have to initialize this variable once per session before usage:
>
> SELECT set_config('olap.rownum_name', false);

Ok, thanks. That has fixed my problem.

Malcolm


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

[ADMIN] postgres at reboot

Hi Everybody,

About 1.5 month ago, my machine (which runs redhat linux
2.6.9-78.0.1.ELsmp on Dell hardware with postgres 8.3.3)
had a terrible crash. I am mostly recovered, but there
is at least one more thing that's not right.

Namely, when the machine gets rebooted, postgres doesn't
start automatically. Before the crash, there was no such
problem.

I see a file /etc/rc.d/init.d/postgresql. Is this the
start-up script? If not, please tell me what would be the
correct one (and where would I find one). If it is, can you
please tell me where I would find the latest one anyway?
(Maybe the latest one got lost and I am looking at an old
copy???)

The detail of how it happens escapes me, but as near as I
can reconstruct in my head, after the reboot I discover that
postgres is not running and I issue:
pg_ctl start
and it complains something to the effect that it is already
started (which seems to be not true) and maybe it gives me
a pid for the postmaster. I think I tried:
pg_ctl stop
and it told me something a bit disageeable. But I found a
file with that pid in /tmp directory and when I remove that
file, then "pg_ctl start" succeeds.

If this sounds familiar to you (or you have some clue as to
what is going on), I would appreciate a tip.

Regards,

Tena Sakai
tsakai@gallo.ucsf.edu

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

Re: [PERFORM] Slow updates, poor IO

On Thursday 25 September 2008, John Huttley <John@mib-infotech.co.nz> wrote:
>
> Comments anyone?

Don't do full table updates? This is not exactly a news flash.


--
Alan

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

Re: [PERFORM] Slow updates, poor IO

On Thu, Sep 25, 2008 at 1:24 PM, John Huttley <John@mib-infotech.co.nz> wrote:
> I've just had an interesting encounter with the slow full table update
> problem that is inherent with MVCC
>
> The system is 64 bit linux with 2.6.25 kernel feeding scsi disks.
>
> the table is
>
> CREATE TABLE file (
> fileid integer NOT NULL,
> fileindex integer DEFAULT 0 NOT NULL,
> jobid integer NOT NULL,
> pathid integer NOT NULL,
> filenameid integer NOT NULL,
> markid integer DEFAULT 0 NOT NULL,
> lstat text NOT NULL,
> md5 text NOT NULL,
> perms text
> );
>
> ALTER TABLE ONLY file
> ADD CONSTRAINT file_pkey PRIMARY KEY (fileid);
>
> CREATE INDEX file_fp_idx ON file USING btree (filenameid, pathid);
> CREATE INDEX file_jobid_idx ON file USING btree (jobid);
>
> There are 2.7M rows.
>
> running update file set perms='0664' took about 10 mins

So, how many rows would already be set to 0664? Would adding a where
clause speed it up?

update file set perms='0664' where perms <> '0664';

> during this period, vmstat reported Blocks Out holding in the 4000 to 6000
> range.
>
>
> When I dropped the indexes this query ran in 48sec.
> Blocks out peaking at 55000.
>
> So there is a double whammy.
> MVCC requires more work to be done when indexes are defined and then this
> work
> results in much lower IO, compounding the problem.

That's because it becomes more random and less sequential. If you had
a large enough drive array you could get that kind of performance for
updating indexes, since the accesses would tend to hit different
drives most the time.

Under heavy load on the production servers at work we can see 30 to 60
Megs a second random access with 12 drives, meaning 2.5 to 5Megs per
second per drive. Sequential throughput is about 5 to 10 times
higher.

What you're seeing are likely the effects of running a db on
insufficient drive hardware.

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

Re: [ADMIN] missing chunk number 0 for toast value

"Scott Marlowe" <scott.marlowe@gmail.com> writes:
> On Thu, Sep 25, 2008 at 10:09 AM, BJ Taylor
> <btaylor@propertysolutions.com> wrote:
>> PANIC: right sibling's left-link doesn't match: block 175337 links to
>> 243096 instead of expected 29675 in index "dbmail_headervalue_3"
>> STATEMENT: INSERT INTO dbmail_headervalue (headername_id, physmessage_id,
>> headervalue) VALUES (4,12335778,'from [76.13.13.25] by
>> n6.bullet.mail.ac4.yahoo.com with NNFMP; 25 Sep 2008 04:01:36 -0000')
>> LOG: server process (PID 13888) was terminated by signal 6: Aborted
>> LOG: terminating any other active server processes
>> WARNING: terminating connection because of crash of another server process

> Tom, does postgres generate abort signal? Or would this be an external signal?

Yeah, we call abort() after reporting a PANIC error, so as to get a core
dump.

regards, tom lane

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

[PHP] Can't get PHP PDO LOB working with PostgreSQL (WRONG CODE)

I am very sorry I submitted the wrong code in the original
email. The email below is the right one! Please disregard my first
email to this list.

Hi.

I have spent about two working days trying to get PostgreSQL working
with PDO inserting binary content and pulling it back out without
success.

I have tested this on Debian Etch using PHP 5.2.0 and PostgreSQL(libpq)
8.1.11. I have enabled the PostgreSQL PDO driver.

I have set up a simple table to hold the content:

id serial
blob_type character varying
attachment oid

I am using a simple form to process the upload, and my PHP upload
script looks like this (modified a little from the PHP manual):

try {

$pdo = new PDO ("$pdo_database:host=$pdo_hostname;dbname=
$pdo_dbname","$pdo_username","$pdo_password");
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);

} catch (Exception $e) {

echo 'Caught exception: ',$e->getMessage(), "\n";

}

require_once ("knl_mime_type.php"); // Gets the correct mime type.
$mime_type = new knl_mime_type();
$blob_type = $mime_type->getMimeType($tmpfilename);

$pdo->beginTransaction();
$oid = $pdo->pgsqlLOBCreate();
$stream = $pdo->pgsqlLOBOpen($oid, 'w');
$local = fopen($tmpfilename, 'rb');
stream_copy_to_stream($local, $stream);
$local = null;
$stream = null;

$attachment = fopen($_FILES['file']['tmp_name'], "rb");
$filename = $_FILES['file']['name'];

$stmt = $pdo->prepare("INSERT INTO attachments (blob_type, filename,
attachment) VALUES (:blob_type, :filename, :attachment)");

$stmt->bindParam(':blob_type', $blob_type, PDO::PARAM_STR);
$stmt->bindParam(':filename', $filename, PDO::PARAM_STR);
$stmt->bindParam(':attachment', $attachment, PDO::PARAM_LOB);

$stmt->execute();

$pdo->commit();

When I submit the form, I can see (using PHPPgAdmin) the binary file, in
this test case a PNG image being inserted.

From the table I see this info using PHPPgAdmin:

id blob_type filename attachment
25 image/png shot2.png 16441

I don't know how the binary data are supposed to look like since I am
migrating from MySQL, and only have that as a comparison.

If I understand the PostgreSQL manual correctly the above number
"16441" is a OID reference number to the binary data.

I don't know if the above is correct or if PostgreSQL has received the
binary data correctly, maybe someone can confirm this for me please?

Anyway, when I try to pull that data from the database (again using the
example from the PHP manual) I just get the reference number "16441"
back to the browser.

I am using the following code to retrieve the data:

$stmt = $pdo->prepare("SELECT blob_type, attachment FROM attachments
WHERE id = :id LIMIT 1");
$stmt->bindParam(':id', $_GET['id'], PDO::PARAM_STR);

$stmt->execute();

$results = $stmt->fetchAll();

foreach ($results as $row) {
$blob_type = $row['blob_type'];
$attachment = $row['attachment'];
}

header("Content-type: $blob_type");
echo $attachment;

If I use Firefox and take a look at the source code behind the page I
get served, I just see the number "16441" and nothing else.

Please notice that the above example are taken directly from the PHP
manual just modified a little. I have also tried using the examples
directly without any modifications, but the result is the same.

http://dk.php.net/manual/en/function.pdo-pgsqllobcreate.php

What am I missing or doing wrong here?

Best regards.

Rico.

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

Re: [GENERAL] ease of use sync

On Thu, Sep 25, 2008 at 12:09 PM, zach cruise <zachc1980@gmail.com> wrote:
> on projects where i ended up selecting oracle, *my* main reasons were
> (1) clustering/replication
> (2) cross-database query
> (3) promise of drcp
> in that order
>
> for (1), actually more for synchronization/transfer, i got a simple
> suggestion:
> while installing postgresql,

But for 99.9% of people installing they don't want to deal with it,
and if they're on a unix OS using packages, it would have to halt
install to ask a question, which is considered bad form.

So why not instead build a script to do all the things you do by hand
afterwards. I'd think that would get more traction.

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

[PERFORM] Slow updates, poor IO

I've just had an interesting encounter with the slow full table update
problem that is inherent with MVCC

The system is 64 bit linux with 2.6.25 kernel feeding scsi disks.

the table is

CREATE TABLE file (
fileid integer NOT NULL,
fileindex integer DEFAULT 0 NOT NULL,
jobid integer NOT NULL,
pathid integer NOT NULL,
filenameid integer NOT NULL,
markid integer DEFAULT 0 NOT NULL,
lstat text NOT NULL,
md5 text NOT NULL,
perms text
);

ALTER TABLE ONLY file
ADD CONSTRAINT file_pkey PRIMARY KEY (fileid);

CREATE INDEX file_fp_idx ON file USING btree (filenameid, pathid);
CREATE INDEX file_jobid_idx ON file USING btree (jobid);

There are 2.7M rows.

running update file set perms='0664' took about 10 mins

during this period, vmstat reported Blocks Out holding in the 4000 to
6000 range.


When I dropped the indexes this query ran in 48sec.
Blocks out peaking at 55000.

So there is a double whammy.
MVCC requires more work to be done when indexes are defined and then
this work
results in much lower IO, compounding the problem.


Comments anyone?


--john

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

[PHP] Can't get PHP PDO LOB working with PostgreSQL

Hi.

I have spent about two working days trying to get PostgreSQL working
with PDO inserting binary content and pulling it back out without
success.

I have tested this on Debian Etch using PHP 5.2.0 and PostgreSQL(libpq)
8.1.11. I have enabled the PostgreSQL PDO driver.

I have set up a simple table to hold the content:

id serial
blob_type character varying
attachment oid

I am using a simple form to process the upload, and my PHP upload
script looks like this (modified a little from the PHP manual):

try {

$pdo = new PDO ("$pdo_database:host=$pdo_hostname;dbname=
$pdo_dbname","$pdo_username","$pdo_password");
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);

} catch (Exception $e) {

echo 'Caught exception: ',$e->getMessage(), "\n";

}

ini_set('max_execution_time', '0');
ini_set('memory_limit', '128M');

require_once ("knl_mime_type.php"); // Gets the correct mime type.
$mime_type = new knl_mime_type();
$blob_type = $mime_type->getMimeType($tmpfilename);

$pdo->beginTransaction();

$attachment = fopen($_FILES['file']['tmp_name'], "rb");
$filename = $_FILES['file']['name'];

$stmt = $pdo->prepare("INSERT INTO attachments (blob_type, filename,
attachment) VALUES (:blob_type, :filename, :attachment)");

$stmt->bindParam(':blob_type', $blob_type, PDO::PARAM_STR);
$stmt->bindParam(':filename', $filename, PDO::PARAM_STR);
$stmt->bindParam(':attachment', $attachment, PDO::PARAM_LOB);

$stmt->execute();

$pdo->commit();

When I submit the form, I can see (using PHPPgAdmin) the binary file, in
this test case a PNG image being inserted.

From the table I see this info using PHPPgAdmin:

id blob_type filename attachment
25 image/png shot2.png 16441

I don't know how the binary data are supposed to look like since I am
migrating from MySQL, and only have that as a comparison.

If I understand the PostgreSQL manual correctly the above number
"16441" is a OID reference number to the binary data.

I don't know if the above is correct or if PostgreSQL has received the
binary data correctly, maybe someone can confirm this for me please?

Anyway, when I try to pull that data from the database (again using the
example from the PHP manual) I just get the reference number "16441"
back to the browser.

I am using the following code to retrieve the data:

$stmt = $pdo->prepare("SELECT blob_type, attachment FROM attachments
WHERE id = :id LIMIT 1");
$stmt->bindParam(':id', $_GET['id'], PDO::PARAM_STR);

$stmt->execute();

$results = $stmt->fetchAll();

foreach ($results as $row) {
$blob_type = $row['blob_type'];
$attachment = $row['attachment'];
}

header("Content-type: $blob_type");
echo $attachment;

If I use Firefox and take a look at the source code behind the page I
get served, I just see the number "16441" and nothing else.

Please notice that the above example are taken directly from the PHP
manual just modified a little. I have also tried using the examples
directly without any modifications, but the result is the same.

http://dk.php.net/manual/en/function.pdo-pgsqllobcreate.php

What am I missing or doing wrong here?

Best regards.

Rico.

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

[PERFORM] CPU load

Hello,

postmaster heavily loads processor. The database is accessed from java
aplication (with several threads), C applications and from PHP scripts.

It seems that one php script, called periodicaly, rises the load but the
script is very simple, something like this:

$var__base = new baza($dbhost,$dbport,$dbname,$dbuser,$dbpasswd);
$pok_baza = new upit($var__base->veza);
$upit_datum="SELECT * FROM system_alarm WHERE date= '$danas' AND
time>=(LOCALTIME - interval '$vrijeme_razmak hours') ORDER BY date DESC,
time DESC";

The statment is executed in approximately 0.6 sec.

The number of open connections is constantly 107.

The operating system is Debian GNU/Linux kernel 2.6.18-4-686.
Database version is PostgreSQL 8.2.4.


Thank you very much for any help.

Maja Stula


_________________________________________________________________________

The result of the top command:

top - 20:44:58 up 5:36, 1 user, load average: 1.31, 1.39, 1.24
Tasks: 277 total, 2 running, 275 sleeping, 0 stopped, 0 zombie
Cpu(s): 11.5%us, 2.2%sy, 0.0%ni, 86.3%id, 0.0%wa, 0.0%hi, 0.0%si,
0.0%st
Mem: 3370808k total, 1070324k used, 2300484k free, 49484k buffers
Swap: 1951888k total, 0k used, 1951888k free, 485396k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4990 postgres 25 0 41160 19m 18m R 100 0.6 1:36.74 postmaster
15278 test 24 0 1000m 40m 5668 S 9 1.2 1:42.37 java
18892 root 15 0 2468 1284 884 R 0 0.0 0:00.05 top
1 root 15 0 2044 696 596 S 0 0.0 0:02.51 init
2 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/0
3 root 34 19 0 0 0 S 0 0.0 0:00.12 ksoftirqd/0
4 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/1
5 root 34 19 0 0 0 S 0 0.0 0:00.00 ksoftirqd/1
6 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/2
7 root 34 19 0 0 0 S 0 0.0 0:00.00 ksoftirqd/2

__________________________________________________________________________

The result of vmstat command:

kamis03:/etc# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
2 0 0 2271356 49868 505252 0 0 2 32 40 83 6 1
93 0
2 0 0 2271232 49868 505304 0 0 0 2348 459 1118 14 2
84 0
3 0 0 2271232 49868 505304 0 0 0 16 305 1197 11 2
87 0
3 0 0 2270984 49868 505432 0 0 0 8 407 1821 15 3
82 0
2 0 0 2270984 49868 505432 0 0 0 0 271 1328 11 2
87 0
1 0 0 2270984 49868 505440 0 0 0 24 375 1530 5 1
94 0
2 0 0 2270488 49868 505440 0 0 0 1216 401 1541 12 2
86 0

__________________________________________________________________________

The cpu configuration is:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5310 @ 1.60GHz
stepping : 7
cpu MHz : 1596.076
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm
bogomips : 3194.46

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5310 @ 1.60GHz
stepping : 7
cpu MHz : 1596.076
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 4
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm
bogomips : 3191.94

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5310 @ 1.60GHz
stepping : 7
cpu MHz : 1596.076
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 4
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm
bogomips : 3192.01

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5310 @ 1.60GHz
stepping : 7
cpu MHz : 1596.076
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 3
cpu cores : 4
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm
bogomips : 3192.01

processor : 4
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5310 @ 1.60GHz
stepping : 7
cpu MHz : 1596.076
cache size : 4096 KB
physical id : 1
siblings : 4
core id : 0
cpu cores : 4
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm
bogomips : 3191.98

processor : 5
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5310 @ 1.60GHz
stepping : 7
cpu MHz : 1596.076
cache size : 4096 KB
physical id : 1
siblings : 4
core id : 1
cpu cores : 4
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm
bogomips : 3191.98

processor : 6
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5310 @ 1.60GHz
stepping : 7
cpu MHz : 1596.076
cache size : 4096 KB
physical id : 1
siblings : 4
core id : 2
cpu cores : 4
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm
bogomips : 3191.97

processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5310 @ 1.60GHz
stepping : 7
cpu MHz : 1596.076
cache size : 4096 KB
physical id : 1
siblings : 4
core id : 3
cpu cores : 4
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm
bogomips : 3191.97

__________________________________________________________________________


Postgresql.conf file:

# -----------------------------
# PostgreSQL configuration file
# -----------------------------
#
# This file consists of lines of the form:
#
# name = value
#
# (The '=' is optional.) White space may be used. Comments are introduced
# with '#' anywhere on a line. The complete list of option names and
# allowed values can be found in the PostgreSQL documentation. The
# commented-out settings shown in this file represent the default values.
#
# Please note that re-commenting a setting is NOT sufficient to revert it
# to the default value, unless you restart the postmaster.
#
# Any option can also be given as a command line switch to the
# postmaster, e.g. 'postmaster -c log_connections=on'. Some options
# can be changed at run-time with the 'SET' SQL command.
#
# This file is read on postmaster startup and when the postmaster
# receives a SIGHUP. If you edit the file on a running system, you have
# to SIGHUP the postmaster for the changes to take effect, or use
# "pg_ctl reload". Some settings, such as listen_addresses, require
# a postmaster shutdown and restart to take effect.


#---------------------------------------------------------------------------
# FILE LOCATIONS
#---------------------------------------------------------------------------

# The default values of these variables are driven from the -D command line
# switch or PGDATA environment variable, represented here as ConfigDir.

#data_directory = 'ConfigDir' # use data in another directory
hba_file = '/etc/postgresql/8.1/main/pg_hba.conf' # host-based
authentication file
ident_file = '/etc/postgresql/8.1/main/pg_ident.conf' # IDENT
configuration file

# If external_pid_file is not explicitly set, no extra pid file is written.
external_pid_file = '/var/run/postgresql/8.1-main.pid' # write an extra
pid file


#---------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#---------------------------------------------------------------------------

# - Connection Settings -

#listen_addresses = 'localhost' # what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost', '*' = all
port = 5432

# Maksimalni broj konekcija je podignut na 1000
# Maja 15.6
max_connections = 1000
#max_connections = 100
# note: increasing max_connections costs ~400 bytes of shared memory per
# connection slot, plus lock space (see max_locks_per_transaction). You
# might also need to raise shared_buffers to support more connections.
#superuser_reserved_connections = 2
unix_socket_directory = '/var/run/postgresql'
#unix_socket_group = ''
#unix_socket_permissions = 0777 # octal
#bonjour_name = '' # defaults to the computer name

# - Security & Authentication -

#authentication_timeout = 60 # 1-600, in seconds
ssl = false
#password_encryption = on
#db_user_namespace = off

# Kerberos
#krb_server_keyfile = ''
#krb_srvname = 'postgres'
#krb_server_hostname = '' # empty string matches any keytab entry
#krb_caseins_users = off

# - TCP Keepalives -
# see 'man 7 tcp' for details

#tcp_keepalives_idle = 0 # TCP_KEEPIDLE, in seconds;
# 0 selects the system default
#tcp_keepalives_interval = 0 # TCP_KEEPINTVL, in seconds;
# 0 selects the system default
#tcp_keepalives_count = 0 # TCP_KEEPCNT;
# 0 selects the system default


#---------------------------------------------------------------------------
# RESOURCE USAGE (except WAL)
#---------------------------------------------------------------------------

# - Memory -

#shared_buffers = 1000 # min 16 or max_connections*2, 8KB each
# broj buffera mora biti dva puta veci od max. broj konekcija
shared_buffers = 2000
#temp_buffers = 1000 # min 100, 8KB each
#max_prepared_transactions = 5 # can be 0 or more
# note: increasing max_prepared_transactions costs ~600 bytes of shared
memory
# per transaction slot, plus lock space (see max_locks_per_transaction).
#work_mem = 1024 # min 64, size in KB
#maintenance_work_mem = 16384 # min 1024, size in KB
#max_stack_depth = 2048 # min 100, size in KB

# - Free Space Map -

#max_fsm_pages = 20000 # min max_fsm_relations*16, 6 bytes each
#max_fsm_relations = 1000 # min 100, ~70 bytes each

# - Kernel Resource Usage -

#max_files_per_process = 1000 # min 25
#preload_libraries = ''

# - Cost-Based Vacuum Delay -

#vacuum_cost_delay = 0 # 0-1000 milliseconds
#vacuum_cost_page_hit = 1 # 0-10000 credits
#vacuum_cost_page_miss = 10 # 0-10000 credits
#vacuum_cost_page_dirty = 20 # 0-10000 credits
#vacuum_cost_limit = 200 # 0-10000 credits

# - Background writer -

#bgwriter_delay = 200 # 10-10000 milliseconds between rounds
#bgwriter_lru_percent = 1.0 # 0-100% of LRU buffers scanned/round
#bgwriter_lru_maxpages = 5 # 0-1000 buffers max written/round
#bgwriter_all_percent = 0.333 # 0-100% of all buffers scanned/round
#bgwriter_all_maxpages = 5 # 0-1000 buffers max written/round


#---------------------------------------------------------------------------
# WRITE AHEAD LOG
#---------------------------------------------------------------------------

# - Settings -

#fsync = on # turns forced synchronization on or off
#wal_sync_method = fsync # the default is the first option
# supported by the operating system:
# open_datasync
# fdatasync
# fsync
# fsync_writethrough
# open_sync
#full_page_writes = on # recover from partial page writes
#wal_buffers = 8 # min 4, 8KB each
#commit_delay = 0 # range 0-100000, in microseconds
#commit_siblings = 5 # range 1-1000

# - Checkpoints -

#checkpoint_segments = 3 # in logfile segments, min 1, 16MB each
#checkpoint_timeout = 300 # range 30-3600, in seconds
#checkpoint_warning = 30 # in seconds, 0 is off

# - Archiving -

#archive_command = '' # command to use to archive a logfile
# segment


#---------------------------------------------------------------------------
# QUERY TUNING
#---------------------------------------------------------------------------

# - Planner Method Configuration -

#enable_bitmapscan = on
#enable_hashagg = on
#enable_hashjoin = on
#enable_indexscan = on
#enable_mergejoin = on
#enable_nestloop = on
#enable_seqscan = on
#enable_sort = on
#enable_tidscan = on

# - Planner Cost Constants -

#effective_cache_size = 1000 # typically 8KB each
#random_page_cost = 4 # units are one sequential page fetch
# cost
#cpu_tuple_cost = 0.01 # (same)
#cpu_index_tuple_cost = 0.001 # (same)
#cpu_operator_cost = 0.0025 # (same)

# - Genetic Query Optimizer -

#geqo = on
#geqo_threshold = 12
#geqo_effort = 5 # range 1-10
#geqo_pool_size = 0 # selects default based on effort
#geqo_generations = 0 # selects default based on effort
#geqo_selection_bias = 2.0 # range 1.5-2.0

# - Other Planner Options -

#default_statistics_target = 10 # range 1-1000
#constraint_exclusion = off
#from_collapse_limit = 8
#join_collapse_limit = 8 # 1 disables collapsing of explicit
# JOINs


#---------------------------------------------------------------------------
# ERROR REPORTING AND LOGGING
#---------------------------------------------------------------------------

# - Where to Log -

#log_destination = 'stderr' # Valid values are combinations of
# stderr, syslog and eventlog,
# depending on platform.

# This is used when logging to stderr:
#redirect_stderr = off # Enable capturing of stderr into log
# files

# These are only used if redirect_stderr is on:
#log_directory = 'pg_log' # Directory where log files are written
# Can be absolute or relative to PGDATA
#log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' # Log file name pattern.
# Can include strftime() escapes
#log_truncate_on_rotation = off # If on, any existing log file of the same
# name as the new log file will be
# truncated rather than appended to. But
# such truncation only occurs on
# time-driven rotation, not on restarts
# or size-driven rotation. Default is
# off, meaning append to existing files
# in all cases.
#log_rotation_age = 1440 # Automatic rotation of logfiles will
# happen after so many minutes. 0 to
# disable.
#log_rotation_size = 10240 # Automatic rotation of logfiles will
# happen after so many kilobytes of log
# output. 0 to disable.

# These are relevant when logging to syslog:
#syslog_facility = 'LOCAL0'
#syslog_ident = 'postgres'


# - When to Log -

#client_min_messages = notice # Values, in order of decreasing detail:
# debug5
# debug4
# debug3
# debug2
# debug1
# log
# notice
# warning
# error

#log_min_messages = notice # Values, in order of decreasing detail:
# debug5
# debug4
# debug3
# debug2
# debug1
# info
# notice
# warning
# error
# log
# fatal
# panic

#log_error_verbosity = default # terse, default, or verbose messages

#log_min_error_statement = panic # Values in order of increasing severity:
# debug5
# debug4
# debug3
# debug2
# debug1
# info
# notice
# warning
# error
# panic(off)

#log_min_duration_statement = -1 # -1 is disabled, 0 logs all statements
# and their durations, in milliseconds.

#silent_mode = off # DO NOT USE without syslog or
# redirect_stderr

# - What to Log -

#debug_print_parse = off
#debug_print_rewritten = off
#debug_print_plan = off
#debug_pretty_print = off
#log_connections = off
#log_disconnections = off
#log_duration = off
log_line_prefix = '%t ' # Special values:
# %u = user name
# %d = database name
# %r = remote host and port
# %h = remote host
# %p = PID
# %t = timestamp (no milliseconds)
# %m = timestamp with milliseconds
# %i = command tag
# %c = session id
# %l = session line number
# %s = session start timestamp
# %x = transaction id
# %q = stop here in non-session
# processes
# %% = '%'
# e.g. '<%u%%%d> '
#log_statement = 'none' # none, mod, ddl, all
#log_hostname = off


#---------------------------------------------------------------------------
# RUNTIME STATISTICS
#---------------------------------------------------------------------------

# - Statistics Monitoring -

#log_parser_stats = off
#log_planner_stats = off
#log_executor_stats = off
#log_statement_stats = off

# - Query/Index Statistics Collector -

#stats_start_collector = on
#stats_command_string = off
#stats_block_level = off
stats_row_level = on
#stats_reset_on_server_start = off


#---------------------------------------------------------------------------
# AUTOVACUUM PARAMETERS
#---------------------------------------------------------------------------

autovacuum = on # enable autovacuum subprocess?
#autovacuum_naptime = 60 # time between autovacuum runs, in secs
#autovacuum_vacuum_threshold = 1000 # min # of tuple updates before
# vacuum
#autovacuum_analyze_threshold = 500 # min # of tuple updates before
# analyze
#autovacuum_vacuum_scale_factor = 0.4 # fraction of rel size before
# vacuum
#autovacuum_analyze_scale_factor = 0.2 # fraction of rel size before
# analyze
#autovacuum_vacuum_cost_delay = -1 # default vacuum cost delay for
# autovac, -1 means use
# vacuum_cost_delay
#autovacuum_vacuum_cost_limit = -1 # default vacuum cost limit for
# autovac, -1 means use
# vacuum_cost_limit


#---------------------------------------------------------------------------
# CLIENT CONNECTION DEFAULTS
#---------------------------------------------------------------------------

# - Statement Behavior -

#search_path = '$user,public' # schema names
#default_tablespace = '' # a tablespace name, '' uses
# the default
#check_function_bodies = on
#default_transaction_isolation = 'read committed'
#default_transaction_read_only = off
#statement_timeout = 0 # 0 is disabled, in milliseconds

# - Locale and Formatting -

#datestyle = 'iso, mdy'
#timezone = unknown # actually, defaults to TZ
# environment setting
#australian_timezones = off
#extra_float_digits = 0 # min -15, max 2
#client_encoding = sql_ascii # actually, defaults to database
# encoding

# These settings are initialized by initdb -- they might be changed
lc_messages = 'en_US.UTF-8' # locale for system error message
# strings
lc_monetary = 'en_US.UTF-8' # locale for monetary formatting
lc_numeric = 'en_US.UTF-8' # locale for number formatting
lc_time = 'en_US.UTF-8' # locale for time formatting

# - Other Defaults -

#explain_pretty_print = on
#dynamic_library_path = '$libdir'


#---------------------------------------------------------------------------
# LOCK MANAGEMENT
#---------------------------------------------------------------------------

#deadlock_timeout = 1000 # in milliseconds
#max_locks_per_transaction = 64 # min 10
# note: each lock table slot uses ~220 bytes of shared memory, and there are
# max_locks_per_transaction * (max_connections + max_prepared_transactions)
# lock table slots.


#---------------------------------------------------------------------------
# VERSION/PLATFORM COMPATIBILITY
#---------------------------------------------------------------------------

# - Previous Postgres Versions -

#add_missing_from = off
#backslash_quote = safe_encoding # on, off, or safe_encoding
#default_with_oids = off
#escape_string_warning = off
#regex_flavor = advanced # advanced, extended, or basic
#sql_inheritance = on

# - Other Platforms & Clients -

#transform_null_equals = off


#---------------------------------------------------------------------------
# CUSTOMIZED OPTIONS
#---------------------------------------------------------------------------

#custom_variable_classes = '' # list of custom variable class names


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

Re: [ADMIN] missing chunk number 0 for toast value

On Thu, Sep 25, 2008 at 10:09 AM, BJ Taylor
<btaylor@propertysolutions.com> wrote:
> PANIC: right sibling's left-link doesn't match: block 175337 links to
> 243096 instead of expected 29675 in index "dbmail_headervalue_3"
> STATEMENT: INSERT INTO dbmail_headervalue (headername_id, physmessage_id,
> headervalue) VALUES (4,12335778,'from [76.13.13.25] by
> n6.bullet.mail.ac4.yahoo.com with NNFMP; 25 Sep 2008 04:01:36 -0000')
> LOG: server process (PID 13888) was terminated by signal 6: Aborted
> LOG: terminating any other active server processes
> WARNING: terminating connection because of crash of another server process

Tom, does postgres generate abort signal? Or would this be an external signal?

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

Re: [GENERAL] Indirect access to NEW or OLD records

I have tried plperl, but the following sample does not work:

CREATE FUNCTION "extract_field_as_varchar" (rec record, field varchar)
RETURNS varchar AS
$body$
...
$body$
LANGUAGE 'plperl' VOLATILE CALLED ON NULL INPUT SECURITY INVOKER;

It says "ERROR: plperl functions cannot take type record".

So, I cannot ever create an utility function to call it as:

value := extract_field_as_varchar(NEW, 'field');

Seems I have to write an entire trigger in plperl to access NEW record
indirectly?


On Thu, Sep 25, 2008 at 10:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Dmitry Koterov" <dmitry@koterov.ru> writes:
>> I have a variable with a field name and want to extract this field
>> value from NEW record:
>
>> DECLARE
>> field VARCHAR = 'some_field';
>> BEGIN
>> ...
>> value := NEW.{field}; -- ???
>> END;
>
>> Is it possible in pl/pgsql?
>
> No. Quite aside from the lack of syntax for that, plpgsql would be
> unhappy if the data type wasn't the same on successive executions.
>
> Use one of the less strongly typed PLs instead. I believe this is
> pretty easy in plperl or pltcl. (Maybe plpython too, but I don't know
> that language.)
>
> regards, tom lane
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

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

Re: [BUGS] [ADMIN] Postgres Stats after Crash Recovery

I confirm this as a bug. First ANALYZE after crash recovery leaves stats
showing as zeroes. Repeatable on CVS HEAD with ANALYZE and VACUUM
ANALYZE.

Forwarding to bugs.


On Wed, 2008-09-24 at 15:29 -0400, Chirag Dave wrote:
>
> Testing AutoVac on 8.3 , i came across the problem of loosing stats
> data, which was discussed in my last post
>
> http://archives.postgresql.org/pgsql-general/2008-08/msg00198.php
>
> that problem was recognized that doing hard stop, server will throw
> away the stats while going through crash recovery.
>
> Problem i see is after crash recovery , we have to manually analyze
> database in order for autovac to work but it not working as expected.
>
> Here is test case:
>
> foo=# SELECT version();
>
> version
> ------------------------------------------------------------------------------------------------
> PostgreSQL 8.3.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC)
> 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
> (1 row)
>
> foo=# SELECT * from pg_stat_user_tables where relname='accounts';
> -[ RECORD 1 ]----+------------------------------
> relid | 57350
> schemaname | public
> relname | accounts
> seq_scan | 1
> seq_tup_read | 1000000
> idx_scan | 0
> idx_tup_fetch | 0
> n_tup_ins | 1000000
> n_tup_upd | 0
> n_tup_del | 0
> n_tup_hot_upd | 0
> n_live_tup | 1000000
> n_dead_tup | 0
> last_vacuum | 2008-09-24 15:04:35.384012-04
> last_autovacuum |
> last_analyze | 2008-09-24 15:04:35.384012-04
> last_autoanalyze |
>
>
> Next i will stop DB immediate and expect to loose stats as normal
> behavior.
>
> pg_ctl -m immediate -D /opt/rg/foo/pgsql83 stop
> waiting for server to shut down...LOG: received immediate shutdown
> request
> done
> server stopped
>
> After stating the DB, as expected:
> foo=# SELECT * from pg_stat_user_tables where relname='accounts';
> -[ RECORD 1 ]----+---------
> relid | 57350
> schemaname | public
> relname | accounts
> seq_scan | 0
> seq_tup_read | 0
> idx_scan | 0
> idx_tup_fetch | 0
> n_tup_ins | 0
> n_tup_upd | 0
> n_tup_del | 0
> n_tup_hot_upd | 0
> n_live_tup | 0
> n_dead_tup | 0
> last_vacuum |
> last_autovacuum |
> last_analyze |
> last_autoanalyze |
>
> Next step is to manually analyse to collects the stats again:
> foo=# ANALYZE ;
> ANALYZE
> foo=# SELECT * from pg_stat_user_tables where relname='accounts';
> -[ RECORD 1 ]----+---------
> relid | 57350
> schemaname | public
> relname | accounts
> seq_scan | 0
> seq_tup_read | 0
> idx_scan | 0
> idx_tup_fetch | 0
> n_tup_ins | 0
> n_tup_upd | 0
> n_tup_del | 0
> n_tup_hot_upd | 0
> n_live_tup | 0
> n_dead_tup | 0
> last_vacuum |
> last_autovacuum |
> last_analyze |
> last_autoanalyze |
>
> note: After ANALYSE, ststs were not updated.
>
> Running ANALYSE, second time seems to does the trick.
>
> foo=# ANALYZE ;
> ANALYZE
> foo=# SELECT * from pg_stat_user_tables where relname='accounts';
> -[ RECORD 1 ]----+------------------------------
> relid | 57350
> schemaname | public
> relname | accounts
> seq_scan | 0
> seq_tup_read | 0
> idx_scan | 0
> idx_tup_fetch | 0
> n_tup_ins | 0
> n_tup_upd | 0
> n_tup_del | 0
> n_tup_hot_upd | 0
> n_live_tup | 1000062
> n_dead_tup | 0
> last_vacuum |
> last_autovacuum |
> last_analyze | 2008-09-24 15:13:13.423424-04
> last_autoanalyze |
>
>
> So question i have is, is this normal operation,why we need to analyze
> twice to updates the stats ? if table/tables are candidate for
> vacuuming after crash recovery will never get auto-vac unless you do
> 'ANALYZE' twice.
>
> Thanks in advance,
>
> Chirag Dave
> DBA
> Afilias

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support


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

Re: [JDBC] Performance comparison to psql.

I seem unable to perform basic calculus today... sorry again, with psql -1 the process took 97m
just to set the record straight -- the overhead from the implicit transactions was 15m

M.

On Thu, Sep 25, 2008 at 7:12 PM, Michael Nacos <m.nacos@gmail.com> wrote:
right! the -1 flag...

I repeated the psql test, this time with the -1 flag, and the process completed in 107m
so the transaction overhead in the previous psql tests is 5m
psql is probably reading each line from the input file and immediately submitting it
pgBee groups together many lines and batches them off to the server in one step

btw, it's operations/sec, not milliseconds in my previous email -- sorry! I am not using
prepared statements as I have to cope with arbitrary SQL, so it looks like I'm approaching
the performance of unbatched but prepared JDBC statements mentioned in this table:


Comparison table (records inserted per millisecond)
COPY JDBC JDBC batch
WITHOUT INDEXES: 198 1.5 14
WITH 2 INDEXES: 45 1.5 10

898 operations/second vs. 1500 records/second in the table above. Besides, these numbers
must be hardware-specific (I'm using a laptop with a 5400rpm disk)

Michael


Re: [GENERAL] My first revoke

On 25/09/2008 19:24, Fernando Moreno wrote:
> only have to grant select on the tables you want, and yes, one by one.

If you use pgAdmin, it has a wizard for doing a bunch of objects in one go.

Ray.


------------------------------------------------------------------
Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland
rod@iol.ie
Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals
------------------------------------------------------------------

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

Re: [ADMIN] Hex representation

Change the shbang line to match where your php in installed (if it is at
all)

#!/full_path_to_my_php -q

-----Original Message-----
From: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Carol Walter
Sent: Thursday, September 25, 2008 1:15 PM
To: Steve Crawford
Cc: Scott Marlowe; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Hex representation

Well, it was a bit convoluted, but I created the file with Excel,
filling the right number of cells with \x55. This worked too. The
script wouldn't run for me. I got an error about a "bad interpreter".

Carol

On Sep 25, 2008, at 1:40 PM, Steve Crawford wrote:

> Scott Marlowe wrote:
>> I used this very simple little php script to make this
>>
>> filename: mk55:
>> #!/usr/bin/php -q
>> <?php
>> for ($i=0;$i<262144;$i++){
>> print chr(85);
>> }
>> ?>
>>
> Or, using standard *nix tools (Note: 0x55 = ascii U):
> dd bs=1k count=256 if=/dev/zero | tr '\000' U > full_of_0x55
>
> Cheers,
> Steve
>
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin


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

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

Re: [GENERAL] My first revoke

Hi, first of all, a new role doesn't have any privilege on any table (every type of database object has different default privileges), so you only have to grant select on the tables you want, and yes, one by one.

You can also grant or revoke privileges this way: grant select on table1,table2,table3...tableN to my_role;

Re: [pgsql-es-ayuda] postgresql 8.1.7 - ¿Donde?

Viktor Sanikidze wrote:
> Hola. Estoy encantado de encontrar esta comunidad en español.
> MI consulta es la siguiente:
> ¿Puede alguien decirme donde descargar la versión 8.1.7 del postreSQL?
>
> Lo encontré en varios sitios pero no funciona ningún mirror. Sería para redhat 5 y quiero instalarlo porque necesito usar un programa (juniper NetScreen) y no me deja con una versión posterior.
> Gracias a tod@s de antemano.
>
> ########## PERFORMING PRE-INSTALLATION TASKS ##########
> Creating staging directory...ok
> Running preinstallcheck...
> Checking if platform is valid...............................ok
> Checking for correct intended platform......................ok
> Checking for CPU architecture...............................ok
> Checking if all needed binaries are present.................ok
> Checking for platform-specific binaries.....................ok
> Checking for platform-specific packages.....................ok
> Checking in System File for PostgreSQL and XDB parameters...ok
> Checking for PostgreSQL.....................................
> PostgreSQL version 8.1.7 not found in /usr
> Specify location of PostgreSQL 8.1.7 bin directory[/usr/bin]> /usr/SQL/8.3/bin
> FAILED
> PostgreSQL version '8.3.3' found, '8.1.7' needed to continue.
>
>
> _________________________________________________________________
> Discover the new Windows Vista
> http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE--
> TIP 7: no olvides aumentar la configuración del "free space map"
>
>
>


Puedes usar :

http://yum.pgsqlrpms.org/


Leonel

--
TIP 7: no olvides aumentar la configuración del "free space map"

Re: [GENERAL] Oracle and Postgresql

On Thu, Sep 25, 2008 at 3:52 PM, Andrew Sullivan <ajs@commandprompt.com> wrote:
On Thu, Sep 25, 2008 at 01:13:29PM +0300, Asko Oja wrote:
>
> but why would you put part of your business logic into some configuration
> tables while you could keep it in your own functions

Because the parameters of the business logic should not be in the
code.  The parameters should be part of the configuration, to be
administered by the administrators (i.e. the DBAs) and not by the
database developers.  In traditional large database shops, that is the
division of responsibility, and the inability to work in that way will
hamper Postgres adoption in that environment.  (Maybe we don't care,
but let's at least be honest that changing the culture of such
database shops is not something we're going to achieve quickly.)

Well by configuration tables i meant some oracle/postgresql system tables.
We also have parameters of business logic in configuration database that is replicated into each oltp database that needs them and they are updated by dba's during normal release process. Althou this part is managed by DBA's the changes themselves are prepared by developers. So i see no PostgreSQL ability to work that way.  What i see is lack of useless bells and whistles in PostgreSQL and i like it.

regards,
Asko

Re: [GENERAL] Oracle and Postgresql

On Sep 1, 2008, at 12:42 AM, Henry wrote:
> This is /finally/ being addressed, although (very) belatedly. The
> Pg core
> dev team always argued that replication was an add-on and should not
> form
> part of the core (ie, similar nonsense excuses the MySQL team used for
> "add-ons" such as triggers, etc).

I believe the developer stance is more the same than you seem to
imagine. The upcoming developments allow replication utilities to tie
in at a deeper and more effective level, and with that new replication
solutions will come along. But I do not think there is any goal to
implement a single replication solution within core and not support
external solutions.

The point of the PostgreSQL developer stance is that until something
can be done correctly, even if it's a lot more work, it's sometimes
better not to do at all. It was recognized early on that if we tried
to figure out the replication puzzle ourself, it would invariably be
complex and never ideally suited for every situation. It would cost a
lot of resources that the team really needed to spend elsewhere at the
time.

MySQL's stance on things like triggers and subselects and so on is
*not* that at all. They recognize that a proper implementation would
be complicated and take a lot of time, so they strongly want to avoid
it, and make lame excuses a lot. When they do finally get around to
implementing something, they have traditionally done it in a broken or
lazy way - e.g. you cannot have two triggers on the same type of
action on the same table, instead you must write a wrapper function
that calls other functions; subselects are always evaluated
independently meaning they usually equate to "horribly slow", there's
a lot of bugs, etc.

I prefer the way PostgreSQL development has been going, personally. :)

Cheers,
--
Casey Allen Shobe
Database Architect, The Berkeley Electronic Press

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

Re: [GENERAL] Oracle and Postgresql

On Sep 4, 2008, at 7:40 PM, Robert Treat wrote:
> It is not as simple as Oracles database link syntax. Setting up a
> connection
> involves a couple of sql looking commands, and once you setup a
> connection to
> a remote database, you can reference a table with something like
> select *
> from mytable@myotherdb. There's no way a function oriented solution
> can
> match that imho.

I have long thought that what would be really useful is a standard way
for third-party modules to extend or override the SQL language support
within PostgreSQL itself without needing to be integrated in core.

E.g. it should be possible for all of EnterpriseDB's Oracle-compatible
SQL changes to exist as a separate module, somebody could change the
behavior of a select to default ordering to imitate Oracle etc. It
should be possible for a replication engine to add syntax for options
specific to it. Contrib modules like dblink could install SQL-like
command support.

This would be both invaluable for compatibility efforts and probably
raise the amount of 3rd party stuff that actually gets used
(currently, many places I've seen avoid Slony because they fear having
to use the commandline scripts it comes with, and if you want to
manipulate Slony from the database itself, oftentimes this means you
have to use pl/perlu or another untrusted language.

Don't get me wrong, functions are great too. :) But currently the
above means that a lot of risk is introduced and you have to put a lot
of faith in the perl code - an exploit poses a lot of risk. If Slony
exposed it's own data to PG via custom SQL extensions, this would be
more secure by design.

Cheers,
--
Casey Allen Shobe
Database Architect, The Berkeley Electronic Press

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

Re: [ADMIN] Hex representation

Well, it was a bit convoluted, but I created the file with Excel,
filling the right number of cells with \x55. This worked too. The
script wouldn't run for me. I got an error about a "bad interpreter".

Carol

On Sep 25, 2008, at 1:40 PM, Steve Crawford wrote:

> Scott Marlowe wrote:
>> I used this very simple little php script to make this
>>
>> filename: mk55:
>> #!/usr/bin/php -q
>> <?php
>> for ($i=0;$i<262144;$i++){
>> print chr(85);
>> }
>> ?>
>>
> Or, using standard *nix tools (Note: 0x55 = ascii U):
> dd bs=1k count=256 if=/dev/zero | tr '\000' U > full_of_0x55
>
> Cheers,
> Steve
>
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin


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

Re: [GENERAL] Oracle and Postgresql

On Sep 15, 2008, at 6:58 AM, David Fetter wrote:
>> Roles,
>
> We have 'em.

We do NOT have secure application roles or anywhere near the level of
configurability in security aspects as Oracle. We've got a great
foundation, but we lack a lot of fine-grained granularity (e.g. an
Oracle SAR can allow a role to execute a particular function based on
the result of another function call or query, which has rather a lot
of possibilities - consider grant connect on database to staff when
hour_of_day () between 9 and 6; also consider row-level and column-
level and even field-level access controls).

It's complicated in Oracle, but there's a lot of possibilities there
that we simply cannot reproduce. But this could be extended one day. :)

Cheers,
--
Casey Allen Shobe
Database Architect, The Berkeley Electronic Press


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

Re: [ADMIN] Hex representation

Hi Steve,

That's a cool way to do it.  I wish I thought of it.
Here's yet another way by java:

public class lotsofhex55 {

        public static void main (String[] argv) {

                char myHex55;
                myHex55 = (char) 0x55;

                        // replace 256 with 262144 after testing
                for (int i = 0; i < 256; i++) {
                   System.out.print (myHex55);
                }
        } // end main()
} // end class

Regards,

Tena Sakai
tsakai@gallo.ucsf.edu


-----Original Message-----
From: pgsql-admin-owner@postgresql.org on behalf of Steve Crawford
Sent: Thu 9/25/2008 10:40 AM
To: Scott Marlowe
Cc: Carol Walter; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Hex representation

Scott Marlowe wrote:
> I used this very simple little php script to make this
>
> filename: mk55:
> #!/usr/bin/php -q
> <?php
> for ($i=0;$i<262144;$i++){
>     print chr(85);
> }
> ?>
>  
Or, using standard *nix tools (Note: 0x55 = ascii U):
dd bs=1k count=256 if=/dev/zero | tr '\000' U  > full_of_0x55

Cheers,
Steve


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