Re: [HACKERS] Open 7.1 items

[Oleg Bartunov]

On Wed, 24 Jan 2001, Bruce Momjian wrote:

> Here are my open 7.1 items.  Thanks for shrinking the list so far.
>
> ---
>
> FreeBSD locale bug

AFAIK, Tom have fixed it, if this bug is about -funsigned-char

> Reorder INSERT firing in rules
> Philip Warner UPDATE crash
> JDBC LargeObject short read return value missing
> SELECT cash_out(1) crashes all backends
> LAZY VACUUM
> FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
> Usernames limited in length
> Does pg_dump preserve COMMENTs?
> Failure of nested cursors in JDBC
> JDBC setMaxRows() is global variable affecting other objects
> Does JDBC Makefile need current dir?
> Fix for pg_dump of bad system tables
> Steve Howe failure query with rules
> ODBC/JDBC not disconnecting properly?
> Magnus Hagander ODBC issues?
> Merge MySQL/PgSQL translation scripts
> Fix ipcclean on Linux
> Merge global and template BKI files?
>
>
>

Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

[HACKERS] Open 7.1 items

[Bruce Momjian]

Here are my open 7.1 items.  Thanks for shrinking the list so far.

---

FreeBSD locale bug
Reorder INSERT firing in rules
Philip Warner UPDATE crash
JDBC LargeObject short read return value missing
SELECT cash_out(1) crashes all backends
LAZY VACUUM
FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
Usernames limited in length
Does pg_dump preserve COMMENTs?
Failure of nested cursors in JDBC
JDBC setMaxRows() is global variable affecting other objects
Does JDBC Makefile need current dir?
Fix for pg_dump of bad system tables
Steve Howe failure query with rules
ODBC/JDBC not disconnecting properly?
Magnus Hagander ODBC issues?
Merge MySQL/PgSQL translation scripts
Fix ipcclean on Linux
Merge global and template BKI files?


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

[HACKERS] TODO.deail

[Bruce Momjian]

I have removed unused entries from TODO.detail.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] Re: AW: Re: MySQL and BerkleyDB (fwd)

[Bruce Momjian]

Added to TODO.detail/replication.

> [ Charset ISO-8859-1 unsupported, converting... ]
> > >   I had thought that the pre-commit information could be stored in an
> > > auxiliary table by the middleware program ; we would then have
> > > to re-implement some sort of higher-level WAL (I thought of the list
> > > of the commands performed in the current transaction, with a sequence
> > > number for each of them that would guarantee correct ordering between
> > > concurrent transactions in case of a REDO). But I fear I am missing
> > 
> > This wouldn't work for READ COMMITTED isolation level.
> > But why do you want to log commands into WAL where each modification
> > is already logged in, hm, correct order?
> > Well, it has sense if you're looking for async replication but
> > you need not in two-phase commit for this and should aware about
> > problems with READ COMMITTED isolevel.
> > 
> 
> I believe the issue here is that while SERIALIZABLE ISOLATION means all
> queries can be run serially, our default is READ COMMITTED, meaning that
> open transactions see committed transactions, even if the transaction
> committed after our transaction started.  (FYI, see my chapter on
> transactions for help,  http://www.postgresql.org/docs/awbook.html.)
> 
> To do higher-level WAL, you would have to record not only the queries,
> but the other queries that were committed at the start of each command
> in your transaction.
> 
> Ideally, you could number every commit by its XID your log, and then
> when processing the query, pass the "committed" transaction ids that
> were visible at the time each command began.
> 
> In other words, you can replay the queries in transaction commit order,
> except that you have to have some transactions committed at specific
> points while other transactions are open, i.e.:
> 
> XID   Open XIDS   Query
> 500   UPDATE t SET col = 3;
> 501   500 BEGIN;
> 501   500 UPDATE t SET col = 4;
> 501   UPDATE t SET col = 5;
> 501   COMMIT;
> 
> This is a silly example, but it shows that 500 must commit after the
> first command in transaction 501, but before the second command in the
> transaction.  This is because UPDATE t SET col = 5 actually sees the
> changes made by transaction 500 in READ COMMITTED isolation level.
> 
> I am not advocating this.  I think WAL is a better choice.  I just
> wanted to outline how replaying the queries in commit order is 
> insufficient.
> 
> > Back to two-phase commit - it's easiest part of work required for
> > distributed transaction processing.
> > Currently we place single commit record to log and transaction is
> > committed when this record (and so all other transaction records)
> > is on disk.
> > Two-phase commit:
> > 
> > 1. For 1st phase we'll place into log "prepared-to-commit" record
> >and this phase will be accomplished after record is flushed on disk.
> >At this point transaction may be committed at any time because of
> >all its modifications are logged. But it still may be rolled back
> >if this phase failed on other sites of distributed system.
> > 
> > 2. When all sites are prepared to commit we'll place "committed"
> >record into log. No need to flush it because of in the event of
> >crash for all "prepared" transactions recoverer will have to
> >communicate other sites to know their statuses anyway.
> > 
> > That's all! It is really hard to implement distributed lock- and
> > communication- managers but there is no problem with logging two
> > records instead of one. Period.
> 
> Great.
> 
> 
> -- 
>   Bruce Momjian|  http://candle.pha.pa.us
>   [EMAIL PROTECTED]   |  (610) 853-3000
>   +  If your life is a hard drive, |  830 Blythe Avenue
>   +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] Re: AW: Re: MySQL and BerkleyDB (fwd)

[Bruce Momjian]

Added to TODO.detail/replication.

[ Charset ISO-8859-1 unsupported, converting... ]
> >   I had thought that the pre-commit information could be stored in an
> > auxiliary table by the middleware program ; we would then have
> > to re-implement some sort of higher-level WAL (I thought of the list
> > of the commands performed in the current transaction, with a sequence
> > number for each of them that would guarantee correct ordering between
> > concurrent transactions in case of a REDO). But I fear I am missing
> 
> This wouldn't work for READ COMMITTED isolation level.
> But why do you want to log commands into WAL where each modification
> is already logged in, hm, correct order?
> Well, it has sense if you're looking for async replication but
> you need not in two-phase commit for this and should aware about
> problems with READ COMMITTED isolevel.
> 
> Back to two-phase commit - it's easiest part of work required for
> distributed transaction processing.
> Currently we place single commit record to log and transaction is
> committed when this record (and so all other transaction records)
> is on disk.
> Two-phase commit:
> 
> 1. For 1st phase we'll place into log "prepared-to-commit" record
>and this phase will be accomplished after record is flushed on disk.
>At this point transaction may be committed at any time because of
>all its modifications are logged. But it still may be rolled back
>if this phase failed on other sites of distributed system.
> 
> 2. When all sites are prepared to commit we'll place "committed"
>record into log. No need to flush it because of in the event of
>crash for all "prepared" transactions recoverer will have to
>communicate other sites to know their statuses anyway.
> 
> That's all! It is really hard to implement distributed lock- and
> communication- managers but there is no problem with logging two
> records instead of one. Period.
> 
> Vadim
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

[HACKERS] 7.1 question

[Bruce Momjian]

Magnus, is this done?

> > Zeugswetter Andreas SB  <[EMAIL PROTECTED]> writes:
> > > It is possible to make the above work (at least on MSVC).
> > > The switch is /MD that needs to be used for both the psql.exe and 
> > > libpq.dll. This forces the use of Multithreaded DLL runtime 
> > libraries.
> > 
> > I like this answer.  We should be trying to make the Win32 environment
> > more like Unix, rather than catering to its gratuitous differences.
> 
> Definitly, me too. I'll try this as soon as I get time on it, and update my
> patch with it. Unless somebody beats me to it, that is.
> 
> //Magnus
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] Bad REFERENCES behaviour

[Stephan Szabo]

On Thu, 25 Jan 2001, Christopher Kings-Lynne wrote:

> There seems to be a bug in the 'REFERENCES' statement.  You can create
> foreign key references to fields that do not exist, that then cause odd (ie.
> hard to resolve) error messages.
> 
> The operator error below (that should not be possible) is in creating a
> reference to a column that does not exist users(id).
> 
> My example:
> 
> test=# select version();
>  version
> -
>  PostgreSQL 7.0.3 on i386-unknown-freebsdelf4.2, compiled by cc
> (1 row)
> 
> test=# create table users(userid int4);
> CREATE
> test=# create table newsletter(user_id int4 references users(id));
> NOTICE:  CREATE TABLE will create implicit trigger(s) for FOREIGN KEY
> check(s)
> CREATE
> test=# insert into newsletter values (4);
> ERROR:  constraint : table users does not have an attribute id
> test=#
> 
> When we got this error message we spent an hour trying to figure out what
> the heck the problem was!  In the end we simply deleted the bad trigger by
> oid and just recreated it using CREATE CONSTRAINT TRIGGER.
> 
> I have not yet checked whether table foreign key constraints, or the CREATE
> CONSTRAINT TRIGGER functionality has the same bug.

They all did.  In 7.1 you should be safe from invalid column names in the
actual constraint definitions but create constraint trigger doesn't check
(because it has no real way of knowing what its parameters are supposed to
mean).

[HACKERS] Bad REFERENCES behaviour

[Christopher Kings-Lynne]

There seems to be a bug in the 'REFERENCES' statement.  You can create
foreign key references to fields that do not exist, that then cause odd (ie.
hard to resolve) error messages.

The operator error below (that should not be possible) is in creating a
reference to a column that does not exist users(id).

My example:

test=# select version();
 version
-
 PostgreSQL 7.0.3 on i386-unknown-freebsdelf4.2, compiled by cc
(1 row)

test=# create table users(userid int4);
CREATE
test=# create table newsletter(user_id int4 references users(id));
NOTICE:  CREATE TABLE will create implicit trigger(s) for FOREIGN KEY
check(s)
CREATE
test=# insert into newsletter values (4);
ERROR:  constraint : table users does not have an attribute id
test=#

When we got this error message we spent an hour trying to figure out what
the heck the problem was!  In the end we simply deleted the bad trigger by
oid and just recreated it using CREATE CONSTRAINT TRIGGER.

I have not yet checked whether table foreign key constraints, or the CREATE
CONSTRAINT TRIGGER functionality has the same bug.

Chris

RE: [HACKERS] (one more time) Patches with vacuum fixes available .

[Mikheev, Vadim]

> Did we decide against LAZY? Seems we have a number of people 
> concerned about vacuum downtime, and I can see this as a win
> for them. If they don't specify LAZY, the code is not run.

First sorry that I wasn't able to deal with vlazy earlier.

Now I have one more open item for 7.1 - restoring index structure
at runtime (add tuple to parent page for aborted split op,
create root page if no one exists). I'll try to deal with both
items (in any case vlazy will be ported to 7.1, as required
by contract).

As for reported problem: I just looked at Denis' tgz and
found only table, index and sequence(?) data files - I would
need in schema definitions, pg_log and pg_variable files
as well. Denis? Also, when these copies were made -
before/after unsuccessful vacuum+lazy?

Vadim

Re: [HACKERS] Re: postgresql.conf and postgres options

[Bruce Momjian]

Defaults are listed as the assignment value, and of course, the are all
commented out.

> I think the list is great, show what can be configured rather than 
> guessing/digging to find it, where it belongs, in what order (if any), etc. 
> etc. etc.
> The only addition I could think would be to label (default value).
> 
> Needless, I like it.. :)
> 
> 
> At 1/24/2001 01:03 PM, Bruce Momjian wrote:
> > > Bruce Momjian writes:
> > >
> > > > I have added all possible config options to postgresql.conf.sample.
> > >
> > > It was actually fully intentional that there was *no* list of all possible
> > > config options in the sample file, because
> > >
> > > 1) Who's going to maintain this?
> > >
> > > 2) People should read the documentation before messing with options.
> > >
> > > (" is not the correct string delimiter either.)
> >
> >Changed to ''.  Thanks.
> >
> > >
> > > I have bad experiences with sample config files.  The first thing I
> > > usually do is delete them and dig up the documentation.
> > >
> > > Do other people have comments on this issue?
> >
> >I have marked all places where these defaults are set in the C code,
> >pointing them to update postgresql.conf.sample.
> >
> >I found it is nice to see a nice list of all options for quick review.
> >It makes the file much more useful, I think.
> 
> 
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] FW: Postgresql on win32

[Bruce Momjian]

I have added ./include/config.h.win32 to the RELEASE_CHANGES update
list.

> Magnus Hagander writes:
> 
> > > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > > We're losing this battle anyway.  Look into
> > > src/interfaces/libpq/libpq.rc.
> > >
> > > Ugh.  Magnus, is there any reasonable way to generate that
> > > thing on the fly on Win32?
> > It's the same thing as with version.h - e.g. not really :-( It can be done,
> > but I doubt it can be done cleanly.
> 
> > I have no idea how to do this, though, so I can't submit a patch. But if
> > someone were to do it and tell me where/how it goes into a header, I can
> > update the win32 patch to work with it...
> 
> Since all files are now up to date for 7.1 I don't feel a lot of urge to
> work on this right now.  Maybe when we change this version again.
> 
> But realistically we're going to have to hand-maintain config.h.win32
> anyway to account for new configure tests.
> 
> -- 
> Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/
> 
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

RE: [HACKERS] Permissions on CHECKPOINT

[Mikheev, Vadim]

>   >Contrary to what the submitted documentation claims, there is no
>   >permission checking done on the CHECKPOINT command.  
> Should there be?
>   
> Vadim seemed to indicate that he was going to make that restriction.
> Perhaps I misunderstood.

Yes, there should be permission checking - I'll add it later (in 7.1)
if no one else.

Vadim

Re: [HACKERS] Re: [GENERAL] child table doesn't inherit PRIMARY KEY?

[Bruce Momjian]

Thanks.  Done.

> Bruce Momjian wrote:
>   >> On Wed, 24 Jan 2001, Bruce Momjian wrote:
> 
>   >I smell TODO item.  In fact, I now see a TODO item:
>   >
>   >* Unique index on base column not honored on inserts from inherited table
>   >  INSERT INTO inherit_table (unique_index_col) VALUES (dup) should fail
>   >  [inherit]
>   >
>   >So it seems the fact the UNIQUE doesn't apply to the new table is just a
>   >manifestion of the fact that people expect UNIQUE to span the entire
>   >inheritance tree.  I will add the emails to [inherit] and mark it as
>   >resolved.
> 
> Bruce, could you add this text to TODO.detail on the subject of 
> inherited constraints.  I first sent it on Christmas Eve, and I 
> think most people were too busy holidaying to comment.
> 
> =
> Tom Lane wrote:
>   >Hm.  The short-term answer seems to be to modify the queries generated
>   >by the RI triggers to say "ONLY foo".  I am not sure whether we
>   >understand the semantics involved in allowing a REFERENCES target to be
>   >taken as an inheritance tree rather than just one table, but certainly
>   >the current implementation won't handle that correctly.
> 
> May I propose these semantics as a basis for future development:
> 
> 1. An inheritance hierarchy (starting at any point in a tree) should be
> equivalent to an updatable view of all the tables at the point of
> reference and below.  By default, all descendant tables are combined
> with the ancestor for all purposes.  The keyword ONLY must be used to
> alter this behaviour.  Only inherited columns of descendant tables are
> visible from higher in the tree.  Columns may not be dropped in descendants.
> If columns are added to ancestors, they must be inserted correctly in
> descendants so as to preserve column ordering and inheritance.  If
> a column is dropped in an ancestor, it is dropped in all descendants.
> 
> 2. Insertion into a hierarchy means insertion into the table named in
> the INSERT statement; updating or deletion affects whichever table(s)
> the affected rows are found in.  Updating cannot move a row from one
> table to another.
> 
> 3. Inheritance of a table implies inheriting all its constraints unless
> ONLY is used or the constraints are subsequently dropped; again, dropping
> operates through all descendant tables.  A primary key, foreign key or
> unique constraint cannot be dropped or modified for a descendant.  A
> unique index on a column is shared by all tables below the table for
> which it is declared.  It cannot be dropped for any descendant.
> 
> In other words, only NOT NULL and CHECK constraints can be dropped in
> descendants.
> 
> In multiple inheritance, a column may inherit multiple unique indices
> from its several ancestors.  All inherited constraints must be satisfied
> together (though check constraints may be dropped).
> 
> 4. RI to a table implies the inclusion of all its descendants in the
> check.  Since a referenced column may be uniquely indexed further up
> the hierarchy than in the table named, the check must ensure that
> the referenced value occurs in the right segment of the hierarchy.  RI
> to one particular level of the hierarchy, excluding descendants, requires
> the use of ONLY in the constraint.
> 
> 5. Dropping a table implies dropping all its descendants.
> 
> 6. Changes of permissions on a table propagate to all its descendants.
> Permissions on descendants may be looser than those on ancestors; they
> may not be more restrictive.
> 
> 
> This scheme is a lot more restrictive than C++'s or Eiffel's definition
> of inheritance, but it seems to me to make the concept truly useful,
> without introducing excessive complexity.
> 
> 
> 
> -- 
> Oliver Elphick[EMAIL PROTECTED]
> Isle of Wight  http://www.lfix.co.uk/oliver
> PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
> GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
>  
>  "If anyone has material possessions and sees his
>   brother in need but has no pity on him, how can the
>   love of God be in him?"
> I John 3:17 
> 
> 
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] Re: unixODBC again :-(

[Bruce Momjian]

Glad these items are being resolved.  THis has sat around too long. 
Please keep discussing and come up with a good patch.  We will help
however we can.


> [EMAIL PROTECTED] wrote:
> 
> > Nick Gorham writes:
> >
> > > Well because the driver does not know where to get the config info
> > > from,
> >
> > Then the driver should be fixed to do that, with or without unixODBC.
> 
> Well yes, but again, using the Windows situation as a model (not that
> I would normally suggest windows as a role model for anything), its not the
> drivers job to know or care where the info comes from, that the job of the
> (a) driver manager.
> 
> > > libodbcinst.so in unixODBC provides SQLGetPrivateProfileString,
> > > the location of user and system ini files are defined by this lib, if
> > > it doesn't do this you may have the situation where the driver manager
> > > gets information from one ini file and the driver from a different
> > > one.
> >
> > --with-odbcinst=DIRECTORY
> 
> Yes but there are two places, the user ~/.odbc.ini directory, and the
> system /sysconfdir/odbc.ini.
> 
> using the odbcinst lib, means all drivers can use the same info store, and
> you can just install a binary driver without having to set any
> configuration.
> 
> > > > > Add the option to detect a
> > > > > server name of localhost, and open the unix domain socket,
> > > >
> > > > I don't think so.  localhost is a valid host name.
> > >
> > > Ok, but don't you think it is worth having some way to get it to use
> > > UNIX domain sockets instead of TCP ones, for instance if postmaster
> > > isn't started with a -i ?
> >
> > Yes, that would be okay, but it's not okay to eliminate a feature to add
> > another one.
> 
> I would agree with that, I just did it the way I did as it fitted what some
> users needed. Not sure how many people would have a network setup with
> localhost set in dns to point to another machine, Though I agree there is
> no reason why you couldn't do it.
> 
> > > > We have a general approach to non-standard socket names now.
> > >
> > > Great, thats a non problem then, what do you do ?
> >
> > Pick up DEFAULT_PGSOCKET_DIR from config.h.
> 
> Thats ok, but if I was to keep a driver in unixODBC distrib, I would have
> to have a --postgres-socket= option in the config, same problem with
> odbcinst but in reverse. Maybe no simple answer to that one.
> 
> All I do at the moment, is have the driver try the two places it knows
> about, maybe it should be in the ini file, perhaps if the socket_location
> is set it would connect via that. It would fix the problem with using
> localhost to switch the connection method.
> 
> --
> Nick Gorham
> When I die, I want to go like my grandfather did, gently while sleeping,
> and not like his passangers, screaming in a panic, looking for the
> inflatable raft. -- Seen on ./
> 
> 
> 
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] beta3 Solaris 7 (SPARC) port report [ Was: Lookingfor . . . ]

