[BUGS] BUG #4243: Idle in transaction

The following bug has been logged online:

Bug reference: 4243
Logged by: Clemens Wagner
Email address: clemens.wagner@denkwerk.com
PostgreSQL version: 8.2.7 and 8.3.1
Operating system: Linux 2.6.18-53.1.14.el5
Description: Idle in transaction
Details:

I have sometimes hanging psql backend processes with "idle in transaction"
state:

------ 8< ------
499 ? Ss 0:00 postgres: logger process
501 ? Ss 0:00 postgres: writer process
502 ? Ss 0:00 postgres: wal writer process
503 ? Ss 0:00 postgres: autovacuum launcher process
504 ? Ss 0:03 postgres: stats collector process
1896 ? Ss 0:04 postgres: seis survey 127.0.0.1(40753) SELECT
waiting
1917 ? Ss 0:03 postgres: seis survey 127.0.0.1(58432) idle in
transaction
2139 ? Ss 0:00 postgres: seis survey 127.0.0.1(40649) idle
2410 ? Ss 0:03 postgres: seis survey 127.0.0.1(33320) SELECT
waiting
12797 ? Ss 0:00 postgres: autovacuum worker process survey
21315 ? Ss 0:00 postgres: seis survey 127.0.0.1(55182) idle
21342 ? Ss 0:01 postgres: seis survey 127.0.0.1(33722) idle
21730 ? Ss 0:00 postgres: seis survey 127.0.0.1(52894) idle
------ >8 ------

They block other processes from working. I know that this state indicates a
non-terminated transaction. If I kill the process from shell with SIGTERM
and I got the folowing stack trace:

------ >8 ------
Caused by: org.postgresql.util.PSQLException: FATAL: terminating connection
due
to administrator command
at
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryEx
ecutorImpl.java:1592)
at
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutor
Impl.java:1327)
at
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.ja
va:192)
at
org.postgresql.jdbc2.AbstractJdbc2Connection.executeTransactionComman
d(AbstractJdbc2Connection.java:650)
at
org.postgresql.jdbc2.AbstractJdbc2Connection.rollback(AbstractJdbc2Co
nnection.java:687)
at
com.denkwerk.database.jdbc.JDBCContext.rollbackTransaction(JDBCContex
t.java:189)
... 60 more
------ 8< ------

I think this problem occurs while a (auto) vacuum is running and there is
high traffic on the database. It leads sometimes to an inconsisten database
with double primary keys in a table or a broken unique indexes (
"pg_statistic_relid_att_index" for instance). I can't enforce this error.

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

Re: [GENERAL] ERROR: missing FROM-clause entry for table on postgresql 8.1 not on 7.4; deleting from a join

m laks wrote:
> Hi,
> I am migrating to postgresql 8.1 from 7.4 with debian.
>
> Now I notice that one of my perl DBI scripts is crashing with the error
> above, and worked fine before.
>
> LTA_IDB=# delete from instancetable where ( (imagelevel.serparent=
> '1.2.840.113704.1.111.4640.1185891989.4') and (instancetable.imageuid=
> imagelevel.sopinsuid)); (at least in postgresql 7.4 using perl DBI).
>
> It worked on postgresql 7.4 and now on postgresql 8.1 I get error:
>
> ERROR: missing FROM-clause entry for table "imagelevel"

How about something along these lines:

delete from instancetable
USING imagelevel
WHERE (
(imagelevel.serparent= '1.2.840.113704.1.111.4640.1185891989.4') and
(instancetable.imageuid= imagelevel.sopinsuid)
);

--
Tommy Gildseth
DBA, Gruppe for databasedrift
Universitetet i Oslo, USIT
m: +47 45 86 38 50
t: +47 22 85 29 39

--
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] ERROR: missing FROM-clause entry for table on postgresql 8.1 not on 7.4; deleting from a join

On Tue, Jun 17, 2008 at 1:25 AM, m laks <mlaks2000@yahoo.com> wrote:
> Hi,
> I am migrating to postgresql 8.1 from 7.4 with debian.
>
[...]
>
> the following worked before:
>
> LTA_IDB=# delete from instancetable where ( (imagelevel.serparent=
> '1.2.840.113704.1.111.4640.1185891989.4') and (instancetable.imageuid=
> imagelevel.sopinsuid)); (at least in postgresql 7.4 using perl DBI).
>
> It worked on postgresql 7.4 and now on postgresql 8.1 I get error:
>
> ERROR: missing FROM-clause entry for table "imagelevel"
>

maybe the add_missing_from parameter in postgresql.conf is what you
need to get some sleep :)
it's there for older application like yours

--
regards,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 87171157

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

Re: [pgsql-it-generale] to_tsvector: errori nella configurazione italiana

On 16/giu/08, at 08:13, Giorgio Valoti wrote:

> […]

Prima di arrendermi volevo chiedere se qualcuno aveva altri
suggerimenti. Ho aggiornato alla 8.3.3 senza nessun risultato e ho
provato lo stesso database sotto una SuSE 9.2 dove ho verificato che
to_tsvector funziona senza problemi. Sono compilati praticamente allo
stesso modo: dove può stare la differenza?

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

[GENERAL] ERROR: missing FROM-clause entry for table on postgresql 8.1 not on 7.4; deleting from a join