[Peter Eisentraut]

Frank Joerdens writes:

[randomly varying set of regression tests fail]

> Running the tests on my Linux box gives no failed tests. Must I assume
> that those failed tests indicate some issue that is is detrimental to
> the proper functioning of the server on this Solaris installation? Do
> you want the regression.diffs?

Could you go into src/test/regress/pg_regress.sh and edit around line 162

#case $host_platform in
#*-*-qnx* | *beos*)
unix_sockets=no;;
#*)
#unix_sockets=yes;;
#esac

(i.e., ensure that unix_sockets is set to 'no'), and rerun 'make check'.

I have experienced before that Unix sockets will cause random connection
abortions on Solaris, which will cause the regression tests to fail
arbitrarily.

> I also tried using the Sun compiler, which didn't work at all.

details on "didn't work" requested...

> now I get scary stuff like:
>
> --- begin scary stuff ---
> test int2 ... ERROR:  pg_atoi: error in "34.5": can't
> parse ".5"
> ERROR:  pg_atoi: error reading "10": Result too large
> ERROR:  pg_atoi: error in "asdf": can't parse "asdf"

This is normal.  The regression tests sometimes involve intentional
invalid input.

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/

Re: [HACKERS] This script will crash the connection

[Jan Wieck]

Tom Lane wrote:
> "Steve Howe" <[EMAIL PROTECTED]> writes:
> > create rule blah_update as
> >  on update to blah
> >do
> >  notify TestEvent;
>
> > UPDATE blah SET n1=n1+1;  -- Won't crash the connection
> > UPDATE blah SET n1=2 WHERE var_field='aaa' AND n1=1 AND n2=2 AND arr_str IS
> > NULL AND m IS NULL; -- Will crash the connection
>
> The problem here is that the query rewriter tries to hang the query's
> qualification (WHERE clause) onto the rule's action query, so that
> the action query won't be done unless the query finds at least one
> row to update.
>
> NOTIFY commands, being utility statements, don't have qualifications.
> In 7.0 and before, the qual clause just vanished into the ether, and
> so in this example the NOTIFY would execute whether the UPDATE updated
> any rows or not.  In 7.1 there is physically noplace to hang the qual
> (no jointree) and thus a crash.
>
> Not sure what to do here.  Adding quals to utility statements is right
> out, however --- even if we weren't late in beta, the concept doesn't
> make any sense to me.  For one reason, utility statements don't have
> FROM clauses against which to evaluate the quals.  I am leaning to the
> idea that we should forbid NOTIFY in rules altogether.  Jan, what's your
> thought?
>
> Steve, your immediate move is to use a trigger rather than a rule to
> execute the NOTIFY.  Meanwhile, we have to think about what to do...

Would be something for a STATEMENT trigger. We don't have 'em
yet and I'm not sure  what  kind  of  information  they  will
receive  if we finally implement them. But the number of rows
affected by the statement is a good candidate.


Jan

--

#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.  #
#== [EMAIL PROTECTED] #



_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: [HACKERS] WAL documentation

[Peter Eisentraut]

Oliver Elphick writes:

> Here's a patch to the wal.sgml text to take acocunt of Vadim's
> explanations.

I checked in your documentation plus some fixes at other places.  Does
somebody care to submit some new words to describe the fsync option
(http://www.postgresql.org/devel-corner/docs/postgres/runtime-config.htm)?

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/

Re: [HACKERS] LEFT JOIN in pg_dumpall is a bug

[Tom Lane]

Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I'm not sure whether this is actually an overall improvement.  I'm tempted
> to just coalesce(usename, {some default user}) instead.

I thought about that to begin with, but figured you wouldn't like it ;-)

regards, tom lane

Re: [HACKERS] WAL documentation

[Oliver Elphick]

Here's a patch to the wal.sgml text to take acocunt of Vadim's
explanations.




*** wal.sgml.orig	Wed Jan 24 21:55:56 2001
--- wal.sgml	Wed Jan 24 22:08:44 2001
***
*** 149,154 
--- 149,176 
  
  
  
+ 
+ Database Recovery with WAL
+ 
+ 
+ After a checkpoint has been made and the log flushed, the checkpoint's
+ position is saved in pg_control. Therefore, when
+ recovery is to be done, the backend first reads
+ pg_control, and then the checkpoint record; next it
+ reads the redo record, whose position is saved in the checkpoint, and
+ begins the REDO operation.  Because the entire content of the
+ pages is saved in the log on the first page modification after a
+ checkpoint, the pages will be first restored to a consistent state.
+ 
+ Using pg_control to get the checkpoint position speeds
+ up the recovery process, but to handle possible corruption of
+ pg_control, we should actually
+ implement the reading of existing log segments in reverse order -- newest
+ to oldest -- in order to find the last checkpoint.  This has not yet been
+ done at release 7.1.
+ 
+ 
+ 

  
  WAL parameters
***
*** 187,196 
  what record in the log (known as the redo record) it should start the
  REDO operation, since any changes made to data files before that record
  are already on disk. After a checkpoint has been made, any log segments
! written before the redo record may be removed/archived, so checkpoints
! are used to free disk space in the WAL directory. The checkpoint maker
! is also able to create a few log segments for future use, so as to avoid
! the need for LogInsert or LogFlush to spend time in creating them.
  
  
  
--- 209,220 
  what record in the log (known as the redo record) it should start the
  REDO operation, since any changes made to data files before that record
  are already on disk. After a checkpoint has been made, any log segments
! written before the redo record are automatically removed, so checkpoints
! are used to free disk space in the WAL directory.  Once WAL-based BAR
! is implemented, the log segments can be archived instead of just being
! removed.  The checkpoint maker is also able to create a few log segments
! for future use, so as to avoid the need for LogInsert
! or LogFlush to spend time in creating them.
  
  
  


Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "If anyone has material possessions and sees his
  brother in need but has no pity on him, how can the
  love of God be in him?"
I John 3:17 

Re: [HACKERS] Permissions on CHECKPOINT

[Oliver Elphick]

Peter Eisentraut wrote:
  >Contrary to what the submitted documentation claims, there is no
  >permission checking done on the CHECKPOINT command.  Should there be?
  
Vadim seemed to indicate that he was going to make that restriction.
Perhaps I misunderstood.

If it's too late to make the change for 7.1, the fact should be
documented in a Bug section of the man page.

  >Btw., is there any normal usage application of this command?  This relates
  >to the previous paragraph somewhat.
  >
  >-- 
  >Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/
  >

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "If anyone has material possessions and sees his
  brother in need but has no pity on him, how can the
  love of God be in him?"
I John 3:17 

Re: [HACKERS] Open 7.1 items

[The Hermit Hacker]

On Wed, 24 Jan 2001, Hannu Krosing wrote:

> Bruce Momjian wrote:
> >
> > > You can't reasonably expect people to read all e-mail from last few
> > > weeks
> > > (probably a few thousands) and spot the same items as you.
> > >
> > > > May as well read the email rather than link to a web page.
> > >
> > > Still it would be good to have a "TODO before 7.1 relese"
> >
> > I send each article to the appropriate list with a comment at the top
> > asking for assistance.  I can't boild down many of these items into
> > short descriptions.  People need to see the detail of the emails.
>
> But maybe we could agree on something in Subject:,  maybe [TODO - 7.1]
> so that it is immediately clear it's urgent ?

Sounds reasonable to me ...

[HACKERS] Re: postgresql.conf and postgres options

[Thomas Swan]

I think the list is great, show what can be configured rather than 
guessing/digging to find it, where it belongs, in what order (if any), etc. 
etc. etc.
The only addition I could think would be to label (default value).

Needless, I like it.. :)


At 1/24/2001 01:03 PM, Bruce Momjian wrote:
> > Bruce Momjian writes:
> >
> > > I have added all possible config options to postgresql.conf.sample.
> >
> > It was actually fully intentional that there was *no* list of all possible
> > config options in the sample file, because
> >
> > 1) Who's going to maintain this?
> >
> > 2) People should read the documentation before messing with options.
> >
> > (" is not the correct string delimiter either.)
>
>Changed to ''.  Thanks.
>
> >
> > I have bad experiences with sample config files.  The first thing I
> > usually do is delete them and dig up the documentation.
> >
> > Do other people have comments on this issue?
>
>I have marked all places where these defaults are set in the C code,
>pointing them to update postgresql.conf.sample.
>
>I found it is nice to see a nice list of all options for quick review.
>It makes the file much more useful, I think.

Re: [HACKERS] function optimization ???

[Brent Verner]

On 24 Jan 2001 at 12:14 (-0500), Tom Lane wrote:
| Brent Verner <[EMAIL PROTECTED]> writes:
| > calling it as:
| >   SELECT p.*, p.book_info.title FROM pricing p WHERE vista_ans='POD';
| > background and observation:
| >   the pricing table is fairly large, but only a small number meet
| >   "WHERE vista_ans='POD'". I can select all where vista_ans='POD'
| >   very quickly (.2 sec), but adding in the get_book(pricing) call
| >   slows this down to about 20sec. I can, with an external sql query,
| >   select all of the desired records in about 1 sec, so it appears
| >   to me that the function is being called regardless of whether
| >   or not the WHERE clause is being satisfied.
| 
| This conclusion is absolutely false: the SELECT target list is NOT
| evaluated except at rows where the WHERE condition is satisfied.
| 
| I suspect the real problem is that the select inside the function
| is not being done as efficiently as you'd like.

yes, this is indeed the case. Sorry for the noise, my 'with an external
query' case was a broken product of sleep-dep :\.

thanks.
  brent

Re: [HACKERS] Open 7.1 items

[Bruce Momjian]

> On Wed, 24 Jan 2001, Hannu Krosing wrote:
> 
> > Bruce Momjian wrote:
> > >
> > > > You can't reasonably expect people to read all e-mail from last few
> > > > weeks
> > > > (probably a few thousands) and spot the same items as you.
> > > >
> > > > > May as well read the email rather than link to a web page.
> > > >
> > > > Still it would be good to have a "TODO before 7.1 relese"
> > >
> > > I send each article to the appropriate list with a comment at the top
> > > asking for assistance.  I can't boild down many of these items into
> > > short descriptions.  People need to see the detail of the emails.
> >
> > But maybe we could agree on something in Subject:,  maybe [TODO - 7.1]
> > so that it is immediately clear it's urgent ?
> 
> Sounds reasonable to me ...

Great idea.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

[HACKERS] Permissions on CHECKPOINT

[Peter Eisentraut]

Contrary to what the submitted documentation claims, there is no
permission checking done on the CHECKPOINT command.  Should there be?

Btw., is there any normal usage application of this command?  This relates
to the previous paragraph somewhat.

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/

Re: [HACKERS] Re: [GENERAL] child table doesn't inherit PRIMARY KEY?

[Oliver Elphick]

Bruce Momjian wrote:
  >> On Wed, 24 Jan 2001, Bruce Momjian wrote:

  >I smell TODO item.  In fact, I now see a TODO item:
  >
  >* Unique index on base column not honored on inserts from inherited table
  >  INSERT INTO inherit_table (unique_index_col) VALUES (dup) should fail
  >  [inherit]
  >
  >So it seems the fact the UNIQUE doesn't apply to the new table is just a
  >manifestion of the fact that people expect UNIQUE to span the entire
  >inheritance tree.  I will add the emails to [inherit] and mark it as
  >resolved.

Bruce, could you add this text to TODO.detail on the subject of 
inherited constraints.  I first sent it on Christmas Eve, and I 
think most people were too busy holidaying to comment.

=
Tom Lane wrote:
  >Hm.  The short-term answer seems to be to modify the queries generated
  >by the RI triggers to say "ONLY foo".  I am not sure whether we
  >understand the semantics involved in allowing a REFERENCES target to be
  >taken as an inheritance tree rather than just one table, but certainly
  >the current implementation won't handle that correctly.

May I propose these semantics as a basis for future development:

1. An inheritance hierarchy (starting at any point in a tree) should be
equivalent to an updatable view of all the tables at the point of
reference and below.  By default, all descendant tables are combined
with the ancestor for all purposes.  The keyword ONLY must be used to
alter this behaviour.  Only inherited columns of descendant tables are
visible from higher in the tree.  Columns may not be dropped in descendants.
If columns are added to ancestors, they must be inserted correctly in
descendants so as to preserve column ordering and inheritance.  If
a column is dropped in an ancestor, it is dropped in all descendants.

2. Insertion into a hierarchy means insertion into the table named in
the INSERT statement; updating or deletion affects whichever table(s)
the affected rows are found in.  Updating cannot move a row from one
table to another.

3. Inheritance of a table implies inheriting all its constraints unless
ONLY is used or the constraints are subsequently dropped; again, dropping
operates through all descendant tables.  A primary key, foreign key or
unique constraint cannot be dropped or modified for a descendant.  A
unique index on a column is shared by all tables below the table for
which it is declared.  It cannot be dropped for any descendant.

In other words, only NOT NULL and CHECK constraints can be dropped in
descendants.

In multiple inheritance, a column may inherit multiple unique indices
from its several ancestors.  All inherited constraints must be satisfied
together (though check constraints may be dropped).

4. RI to a table implies the inclusion of all its descendants in the
check.  Since a referenced column may be uniquely indexed further up
the hierarchy than in the table named, the check must ensure that
the referenced value occurs in the right segment of the hierarchy.  RI
to one particular level of the hierarchy, excluding descendants, requires
the use of ONLY in the constraint.

5. Dropping a table implies dropping all its descendants.

6. Changes of permissions on a table propagate to all its descendants.
Permissions on descendants may be looser than those on ancestors; they
may not be more restrictive.


This scheme is a lot more restrictive than C++'s or Eiffel's definition
of inheritance, but it seems to me to make the concept truly useful,
without introducing excessive complexity.



-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "If anyone has material possessions and sees his
  brother in need but has no pity on him, how can the
  love of God be in him?"
I John 3:17 

Re: [HACKERS] LEFT JOIN in pg_dumpall is a bug

[Peter Eisentraut]

Tom Lane writes:

> If you think depending on POSIX utilities is OK, then use cut.
> I'd recommend sed, though.

This has gotten pretty silly:

TAB='   ' # tab here

$PSQL -d template1 -At -F "$TAB" \
  -c "SELECT datname, usename, pg_encoding_to_char(d.encoding),
datistemplate, datpath, 'x' FROM pg_database d LEFT JOIN pg_shadow u ON
(datdba = usesysid) WHERE datallowconn;" | \
while read RECORDS; do
DATABASE=`echo "x$RECORDS" | sed "s/^x\([^$TAB]*\).*/\1/"`
DBOWNER=`echo "x$RECORDS" | sed "s/^x[^$TAB]*$TAB\([^$TAB]*\).*/\1/"`
ENCODING=`echo "x$RECORDS" | sed "s/^x[^$TAB]*$TAB[^$TAB]*$TAB\([^$TAB]*\).*/\1/"`
ISTEMPLATE=`echo "x$RECORDS" | sed 
"s/^x[^$TAB]*$TAB[^$TAB]*$TAB[^$TAB]*$TAB\([^$TAB]*\).*/\1/"`
DBPATH=`echo "x$RECORDS" | sed 
"s/^x[^$TAB]*$TAB[^$TAB]*$TAB[^$TAB]*$TAB[^$TAB]*$TAB\([^$TAB]*\).*/\1/"`

I'm not sure whether this is actually an overall improvement.  I'm tempted
to just coalesce(usename, {some default user}) instead.

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/

RE: [HACKERS] WAL documentation

[Mikheev, Vadim]

> 1) In the 'WAL Parameters' section, paragraph 3 there is the following
> sentence: "After a checkpoint has been made, any log segments written
> before the redo record may be removed/archived..."  What does the 'may'
> refer mean? Does the database administrator need to go into the 
> directory and remove the no longer necessary log files?  What does
> archiving have to do with this? If I archived all log files, could
> I roll forward a backup made previously? That is the only reason I can
> think of that you would archive log files (at least that is why you
> archive log files in Oracle).

Offline log segments are removed automatically at checkpoint time.
WAL based BAR is not implemented yet, so no archiving is made
currently.

> 2) The doc doesn't seem to explain how on database recovery 
> the database knows which log file to start with. I think walking
> through an example of how after a database crash, the log file is
> used for recovery, would be useful. At least it would make me as
> a user of postgres feel better if I understood how crashes are
> recovered from.

After checkpoint is made (log flushed) its position is saved in
pg_control file. So, on recovery backend first read pg_control,
than checkpoint record, than redo record (its position is saved
in checkpoint) and begins REDO op. Because of entire content of
pages is saved in log on first-after-checkpoint page modification
pages will be first restored to consistent stage.

Using pg_control to get checkpoint position speed up things but
to handle possible pg_control corruption we obviously should
implement reading existent log segments (from the last one -
newest - to oldest) to get last checkpoint.

Vadim

Re: [HACKERS] Open 7.1 items

[Hannu Krosing]

Bruce Momjian wrote:
> 
> > You can't reasonably expect people to read all e-mail from last few
> > weeks
> > (probably a few thousands) and spot the same items as you.
> >
> > > May as well read the email rather than link to a web page.
> >
> > Still it would be good to have a "TODO before 7.1 relese"
> 
> I send each article to the appropriate list with a comment at the top
> asking for assistance.  I can't boild down many of these items into
> short descriptions.  People need to see the detail of the emails.

But maybe we could agree on something in Subject:,  maybe [TODO - 7.1] 
so that it is immediately clear it's urgent ?

-
Hannu

Re: [HACKERS] postgresql.conf and postgres options

[Lamar Owen]

Bruce Momjian wrote:
> I have added all possible config options to postgresql.conf.sample.

> I have attached the new version of the file.  I think you will be amazed
> at how GUC gives us such powerful control over PostgreSQL.

Good.  As a sysadmin I _like_ sample configs (which I usually rename to
something else, and write my own, of course), as it gives a single
concise quick-reference to the syntax.

Lots of packages do this -- squid is the biggest one I can think of
right now (biggest in terms of config file size and power).  Samba is
another example.  There are a plethora of others, of course.

But, Peter's point does hold -- someone will have to maintain this.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

[HACKERS] beta3 Solaris 7 (SPARC) port report [ Was: Looking for . . . ]

[Frank Joerdens]

On Tue, Jan 23, 2001 at 11:57:52AM -0500, Tom Lane wrote:
[ . . . ]
> After you build PG and test it, send us a port report, and we'll add
> Solaris 7 to the list of recently tested platforms.  That's how it
> works ...

The installation by simply running configure, make, make install went
completely smoothly, no hassle whatsoever (except for the
flex-is-not-present warning which I think you can ignore)! 

The system is, to be precise:

$ uname -a 

SunOS [hostname] 5.7 Generic_106541-12 sun4u sparc SUNW,Ultra-4

I did encounter some _weird_ stuff with the regression tests. Does that
not work via make check (the 'standalone' variety) when you've already
typed make install (on Linux it does!)?? Make installcheck seems to
produce non-failures semi-reliably (why does the random test not fail on
the 1st try, but on the 2nd, and then again not on the 3rd???). Below
are the dirty details.

As to what is mentioned in the Admin Guide about Solaris' default
settings for shared memore being too low, at least on the machine I am
testing on it is set to 4 GB!

$ cat /etc/system |grep shm
*   exclude: sys/shmsys
set shmsys:shminfo_shmmax = 4294967295
set shmsys:shminfo_shmmin = 1
set shmsys:shminfo_shmmni = 100
set shmsys:shminfo_shmseg = 10


Cheers, Frank

-- begin dirty details --
I can start, connect, create databases etc.. However, running the
regression tests gives 4 failed out of 76:

 reltime  ... FAILED
 tinterval... FAILED
test horology ... FAILED
test misc ... FAILED

I checked the timezone issue mentioned in the src/test/regress/README
file. The command

$ env TZ=PST8PDT date

returns 'Wed Jan 24 11:19:02 PST 2001', 9 hrs back, which is the time
difference between here and California, so I guess that is OK.

Running the tests on my Linux box gives no failed tests. Must I assume
that those failed tests indicate some issue that is is detrimental to
the proper functioning of the server on this Solaris installation? Do
you want the regression.diffs?

I also tried using the Sun compiler, which didn't work at all. 

 . . . [ goes away to do more testing ] . . .

What's really weird, I just ran ./configure, make, make install, make
check again, again with 4 failed, but different ones! 


 tinterval... FAILED
 inet ... FAILED
 comments ... FAILED
test misc ... FAILED


2 things were different: a) I set the compiler explicitly to
/usr/local/bin/gcc via the CC environment variable and b) I used the
default prefix this time. I'll try again with the old settings. 

 . . . [ goes away to do more testing ] . . .

make distclean
./configure --prefix=/usr/db/pgsql
make
make check

produces 6 out of 76 this time! They are:

 date ... FAILED
 type_sanity  ... FAILED
 opr_sanity   ... FAILED
 arrays   ... FAILED
 btree_index  ... FAILED
test misc ... FAILED

It looks progressively worse. I'll remove the source tree and start from scratch.

 . . . [ goes away to do more testing ] . . .

6 out of 76 again, but different ones . . .

 interval ... FAILED
 abstime  ... FAILED
 comments ... FAILED
 oidjoins ... FAILED
test horology ... FAILED
test misc ... FAILED

 . . . [ goes away to do more testing ] . . .

This time with the already installed database after initdb:

$ make installcheck

now I get scary stuff like:

--- begin scary stuff ---
test int2 ... ERROR:  pg_atoi: error in "34.5": can't
parse ".5"
ERROR:  pg_atoi: error reading "10": Result too large
ERROR:  pg_atoi: error in "asdf": can't parse "asdf"
ok
test int4 ... ERROR:  pg_atoi: error in "34.5": can't
parse ".5"
ERROR:  pg_atoi: error reading "1": Result too large
ERROR:  pg_atoi: error in "asdf": can't parse "asdf"
ok
test int8 ... ok
test oid  ... ERROR:  oidin: error in "asdfasd": can't
parse "asdfasd"
ERROR:  oidin: error in "99asdfasd": can't parse "asdfasd"
ok
test float4   ... ERROR:  Bad float4 input format --
overflow
--- end scary stuff ---

However, it works! All 76 tests pass.

 . . . [ goes away to do more testing ] . . .

running make installcheck again gives:

test random   ... failed (ignored)

 . . . [ goes away to do more testing ] . . .

All 76 tests pass.
-- end dirty details --

RE: [HACKERS] FW: Postgresql on win32

[Peter Eisentraut]

Magnus Hagander writes:

> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > We're losing this battle anyway.  Look into
> > src/interfaces/libpq/libpq.rc.
> >
> > Ugh.  Magnus, is there any reasonable way to generate that
> > thing on the fly on Win32?
> It's the same thing as with version.h - e.g. not really :-( It can be done,
> but I doubt it can be done cleanly.

> I have no idea how to do this, though, so I can't submit a patch. But if
> someone were to do it and tell me where/how it goes into a header, I can
> update the win32 patch to work with it...

Since all files are now up to date for 7.1 I don't feel a lot of urge to
work on this right now.  Maybe when we change this version again.

But realistically we're going to have to hand-maintain config.h.win32
anyway to account for new configure tests.

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/

Re: [HACKERS] Open 7.1 items

[Bruce Momjian]

> You can't reasonably expect people to read all e-mail from last few
> weeks
> (probably a few thousands) and spot the same items as you.
> 
> > May as well read the email rather than link to a web page.
> 
> Still it would be good to have a "TODO before 7.1 relese"

I send each article to the appropriate list with a comment at the top
asking for assistance.  I can't boild down many of these items into
short descriptions.  People need to see the detail of the emails.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] Open 7.1 items

[Hannu Krosing]

Bruce Momjian wrote:
> 
> > On Wed, 24 Jan 2001, Bruce Momjian wrote:
> >
> > > > > It has to be done separately because you need to see the full content
> > > > > and reply to each individually.  Also, they go to different lists
> > > > > sometimes.  Pretty confusing.
> > > >
> > > > Could you post a list of open issues where each has just a number,
> > > > heading
> > > > (optional) and link to an email in some mailing-list archive ?
> > >
> > > Not really.  I don't have time to make a web site out of this thing.
> > > :-)
> >
> > If they were previously sent to the lists, there should be a link in the
> > archives to point ppl to, no? :0
> 
> Sure, but this is hard enough.  Finding them is even harder. 

IIRC you complained that there are 20 open issues that needed to be
resolved
befor releasing 7.1, no?

Just to start discussing them, we should need a more or less closed list
of issues.

Or was the original posting (the one that started this thread) just a
comment 
about how hard life is ;) ;)

You can't reasonably expect people to read all e-mail from last few
weeks
(probably a few thousands) and spot the same items as you.

> May as well read the email rather than link to a web page.

Still it would be good to have a "TODO before 7.1 relese"

-
Hannu