Hi, I am migrating to postgresql 8.1 from 7.4 with debian. Now I notice that one of my perl DBI scripts is crashing with the error above, and worked fine before. From google I learn that postgresql is  getting tougher on us malfeasant coders who violate the SQL rules :(.  I have not slept in two days :(. I am unable to do a delete from a table  where the condition is that of a join. I am ignorant on how to do it correctly. the following worked before: LTA_IDB=# delete  from instancetable where ( (imagelevel.serparent= '1.2.840.113704.1.111.4640.1185891989.4') and (instancetable.imageuid= imagelevel.sopinsuid));        (at least in postgresql 7.4 using perl DBI). It worked on postgresql 7.4 and now on postgresql 8.1 I get error: ERROR:  missing FROM-clause entry for table "imagelevel" (Here we want to drop those entries in instancetable whose imageuid agrees with the imagelevel entries with serpatient 1.2.840.113704.1.111.4640.1185891989.4. (these are CT scan and MRI DICOM medical images)). Now this following select works: select * from instancetable, imagelevel where ( (imagelevel.serparent= '1.2.840.113704.1.111.4640.1185891989.4') and (instancetable.imageuid= imagelevel.sopinsuid)); without error in psql. Then how to drop them? (Now I actually want to drop those corrsponding entries in both instancetable and imagelevel)  So I tried stuff like this: with failure: :( LTA_IDB=# delete from select * from instancetable, imagelevel where ( (imagelevel.serparent= '1.2.840.113704.1.111.4640.1185891989.4') and (instancetable.imageuid= imagelevel.sopinsuid)); ERROR:  syntax error at or near "select" at character 13 LINE 1: delete from select * from instancetable, imagelevel where ( ... LTA_IDB=# delete from select * from instancetable, imagelevel where ( (imagelevel.serparent= '1.2.840.113704.1.111.4640.1185891989.4') and (instancetable.imageuid= imagelevel.sopinsuid)); ERROR:  syntax error at or near "select" at character 13 LINE 1: delete from select * from instancetable, imagelevel where ( ...                     ^ LTA_IDB=# delete from (select * from instancetable, imagelevel where ( (imagelevel.serparent= '1.2.840.113704.1.111.4640.1185891989.4') and (instancetable.imageuid= imagelevel.sopinsuid))); ERROR:  syntax error at or near "(" at character 13 LINE 1: delete from (select * from instancetable, imagelevel where (...                     ^ LTA_IDB=# delete from instancetable  (select * from instancetable, imagelevel where ( (imagelevel.serparent= '1.2.840.113704.1.111.4640.1185891989.4') and (instancetable.imageuid= imagelevel.sopinsuid))); ERROR:  syntax error at or near "(" at character 28 LINE 1: delete from instancetable  (select * from instancetable, ima...                                    ^ LTA_IDB=# delete from instancetable  select * from instancetable, imagelevel where ( (imagelevel.serparent= '1.2.840.113704.1.111.4640.1185891989.4') and (instancetable.imageuid= imagelevel.sopinsuid)); ERROR:  syntax error at or near "select" at character 28 LINE 1: delete from instancetable  select * from instancetable, imag... I tried reading around... .. I thank you deeply! Thanks, Mitchell Laks

Re: [GENERAL] PostgreSQL and AMD?

On Sun, 15 Jun 2008, John Tregea wrote:

> The machines would be running Windows XP Pro (our clients requirement).
> Can anyone tell me if PostgreSQL runs fine on the AMD platform and
> specifically does anyone have experience with the AMD Phenomâ„¢ Quad
> Core Processors 9600B.

Once you've settled on Windows as your PostgreSQL platform, you've kind of
given up on prioritizing performance at that point--there's a couple of
issues that limit how good that can possibly be no matter what hardware
you throw at it. Details like which processor you're using are pretty
trivial in comparision. Also, the real questions you should be asking are
ones like "did I get a good disk controller for database use?" which is a
really serious concern in this space. My guess is you're talking about an
HP DC5850. I am rather skeptical of the disk subsystem in that system (at
most two disks and just a crappy BIOS RAID) working well in a database
context. It's probably fine for a non-critical system, but I wouldn't run
a business on it.

In general, AMD has been lagging just a bit behind Intel's products
recently on systems with a small number of sockets. There are occasional
reports where multi-socket multi-core systems from AMD are claimed to do
better than similar Intel systems due to AMD's better bus design, I
haven't seen that big difference either way myself in recent products.

I've been using several different types of Opteron and X2 processors
systems from AMD the last couple of years and typically they work just
fine. But Phenom has really been a troubled platform launch for AMD and I
think that's why nobody has offered any suggestions to you yet--I haven't
heard any reports from people using that chip in a server environment yet.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [ADMIN] block error, but can't pg_dump

Thanks for your reply.  I'm afraid my Linux/Postgresql isn't quite good enough to use your answer.

1) Yes, I was selecting the records by the primary key.

2) Much of the data in this table can be dumped.  It's helpful for reports but it would be fine to archive it or even zero it out if it would get this working again.  I'd love to save recent data somehow, though, and the pg_dump only dumps the oldest.

3) I'm using Red Hat Linux, but when I tried to install the rhdb it failed on make although I downloaded version 4.0.  I am using Postgresql 8.0.13 -- I know I should upgrade but I needed an older version for older software I was using and then even now I shouldn't upgrade until I can backup everything.

4) I don't quite know how to get the OID of my database (directory name) and the relfilenode of the table.  If I try and connect to pg_database (psql -d pg_database) when signed in as the postgresql user, I get:
psql: FATAL:  database "pg_database" does not exist
I've looked online but can't find a page to describe what to do. 

I've thought about using delete * where... from the database to delete the older records in case that fixes it, but select * where... for older records doesn't work, so I assume delete won't either?  I don't want to try this if it doesn't even get me anywhere.

Thanks so much for your help.




At 03:44 PM 6/13/2008 -0400, Tom Lane wrote:

NOW Web Sites Manager <webperson@now.org> writes:
> I have a table that reports one block error when I try to select
> everything, reindex, vacuum, etc. (invalid page header in block
> 413620 of relation "tablename")  I've read on the list that the thing
> to do is use pg_dump and then restore it.  However, pg_dump fails
> with the same error.

> I can't take down the whole server, let alone easily Postgresql, to
> debug this.  Any ideas as to how I could do this?  I wrote a Perl
> script to select the records one by one but it didn't find a bad
> record although maybe it's how I wrote the script (it just selected
> the records one by one.)

Hm, were you selecting the records by primary key?  (or some other way
that would have produced an index search?)  If so, the above suggests
that the corrupted block is one that happens not to contain any live
data, which would be a lucky break for you.

Personally I'd want to know what was going on before taking any drastic
measures, so I'd try to dump out the block with pg_filedump:
http://sources.redhat.com/rhdb/

However, if you're comfortable that your perl script was able to
retrieve everything you care about from the table, you could skip
that and go directly to zeroing out the block, which is the appropriate
recovery action when you don't care about the data in it.  The usual
way to do that is with dd:
        dd if=/dev/zero of=TARGETFILE bs=8k seek=413620 count=1
(Sorry, no idea how to do it if you're on Windows.)

The trick is to be sure you've got the right target file.  You need the
OID of your database (directory name) and the relfilenode (NOT OID)
of the table, which you get from pg_database and pg_class respectively.
Then the file is $PGDATA/base/DBOID/RELFILENODE.

Hm, wait a second, block 413620 would be past the 1-GB mark, well
past it in fact.  What you're actually gonna need is
        dd if=/dev/zero of=TARGETFILE.3 bs=8k seek=20404 count=1
ie the filename you want is RELFILENODE.3 not just RELFILENODE.

You might want to read the "Database Physical Storage" chapter of
TFM to be sure you follow all this before you start zapping data.

                          regards, tom lane

Re: [GENERAL] inserting to a multi-table view

On Mon, Jun 16, 2008 at 10:24 PM, Richard Broersma
<richard.broersma@gmail.com> wrote:
> On Mon, Jun 16, 2008 at 8:32 PM, Michael Shiulman <shulman@mathcamp.org> wrote:
> Anyway, here is a link discussing a generalized vertical partitioned
> view. Perhaps it can give you some idea to get yourself rolling.
> http://archives.postgresql.org/pgsql-general/2006-12/msg01119.php

Oops, there is one other thing to bring up. If your clients
front-ends use a form of Optimistic locking, they will probably balk
at update-able views on vertically partitioned joined tables.

However, in the case of using ODBC, there was a work-around that
solved the problem of optimistic locking. However, you are still
faced with the problem of update anomalies caused by concurrent
updates on your base tables.

http://archives.postgresql.org/pgsql-odbc/2006-12/msg00029.php

--
Regards,
Richard Broersma Jr.

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

--
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] inserting to a multi-table view

On Mon, Jun 16, 2008 at 8:32 PM, Michael Shiulman <shulman@mathcamp.org> wrote:

> No, I don't think table inheritance will help. My actual situation is
> somewhat more complicated: the view takes data from more than two
> tables with a many-to-one rather than one-to-one relationship. For
> instance, consider tables "person", "address", and "phone", with a
> view "person_with_contact_info" that joins a person with their primary
> address and phone number, while inserting to the view should insert a
> person along with an address and phone number. In that case there is
> no table that can inherit from the other to solve the problem.

Ya, I agree. Postgresql inheritance is really just fancy horizontal
partitioning with a built-in UNION ALL. As far as I know, it still
doesn't support referential integrity (i.e. foreign keys from the
sub-tables). Building your own vertically partitioned schema will
fix many of the referential integrity problems, but at the expense of
opening your self up for view update anomoloies (I wished that the
postgresql update rules where executed as serializable transactions,
that way if one of the joined tables in the view was updated during
your change, it would though an exception rollback your update instead
of writing over the other persons work.)

Anyway, here is a link discussing a generalized vertical partitioned
view. Perhaps it can give you some idea to get yourself rolling.
http://archives.postgresql.org/pgsql-general/2006-12/msg01119.php

--
Regards,
Richard Broersma Jr.

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

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

Re: [lapug] June blog

On Mon, Jun 16, 2008 at 7:59 AM, Richard Broersma
<richard.broersma@gmail.com> wrote:
> On Mon, Jun 16, 2008 at 7:49 AM, Selena Deckelmann
> <selenamarie@gmail.com> wrote:
>> So, I'll most likely be upgrading the whole system sometime this
>> evening. Sorry about the inconvenience. Should be fixed up by
>> tomorrow.
>
> Thanks for updating us on the situation, and thanks so much for your
> help and assistance!

No problem! All's well at this point.

Also, in a couple more weeks, I'll have worked the kinks out on a fast
and easy moderation system for accepting talks for conferences :D

-selena

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

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

Re: [BUGS] UUIDs generated using ossp-uuid on windows not unique

Hi.