Re: [HACKERS] Re: unixODBC again :-(

[Peter Eisentraut]

Nick Gorham writes:

> Well because the driver does not know where to get the config info
> from,

Then the driver should be fixed to do that, with or without unixODBC.

> libodbcinst.so in unixODBC provides SQLGetPrivateProfileString,
> the location of user and system ini files are defined by this lib, if
> it doesn't do this you may have the situation where the driver manager
> gets information from one ini file and the driver from a different
> one.

--with-odbcinst=DIRECTORY

> > > Add the option to detect a
> > > server name of localhost, and open the unix domain socket,
> >
> > I don't think so.  localhost is a valid host name.
>
> Ok, but don't you think it is worth having some way to get it to use
> UNIX domain sockets instead of TCP ones, for instance if postmaster
> isn't started with a -i ?

Yes, that would be okay, but it's not okay to eliminate a feature to add
another one.

> > We have a general approach to non-standard socket names now.
>
> Great, thats a non problem then, what do you do ?

Pick up DEFAULT_PGSOCKET_DIR from config.h.

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/

Re: [HACKERS] Strange.. solved

[Stephan Szabo]

Actually, if you look in pg_trigger,  is technically the
constraint name and it should have a system generated constraint name
which you probably can use drop trigger on.  It looks like part of
a FK constraint so I'm not sure how you got just 1/2 of it since
dropping subject should have dropped it (unless you did a partial
dump and restore).


On Mon, 22 Jan 2001, Patrick Welche wrote:

> By comparing backups, I found
> 
> CREATE CONSTRAINT TRIGGER "" AFTER INSERT OR UPDATE ON "person"  NOT 
>DEFERRABLE INITIALLY IMMEDIATE FOR EACH ROW EXECUTE PROCEDURE "RI_FKey_check_ins" 
>('', 'person', 'subject', 'UNSPECIFIED', 'subjectid', 'id');
> 
> Don't know where that came from, but probably operator error.. There isn't
> an easy way of scrubbing an unnamed trigger is there? (I dump/edit/reloaded)
> 
> Cheers,
> 
> Patrick
> 

[HACKERS] Re: [GENERAL] child table doesn't inherit PRIMARY KEY?

[Stephan Szabo]

On Wed, 24 Jan 2001, Bruce Momjian wrote:

> 
> OK, what do people want to do with this item?  Add to TODO list?
> 
> Seems making a separat unique constraint would be easy to do and be of
> value to most users.

The problem is that doing that will pretty much guarantee that we won't
be doing foreign keys to inheritance trees without changing that behavior
and we've seen people asking about adding that too.  I think that this
falls into the general category of "Make inheritance make sense" (Now 
there's a todo item :) )  Seriously, I think the work on how inheritance
is going to work will decide this, maybe we end up with a real inheritance
tree system and something that works like the current stuff in which case
I'd say it's probably one unique for the former and one per for the
latter.

Re: [HACKERS] postgresql.conf and postgres options

[Bruce Momjian]

> Bruce Momjian writes:
> 
> > I have added all possible config options to postgresql.conf.sample.
> 
> It was actually fully intentional that there was *no* list of all possible
> config options in the sample file, because
> 
> 1) Who's going to maintain this?
> 
> 2) People should read the documentation before messing with options.
> 
> (" is not the correct string delimiter either.)

Changed to ''.  Thanks.

> 
> I have bad experiences with sample config files.  The first thing I
> usually do is delete them and dig up the documentation.
> 
> Do other people have comments on this issue?

I have marked all places where these defaults are set in the C code,
pointing them to update postgresql.conf.sample.  

I found it is nice to see a nice list of all options for quick review.
It makes the file much more useful, I think.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

RE: [HACKERS] WAL documentation

[Mikheev, Vadim]

> The WAL logs auto-delete I think.

At checkpoint time.

Vadim

[HACKERS] Re: [GENERAL] child table doesn't inherit PRIMARY KEY?

[Bruce Momjian]

> On Wed, 24 Jan 2001, Bruce Momjian wrote:
> 
> > 
> > OK, what do people want to do with this item?  Add to TODO list?
> > 
> > Seems making a separat unique constraint would be easy to do and be of
> > value to most users.
> 
> The problem is that doing that will pretty much guarantee that we won't
> be doing foreign keys to inheritance trees without changing that behavior
> and we've seen people asking about adding that too.  I think that this
> falls into the general category of "Make inheritance make sense" (Now 
> there's a todo item :) )  Seriously, I think the work on how inheritance
> is going to work will decide this, maybe we end up with a real inheritance
> tree system and something that works like the current stuff in which case
> I'd say it's probably one unique for the former and one per for the
> latter.

I smell TODO item.  In fact, I now see a TODO item:

* Unique index on base column not honored on inserts from inherited table
  INSERT INTO inherit_table (unique_index_col) VALUES (dup) should fail
  [inherit]

So it seems the fact the UNIQUE doesn't apply to the new table is just a
manifestion of the fact that people expect UNIQUE to span the entire
inheritance tree.  I will add the emails to [inherit] and mark it as
resolved.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

RE: [HACKERS] Re: AW: Re: MySQL and BerkleyDB (fwd)

[Mikheev, Vadim]

> > 1. For 1st phase we'll place into log "prepared-to-commit" record
> >and this phase will be accomplished after record is 
> >flushed on disk.
> >At this point transaction may be committed at any time because of
> >all its modifications are logged. But it still may be rolled back
> >if this phase failed on other sites of distributed system.
> 
> 1st phase will also need to do all the delayed constraint checks,
> and all other work a commit currently does, that could possibly lead 
> to a transaction abort. The 2nd phase of 2phase commit is not 

It was assumed.

Vadim

[HACKERS] PHP - Postgres large object functions

[Ned Lilly]

Adam, FYI, according to Rasmus Lerdorf, your patches have been 
committed.  From the changelog:

2001-01-18  Derick Rethans  <[EMAIL PROTECTED]> 

* ext/pgsql/pgsql.c
  ext/pgsql/php_pgsql.h:
- Added the pg_lolseek function, which allows for arbitrary seeking within
  a large object, and the pg_lotell call, which can be used to find the
  current file offset for a large object (Submitted by: Adam Haberlach
  <[EMAIL PROTECTED]> ).
- Added the pg_lolseek and pg_lotell functions


Regards,
Ned

-- 

Ned Lilly e: [EMAIL PROTECTED]
Vice Presidentw: www.greatbridge.com
Evangelism / Hacker Relationsv: 757.233.5523
Great Bridge, LLCf: 757.233.



-- Adam's original message:

On Mon, Jan 22, 2001 at 11:55:56PM -0500, Bruce Momjian wrote:
> > On Wed, Dec 27, 2000 at 12:56:26AM -0500, Bruce Momjian wrote:
> > > I have been asked by the major PHP developer Rasmus Lerdorf to see if
> > > the PostgreSQL/PHP interface needs any improvements.
> > > 
> > > Is the current PostgreSQL interface module in PHP adequate?  Does it
> > > support all the current libpq features?
> > > 
> > > If not, would someone submit some patches to the PHP folks.  They want
> > > us to work well with PHP.  They are basically encouraging us to improve
> > > it in any way we can.
> > 
> > I use PHP and Postgres together quite a bit, and find the APIs
> > complete enough for most things.  However, just last week I implemented
> > 
> > pg_lolseek($loid, $offset $whence)
> > and
> > pg_lotell($loid)
> > 
> > For some stuff that we are working on.  They are pretty straightforward,
> > and I can package them up and submit them if someone wants.
> > 

> Would to send this over to the PHP folks for inclusion?  Thanks.

I sent them patches against the at-the-time up-to-date CVS tree back
when this first came up, they said that they failed, so I sent them another
set, and have not heard back from them.  It doesn't seem to show up in the
cvs logs.

I'll bug someone again and see if I can find out what happened.  I mean,
they only have 240 people with write access to the cvs tree...

-- 
Adam Haberlach|A cat spends her life conflicted between a
[EMAIL PROTECTED]   |deep, passionate, and profound desire for
http://www.newsnipple.com |fish and an equally deep, passionate, and
'88 EX500 |profound desire to avoid getting wet.

Re: [HACKERS] LEFT JOIN in pg_dumpall is a bug

[Tom Lane]

Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Is there a more robust way of reading the data into the script?

> Provided that 'cut' is portable, then this works for me:

My old copy of Horton's _Portable C Software_ says that cut(1) is a
SysV-ism adopted by POSIX.  At that time (1990) it wasn't portable,
and he recommended using awk or sed instead.

If you think depending on POSIX utilities is OK, then use cut.
I'd recommend sed, though.  The GNU coding standards for Makefiles
suggest not depending on programs outside this set:

 cat cmp cp diff echo egrep expr false grep install-info
 ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch true

regards, tom lane

Re: [HACKERS] postgresql.conf and postgres options

[Bruce Momjian]

I have added all possible config options to postgresql.conf.sample.

I have attached the new version of the file.  I think you will be amazed
at how GUC gives us such powerful control over PostgreSQL.

Thanks, Peter.

> Oliver Elphick writes:
> 
> > 2.  The following command line options to postgres don't have an equivalent in
> > postgresql.conf.  Is that intentional?  (I suppose it is in several cases,
> > and I have left out some where it is obviously intentional.)  I can't see
> > why these items can't be put in the configuration file:
> 
> > -C  Noversion = true   [not documented in postgres man page]
> 
> This option doesn't do anything.
> 
> > -D  potential_Datadir = arg  [set PGDATA]
> 
> This option can't be in the config file because it is used to *find* the
> config file.
> 
> > -E  EchoQuery = true   [echo queries to log]
> 
> Hmm, there's debug_print_query.  This will probably be consolidated in the
> future.
> 
> > -e  EuroDates = true   [use European format for dates]
> 
> This should be a config file option, but Thomas Lockhart couldn't make up
> his mind what to call it.  ;-)
> 
> > -N  UseNewLine = 0 [newline is not a query separator]
> 
> I don't think this is useful.
> 
> > -o  [set stdout, stderr to file arg]
> 
> I think this is broken or not well maintained.  Will be cleaned up in some
> later release.
> 
> -- 
> Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/
> 
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026


#
# PostgreSQL configuration file
# -
#
# This file consists of lines of the form
#
#   name = value
#
# (The `=' is optional.) White space is collapsed, comments are
# introduced by `#' anywhere on a line. The complete list of option
# names and allowed values can be found in the PostgreSQL
# documentation. Examples are:

#log_connections = on
#fsync = off
#max_connections = 64

# 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 set at run-time with the 'SET' SQL command.


#


#
#   Connection Parameters
#
#tcpip_socket = false
#ssl = false

#max_connections = 32 # 1-1024

#port = 5432 
#hostname_lookup = false
#show_source_port = false

#unix_socket_directory = ""
#unix_socket_group = ""
#unix_socket_permissions = 0777

#virtual_host = ""

#krb_server_keyfile = ""


#
#   Performance
#
#sort_mem = 512
#shared_buffers = 2*max_connections # min 16
#fsync = true


#
#   Optimizer Parameters
#
#enable_seqscan = true
#enable_indexscan = true
#enable_tidscan = true
#enable_sort = true
#enable_nestloop = true
#enable_mergejoin = true
#enable_hashjoin = true

#ksqo = false
#geqo = true

#effective_cache_size = 1000  # default in 8k pages
#random_page_cost = 4
#cpu_tuple_cost = 0.01
#cpu_index_tuple_cost = 0.001
#cpu_operator_cost = 0.0025
#geqo_selection_bias = 2.0 # range 1.5-2.0


#
#   GEQO Optimizer Parameters
#
#geqo_threshold = 11
#geqo_pool_size = 0  #default based in tables, range 128-1024
#geqo_effort = 1
#geqo_generations = 0
#geqo_random_seed = -1 # auto-compute seed


#
#   Inheritance
#
#sql_inheritance = true


#
#   Deadlock
#
#deadlock_timeout = 1000


#
#   Expression Depth Limitation
#
#max_expr_depth = 1 # min 10


#
#   Write-ahead log (WAL)
#
#wal_buffers = 8 # min 4
#wal_files = 0 # range 0-64
#wal_debug = 0 # range 0-16
#commit_delay = 5 # range 0-1000
#checkpoint_timeout = 300 # range 30-1800


#
#   Debug display
#
#silent_mode = false

#log_connections = false
#log_timestamp = false
#log_pid = false

#debug_level = 0 # range 0-16

#debug_print_query = false
#debug_print_parse = false
#debug_print_rewritten = false
#debug_print_plan = false
#debug_pretty_print = false

#ifdef USE_ASSERT_CHECKING
#debug_assertions = true
#endif


#
#   Syslog
#
#ifdef ENABLE_SYSLOG
#syslog = 0 # range 0-2
#syslog_facility = "LOCAL0"
#syslog_ident = "postgres"
#endif


#
#   Statistics
#
#show_parser_stats = false
#show_planner_stats = false
#show_executor_stats = false
#show_query_stats = false
#ifdef BTREE_BUILD_STATS
#show_btree_build_stats = false
#endif


#
#   Lock Tracing
#
#trace_notify = false
#ifdef LOCK_DEBUG
#trace_locks = false
#trace_userlocks = false
#trace_spinlocks = false
#debug_deadlocks = false
#trace_lock_oidmin = 16384
#trace_lock_table = 0
#endif

[HACKERS] Re: [INTERFACES] ODBC gives pq_recvbuf: unexpected EOF on client connection

[Bruce Momjian]

Can someone research this?  I heard JDBC has the same problem.


> Cedar Cox <[EMAIL PROTECTED]> writes:
> > I'm using ODBC/MS Access and every time my client shuts down
> > I get the log message:
> > pq_recvbuf: unexpected EOF on client connection
> > Is there something I'm doing wrong here?
> 
> Not you, the ODBC driver --- it's just unceremoniously closing the
> socket connection without being polite enough to send the disconnect
> message (a single 'X', I think) first.
> 
> Somebody ought to fix that, but it's not a real high priority.
> There's no bad side-effects other than cluttering the postmaster log.
> 
> > (yes I did copy the JDBC post.. ;)
> 
> I haven't looked at the JDBC code, but evidently it's equally impolite.
> 
>   regards, tom lane
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

[HACKERS] Re: [GENERAL] MySQL -> Postgres dump converter

[Bruce Momjian]

Can someone look at both versions and merge the improvements into our
version?  Should be pretty easy.

> > Can some PostgreSQL people comment on this?  This person wrote a
> > MySQL->PostgreSQL converter too.  His version is at:
> > http://ziet.zhitomir.ua/~fonin/code
> 
> -- THIS VERSION IS EXTREMELY BUGSOME ! USE IT ON YOUR OWN RISK !!!
> 
> Hmm. My version does not have this feature, but it could be added ;)
> 
> Seriously, I haven't looked at the differences, but there is a licensing
> difference (BSD vs GPL). Someone else with experience with MySQL should
> evaluate both packages.
> 
> mysql2pgsql has been used to convert SourceForge, with ~90 tables and
> moderately complicated schema, but that did not include enumerated types
> (done with ints at SF) and "unique" keys (done with sequences at SF)
> afaicr.
> 
> > Sucks found:...
> 
> Each is a one-liner to fix in mysql2pgsql. The (nonstandard) types
> mentioned weren't used in the test cases I had available. I didn't
> realize that we had *any* reports of troubles or lacking features in the
> existing converter, but I'll leave it up to y'all to decide if the
> licensing issues and feature issues are significant.
> 
> I'm willing to provide patches to address some of the concerns, but of
> course will not be able to look at the GPL'd code for hints and can only
> use the information posted here to help afaik.
> 
> Comments?
> 
>- Thomas
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] (one more time) Patches with vacuum fixes available .

[Lamar Owen]

Bruce Momjian wrote:
> 
> Did we decide against LAZY?  Seems we have a number of people concerned
> about vacuum downtime, and I can see this as a win for them.  If they
> don't specify LAZY, the code is not run.

I see a number of possibilities:
1.) A tested 'feature patch' available for separate download;
2.) A configure switch '--enable-lazy-vacuum' perhaps;
3.) The (marginally if at all documented) LAZY parameter, with the code
sitting there dormant until the parameter is passed. Those who need it
probably read this list anyway.

Are we anywhere near comfortable that the code to support LAZY doesn't
impact standard VACUUM in any way?  That for me is the acid test -- if
VACUUM proper gets a bug due to the addition, that would be _bad_.  But,
if someone either applied the feature patch or enabled the configure
switch, well, then that's their choice, and their problem.

Then those who don't need it can still have reasonable confidence in the
solidity of the VACUUM code.  The fact that LAZY will get really lazy
and go away at 7.2 is a factor, as well.  But the fact that 7.2, which
will obviate all this (hopefully), is several months at the very least
down the road makes it desireable NOW to have the LAZY behavior.

I for one don't _need_ the LAZY behavior -- my VACUUMs take seconds, not
hours.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Re: [HACKERS] Re: unixODBC again :-(

[Peter Eisentraut]

Bruce Momjian writes:

> > 1. Add options to use unixODBC in the configure.in file, the mainly consists of 
>finding the root of the unixODBC install prefix, and adding
> > -I /unixODBC/path/include and -L /unixODBC/path/lib to the driver build

--with-includes, --with-libraries

> > 2. Change the way the driver gets config info, to be the same as when built under 
>windows. link with -lodbcinst and it provides
> > SQLGetPrivateProfileString. the code that calls this works as long as the correct 
>define is set.

I don't understand this.  The driver gets the config info just fine; why
add another way?

> > 3. Stop calling ODBC functions in the driver, this is simple but messy, the 
>problem being the call (say) in SQLAllocStmt that calls
> > SQLAllocHandle in the driver, ends up calling the SQLAllocHandle in the driver 
>manager.

This is fixed using magic linker options on ELF platforms.  I don't recall
how the patch tried to address this, but a better solution is probably
necessary.

> > There are a couple of other changes I have made, that you may want
> to add, I added the code to allow encrypted passwords (taken from the
> pg > lib), as crypt is avaiable on unix.

Why not.

> Add the option to detect a
> server name of localhost, and open the unix domain socket,

I don't think so.  localhost is a valid host name.

> in fact try
> two > places, to handle the debian build where the location is
> different.

We have a general approach to non-standard socket names now.

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/

Re: [HACKERS] Libpq async issues

[Alfred Perlstein]

* Tom Lane <[EMAIL PROTECTED]> [010124 10:27] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > * Bruce Momjian <[EMAIL PROTECTED]> [010124 07:58] wrote:
> >> I have added this email to TODO.detail and a mention in the TODO list.
> 
> > The bug mentioned here is long gone,
> 
> Au contraire, the misdesign is still there.  The nonblock-mode code
> will *never* be reliable under stress until something is done about
> that, and that means fairly extensive code and API changes.

The "bug" is the one mentioned in the first paragraph of the email
where I broke _blocking_ connections for a short period.

I still need to fix async connections for myself (and of course
contribute it back), but I just haven't had the time.  If anyone
else wants it fixed earlier they can wait for me to do it, do it
themself, contract me to do it or hope someone else comes along
to fix it.

I'm thinking that I'll do what you said and have seperate paths
for writing/reading to the socket and API's to do so that give
the user the option of a boundry, basically:

 buffer this, but don't allow me to write until it's flushed

which would allow for larger than 8k COPY rows to go into the
backend.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] LEFT JOIN in pg_dumpall is a bug

[Peter Eisentraut]

Tom Lane writes:

> > $PSQL -d template1 -At -F ' ' \
> >   -c "SELECT datname, usename, pg_encoding_to_char(d.encoding),
> > datistemplate, datpath FROM pg_database d LEFT JOIN pg_shadow u ON (datdba
> > = usesysid) WHERE datallowconn;" | \
> > while read DATABASE DBOWNER ENCODING ISTEMPLATE DBPATH; do

> Oops, you're right, the read won't keep the columns straight.  Come to
> think of it, it would do the wrong thing for empty-string datname or
> usename, too,

It won't actually work to restore such a setup, because zero-length
identifiers are no longer allowed.

> Is there a more robust way of reading the data into the script?

Provided that 'cut' is portable, then this works for me:

TAB='   ' # tab here

$PSQL -d template1 -At -F "$TAB" \
  -c "SELECT datname, usename, pg_encoding_to_char(d.encoding),
datistemplate, datpath FROM pg_database d LEFT JOIN pg_shadow u ON (datdba
= usesysid) WHERE datallowconn;" | \
while read THINGS; do
DATABASE=`echo "$THINGS" | cut -f 1`
DBOWNER=`echo "$THINGS" | cut -f 2`
ENCODING=`echo "$THINGS" | cut -f 3`
ISTEMPLATE=`echo "$THINGS" | cut -f 4`
DBPATH=`echo "$THINGS" | cut -f 5`

If 'cut' is not portable, then I don't believe you can do it with
IFS-based word splitting, because two adjacent separator characters don't
seem to indicate an empty field but are instead taken as one separator.

> I think I'd rather see a warning, though, and let the script try to dump
> the DB anyway.

Maybe for databases without an owner, but not for empty database or user
names.

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/

[HACKERS] Re: [PATCHES] Small patch to replace 'idle' by 'trans' if transactionisstill open

[Bruce Momjian]