Sorry, late the information.....
My patch was applied after the review of Ralf-san. However, The timing of a
release was different. Then, patch is only current CVS-HEAD.
http://cvs.ossp.org/chngview?cn=6001

I thought that this problem was very important. It was sufficient reason to
apply to 8.3.3 of pginstaller. Therefore, It should return the result of a wish.

Regards,
Hiroshi Saito

----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>

> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>> Tom Lane wrote:
>>> Perhaps the v4 generation method would work better for you?
>
>> actually this has been reported before and seems to be an issue in the
>> windows port of the ossp-uuid library:
>> http://archives.postgresql.org/pgsql-bugs/2008-05/msg00059.php
>
> Oh, so that doesn't work either :-(. However, at least it's been
> fixed upstream:
> http://archives.postgresql.org/pgsql-bugs/2008-05/msg00070.php
> http://cvs.ossp.org/pkg/lib/uuid/ChangeLog
>
> regards, tom lane
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs

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

Re: [pgus-board] Vision

Michael Alan Brewer wrote:

>> A lot of this is going to be a bit of repeat of the bylaws but perhaps
>> in a more marketable way.
>>
>> US PostgreSQL Association Vision
>>
>> The US PostgreSQL Association, also known as PGUS is a Professional non
>> profit corporation.
>
> Is "PGUS" our official nickname? (Kidding! ;) )

Well actually one of the thoughts is to make it a DBA.

>
> Should "Professional" be capitalized (especially if "non profit" is
> neither capitalized or hyphenated)?

I am not sure actually. I was using Professional as a title but I don't
know that it matters if I lower case it.

>
>> We are dedicated to all users of PostgreSQL whether
>> hobbyists, professional developers, PostgreSQL.Org contributors, user
>> groups or students.
>
> Perhaps change "whether hobbyists" to "whether they are".
>

Yep I can do that.

>>
>> (c) Organize, hold and conduct meetings, discussion, and forums on the
>> contemporary issues concerning the use of PostgreSQL.
>
> Should "discussion" be plural (since "meetings" and "forums" are)?

I believe you conduct discussion but have discussions (that is straight
from the bylaws so I lean to attorney for that one).

>
>> Practically speaking, this means we want to:
>>
>> * Penetrate academia presenting an alternative to already heavily
>> invested technologies such as Oracle and Microsoft SQL.
>
> Might as well include MySQL in the mix. (Is the "Practically
> speaking" section to go on the vision page, or is this for internal
> use?)

I ignored MySQL on purpose of course. Granting course to a lessor enemy
just empowers them. However regardless of that, MySQL really isn't a
player in academia in terms of what is "taught", is it? Everything I
have seen in terms of curriculum is blantantly Oracle or MS SQL. Am I wrong?

>
>> * Create sponsorship programs that utilize the power and influence of
>> the for profit market
>
> "for profit" should probably be hyphenated, like "non-profit".
>

Yep I could change that.

>> to continue the penetration of PostgreSQL by
>> educating professional users and corporations on the benefits of using
>> the database.
>
> Me likey the alliteration. ;)
>
> Anyhoo, I like the Vision statement; well done, Joshua! :)
>

Thanks, I will make your suggested changes sans MySQL until further
discussion from you :)

Joshua D. Drake

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

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

Re: [pgsql-jobs] Work with the largest PostgreSQL installation in the world at hi5

so the DAE needs a sense of humor, the DFE does not! the DFE needs to have the companies they have worked for still exist!

 

 

From: pgsql-jobs-owner@postgresql.org [mailto:pgsql-jobs-owner@postgresql.org] On Behalf Of Cecilia Wong
Sent: Monday, June 16, 2008 5:24 PM
To: pgsql-jobs@postgresql.org
Subject: [pgsql-jobs] Work with the largest PostgreSQL installation in the world at hi5

 

hi5 is one of the world’s largest social networks and operates the largest PostgreSQL installation in the world across hundreds of database and storage servers. Our unique systems store billions of friend relationships and instantly make this information available.

 

We have 2 positions available in our San Francisco, CA office:

 

Database Applications Engineer

 

As a Database Application Engineer at hi5, you will be supporting the DB engineering team by designing sane schema, writing efficient SQL, and generally impressing us with your working knowledge of databases.

You will also be responsible for the following:

• Assist the applications engineering team with the most effective practices for DB usage (Schema design, SQL construction).
• Participate in applications engineering architecture process.
• Participate in DB engineering architecture process.
• Provide feedback to DB engineers and architects regarding quality and availability of DB interfaces for applications developers.
• Participate in implementation of database engineering team projects.
• Support operations group, both proactively and in crisis mode.

Requirements:

• Knowledge of the strengths and weaknesses of DB clients and RDBMS along with SQL.
• Experience within or interacting with operations teams.

• Java experience.  
• Near rock star status software engineering skills (i.e., OO, Agile methods).
• Applied knowledge of software design, implementation, and industry-leading practices.
• Excellent communication and interpersonal skills.
• A sense of humor, especially during production crises.

Preferred:

• Web applications experience.

 

 

Database Frameworks Engineer

 

Responsibilities:

• Keep the databases up and running.
• Insulate the rest of engineering from the fact that keeping databases up and running is not trivial.

Requirements:

• Expert Java programming Skills
• At least 7 years experience.
• Experience in maintaining at least 1 ORM (if you don't know what an ORM is, don't bother)
• Experience with either PostgreSQL, or two other RDBMS one of which is Oracle.
• SQL and schema design.
• All of the above in a company that still exists.

 

 