> Tom Lane writes:
> 
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Any solid consensus on this?
> >
> > I'm for it (given a short status string --- "idle in tx" or "idle in trans"
> > seem fine).  Marc's for it.  Who's against it?
> 
> (I'm not.)  If you're going to do "idle in trans" you might as well spell
> it out.  The string will be truncated to the allowed length with no penalty.

OK, patch applied:

#$ ps -ax|grep post
27085  ??  Ss 0:00.05 ./bin/postmaster -B 384 -i -d0 -o -F -d0
27108  ??  S  0:00.04 postgres test [local] idle (postmaster)
27150  p7  S+ 0:00.01 grep post
#$ ps -ax|grep post
27085  ??  Is 0:00.05 ./bin/postmaster -B 384 -i -d0 -o -F -d0
27108  ??  S  0:00.04 postgres test [local] idle in transaction (postmaster
27185  p7  S+ 0:00.02 grep post
#$ 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026


? config.log
? config.cache
? config.status
? GNUmakefile
? src/Makefile.custom
? src/GNUmakefile
? src/Makefile.global
? src/log
? src/crtags
? src/backend/postgres
? src/backend/catalog/global.description
? src/backend/catalog/global.bki
? src/backend/catalog/template1.bki
? src/backend/catalog/template1.description
? src/backend/port/Makefile
? src/bin/initdb/initdb
? src/bin/initlocation/initlocation
? src/bin/ipcclean/ipcclean
? src/bin/pg_config/pg_config
? src/bin/pg_ctl/pg_ctl
? src/bin/pg_dump/pg_dump
? src/bin/pg_dump/pg_restore
? src/bin/pg_dump/pg_dumpall
? src/bin/pg_id/pg_id
? src/bin/pg_passwd/pg_passwd
? src/bin/pgaccess/pgaccess
? src/bin/pgtclsh/Makefile.tkdefs
? src/bin/pgtclsh/Makefile.tcldefs
? src/bin/pgtclsh/pgtclsh
? src/bin/pgtclsh/pgtksh
? src/bin/psql/psql
? src/bin/scripts/createlang
? src/include/config.h
? src/include/stamp-h
? src/interfaces/ecpg/lib/libecpg.so.3.2.0
? src/interfaces/ecpg/preproc/ecpg
? src/interfaces/libpgeasy/libpgeasy.so.2.1
? src/interfaces/libpgtcl/libpgtcl.so.2.1
? src/interfaces/libpq/libpq.so.2.1
? src/interfaces/perl5/blib
? src/interfaces/perl5/Makefile
? src/interfaces/perl5/pm_to_blib
? src/interfaces/perl5/Pg.c
? src/interfaces/perl5/Pg.bs
? src/pl/plperl/blib
? src/pl/plperl/Makefile
? src/pl/plperl/pm_to_blib
? src/pl/plperl/SPI.c
? src/pl/plperl/plperl.bs
? src/pl/plpgsql/src/libplpgsql.so.1.0
? src/pl/tcl/Makefile.tcldefs
Index: src/backend/tcop/postgres.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/tcop/postgres.c,v
retrieving revision 1.204
diff -c -r1.204 postgres.c
*** src/backend/tcop/postgres.c 2001/01/24 14:32:32 1.204
--- src/backend/tcop/postgres.c 2001/01/24 15:52:18
***
*** 1791,1797 
  
EnableNotifyInterrupt();
  
!   set_ps_display("idle");
  
/* Allow "die" interrupt to be processed while waiting */
ImmediateInterruptOK = true;
--- 1791,1799 
  
EnableNotifyInterrupt();
  
!   if (!IsTransactionBlock())
!   set_ps_display("idle");
!   elseset_ps_display("idle in transaction");
  
/* Allow "die" interrupt to be processed while waiting */
ImmediateInterruptOK = true;
Index: src/backend/utils/misc/postgresql.conf.sample
===
RCS file: 
/home/projects/pgsql/cvsroot/pgsql/src/backend/utils/misc/postgresql.conf.sample,v
retrieving revision 1.2
diff -c -r1.2 postgresql.conf.sample
*** src/backend/utils/misc/postgresql.conf.sample   2000/12/03 21:12:19 1.2
--- src/backend/utils/misc/postgresql.conf.sample   2001/01/24 15:52:18
***
*** 18,20 
--- 18,196 
  # 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 set at run-time with the 'SET' SQL command.
+ 
+ 
+   enable_seqscan = true
+   enable_indexscan = true
+   enable_tidscan = true
+   enable_sort = true
+   enable_nestloop = true
+   enable_mergejoin = true
+   enable_hashjoin = true
+ 
+   ksqo = izer, false
+   geqo = true
+ 
+   tcpip_socket = false
+   ssl = false
+   fsync = true
+   silent_mode = false
+ 
+   log_connections = false
+   log_timestamp = false
+   log_pid = false
+ 
+ #ifdef USE_ASSERT_CHECKING
+   debug_assertions = true
+ #endif
+ 
+   debug_print_query = false
+   debug_print_parse = false
+   debug_print_rewritten = false
+   debug_print_plan = false
+   debug_pretty_print = false
+ 
+   show_parser_stats = false
+   show_planner_stats = false
+   show_executor_stats = false
+   show_qu

Re: [HACKERS] (one more time) Patches with vacuum fixes available.

[The Hermit Hacker]

On Wed, 24 Jan 2001, Tom Lane wrote:

> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Did we decide against LAZY?
>
> I thought the core consensus was that it was too risky to install
> post-beta.  On the other hand, we're installing some other pretty
> major fixes.  Do we want to re-open that discussion?

I would like to see it in myself ... it will be useless post v7.1, with
all the work planned for v7.2 ... if there is some way we could get it in
before beta4 goes out, I'd feel even better about it ... Vadim? :)

Re: [HACKERS] function optimization ???

[Tom Lane]

Brent Verner <[EMAIL PROTECTED]> writes:
> calling it as:
>   SELECT p.*, p.book_info.title FROM pricing p WHERE vista_ans='POD';
> background and observation:
>   the pricing table is fairly large, but only a small number meet
>   "WHERE vista_ans='POD'". I can select all where vista_ans='POD'
>   very quickly (.2 sec), but adding in the get_book(pricing) call
>   slows this down to about 20sec. I can, with an external sql query,
>   select all of the desired records in about 1 sec, so it appears
>   to me that the function is being called regardless of whether
>   or not the WHERE clause is being satisfied.

This conclusion is absolutely false: the SELECT target list is NOT
evaluated except at rows where the WHERE condition is satisfied.

I suspect the real problem is that the select inside the function
is not being done as efficiently as you'd like.  How big is
catalog_general, and would a sequential scan over it inside the
function account for the performance discrepancy?

IIRC, 7.0.* is not very bright about using indexscans in situations
where the righthand side of the WHERE clause is anything more complex
than a literal constant or simple parameter reference ($n).  The
fieldselect you have here would be enough to defeat the indexscan
recognizer.  This is fixed in 7.1, however.  For now, you could
declare book_info as taking a simple datum and invoke it as
p.vista_isbn.book_info.title

BTW, star_isbn and vista_isbn are the same datatype, I trust, else
that might cause failure to use an indexscan too.

regards, tom lane

[HACKERS] Re: [PATCHES] PgAccess schema-diagram cleanup

[Ross J. Reedstrom]

It got bounced to Constantin. I'm not sure if it's made it in, there.
I'll ping him and see if he needs a new patch.

Ross

On Wed, Jan 24, 2001 at 08:49:13AM -0500, Bruce Momjian wrote:
> 
> Ross, this looks very good.  What happened to it?
> 
> > Here's a patch to clean up some issues with the schema diagram
> > editor in pgaccess. This patch:
> > 
> > * allows schema window to be resized up to full screen size
> > * autosizes window on schema open
> > * allows multiselect of tables (by shift click) to allow
> > dragging of sets of tables
> > deletion of sets of tables
> > * fixes a bug in table deletion code that did not delete
> >   links to that table properly
> > * changes link lines to be continous, so they export better
> > via postscript->pstoedit->xfig
> > 
> > It does not change the name of the feature from schema, as I 
> > asked about on HACKERS. I'm off for a week's vacation starting
> > tomorrow, so I probably won't see any commentary on this until
> > Monday the 24th
> > 
> > Ross

Re: [HACKERS] Libpq async issues

[Alfred Perlstein]

* Bruce Momjian <[EMAIL PROTECTED]> [010124 07:58] wrote:
> 
> I have added this email to TODO.detail and a mention in the TODO list.

The bug mentioned here is long gone, however the problem with
issuing non-blocking COPY commands is still present (8k limit on
buffer size).  I hope to get to fix this sometime soon, but you
shouldn't worry about the "normal" path.

There's also a bug with PQCopyEnd(sp?) where it can still block because
it automagically calls into a routine that select()'s waiting for data.

It's on my TODO list as well, but a little behind a several thousand
line server I'm almost complete with.

-Alfred

> 
> > >> Um, I didn't have any trouble at all reproducing Patrick's complaint.
> > >> pg_dump any moderately large table (I used tenk1 from the regress
> > >> database) and try to load the script with psql.  Kaboom.
> > 
> > > This is after or before my latest patch?
> > 
> > Before.  I haven't updated since yesterday...
> > 
> > > I can't seem to reproduce this problem,
> > 
> > Odd.  Maybe there is something different about the kernel's timing of
> > message sending on your platform.  I see it very easily on HPUX 10.20,
> > and Patrick sees it very easily on whatever he's using (netbsd I think).
> > You might try varying the situation a little, say
> > psql mydb  > psql -f dumpfile mydb
> > psql mydb
> > \i dumpfile
> > and the same with -h localhost (to get a TCP/IP connection instead of
> > Unix domain).  At the moment (pre-patch) I see failures with the
> > first two of these, but not with the \i method.  -h doesn't seem to
> > matter for me, but it might for you.
> > 
> > > Telling me something is wrong without giving suggestions on how
> > > to fix it, nor direct pointers to where it fails doesn't help me
> > > one bit.  You're not offering constructive critism, you're not
> > > even offering valid critism, you're just waving your finger at
> > > "problems" that you say exist but don't pin down to anything specific.
> > 
> > I have been explaining it as clearly as I could.  Let's try it
> > one more time.
> > 
> > > I spent hours looking over what I did to pqFlush and pqPutnBytes
> > > because of what you said earlier when all the bug seems to have
> > > come down to is that I missed that the socket is set to non-blocking
> > > in all cases now.
> > 
> > Letting the socket mode default to blocking will hide the problems from
> > existing clients that don't care about non-block mode.  But people who
> > try to actually use the nonblock mode are going to see the same kinds of
> > problems that psql is exhibiting.
> > 
> > > The old sequence of events that happened was as follows:
> > 
> > >   user sends data almost filling the output buffer...
> > >   user sends another line of text overflowing the buffer...
> > >   pqFlush is invoked blocking the user until the output pipe clears...
> > >   and repeat.
> > 
> > Right.
> > 
> > > The nonblocking code allows sends to fail so the user can abort
> > > sending stuff to the backend in order to process other work:
> > 
> > >   user sends data almost filling the output buffer...
> > >   user sends another line of text that may overflow the buffer...
> > >   pqFlush is invoked, 
> > > if the pipe can't be cleared an error is returned allowing the user to
> > >   retry the send later.
> > > if the flush succeeds then more data is queued and success is returned
> > 
> > But you haven't thought through the mechanics of the "error is returned
> > allowing the user to retry" code path clearly enough.  Let's take
> > pqPutBytes for an example.  If it returns EOF, is that a hard error or
> > does it just mean that the application needs to wait a while?  The
> > application *must* distinguish these cases, or it will do the wrong
> > thing: for example, if it mistakes a hard error for "wait a while",
> > then it will wait forever without making any progress or producing
> > an error report.
> > 
> > You need to provide a different return convention that indicates
> > what happened, say
> > EOF (-1)=> hard error (same as old code)
> > 0   => OK
> > 1   => no data was queued due to risk of blocking
> > And you need to guarantee that the application knows what the state is
> > when the can't-do-it-yet return is made; note that I specified "no data
> > was queued" above.  If pqPutBytes might queue some of the data before
> > returning 1, the application is in trouble again.  While you apparently
> > foresaw that in recoding pqPutBytes, your code doesn't actually work.
> > There is the minor code bug that you fail to update "avail" after the
> > first pqFlush call, and the much more fundamental problem that you
> > cannot guarantee to have queued all or none of the data.  Think about
> > what happens if the passed nbytes is larger than the output buffer size.
> > You may pass the first pqFlush successfully, then get into the loop and
> > get a won't-block return from pqFlush

Re: [HACKERS] BETWEEN patch

[Tom Lane]

Thomas Swan <[EMAIL PROTECTED]> writes:
> A patch to gram.y in src/backend/parser
> Provides for the SQL99 expected behavior of
>  select * from foo where fo_num between 1 and 5
> yields the same result as
>  select * from foo where fo_num between 5 and 1

This is NOT correct under either SQL92 or SQL99.  Read the spec again.

regards, tom lane

Re: [HACKERS] Libpq async issues

[Tom Lane]

Alfred Perlstein <[EMAIL PROTECTED]> writes:
> * Bruce Momjian <[EMAIL PROTECTED]> [010124 07:58] wrote:
>> I have added this email to TODO.detail and a mention in the TODO list.

> The bug mentioned here is long gone,

Au contraire, the misdesign is still there.  The nonblock-mode code
will *never* be reliable under stress until something is done about
that, and that means fairly extensive code and API changes.

regards, tom lane

RE: [HACKERS] FW: Postgresql on win32

[Magnus Hagander]

> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > We're losing this battle anyway.  Look into 
> src/interfaces/libpq/libpq.rc.
> 
> Ugh.  Magnus, is there any reasonable way to generate that 
> thing on the fly on Win32?
It's the same thing as with version.h - e.g. not really :-( It can be done,
but I doubt it can be done cleanly.


> One could imagine fixing this in configure --- have configure generate
> libpq.rc from libpq.rc.in, and then treat libpq.rc as part of the
> distribution the same as we do for gram.c and so forth.  The version
> info could get substituted into config.h.win32 the same way, 
> I suppose.
> 
> This is pretty ugly, but you could look at it as being no different
> from providing gram.c for those without bison: ship those dependent
> files that can't be remade without tools that may not exist on the
> target platform.
> 
> You'll probably say "that's more trouble than it's worth", but version
> info in a file that's only used by a marginally-supported platform is
> just the kind of thing that humans will forget to update.

If it is possible to do that, then I think it would be the best. (And
putting it in both a .h and the .rc file). It wuold definitly make things
cleaner-looking for the end user :-)

I have no idea how to do this, though, so I can't submit a patch. But if
someone were to do it and tell me where/how it goes into a header, I can
update the win32 patch to work with it...

Regards,
 Magnus

Re: [HACKERS] Re: GreatBridge RPMs (was: Re: question)

[Samy Elashmawy]

Ypu can always use the source to build and install it instead of the RPM.

At 07:18 PM 1/23/2001 +, Thomas Lockhart wrote:
>> I'd hate to wait for the Mandrake specific RPM for every release.
>
>I've been building the Mandrake RPMs, and there is currently a small
>problem in the build which I haven't had time to pursue (yet). The
>Mandrake distro should be available on the postgresql.org ftp site very
>soon after release.
>
> - Thomas
>

Re: [HACKERS] Open 7.1 items

[Bruce Momjian]

> > It has to be done separately because you need to see the full content
> > and reply to each individually.  Also, they go to different lists
> > sometimes.  Pretty confusing.
> 
> Could you post a list of open issues where each has just a number,
> heading 
> (optional) and link to an email in some mailing-list archive ?

Not really.  I don't have time to make a web site out of this thing. 
:-)

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] PgAccess - small bug?

[Bruce Momjian]

Has this been dealt with?

> 
> 
> 
> 
> On Wed, 31 May 2000, Bruce Momjian wrote:
> 
> > I assume this is fixed?
> 
>  Oh, it is really old letter from me. I total forget... 
> 
>  Hmm, I haven't here last version of CVS, but pgaccess in my comp has this
> bug still..
> 
>  Bruce, thanks for answer. I not had hope that anyone advert to this.
> 
>   Karel
> 
> > 
> > > 
> > > Hi,
> > > 
> > > in PgAccess's the create table dialog is small bug. If I define a new table
> > > as interits of other table and I not define any column (as 'field' named this 
> > > dialog) - PgAccess return ERROR message "Your table has not field!". But
> > > PgSQL allow define table as:
> > > 
> > >   CREATE TABLE xxx () INHERITS(yyy); 
> > > 
> > > ...all colunms is from 'yyy'. 
> > > 
> > > NOTE: Why a attribute (column) is in the PgAccsess named 'field'? It is 
> > > abnormal in SQL speech... 
> > > 
> > >   Karel
> > > 
> > > --
> > > Karel Zak <[EMAIL PROTECTED]>  http://home.zf.jcu.cz/~zakkr/
> > > 
> > > Docs: http://docs.linux.cz  (big docs archive)   
> 
> > > Kim Project:  http://home.zf.jcu.cz/~zakkr/kim/  (process manager)
> > > FTP:  ftp://ftp2.zf.jcu.cz/users/zakkr/  (C/ncurses/PgSQL)
> > > --
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > -- 
> >   Bruce Momjian|  http://www.op.net/~candle
> >   [EMAIL PROTECTED]   |  (610) 853-3000
> >   +  If your life is a hard drive, |  830 Blythe Avenue
> >   +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026
> > 
> 
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

[HACKERS] Re: [PATCHES] RE: SSL Connections [doc PATCH]

[Bruce Momjian]

> That would probably be good, yes :-)
> 
> You shuold then change:
> mv privkey.pem cert.pem.pw
> openssl rsa -in cert.pem.pw -out cert.pem
> 
> to
> openssl rsa -in privkey.pem -out cert.pem
> 
> (Sorry, don't have access to the SGML source now, so I can't give you a
> patch)

OK, the SGML diff is:

---

Index: doc/src/sgml/runtime.sgml
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.46
diff -c -r1.46 runtime.sgml
*** doc/src/sgml/runtime.sgml   2001/01/08 21:01:54 1.46
--- doc/src/sgml/runtime.sgml   2001/01/24 15:17:09
***
*** 1911,1918 
 To remove the passphrase (as you must if you want automatic start-up of
 the postmaster), run the commands
  