Please contact:

 

Cecilia Wong

Technical Recruiter | hi5 Networks

415.962.7096

cwong@hi5.com

This electronic message contains information from Multifamily Technology Solutions, Inc. (MyNewPlace.com) and is confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this message is prohibited. If you have received this electronic message in error, please notify us immediately by telephone at (415) 348-2000 or electronic mail.

Re: [GENERAL] inserting to a multi-table view

On Mon, Jun 16, 2008 at 10:03 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>> I can write a trigger
>> function that does the right thing, with 'INSERT ... RETURNING
>> person_id INTO ...', but Postgres will not let me add an INSERT
>> trigger to a view; it says 'ERROR: "studentinfo" is not a table'.
>
> Got a short example of what you've tried so far?

create function ins_st() returns trigger as $$
declare
id integer;
begin
insert into person (...) values (NEW....) returning person_id into id;
insert into student (person_id, ...) values (id, NEW....);
end;
$$ language plpgsql;

create trigger ins_student before insert on studentinfo
for each row execute procedure ins_st();

ERROR: "studentinfo" is not a table

Mike

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

Re: [pgus-board] Vision

On Mon, Jun 16, 2008 at 6:25 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
>
> So to that end I would like to attach the following to our mission.
> Where a mission is our bullet list of accomplishments to make, I would
> like to add our "Vision". I am going to assume that this is "close" to
> what we all think but please (as I know you will) provide comments and
> improvements if you have them.
>
> A lot of this is going to be a bit of repeat of the bylaws but perhaps
> in a more marketable way.
>
> US PostgreSQL Association Vision
>
> The US PostgreSQL Association, also known as PGUS is a Professional non
> profit corporation.

Is "PGUS" our official nickname? (Kidding! ;) )

Should "Professional" be capitalized (especially if "non profit" is
neither capitalized or hyphenated)?

> We are dedicated to all users of PostgreSQL whether
> hobbyists, professional developers, PostgreSQL.Org contributors, user
> groups or students.

Perhaps change "whether hobbyists" to "whether they are".

> Our vision is to:
>
> (a) Educate, promote and support the creation, development and use of
> the PostgreSQL Open Source Database software, a software system which is
> available to the general public without charge;
>
> (b) Provide information and education regarding the use of PostgreSQL;
> and
>
> (c) Organize, hold and conduct meetings, discussion, and forums on the
> contemporary issues concerning the use of PostgreSQL.

Should "discussion" be plural (since "meetings" and "forums" are)?

> Practically speaking, this means we want to:
>
> * Penetrate academia presenting an alternative to already heavily
> invested technologies such as Oracle and Microsoft SQL.

Might as well include MySQL in the mix. (Is the "Practically
speaking" section to go on the vision page, or is this for internal
use?)

> * Create sponsorship programs that utilize the power and influence of
> the for profit market

"for profit" should probably be hyphenated, like "non-profit".

> to continue the penetration of PostgreSQL by
> educating professional users and corporations on the benefits of using
> the database.

Me likey the alliteration. ;)

Anyhoo, I like the Vision statement; well done, Joshua! :)

---Michael Brewer
mbrewer@gmail.com

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

Re: [GENERAL] inserting to a multi-table view

On Mon, Jun 16, 2008 at 10:27 PM, Craig Ringer
<craig@postnewspapers.com.au> wrote:
>> I want to be able to do INSERTs on "studentinfo" and have rows created
>> in both "person" and "student". This requires first inserting into
>> "person", capturing the "person_id" of the resulting row, and using it
>> to insert into "student". This seems as though it must be a common
>> situation.
>
> Have you considered using table inheritance to solve this?

No, I don't think table inheritance will help. My actual situation is
somewhat more complicated: the view takes data from more than two
tables with a many-to-one rather than one-to-one relationship. For
instance, consider tables "person", "address", and "phone", with a
view "person_with_contact_info" that joins a person with their primary
address and phone number, while inserting to the view should insert a
person along with an address and phone number. In that case there is
no table that can inherit from the other to solve the problem.

Mike

--
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] inserting to a multi-table view

Michael Shulman wrote:

> I want to be able to do INSERTs on "studentinfo" and have rows created
> in both "person" and "student". This requires first inserting into
> "person", capturing the "person_id" of the resulting row, and using it
> to insert into "student". This seems as though it must be a common
> situation.

Have you considered using table inheritance to solve this?

It has some limitations, and I've never seen the need myself, but it
sounds like it might fit your needs.

http://www.postgresql.org/docs/8.3/static/ddl-inherit.html

--
Craig Ringer

--
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] Question about Encoding a Custom Type

On Jun 16, 2008, at 16:48, David Fetter wrote:

>> select array_accum(b) from ( select name from srt order by name ) AS
>> A(b);
>
> SELECT ARRAY(SELECT name FROM srt ORDER BY name); -- also works.

Wow, somehow I'd missed that syntax over the years. Thanks David!

Best,

David

--
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] inserting to a multi-table view