! mv privkey.pem cert.pem.pw
! openssl rsa -in cert.pem.pw -out cert.pem 
  
 Enter the old passphrase to unlock the existing key. Now do
  
--- 1911,1917 
 To remove the passphrase (as you must if you want automatic start-up of
 the postmaster), run the commands
  
! openssl rsa -in privkey.pem -out cert.pem
  
 Enter the old passphrase to unlock the existing key. Now do
  

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] Open 7.1 items

[Bruce Momjian]

> > > > They can not be easily summarized in one line.  You really have to see
> > > > the whole email to understand the issues.
> > > >
> > > > How do people want to do this?  I can post them to hackers, or put them
> > > > on my web site.  I posted them to hackers during the past few days, but
> > > > many went unanswered.  These are all relatively new from the past few
> > > > months.
> 
> I guess that having _one_ document with all of them would get much more
> attention.
> 
> It could be just copy and paste from the e-mails, numbered to be easily
> referred to.
> 
> Not everybody here reads _every_ mail on the list, even if it is from
> you ;) 

It has to be done separately because you need to see the full content
and reply to each individually.  Also, they go to different lists
sometimes.  Pretty confusing.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] select within a fucntion

[Hannu Krosing]

"Sinuhé Arroyo Gómez" wrote:
> 
> The thing is that I´m not interested in wasting CPU nor my ystem is
> oversized, and of course, "my friend", I willl use the results of the
> select, because as a matter of fact it was a select .. into statement the
> one I was trying,

There was probably a syntax error that made it into a SELECT statement 
(which SELECT .. INTO is not)

> but to make it easier to understand (I now see you were so
> smart that this was a waste of time), I just wrote a select statement which
> by the way, trows the same exception.

when writing for help or to report a bug, _always_ include the _actual_
code that misbehaves not some other code. I just confuses people.

--
Hannu

Re: [HACKERS] Patches with vacuum fixes available for 7.0.x

[Denis Perchine]

On Wednesday 24 January 2001 20:37, Bruce Momjian wrote:
> Here is another open item.  What are we doing with LAZY vacuum?

Sorry for inserting in the middle. I would like to say that when I tried LAZY 
vacuum on 7.0.3, I had a lockup on one of the table which disappeared after I 
did usual vacuum. I have sent an original version of a table from the backup 
to Vadim, but did not get any response. Just for your info.

-- 
Sincerely Yours,
Denis Perchine

--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--

Re: [HACKERS] Bug in FOREIGN KEY

[Bruce Momjian]

We have to decide how to address this, perhaps with a clearer error
message and a TODO item.

> Bruce Momjian wrote:
> > > Bruce Momjian writes:
> > >
> > > > ERROR:  triggered data change violation on relation "primarytest2"
> > >
> > > We're getting this report about once every 48 hours, which would make it a
> > > FAQ.  (hint, hint)
> > >
> >
> >
> > First time I heard of it.  Does anyone know more details?
> 
> Think  I misinterpreted the SQL3 specs WR to this detail. The
> checks must be made per statement,  not  at  the  transaction
> level.  I'll  try  to fix it, but we need to define what will
> happen with referential actions in the  case  of  conflicting
> actions on the same key - there are some possible conflicts:
> 
> 1.  DEFERRED ON DELETE NO ACTION or RESTRICT
> 
> Do  the referencing rows reference to the new PK row with
> the  same  key  now,  or  is  this  still  a   constraint
> violation?  I  would say it's not, because the constraint
> condition is satisfied at the end of the transaction. How
> do other databases behave?
> 
> 2.  DEFERRED ON DELETE CASCADE, SET NULL or SET DEFAULT
> 
> Again  I'd  say  that  the  action  should  be suppressed
> because a matching PK row is present at transaction end -
> it's  not  the same old row, but the constraint itself is
> still satisfied.
> 
> Implementing it that way (if it is correct that way) requires
> that  the  RI-triggers  check that the key in question really
> disappeared from the PK table,  at  least  for  the  deferred
> invocation at transaction end. This lookup is not required in
> the immediate case, so it would be  possible  to  retain  the
> current  performance  here,  but  we'd  need a mechanism that
> tells the trigger if it is actually invoked in  immediate  or
> deferred mode. Don't know how to do that right now.
> 
> To  fix  it now, I'd tend to remove the triggered data change
> check in the trigger queue (where the error is  coming  from)
> and  add  the  extra  PK lookup to the triggers for 7.1. Then
> think about the suppress of  it  with  an  immediate/deferred
> flag mechanism for 7.2.
> 
> 
> Jan
> 
> --
> 
> #==#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me.  #
> #== [EMAIL PROTECTED] #
> 
> 
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] Open 7.1 items

[The Hermit Hacker]

On Wed, 24 Jan 2001, Bruce Momjian wrote:

> > > It has to be done separately because you need to see the full content
> > > and reply to each individually.  Also, they go to different lists
> > > sometimes.  Pretty confusing.
> >
> > Could you post a list of open issues where each has just a number,
> > heading
> > (optional) and link to an email in some mailing-list archive ?
>
> Not really.  I don't have time to make a web site out of this thing.
> :-)

If they were previously sent to the lists, there should be a link in the
archives to point ppl to, no? :0

Re: [HACKERS] Open 7.1 items

[Hannu Krosing]

Bruce Momjian wrote:
> 
> > > > > They can not be easily summarized in one line.  You really have to see
> > > > > the whole email to understand the issues.
> > > > >
> > > > > How do people want to do this?  I can post them to hackers, or put them
> > > > > on my web site.  I posted them to hackers during the past few days, but
> > > > > many went unanswered.  These are all relatively new from the past few
> > > > > months.
> >
> > I guess that having _one_ document with all of them would get much more
> > attention.
> >
> > It could be just copy and paste from the e-mails, numbered to be easily
> > referred to.
> >
> > Not everybody here reads _every_ mail on the list, even if it is from
> > you ;)
> 
> It has to be done separately because you need to see the full content
> and reply to each individually.  Also, they go to different lists
> sometimes.  Pretty confusing.

Could you post a list of open issues where each has just a number,
heading 
(optional) and link to an email in some mailing-list archive ?


Hannu

AW: [HACKERS] Postgresql on win32

[Zeugswetter Andreas SB]

> Thanks.  Applied.
> 
> [ Charset ISO-8859-1 unsupported, converting... ]
> > Hello!
> > 
> > Here is a patch to make the current snapshot compile on 
> Win32 (native, libpq
> > and psql) again. Changes are:

I thought the consensus was to do something other than that patch.
As it looks, if nothing else is changed on win32 it only produces a memory 
leak instead of a crash.

Andreas

[HACKERS] RE: [PATCHES] RE: SSL Connections [doc PATCH]

[Magnus Hagander]

Needs fixing - no. The current version *works*.
The fix would remove one unnecessary step from it, but it still *works* in
it's current state.

Sorry about this - I've missed looking at it.

//Magnus

> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: den 24 januari 2001 15:47
> To: Magnus Hagander
> Cc: PostgreSQL-development; PostgreSQL-documentation
> Subject: Re: [PATCHES] RE: SSL Connections [doc PATCH]
> 
> 
> 
> Again, is this something that needs fixing?  Just a YES or NO is all I
> need.
> 
> 
> 
> > It looks Ok, but it has one unnecessary step. There is no 
> need to do the "mv
> > privkey.pem cert.pem.pw" if you just use "privkey.pem" in 
> the following
> > openssl command (e.g. openssl rsa -in privkey.pem -out cert.pem".
> > But there is nothing wrong with it as it is now, as far as 
> I can see.
> > 
> > 
> > //Magnus
> > 
> > 
> > > -Original Message-
> > > From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> > > Sent: den 21 december 2000 20:15
> > > To: Magnus Hagander
> > > Cc: 'Matthew Kirkwood'; '[EMAIL PROTECTED]'
> > > Subject: Re: [PATCHES] RE: SSL Connections [doc PATCH]
> > > 
> > > 
> > > I have applied an earlier patch to this file for SSL.  
> Could you check
> > > the current tree and see how you like it?
> > > 
> > > 
> > > > Thanks for that one!
> > > > 
> > > > Here is a patch to update the documentation based on this - 
> > > this should make
> > > > it less dependant on the version of OpenSSL used.
> > > > 
> > > > //Magnus
> > > > 
> > > > 
> > > > 
> > > > > -Original Message-
> > > > > From: Matthew Kirkwood [mailto:[EMAIL PROTECTED]]
> > > > > Sent: den 21 december 2000 16:49
> > > > > To: Oliver Elphick
> > > > > Cc: [EMAIL PROTECTED]
> > > > > Subject: Re: [HACKERS] SSL Connections
> > > > > 
> > > > > 
> > > > > On Wed, 20 Dec 2000, Oliver Elphick wrote:
> > > > > 
> > > > > > To create a quick self-signed certificate, use the 
> CA.pl script
> > > > > > included in OpenSSL:
> > > > > > 
> > > > > > CA.pl -newcert
> > > > > 
> > > > > Or you can do it manually:
> > > > > 
> > > > > openssl req -new -text -out cert.req (you will have to enter 
> > > > > a password)
> > > > > mv privkey.pem cert.pem.pw
> > > > > openssl rsa -in cert.pem.pw -out cert.pem  (this removes 
> > > the password)
> > > > > openssl req -x509 -in cert.req -text -key cert.pem 
> -out cert.cert
> > > > > 
> > > > > Matthew.
> > > > > 
> > > > 
> > > 
> > > [ Attachment, skipping... ]
> > > 
> > > 
> > > -- 
> > >   Bruce Momjian|  http://candle.pha.pa.us
> > >   [EMAIL PROTECTED]   |  (610) 853-3000
> > >   +  If your life is a hard drive, |  830 Blythe Avenue
> > >   +  Christ can be your backup.|  Drexel Hill, 
> > > Pennsylvania 19026
> > > 
> > 
> 
> 
> -- 
>   Bruce Momjian|  http://candle.pha.pa.us
>   [EMAIL PROTECTED]   |  (610) 853-3000
>   +  If your life is a hard drive, |  830 Blythe Avenue
>   +  Christ can be your backup.|  Drexel Hill, 
> Pennsylvania 19026
> 

[HACKERS] Cleanup time

[Bruce Momjian]

I know it is a pain to have to deal with all these items, but we have to
do this for every release.  It helps to make our releases more complete
because all open issues are resolved.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] This script will crash the connection

[Tom Lane]

Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is there a TODO item here, Tom?

Hopefully we can just decide what to do and do it.  I'm waiting to hear
Jan's opinion ...

regards, tom lane

Re: [HACKERS] Open 7.1 items

[Hannu Krosing]

Bruce Momjian wrote:
> 
> I have trickled the emails as I reviewed them, asking for comments.  It
> was not one big email.

...

> > > They can not be easily summarized in one line.  You really have to see
> > > the whole email to understand the issues.
> > >
> > > How do people want to do this?  I can post them to hackers, or put them
> > > on my web site.  I posted them to hackers during the past few days, but
> > > many went unanswered.  These are all relatively new from the past few
> > > months.

I guess that having _one_ document with all of them would get much more
attention.

It could be just copy and paste from the e-mails, numbered to be easily
referred to.

Not everybody here reads _every_ mail on the list, even if it is from
you ;) 


---
Hannu

[HACKERS] Re: [PATCHES] RE: SSL Connections [doc PATCH]

[Bruce Momjian]

Again, is this something that needs fixing?  Just a YES or NO is all I
need.



> It looks Ok, but it has one unnecessary step. There is no need to do the "mv
> privkey.pem cert.pem.pw" if you just use "privkey.pem" in the following
> openssl command (e.g. openssl rsa -in privkey.pem -out cert.pem".
> But there is nothing wrong with it as it is now, as far as I can see.
> 
> 
> //Magnus
> 
> 
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> > Sent: den 21 december 2000 20:15
> > To: Magnus Hagander
> > Cc: 'Matthew Kirkwood'; '[EMAIL PROTECTED]'
> > Subject: Re: [PATCHES] RE: SSL Connections [doc PATCH]
> > 
> > 
> > I have applied an earlier patch to this file for SSL.  Could you check
> > the current tree and see how you like it?
> > 
> > 
> > > Thanks for that one!
> > > 
> > > Here is a patch to update the documentation based on this - 
> > this should make
> > > it less dependant on the version of OpenSSL used.
> > > 
> > > //Magnus
> > > 
> > > 
> > > 
> > > > -Original Message-
> > > > From: Matthew Kirkwood [mailto:[EMAIL PROTECTED]]
> > > > Sent: den 21 december 2000 16:49
> > > > To: Oliver Elphick
> > > > Cc: [EMAIL PROTECTED]
> > > > Subject: Re: [HACKERS] SSL Connections
> > > > 
> > > > 
> > > > On Wed, 20 Dec 2000, Oliver Elphick wrote:
> > > > 
> > > > > To create a quick self-signed certificate, use the CA.pl script
> > > > > included in OpenSSL:
> > > > > 
> > > > > CA.pl -newcert
> > > > 
> > > > Or you can do it manually:
> > > > 
> > > > openssl req -new -text -out cert.req (you will have to enter 
> > > > a password)
> > > > mv privkey.pem cert.pem.pw
> > > > openssl rsa -in cert.pem.pw -out cert.pem  (this removes 
> > the password)
> > > > openssl req -x509 -in cert.req -text -key cert.pem -out cert.cert
> > > > 
> > > > Matthew.
> > > > 
> > > 
> > 
> > [ Attachment, skipping... ]
> > 
> > 
> > -- 
> >   Bruce Momjian|  http://candle.pha.pa.us
> >   [EMAIL PROTECTED]   |  (610) 853-3000
> >   +  If your life is a hard drive, |  830 Blythe Avenue
> >   +  Christ can be your backup.|  Drexel Hill, 
> > Pennsylvania 19026
> > 
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] Open 7.1 items

[Bruce Momjian]

> On Wed, 24 Jan 2001, Bruce Momjian wrote:
> 
> > > > It has to be done separately because you need to see the full content
> > > > and reply to each individually.  Also, they go to different lists
> > > > sometimes.  Pretty confusing.
> > >
> > > Could you post a list of open issues where each has just a number,
> > > heading
> > > (optional) and link to an email in some mailing-list archive ?
> >
> > Not really.  I don't have time to make a web site out of this thing.
> > :-)
> 
> If they were previously sent to the lists, there should be a link in the
> archives to point ppl to, no? :0

Sure, but this is hard enough.  Finding them is even harder.  May as
well read the email rather than link to a web page.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

[HACKERS] Re: [BUGS] select cash_out('2'); crashes backend on 7.0.2

[Bruce Momjian]

Folks, I see we have many problems here:

test=> select textout(2);
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: NOTICE: 
Message from PostgreSQL backend:
The Postmaster has informed me that some other backend died
abnormally and possibly corrupted shared memory.
I have rolled back the current transaction and am going to
terminate your database system connection and exit.
Please reconnect to the database system and repeat your query.
Failed.

and the server log shows:

Reinitializing shared memory and semaphores

Seems like a pretty serious denial of service attack to me.  It restarts
all running backends.

I have aligned the error messages, at least.


> 
> Hello,
> 
>  I was just experimenting, trying to see if I could find a function that
> would format a numeric value like 'money' with Postgres 7.0.2. Here's
> what happened:
> 
> ##
> cascade=> select cash_out(2);
> pqReadData() -- backend closed the channel unexpectedly.
> This probably means the backend terminated abnormally
> before or while processing the request.
> We have lost the connection to the backend, so further processing is
> impossible.  Terminating.
> ##
> 
> The same thing happened with Postgres 6.5.3. Here's my full version:
> PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled by gcc 2.96 
> 
> I'm sure if what I tried is even valid input, but I'm guessing this is
> not a desired result in any case. :) 
> 
> Thanks for the great software and good luck with this!
> 
> A frequent Postgres user,
> 
>   -mark
> 
> personal website }  Summersault Website Development
> http://mark.stosberg.com/{  http://www.summersault.com/
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

[HACKERS] Re: unixODBC again :-(

[Bruce Momjian]

Folks, I need help on this.  It would be nice to support unixODBC, but I
don't understand the ramifications of these changes.

> [EMAIL PROTECTED] wrote:
> 
> > Nick, sorry this was never resolved.  Do have any recollection of the
> > issues involved?
> 
> Hi Bruce,
> 
> Yes I can tell you what I was changing, I would love to get the code in the unixODBC 
>distrib to match the one you have, or even to remove it
> and point people to you.
> 
> There are a few simple changes.
> 
> 1. Add options to use unixODBC in the configure.in file, the mainly consists of 
>finding the root of the unixODBC install prefix, and adding
> -I /unixODBC/path/include and -L /unixODBC/path/lib to the driver build
> 
> 2. Change the way the driver gets config info, to be the same as when built under 
>windows. link with -lodbcinst and it provides
> SQLGetPrivateProfileString. the code that calls this works as long as the correct 
>define is set.
> 
> 3. Stop calling ODBC functions in the driver, this is simple but messy, the problem 
>being the call (say) in SQLAllocStmt that calls
> SQLAllocHandle in the driver, ends up calling the SQLAllocHandle in the driver 
>manager.
> 
> There are a couple of other changes I have made, that you may want to add, I added 
>the code to allow encrypted passwords (taken from the pg
> lib), as crypt is avaiable on unix. Add the option to detect a server name of 
>localhost, and open the unix domain socket, in fact try two
> places, to handle the debian build where the location is different. Again both of 
>these would have no place on Windows but in Unix.
> 
> Its chaos here at the moment, having lost a machine (dead disk) in the move to nice 
>new (old building) offices in the country side, but if
> you want any help, just shout.
> 
> 
> --
> Nick Gorham
> When I die, I want to go like my grandfather did, gently while sleeping,
> and not like his passangers, screaming in a panic, looking for the
> inflatable raft. -- Seen on ./
> 
> 
> 
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

[HACKERS] Re: [PATCHES] Small patch to replace 'idle' by 'trans' if transactionisstill open

[Peter Eisentraut]

Tom Lane writes:

> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Any solid consensus on this?
>
> I'm for it (given a short status string --- "idle in tx" or "idle in trans"
> seem fine).  Marc's for it.  Who's against it?

(I'm not.)  If you're going to do "idle in trans" you might as well spell
it out.  The string will be truncated to the allowed length with no penalty.

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/

Re: [HACKERS] (one more time) Patches with vacuum fixes available .

[Bruce Momjian]

Did we decide against LAZY?  Seems we have a number of people concerned
about vacuum downtime, and I can see this as a win for them.  If they
don't specify LAZY, the code is not run.

> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > should be easily testable though, no?
> 
> What makes you think that?  
> 
> > worst case, we pull it out afterwards ...
> 
> No, worst case is that we release a seriously broken 7.1, and don't
> find out till afterwards.
> 
> There are plenty of new features on my to-do list, if beta no longer
> means anything...
> 
>   regards, tom lane
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

[HACKERS] Re: [PATCHES] PgAccess schema-diagram cleanup

[Bruce Momjian]

Ross, this looks very good.  What happened to it?

> Here's a patch to clean up some issues with the schema diagram
> editor in pgaccess. This patch:
> 
>   * allows schema window to be resized up to full screen size
>   * autosizes window on schema open
>   * allows multiselect of tables (by shift click) to allow
>   dragging of sets of tables
>   deletion of sets of tables
>   * fixes a bug in table deletion code that did not delete
> links to that table properly
>   * changes link lines to be continous, so they export better
>   via postscript->pstoedit->xfig
>   
> It does not change the name of the feature from schema, as I 
> asked about on HACKERS. I'm off for a week's vacation starting
> tomorrow, so I probably won't see any commentary on this until
> Monday the 24th
> 
> Ross
> -- 
> Ross J. Reedstrom, Ph.D., <[EMAIL PROTECTED]> 
> NSBRI Research Scientist/Programmer
> Computer and Information Technology Institute
> Rice University, 6100 S. Main St.,  Houston, TX 77005
> 

[ Attachment, skipping... ]


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

[HACKERS] Re: [GENERAL] User names

[Bruce Momjian]

Seems like a bug that needs fixing.

> "Glen and Rosanne Eustace" <[EMAIL PROTECTED]> writes:
> > Is there a defined max length for postgreSQL user names ?
> > If there is and it is 8, then createuser should enforce it.
> > If the length is > 8 then pg_passwd needs fixing so that it doesn't
> > truncate.
> 
> A quick look in the pg_passwd sources indeed shows some hardwired limits
> on both username and password length.  This is bogus.  Anyone want to
> contribute a patch?
> 
> For the record, the max username length should be NAMEDATALEN-1, and
> the password field in pg_shadow is 'text', so it should be happy to
> take any password that you're willing to type ;-).  However, crypt
> password processing depends on crypt(3), which more than likely ignores
> characters beyond the eighth on most platforms.
> 
>   regards, tom lane
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] Minor buglet in update...from (I think)

[Bruce Momjian]

This still throws a strange error.  Someone want to fix it?