On Mon, Jun 16, 2008 at 8:49 PM, Michael Shulman <shulman@mathcamp.org> wrote:
> Hi,
>
> This feels like a very basic question but I cannot figure it out.
> Suppose I have two tables and a view that combines their data:
>
> CREATE TABLE person
> (person_id SERIAL PRIMARY KEY,
> ...);
>
> CREATE TABLE student
> (student_id SERIAL PRIMARY KEY,
> person_id INTEGER REFERENCES person,
> ...)
>
> CREATE VIEW studentinfo AS
> SELECT * FROM person JOIN student USING person_id;
>
> I want to be able to do INSERTs on "studentinfo" and have rows created
> in both "person" and "student". This requires first inserting into
> "person", capturing the "person_id" of the resulting row, and using it
> to insert into "student". This seems as though it must be a common
> situation.
>
> I am happy to use either rules or triggers, but I can't figure
> out how to do it with either. I can write a rule that does two
> INSERTs but I don't know how to capture the id resulting from the
> first insert and put it into the second. I can write a trigger
> function that does the right thing, with 'INSERT ... RETURNING
> person_id INTO ...', but Postgres will not let me add an INSERT
> trigger to a view; it says 'ERROR: "studentinfo" is not a table'.

Got a short example of what you've tried so far?

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

[GENERAL] inserting to a multi-table view

Hi,

This feels like a very basic question but I cannot figure it out.
Suppose I have two tables and a view that combines their data:

CREATE TABLE person
(person_id SERIAL PRIMARY KEY,
...);

CREATE TABLE student
(student_id SERIAL PRIMARY KEY,
person_id INTEGER REFERENCES person,
...)

CREATE VIEW studentinfo AS
SELECT * FROM person JOIN student USING person_id;

I want to be able to do INSERTs on "studentinfo" and have rows created
in both "person" and "student". This requires first inserting into
"person", capturing the "person_id" of the resulting row, and using it
to insert into "student". This seems as though it must be a common
situation.

I am happy to use either rules or triggers, but I can't figure
out how to do it with either. I can write a rule that does two
INSERTs but I don't know how to capture the id resulting from the
first insert and put it into the second. I can write a trigger
function that does the right thing, with 'INSERT ... RETURNING
person_id INTO ...', but Postgres will not let me add an INSERT
trigger to a view; it says 'ERROR: "studentinfo" is not a table'.

The Postgres manual:

http://www.postgresql.org/docs/8.3/static/rules-triggers.html
says "a trigger that is fired on INSERT on a view can do the same as
a rule: put the data somewhere else and suppress the insert in the
view." So what do I need to do to make an INSERT trigger on a view?

Thanks,
Mike

--
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] Advice on running two database clusters on one server machine

On Sun, Jun 15, 2008 at 11:11 AM, Andreas Philipp
<andreas.philipp@clinicauniversitariateleton.edu.co> wrote:
> Hi all,
>
> We are implementing a hospital information system and a human
> resources/payroll processing system on two identical dedicated servers with
> two Xeon Quad Core processors and 32 GB RAM each, both servers being attached
> via FC to a SAN, and both applications running on PostgreSQL 8.3 / CentOS 51.
>
> We are wondering about the advisability to distribute the databases between
> the two server machines, both machines acting as active production systems
> for one application each, and as warm standby servers for the other, using
> WAL shipping to a second database cluster running on another port on each of
> the two server machines.
>
> What would be the performance cost of doing so, rather than running all
> databases on one database cluster on one machine, and using the second
> machine as a warm standby server for all databases of the two applications?

Well, when both machines are working, your performance would be better
on two machines than on one. But after a failover, the warm standby
will be running two instances of postgresql, and that's sub-optimal.

> What other considerations should we take into account? We have no prior
> experience with PostgeSQL administration, having run our previous systems on
> Windows Servers and MS SQL Server.

Also, worry about the possibility of switching the wrong databases
when things are going wrong, etc with this type of setup.

However, the biggest concern is your FC-SAN setup. Some are very
fast. Some are quite pokey, and once you buy them, the manufacturer
will just laugh and point their fingers at linux, postgresql, or the
phase of the moon as the cause of your performance problem and do
nothing more.

If you haven't tested your FC-SAN setup with both servers running
comlex benchmarks (multiple bonnie++ instances, lots of dds, etc...)
and proven that it's fast, don't expect it to be.

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

Re: [ADMIN] Restore a backup into a new schema

On Fri, Jun 13, 2008 at 3:33 AM, <timalou2@netcourrier.com> wrote:
> Hi,
>
> Is it possible to restore a backup schema to another schema ?
>
> For instance I create a backup of a database called "source" with its public schema with pg_backup
>
> I want to restore this backup in a database called "dest" into a new schema called public2

Easiest way is to edit the pg_dump file by hand or use sed / awk to
change it on the fly.

If there's a lot of data and that makes it tough to do that, look into
dumping the schema and data separately, but this doesn't always work
quite right for some complex schemas.

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

Re: [HACKERS] Reducing overhead for repeat de-TOASTing

Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Comments, better ideas? Anyone think this is too much trouble to take
>> for the problem?

> I definitely think it's worth it, even if it doesn't handle an
> inline-compressed datum.

Yeah. I'm not certain how much benefit we could get there anyway.
If the datum isn't out-of-line then there's a small upper limit on how
big it can be and hence a small upper limit on how long it takes to
decompress. It's not clear that a complicated caching scheme would
pay for itself.

The profile shown here:
http://postgis.refractions.net/pipermail/postgis-devel/2008-June/003081.html
shows that the problem the PostGIS guys are looking at is definitely an
out-of-line case (in fact, it looks like the datum wasn't even compressed).

regards, tom lane

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

Re: [ADMIN] I: Purge Oid

2008/6/13 Miracapillo Alessandro <Alessandro.Miracapillo@one-ans.it>:
>
>
> Hallo,
>
>
>
> I've a problem with postgress 8.1,
>
>
>
> Db_data FS is full because file oid are too large, how I can delete old OID
> file without to risk to damage oid relation database

Ummm, the data directory doesn't fill up because of high oids. is the
data dir full, or are you suffering from oid wraparound issues? Two
different things.

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

[pgsql-advocacy] IBM might open source DB2

http://www.linuxtoday.com/news_story.php3?ltsn=2008-06-16-007-26-PS
http://news.cnet.com/IBM-may-open-source-DB2/2100-7344_3-6241694.html
http://news.zdnet.com/2424-3515_22-206350.html

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

Re: [HACKERS] Crash in pgCrypto?

Andrew Dunstan <andrew@dunslane.net> writes:
> David Fetter wrote:
>> Maybe I'm missing something big, but I don't quite see what
>> constitutes "proper" that doesn't involve the module's having at least
>> one schema to itself.

> ISTM that "uninstall foomodule" will be a whole lot nicer.

Right. We have all the mechanism we need in the form of the dependency
stuff: you just make everything in the module auto-depend on the module
object. People who want to put their modules into private schemas can
do it, but they won't be forced to.

In any case, trying to define a module as a schema doesn't help at all
to solve the hard problem, which is how to get this stuff to play nice
with pg_dump. I think that the agreed-on solution was that pg_dump
should emit some kind of "LOAD MODULE foo" command, and *not* dump any
of the individual objects in the module. We can't have that if we try
to equate modules with schemas instead of making them a new kind of
object.

regards, tom lane

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

Re: [GENERAL] Win32 8.3.3 install fail (sufficient privileges to install system services).

I have the same problem. I use postgres83 as the login for the service.

The way I get around it is I delete the “InstallServices” row from the MSI file using ORCA. This has always worked. I made the assumption the service is just fine and needs no changes.

I am not sure if deleting the service would achieve the same result. Never tried that.

 

[GENERAL] problem with to_ascii() function in version 8.3.3

Hi,

i have a problem with to_ascii() function in version 8.3.3. I have
read Mr. Gonzales's post at
http://groups.google.com/group/pgsql.general/browse_thread/thread/f74650e3b3248ff0/9f36fb072ea1dc98?lnk=gst&q=to_ascii#9f36fb072ea1dc98
and he managed to use to_ascii function with following command
sequence:

create table chartest ( c text);
insert into chartest (c) values ('á');
select to_ascii(encode(convert_to(c,'LATIN9'),'escape'),'LATIN9') from
chartest;

His output was:

to_ascii
----------
a

but i'm getting:

to_ascii
----------
\341

What am I doing wrong? How to_ascii function should be used?

Regards
Pavel Arnošt

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

[GENERAL] Error when trying to drop a tablespace

Hi guys,

I get the following error :

postgres=# DROP TABLESPACE IF EXISTS my_tbs;
ERROR: tablespace "my_tbs" is not empty

I've searched in pg_class and I'm not able to find a relation which
refers to my_tbs with :

postgres=# select * from pg_class where reltablespace=100456;
relname | relnamespace | reltype | relowner | relam | relfilenode |
reltablespace | relpages | reltuples | reltoastrelid | reltoastidxid |
relhasindex | relisshared | relkind | relnatts | relchecks | reltriggers
| relukeys | relfkeys | relrefs | relhasoids | relhaspkey | relhasrules
| relhassubclass | relfrozenxid | relacl | reloptions
---------+--------------+---------+----------+-------+-------------+---------------+----------+-----------+---------------+---------------+-------------+-------------+---------+----------+-----------+-------------+----------+----------+---------+------------+------------+-------------+----------------+--------------+--------+------------
(0 rows)

100456 has been found with :

/oid2name -s|grep my_tbs

Any idea ?
--
Cyril SCETBON

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

Re: [pgadmin-hackers] Dialogs review

Dave Page a écrit :
> On Sun, Jun 15, 2008 at 8:21 AM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
>>
>> I'm thinking about doing a complete review of our dialogs. During my work on
>> the comment tab, I found many dialogs not using spacers and sizers. So, I
>> would like to add them and, if at all possible, make dialogs growable. Of
>> course, I'll wait the comment patch is applied before working on this.
>
> OK. One thought I had - XRCed doesn't do a great job as we already
> know. If you're going to review the dialogues to this level, please
> consider other tools such as DialogBlocks - they may do a far better
> job of automating the process, and have a distinct style in the way
> they handle layout (preferring one sizer type over another for
> example). Let's take the opportunity to review the tools and pick
> something that will make this nice and easy in the future.
>

I downloaded it. I'll try to work with it on one dialog and see how it goes.

> Oh, and just so you know, some of the tools out there are not Open
> Source. pgAdmin is not a political project, and I wouldn't want us to
> discount something that may be a great tool purely because it's not
> OSS. Obviously if it costs money, then that is an issue.
>

It costs 56 €.

>> There's a question left to me. Should I do a complete review and send a
>> complete patch, or should I send one patch for each dialog? A complete patch
>> will be really hard to review. Having one patch for each dialog will be
>> simple to review but the number of patches needed will be a major burden.
>
> Incremental patching is fine. It's easier for everyone in the long run.
>

Yeah, that's what I think.

--
Guillaume.

http://www.postgresqlfr.org

http://dalibo.com

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

Re: [pgsql-es-ayuda] Consulta con Condicionales

2008/6/15 Alvaro Herrera <alvherre@commandprompt.com>:
> "Iván de Gyves López [[POD]]" escribió:
>
>> -------------------------------------------------------------------------------------------------------------------------
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> SELECT COUNT( * ) AS cte FROM rde1 WHERE id = x AND group_id = y, CASE
>> WHEN cte > 0 THEN true ELSE false END AS result;
>
> Usa un subselect
>
> select cte, case when cte > 0 then true else false end as result from
> (select count(*) as cte from rde1 where id = x and group_id = y) as foo
>

¿Hacen falta el case y la subconsulta? Esto debería funcionar, ¿no?
select count(*), count(*) > 0 as result
from rde1 where id = x and group_id = y
Aunque seleccionar un número y si este número es >0 me parece
redundante, pero supongo que algún motivo habrá ...

Saludos
--
Miguel Rodríguez Penabad
--
TIP 5: ¿Has leído nuestro extenso FAQ?

http://www.postgresql.org/docs/faqs.FAQ.html

Re: [pgadmin-hackers] Comments on a separate tab?

Dave Page a écrit :
> On Sat, Jun 14, 2008 at 10:33 PM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
>> My main concern is to be able to create table on my laptop (monitor size
>> 1280x800) and the previous size didn't allow this to me.
>
> Seems reasonable. Note that I was intending to redesign the table
> dialogue anyway - thats the only oversized one iirc.
>

Yes, that's the one that actually triggers me to review all our dialogs.

>> I hope I did a complete review of all dialogs. I think they all look correct
>> on my Linux box. Not sure on Windows and MacOS X.
>
> I'm sure I'll complain quickly enough :-p
>

I hope so :)