> 
> A minor nasty error I got when trying to improve the query used to disable
> triggers:
> 
> create table t1(f1 int4, f2 int4);
> create table t2(f1 int4, f2 int4);
> 
> insert into t1 values(1, 0);
> insert into t1 values(2, 0);
> 
> insert into t2 values(1, 0);
> 
> update t1 set f2=count(*) from t2 where t1.f1=1 and t2.f1=t1.f1 ;
> UPDATE 1
> 
> update t1 set f2=count(*) from t2 where t1.f1=2 and t2.f1=t1.f1 ;
> ERROR:  ExecutePlan: (junk) `ctid' is NULL!
> 
> I would have expected no update to occur since no rows match.
> 
> 
> 
> Philip Warner| __---_
> Albatross Consulting Pty. Ltd.   |/   -  \
> (A.C.N. 008 659 498) |  /(@)   __---_
> Tel: (+61) 0500 83 82 81 | _  \
> Fax: (+61) 0500 83 82 82 | ___ |
> Http://www.rhyme.com.au  |/   \|
>  |----
> PGP key available upon request,  |  /
> and from pgp5.ai.mit.edu:11371   |/
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

[HACKERS] Re: [GENERAL] child table doesn't inherit PRIMARY KEY?

[Bruce Momjian]

OK, what do people want to do with this item?  Add to TODO list?

Seems making a separat unique constraint would be easy to do and be of
value to most users.


> 
> Probably, since I see it in near recent sources (and it affects
> UNIQUE as well.  As I remember it, the last discussion on this couldn't
> determine what the correct behavior for unique/primary key constraints
> was in the inheritance case (is it a single unique hierarchy through
> all the tables [would be needed for fk to inheritance trees] or
> separate unique constraints for each table [which would be similar
> to how many people seem to currently use postgres inheritance as a 
> shortcut]). 
> 
> On Thu, 18 Jan 2001, Bruce Momjian wrote:
> 
> > Does this bug still exist?
> > 
> > [ Charset ISO-8859-1 unsupported, converting... ]
> > > Louis-David Mitterrand writes:
> > > 
> > > > When creating a child (through CREATE TABLE ... INHERIT (parent)) it
> > > > seems the child gets all of the parent's contraints _except_ its PRIMARY
> > > > KEY. Is this normal?
> 
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

[HACKERS] [JOB] pqsql hacker needed

[M Carling]

We'd like to employ a Postgres hacker to speed development of enterprise
features in Postgres.  All code would be immediately contributed back to
the community.  We are not interested in proprietary extensions.

We're a fun company located in Mountain View, CA, with all the usual
benefits such as medical and stock options plus some less common benefits
such as free massages and shower facilities on site.

Please reply with an ASCII resume.

M Carling
CIO
Axis, Inc.

[HACKERS] Re: [PATCHES] RE: SSL Connections [doc PATCH]

[Bruce Momjian]

But shouldn't we remove it to make it clearer?

> Needs fixing - no. The current version *works*.
> The fix would remove one unnecessary step from it, but it still *works* in
> it's current state.
> 
> Sorry about this - I've missed looking at it.
> 
> //Magnus
> 
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> > Sent: den 24 januari 2001 15:47
> > To: Magnus Hagander
> > Cc: PostgreSQL-development; PostgreSQL-documentation
> > Subject: Re: [PATCHES] RE: SSL Connections [doc PATCH]
> > 
> > 
> > 
> > Again, is this something that needs fixing?  Just a YES or NO is all I
> > need.
> > 
> > 
> > 
> > > It looks Ok, but it has one unnecessary step. There is no 
> > need to do the "mv
> > > privkey.pem cert.pem.pw" if you just use "privkey.pem" in 
> > the following
> > > openssl command (e.g. openssl rsa -in privkey.pem -out cert.pem".
> > > But there is nothing wrong with it as it is now, as far as 
> > I can see.
> > > 
> > > 
> > > //Magnus
> > > 
> > > 
> > > > -Original Message-
> > > > From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> > > > Sent: den 21 december 2000 20:15
> > > > To: Magnus Hagander
> > > > Cc: 'Matthew Kirkwood'; '[EMAIL PROTECTED]'
> > > > Subject: Re: [PATCHES] RE: SSL Connections [doc PATCH]
> > > > 
> > > > 
> > > > I have applied an earlier patch to this file for SSL.  
> > Could you check
> > > > the current tree and see how you like it?
> > > > 
> > > > 
> > > > > Thanks for that one!
> > > > > 
> > > > > Here is a patch to update the documentation based on this - 
> > > > this should make
> > > > > it less dependant on the version of OpenSSL used.
> > > > > 
> > > > > //Magnus
> > > > > 
> > > > > 
> > > > > 
> > > > > > -Original Message-
> > > > > > From: Matthew Kirkwood [mailto:[EMAIL PROTECTED]]
> > > > > > Sent: den 21 december 2000 16:49
> > > > > > To: Oliver Elphick
> > > > > > Cc: [EMAIL PROTECTED]
> > > > > > Subject: Re: [HACKERS] SSL Connections
> > > > > > 
> > > > > > 
> > > > > > On Wed, 20 Dec 2000, Oliver Elphick wrote:
> > > > > > 
> > > > > > > To create a quick self-signed certificate, use the 
> > CA.pl script
> > > > > > > included in OpenSSL:
> > > > > > > 
> > > > > > > CA.pl -newcert
> > > > > > 
> > > > > > Or you can do it manually:
> > > > > > 
> > > > > > openssl req -new -text -out cert.req (you will have to enter 
> > > > > > a password)
> > > > > > mv privkey.pem cert.pem.pw
> > > > > > openssl rsa -in cert.pem.pw -out cert.pem  (this removes 
> > > > the password)
> > > > > > openssl req -x509 -in cert.req -text -key cert.pem 
> > -out cert.cert
> > > > > > 
> > > > > > Matthew.
> > > > > > 
> > > > > 
> > > > 
> > > > [ Attachment, skipping... ]
> > > > 
> > > > 
> > > > -- 
> > > >   Bruce Momjian|  http://candle.pha.pa.us
> > > >   [EMAIL PROTECTED]   |  (610) 853-3000
> > > >   +  If your life is a hard drive, |  830 Blythe Avenue
> > > >   +  Christ can be your backup.|  Drexel Hill, 
> > > > Pennsylvania 19026
> > > > 
> > > 
> > 
> > 
> > -- 
> >   Bruce Momjian|  http://candle.pha.pa.us
> >   [EMAIL PROTECTED]   |  (610) 853-3000
> >   +  If your life is a hard drive, |  830 Blythe Avenue
> >   +  Christ can be your backup.|  Drexel Hill, 
> > Pennsylvania 19026
> > 
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

[HACKERS] function optimization ???

[Brent Verner]

Hi,

I've the following function:

  CREATE FUNCTION book_info(pricing)
  RETURNS catalog_general AS '
select *
from catalog_general
where star_isbn = $1.vista_isbn
  ' LANGUAGE 'sql';

calling it as:
  
  SELECT p.*, p.book_info.title FROM pricing p WHERE vista_ans='POD';

background and observation:
  
  the pricing table is fairly large, but only a small number meet
  "WHERE vista_ans='POD'". I can select all where vista_ans='POD'
  very quickly (.2 sec), but adding in the get_book(pricing) call
  slows this down to about 20sec. I can, with an external sql query,
  select all of the desired records in about 1 sec, so it appears
  to me that the function is being called regardless of whether
  or not the WHERE clause is being satisfied.

question:
  
  is there any way the function call could be _not_ called if:
1) the WHERE clause does not reference any of its return values, and
2) the WHERE clause has already been satisified.

  ???

If this behavior is reasonable, could someone point me _toward_ the
code where I'd need to make this optimization. I think this would be
nice to have for 7.2 :)

brent

[HACKERS] Re: [GENERAL] rules on INSERT can't UPDATE new instance?

[Bruce Momjian]

Comments on this?  Seems INSERT should happen at the end.  Is this a
trivial change?


> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is the INSERT rule re-ordering mentioned a TODO item?
> 
> Darn if I know.  I threw the thought out for discussion, but didn't
> see any comments.  I'm not in a hurry to change it, unless there's
> consensus that we should.
> 
>   regards, tom lane
> 
> 
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
>  I thought an INSERT rule with an UPDATE action would work on the same
>  table, but that fails.  Seems the rule is firing before the INSERT
>  happens.
> >> 
> >> Yes, a trigger is the right way to do surgery on a tuple before it is
> >> stored.  Rules are good for generating additional SQL queries that will
> >> insert/update/delete other tuples (usually, but not necessarily, in
> >> other tables).  Even if it worked, a rule would be a horribly
> >> inefficient way to handle modification of the about-to-be-inserted
> >> tuple, because (being an independent query) it'd have to scan the table
> >> to find the tuple you are talking about!
> >> 
> >> The reason the additional queries are done before the original command
> >> is explained thus in the source code:
> >> 
> >> * The original query is appended last if not instead
> >> * because update and delete rule actions might not do
> >> * anything if they are invoked after the update or
> >> * delete is performed. The command counter increment
> >> * between the query execution makes the deleted (and
> >> * maybe the updated) tuples disappear so the scans
> >> * for them in the rule actions cannot find them.
> >> 
> >> This seems to make sense for UPDATE/DELETE, but I wonder whether
> >> the ordering should be different for the INSERT case: perhaps it
> >> should be original-query-first in that case.
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] Patches with vacuum fixes available for 7.0.x

[Bruce Momjian]

Here is another open item.  What are we doing with LAZY vacuum?  

> We recently had a very satisfactory contract completed by
> Vadim.
> 
> Basically Vadim has been able to reduce the amount of time
> taken by a vacuum from 10-15 minutes down to under 10 seconds.
> 
> We've been running with these patches under heavy load for
> about a week now without any problems except one:
>   don't 'lazy' (new option for vacuum) a table which has just
>   had an index created on it, or at least don't expect it to
>   take any less time than a normal vacuum would.
> 
> There's three patchsets and they are available at:
> 
> http://people.freebsd.org/~alfred/vacfix/
> 
> complete diff:
> http://people.freebsd.org/~alfred/vacfix/v.diff
> 
> only lazy vacuum option to speed up index vacuums:
> http://people.freebsd.org/~alfred/vacfix/vlazy.tgz
> 
> only lazy vacuum option to only scan from start of modified
> data:
> http://people.freebsd.org/~alfred/vacfix/mnmb.tgz
> 
> Although the patches are for 7.0.x I'm hoping that they
> can be forward ported (if Vadim hasn't done it already)
> to 7.1.
> 
> enjoy!
> 
> -- 
> -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
> "I have the heart of a child; I keep it in a jar on my desk."
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: AW: [HACKERS] Postgresql on win32

[Bruce Momjian]

OK, suggestions? 

[ Charset ISO-8859-1 unsupported, converting... ]
> 
> > Thanks.  Applied.
> > 
> > [ Charset ISO-8859-1 unsupported, converting... ]
> > > Hello!
> > > 
> > > Here is a patch to make the current snapshot compile on 
> > Win32 (native, libpq
> > > and psql) again. Changes are:
> 
> I thought the consensus was to do something other than that patch.
> As it looks, if nothing else is changed on win32 it only produces a memory 
> leak instead of a crash.
> 
> Andreas
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] WAL fsync scheduling

[Bruce Momjian]

Added to TODO.detail and TODO list.

> [ Charset ISO-8859-1 unsupported, converting... ]
> > > There are two parts to transaction commit.  The first is writing all
> > > dirty buffers or log changes to the kernel, and second is fsync of the
> >
> > Backend doesn't write any dirty buffer to the kernel at commit time.
> 
> Yes, I suspected that.
> 
> > 
> > > log file.
> > 
> > The first part is writing commit record into WAL buffers in shmem.
> > This is what XLogInsert does.  After that XLogFlush is called to ensure
> > that  entire commit record is on disk. XLogFlush does *both* write() and
> > fsync() (single slock is used for both writing and fsyncing) if it needs to
> > do it at all.
> 
> Yes, I realize there are new steps in WAL.
> 
> > 
> > > I suggest having a per-backend shared memory byte that has the following
> > > values:
> > > 
> > > START_LOG_WRITE
> > > WAIT_ON_FSYNC
> > > NOT_IN_COMMIT
> > > backend_number_doing_fsync
> > > 
> > > I suggest that when each backend starts a commit, it sets its byte to
> > > START_LOG_WRITE. 
> >   ^^^
> > Isn't START_COMMIT more meaningful?
> 
> Yes.
> 
> > 
> > > When it gets ready to fsync, it checks all backends. 
> >^^
> > What do you mean by this? The moment just after XLogInsert?
> 
> Just before it calls fsync().
> 
> > 
> > > If all are NOT_IN_COMMIT, it does fsync and continues.
> > 
> > 1st edition:
> > > If one or more are in START_LOG_WRITE, it waits until no one is in
> > > START_LOG_WRITE.  It then checks all WAIT_ON_FSYNC, and if it is the
> > > lowest backend in WAIT_ON_FSYNC, marks all others with its backend
> > > number, and does fsync.  It then clears all backends with its number to
> > > NOT_IN_COMMIT.  Other backend will see they are not the lowest
> > > WAIT_ON_FSYNC and will wait for their byte to be set to NOT_IN_COMMIT
> > > so they can then continue, knowing their data was synced.
> > 
> > 2nd edition:
> > > I have another idea.  If a backend gets to the point that it needs
> > > fsync, and there is another backend in START_LOG_WRITE, it can go to an
> > > interuptable sleep, knowing another backend will perform the fsync and
> > > wake it up.  Therefore, there is no busy-wait or timed sleep.
> > > 
> > > Of course, a backend must set its status to WAIT_ON_FSYNC to avoid a
> > > race condition.
> > 
> > The 2nd edition is much better. But I'm not sure do we really need in
> > these per-backend bytes in shmem. Why not just have some counters?
> > We can use a semaphore to wake-up all waiters at once.
> 
> Yes, that is much better and clearer.  My idea was just to say, "if no
> one is entering commit phase, do the commit.  If someone else is coming,
> sleep and wait for them to do the fsync and wake me up with a singal."  
> 
> > 
> > > This allows a single backend not to sleep, and allows multiple backends
> > > to bunch up only when they are all about to commit.
> > > 
> > > The reason backend numbers are written is so other backends entering the
> > > commit code will not interfere with the backends performing fsync.
> > 
> > Being waked-up backend can check what's written/fsynced by calling XLogFlush.
> 
> Seems that may not be needed anymore with a counter.  The only issue is
> that other backends may enter commit while fsync() is happening.  The
> process that did the fsync must be sure to wake up only the backends
> that were waiting for it, and not other backends that may be also be
> doing fsync as a group while the first fsync was happening.  I leave
> those details to people more experienced.  :-)
> 
> I am just glad people liked my idea.
> 
> -- 
>   Bruce Momjian|  http://candle.pha.pa.us
>   [EMAIL PROTECTED]   |  (610) 853-3000
>   +  If your life is a hard drive, |  830 Blythe Avenue
>   +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] Inline Comments for pg_dump

[Bruce Momjian]

Do we handle COMMENT properly in pg_dump now already?


[ Charset ISO-8859-1 unsupported, converting... ]
> I've very roughly (first time I've tried anything but hello world c) hacked up 
>inline comments.
> 
> pg_dump -I
> 
> Exports the comments generated through COMMENT ON in an appropriate manner (line 
>above) the item with a -- in front.  More or less a self documenting dump, or atleast 
>an attempt at it.
> 
> However, due to my poor programming in this language, I'm not sure of teh best way 
>to handle the issues following:
> - Column comments mis-format the next row (Needs a \t or something)
> - Database comments non-existent, wasn't sure how or where to pull them out.
> - I've only tested TABLE and COLUMN comments.  Didn't have a database handy with the 
>rest, and had a limited amount of time to fiddle.
> 
> Take a look and see if it's worth anything or if it needs to be fixed up.
> --
> Rod Taylor
> 
> There are always four sides to every story: your side, their side, the truth, and 
>what really happened.

[ Attachment, skipping... ]

[ Attachment, skipping... ]


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

[HACKERS] Libpq async issues

[Bruce Momjian]

I have added this email to TODO.detail and a mention in the TODO list.

> >> Um, I didn't have any trouble at all reproducing Patrick's complaint.
> >> pg_dump any moderately large table (I used tenk1 from the regress
> >> database) and try to load the script with psql.  Kaboom.
> 
> > This is after or before my latest patch?
> 
> Before.  I haven't updated since yesterday...
> 
> > I can't seem to reproduce this problem,
> 
> Odd.  Maybe there is something different about the kernel's timing of
> message sending on your platform.  I see it very easily on HPUX 10.20,
> and Patrick sees it very easily on whatever he's using (netbsd I think).
> You might try varying the situation a little, say
>   psql mydbpsql -f dumpfile mydb
>   psql mydb
>   \i dumpfile
> and the same with -h localhost (to get a TCP/IP connection instead of
> Unix domain).  At the moment (pre-patch) I see failures with the
> first two of these, but not with the \i method.  -h doesn't seem to
> matter for me, but it might for you.
> 
> > Telling me something is wrong without giving suggestions on how
> > to fix it, nor direct pointers to where it fails doesn't help me
> > one bit.  You're not offering constructive critism, you're not
> > even offering valid critism, you're just waving your finger at
> > "problems" that you say exist but don't pin down to anything specific.
> 
> I have been explaining it as clearly as I could.  Let's try it
> one more time.
> 
> > I spent hours looking over what I did to pqFlush and pqPutnBytes
> > because of what you said earlier when all the bug seems to have
> > come down to is that I missed that the socket is set to non-blocking
> > in all cases now.
> 
> Letting the socket mode default to blocking will hide the problems from
> existing clients that don't care about non-block mode.  But people who
> try to actually use the nonblock mode are going to see the same kinds of
> problems that psql is exhibiting.
> 
> > The old sequence of events that happened was as follows:
> 
> >   user sends data almost filling the output buffer...
> >   user sends another line of text overflowing the buffer...
> >   pqFlush is invoked blocking the user until the output pipe clears...
> >   and repeat.
> 
> Right.
> 
> > The nonblocking code allows sends to fail so the user can abort
> > sending stuff to the backend in order to process other work:
> 
> >   user sends data almost filling the output buffer...
> >   user sends another line of text that may overflow the buffer...
> >   pqFlush is invoked, 
> > if the pipe can't be cleared an error is returned allowing the user to
> >   retry the send later.
> > if the flush succeeds then more data is queued and success is returned
> 
> But you haven't thought through the mechanics of the "error is returned
> allowing the user to retry" code path clearly enough.  Let's take
> pqPutBytes for an example.  If it returns EOF, is that a hard error or
> does it just mean that the application needs to wait a while?  The
> application *must* distinguish these cases, or it will do the wrong
> thing: for example, if it mistakes a hard error for "wait a while",
> then it will wait forever without making any progress or producing
> an error report.
> 
> You need to provide a different return convention that indicates
> what happened, say
>   EOF (-1)=> hard error (same as old code)
>   0   => OK
>   1   => no data was queued due to risk of blocking
> And you need to guarantee that the application knows what the state is
> when the can't-do-it-yet return is made; note that I specified "no data
> was queued" above.  If pqPutBytes might queue some of the data before
> returning 1, the application is in trouble again.  While you apparently
> foresaw that in recoding pqPutBytes, your code doesn't actually work.
> There is the minor code bug that you fail to update "avail" after the
> first pqFlush call, and the much more fundamental problem that you
> cannot guarantee to have queued all or none of the data.  Think about
> what happens if the passed nbytes is larger than the output buffer size.
> You may pass the first pqFlush successfully, then get into the loop and
> get a won't-block return from pqFlush in the loop.  What then?
> You can't simply refuse to support the case nbytes > bufsize at all,
> because that will cause application failures as well (too long query
> sends it into an infinite loop trying to queue data, most likely).
> 
> A possible answer is to specify that a return of +N means "N bytes
> remain unqueued due to risk of blocking" (after having queued as much
> as you could).  This would put the onus on the caller to update his
> pointers/counts properly; propagating that into all the internal uses
> of pqPutBytes would be no fun.  (Of course, so far you haven't updated
> *any* of the internal callers to behave reasonably in case of a
> won't-block return; PQfn is just one example.)
> 
> An

[HACKERS] BETWEEN patch

[Thomas Swan]

A patch to gram.y in src/backend/parser

Provides for the SQL99 expected behavior of 
select
* from foo where fo_num between 1 and 5 
yields the same result as 
select
* from foo where fo_num between 5 and 1

Granted this is brute force and not very elegant, however it
does provide the correct behavior.  Optimally it would be nice to do
a comparison on the values after between and then sort the 
two limiters and do a single rewrite leaving only one pass or scan.

In other words in pseudo SQL:

select * from foo where fo_num between a and b 

becomes

select * from foo where ((fo_num >= min_value(a, b)) and (fo_num
<= max_value(a,b))

This would yield only two comparisons or resolutions and
then a single sequential or index scan to find the correct tuples.

This was done against beta1... 
 between.patch

-- 
- Thomas Swan
  
- Network Administrator
- Graduate Student  - Computer Science
-
- The Institute for Continuing Studies
- The University of Mississippi
-
-
http://www.ics.olemiss.edu
-
http://www.olemiss.edu

[HACKERS] RE: [PATCHES] RE: SSL Connections [doc PATCH]

[Magnus Hagander]

That would probably be good, yes :-)

You shuold then change:
mv privkey.pem cert.pem.pw
openssl rsa -in cert.pem.pw -out cert.pem

to
openssl rsa -in privkey.pem -out cert.pem

(Sorry, don't have access to the SGML source now, so I can't give you a
patch)

//Magnus

> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: den 24 januari 2001 16:03
> To: Magnus Hagander
> Cc: PostgreSQL-development; PostgreSQL-documentation
> Subject: Re: [PATCHES] RE: SSL Connections [doc PATCH]
> 
> 
> 
> But shouldn't we remove it to make it clearer?
> 
> > Needs fixing - no. The current version *works*.
> > The fix would remove one unnecessary step from it, but it 
> still *works* in
> > it's current state.
> > 
> > Sorry about this - I've missed looking at it.
> > 
> > //Magnus
> > 
> > > -Original Message-
> > > From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> > > Sent: den 24 januari 2001 15:47
> > > To: Magnus Hagander
> > > Cc: PostgreSQL-development; PostgreSQL-documentation
> > > Subject: Re: [PATCHES] RE: SSL Connections [doc PATCH]
> > > 
> > > 
> > > 
> > > Again, is this something that needs fixing?  Just a YES 
> or NO is all I
> > > need.
> > > 
> > > 
> > > 
> > > > It looks Ok, but it has one unnecessary step. There is no 
> > > need to do the "mv
> > > > privkey.pem cert.pem.pw" if you just use "privkey.pem" in 
> > > the following
> > > > openssl command (e.g. openssl rsa -in privkey.pem -out 
> cert.pem".
> > > > But there is nothing wrong with it as it is now, as far as 
> > > I can see.
> > > > 
> > > > 
> > > > //Magnus
> > > > 
> > > > 
> > > > > -Original Message-
> > > > > From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> > > > > Sent: den 21 december 2000 20:15
> > > > > To: Magnus Hagander
> > > > > Cc: 'Matthew Kirkwood'; '[EMAIL PROTECTED]'
> > > > > Subject: Re: [PATCHES] RE: SSL Connections [doc PATCH]
> > > > > 
> > > > > 
> > > > > I have applied an earlier patch to this file for SSL.  
> > > Could you check
> > > > > the current tree and see how you like it?
> > > > > 
> > > > > 
> > > > > > Thanks for that one!
> > > > > > 
> > > > > > Here is a patch to update the documentation based on this - 
> > > > > this should make
> > > > > > it less dependant on the version of OpenSSL used.
> > > > > > 
> > > > > > //Magnus
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > -Original Message-
> > > > > > > From: Matthew Kirkwood [mailto:[EMAIL PROTECTED]]
> > > > > > > Sent: den 21 december 2000 16:49
> > > > > > > To: Oliver Elphick
> > > > > > > Cc: [EMAIL PROTECTED]
> > > > > > > Subject: Re: [HACKERS] SSL Connections
> > > > > > > 
> > > > > > > 
> > > > > > > On Wed, 20 Dec 2000, Oliver Elphick wrote:
> > > > > > > 
> > > > > > > > To create a quick self-signed certificate, use the 
> > > CA.pl script
> > > > > > > > included in OpenSSL:
> > > > > > > > 
> > > > > > > > CA.pl -newcert
> > > > > > > 
> > > > > > > Or you can do it manually:
> > > > > > > 
> > > > > > > openssl req -new -text -out cert.req (you will 
> have to enter 
> > > > > > > a password)
> > > > > > > mv privkey.pem cert.pem.pw
> > > > > > > openssl rsa -in cert.pem.pw -out cert.pem  (this removes 
> > > > > the password)
> > > > > > > openssl req -x509 -in cert.req -text -key cert.pem 
> > > -out cert.cert
> > > > > > > 
> > > > > > > Matthew.
> > > > > > > 
> > > > > > 
> > > > > 
> > > > > [ Attachment, skipping... ]
> > > > > 
> > > > > 
> > > > > -- 
> > > > >   Bruce Momjian|  
http://candle.pha.pa.us
> > > >   [EMAIL PROTECTED]   |  (610) 853-3000
> > > >   +  If your life is a hard drive, |  830 Blythe Avenue
> > > >   +  Christ can be your backup.|  Drexel Hill, 
> > > > Pennsylvania 19026
> > > > 
> > > 
> > 
> > 
> > -- 
> >   Bruce Momjian|  http://candle.pha.pa.us
> >   [EMAIL PROTECTED]   |  (610) 853-3000
> >   +  If your life is a hard drive, |  830 Blythe Avenue
> >   +  Christ can be your backup.|  Drexel Hill, 
> > Pennsylvania 19026
> > 
> 


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] PgAccess - small bug?

[Bruce Momjian]

[ Charset ISO-8859-1 unsupported, converting... ]
> - Original Message - 
> From: "Bruce Momjian" <[EMAIL PROTECTED]>
> To: "Karel Zak" <[EMAIL PROTECTED]>
> Cc: "pgsql-hackers" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Wednesday, January 24, 2001 3:41 PM
> Subject: Re: [HACKERS] PgAccess - small bug?
> 
> 
> > 
> > Has this been dealt with?
> 
> Nope ... :-(
> 
> I'll fix it this weekend!

OK, let me know if you release a new pgaccess and I will add it to CVS.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] (one more time) Patches with vacuum fixes available .

[Tom Lane]

Bruce Momjian <[EMAIL PROTECTED]> writes:
> Did we decide against LAZY?

I thought the core consensus was that it was too risky to install
post-beta.  On the other hand, we're installing some other pretty
major fixes.  Do we want to re-open that discussion?

regards, tom lane

Re: AW: [HACKERS] like and optimization

[Patrick Welche]

On Mon, Jan 22, 2001 at 03:09:03PM -0800, Nathan Myers wrote:
... 
> Posix systems include a set of commands for dumping locales in a standard 
> format, and building from them.  Instead of shipping locales and code to 
> operate on them, one might include a script to run these tools (where 
> they exist) to dump an existing locale, edit it a bit, and build a more 
> PG-friendly locale.

Is there really a standard format for locales? Apparantly there are 3 different
ways of doing LC_COLLATE ?!

Cheers,

Patrick

Re: AW: [HACKERS] like and optimization

[Patrick Welche]

On Mon, Jan 22, 2001 at 05:46:09PM -0500, Tom Lane wrote:
... 
> Are there any BSD-license locale and/or timezone libraries that we might
> assimilate in this way?  We could use an LGPL'd library if there is no
> other alternative, but I'd just as soon not open up the license issue.

The "Citrus Project" is coming up with with i18n for BSD.

FYI

Patrick

Re: [HACKERS] select within a fucntion

[Sinuhé Arroyo Gómez]

The thing is that I´m not interested in wasting CPU nor my ystem is
oversized, and of course, "my friend", I willl use the results of the
select, because as a matter of fact it was a select .. into statement the
one I was trying, but to make it easier to understand (I now see you were so
smart that this was a waste of time), I just wrote a select statement which
by the way, trows the same exception.
Thanks


"Jan Wieck" <[EMAIL PROTECTED]> escribió en el mensaje
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Sinuhi Arroyo wrote:
> > I`mtrying to make a select which envolves two tables with in a
> > functionif the query is written this way: (this is just an example,
> > not my query)
> >
> > a := (select count(*) from xx);
> >
> > it works fine, but if I type the query like this
> >
> > select count(*) from xx;
> >
> > it throws a message that says unexpected query in exec_stmt_execsql.
> > If anyone knows how to fix it, it woul be great.
> > Thanx
>
> What  should  this "select count(*) from xx;" be good for, if
> you don't want to use  the  result?  You  can  of  course  do
> "perform  select  ..."   because  that'd use another PL/pgSQL
> executor construct that doesn't  complain  about  getting  an
> unused return value, but I still wonder why you want to waste
> CPU and IO (bought an oversized system?).
>
>
> Jan
>
> --
>
> #==#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me.  #
> #== [EMAIL PROTECTED] #
>
>
>
> _
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>

[HACKERS] Re: PostgreSQL on WinME?

[Manuel Cabido]

Hi there,

   I would like to inquire of any support for WinME to run
PostgreSQL. Should anyone knows how, I would be grateful to ask for
advice. I need to run PostgreSQL on my WinME box.

-- 
  Manny C. Cabido
  
  e-mail:[EMAIL PROTECTED]
 [EMAIL PROTECTED]
  =