--
Guillaume.

http://www.postgresqlfr.org

http://dalibo.com

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

Re: [pgadmin-hackers] Comments on a separate tab?

On Sat, Jun 14, 2008 at 10:33 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
>
> My main concern is to be able to create table on my laptop (monitor size
> 1280x800) and the previous size didn't allow this to me.

Seems reasonable. Note that I was intending to redesign the table
dialogue anyway - thats the only oversized one iirc.

> I hope I did a complete review of all dialogs. I think they all look correct
> on my Linux box. Not sure on Windows and MacOS X.

I'm sure I'll complain quickly enough :-p

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

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

Re: [pgadmin-hackers] Dialogs review

On Sun, Jun 15, 2008 at 8:21 AM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
> Hi all,
>
> I'm thinking about doing a complete review of our dialogs. During my work on
> the comment tab, I found many dialogs not using spacers and sizers. So, I
> would like to add them and, if at all possible, make dialogs growable. Of
> course, I'll wait the comment patch is applied before working on this.

OK. One thought I had - XRCed doesn't do a great job as we already
know. If you're going to review the dialogues to this level, please
consider other tools such as DialogBlocks - they may do a far better
job of automating the process, and have a distinct style in the way
they handle layout (preferring one sizer type over another for
example). Let's take the opportunity to review the tools and pick
something that will make this nice and easy in the future.

Oh, and just so you know, some of the tools out there are not Open
Source. pgAdmin is not a political project, and I wouldn't want us to
discount something that may be a great tool purely because it's not
OSS. Obviously if it costs money, then that is an issue.

> There's a question left to me. Should I do a complete review and send a
> complete patch, or should I send one patch for each dialog? A complete patch
> will be really hard to review. Having one patch for each dialog will be
> simple to review but the number of patches needed will be a major burden.

Incremental patching is fine. It's easier for everyone in the long run.

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

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

Re: [pgsql-www] Translated documentations

On Sun, Jun 15, 2008 at 3:02 AM, Robert Treat
<xzilla@users.sourceforge.net> wrote:

> This was on my todo list after pgcon, but I hadn't figure out where to put it.
> I think what I would like to do is a combination of this and my original
> thinking, which would be to add a link in the side nav under "archive"
> for "translations", and also a link under the "more manuals" link
> for "foreign languages" on the main doc sidebar, both of which would go to a
> list of foreign language translation links. This would look similar to the
> international community page, where we have the names of the links in the
> foreign language. Sound ok?
>
Sounds good to me for a start. I'd would like to add the
infrastructure to host the translations ourselves (something I
discussed with Tatsuo and a couple of the PostgreSQLFr guys at FOSDEM)
- I've just been swamped recently and haven't had time to look at it
yet.

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

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

Re: [HACKERS] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses

On Sun, Jun 15, 2008 at 11:56:35PM +0200, Peter Eisentraut wrote:

> It would probably be a good idea to check how other programs deal with
> hostname lookups during authentication. Programs like SSH, Apache, and Squid
> come to mind.

There is actually a great deal of controversy about most of this
hostname-based authentication, particularly in the absence of DNSSEC.
If anyone implementing this is interested in the controversy, I have a
huge mail archive of it (because I'm the current editor of the IETF
working group document on this, and therefore have received much hate
mail on the topic). I think it's all summarised in the draft[1] I
mentioned upthread. Since that's possibly about to go to IETF last
call, it'd be a good time for someone planning to implement something
to look at that document, and report on whether it provides any useful
guidance at all. I'd be keenly interested in hearing the verdict.

A

[1]
http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-reverse-mapping-considerations/

--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.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] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses

On Sun, Jun 15, 2008 at 11:53:57PM +0200, Peter Eisentraut wrote:
>
> Isn't that what a local DNS caching-only server would accomplish?

Only if you looked up the DNS name at auth time :)

A

--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/

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