so that fetching an attribute value needs only one SearchSysCacheTuple call
instead of two redundant searches. This speeds up a large SELECT by about
ten percent, and probably will help GROUP BY and SELECT DISTINCT too.
seem to be portable (HPUX doesn't like it, anyway). Also, clean up
StreamConnection(), which was mis-coded to assume that the address
family field is already set when it's called.
Here's another patch for the libpq backend areas. This patch removes all
usage of "FILE *" on the communications channel. It also cleans up the
comments and headers in the pqcomm.c file - a lot of things were either
missing or incorrect. Finally, it removes a couple of unused functions
(leftovers from the time of shared code between the libpq backend and
frontend).
Here is a first patch to cleanup the backend side of libpq.
This patch removes all external dependencies on the "Pfin" and "Pfout" that
are declared in pqcomm.h. These variables are also changed to "static" to
make sure.
Almost all the change is in the handler of the "copy" command - most other
areas of the backend already used the correct functions.
This change will make the way for cleanup of the internal stuff there - now
that all the functions accessing the file descriptors are confined to a
single directory.
where you state a format and arguments. the old behavior required
each appendStringInfo to have to have a sprintf() before it if any
formatting was required.
Also shortened several instances where there were multiple appendStringInfo()
calls in a row, doing nothing more then adding one more word to the String,
instead of doing them all in one call.
fail to consume the rest of the input string, and worse it would write
one more byte than it should into the buffer, probably resulting in coredump.
Fortunately there's a correct implementation next door in pqcomprim.c.
Here are patches needed to complie under AIX 4.2.
I changed configure.in, pqcomm.c, config.h.in, and fe-connect.c.
Also I had to install flex because lex did not want to translate pgc.l.
and make backend/libpq/pqcomm.c only try to lock the socket file when
the call exists. Also, change open-RDONLY to open-WRONLY; at least
on my platform, you can't get a write lock on a file you didn't open
for writing.
> socket-flock.patch
>
> use advisory locks to check if the unix socket can be deleted.
> A running postmaster keeps a lock on that file. A starting
> postmaster exits if the file exists and is locked, otherwise
> it deletes the sockets and proceeds.
> This avoid the need to remove manually the file after a postmaster
> or system crash.
> I don't know if flock is available on any system. If not we could
> define a HAVE_FLOCK set by configure.
patch is applied:
Rewrite rules on relation level work fine now.
Event qualifications on insert/update/delete rules work
fine now.
I added the new keyword OLD to reference the CURRENT
tuple. CURRENT will be removed in 6.5.
Update rules can reference NEW and OLD in the rule
qualification and the actions.
Insert/update/delete rules on views can be established to
let them behave like real tables.
For insert/update/delete rules multiple actions are
supported now. The actions can also be surrounded by
parantheses to make psql happy. Multiple actions are
required if update to a view requires updates to multiple
tables.
Regular users are permitted to create/drop rules on
tables they have RULE permissions for
(DefineQueryRewrite() is now able to get around the
access restrictions on pg_rewrite). This enables view
creation for regular users too. This required an extra
boolean parameter to pg_parse_and_plan() that tells to
set skipAcl on all rangetable entries of the resulting
queries. There is a new function
pg_exec_query_acl_override() that could be used by
backend utilities to use this facility.
All rule actions (not only views) inherit the permissions
of the event relations owner. Sample: User A creates
tables T1 and T2, creates rules that log
INSERT/UPDATE/DELETE on T1 in T2 (like in the regression
tests for rules I created) and grants ALL but RULE on T1
to user B. User B can now fully access T1 and the
logging happens in T2. But user B cannot access T2 at
all, only the rule actions can. And due to missing RULE
permissions on T1, user B cannot disable logging.
Rules on the attribute level are disabled (they don't
work properly and since regular users are now permitted
to create rules I decided to disable them).
Rules on select must have exactly one action that is a
select (so select rules must be a view definition).
UPDATE NEW/OLD rules are disabled (still broken, but
triggers can do it).
There are two new system views (pg_rule and pg_view) that
show the definition of the rules or views so the db admin
can see what the users do. They use two new functions
pg_get_ruledef() and pg_get_viewdef() that are builtins.
The functions pg_get_ruledef() and pg_get_viewdef() could
be used to implement rule and view support in pg_dump.
PostgreSQL is now the only database system I know, that
has rewrite rules on the query level. All others (where I
found a rule statement at all) use stored database
procedures or the like (triggers as we call them) for
active rules (as some call them).
Future of the rule system:
The now disabled parts of the rule system (attribute
level, multiple actions on select and update new stuff)
require a complete new rewrite handler from scratch. The
old one is too badly wired up.
After 6.4 I'll start to work on a new rewrite handler,
that fully supports the attribute level rules, multiple
actions on select and update new. This will be available
for 6.5 so we get full rewrite rule capabilities.
Jan
no longer returns buffer pointer, can be gotten from scan;
descriptor; bootstrap can create multi-key indexes;
pg_procname index now is multi-key index; oidint2, oidint4, oidname
are gone (must be removed from regression tests); use System Cache
rather than sequential scan in many places; heap_modifytuple no
longer takes buffer parameter; remove unused buffer parameter in
a few other functions; oid8 is not index-able; remove some use of
single-character variable names; cleanup Buffer variables usage
and scan descriptor looping; cleaned up allocation and freeing of
tuples; 18k lines of diff;
As Bruce mentioned, this is due to the conflict among changes we made.
Included patches should fix the problem(I changed all MB to
MULTIBYTE). Please let me know if you have further problem.
P.S. I did not include pathces to configure and gram.c to save the
file size(configure.in and gram.y modified).
calls. Outside a transaction, the backend detects them as buffer
leaks; it sends a NOTICE, and frees them. This sometimes cause a
segmentation fault (at least on Linux). These indexes are initialized
on the first lo_read/lo_write/lo_tell call, and (normally) closed
on a lo_close call. Thus the buffer leaks appear when lo direct
access functions are used, and not with lo_import/lo_export functions
(libpq version calls lo_close before ending the command, and the
backend version uses another path).
The included patches (against recent snapshot, and against 6.3.2)
cause indexes to be closed on transaction end (that is on explicit
'END' statment, or on command termination outside trasaction blocks),
thus preventing the buffer leaks while increasing performance inside
transactions. Some (all?) 'classic' memory leaks are also removed.
I hope it will be ok.
--- Pascal ANDRE, graduated from Ecole Centrale Paris andre@via.ecp.fr
Making PQrequestCancel safe to call in a signal handler turned out to be
much easier than I feared. So here are the diffs.
Some notes:
* I modified the postmaster's packet "iodone" callback interface to allow
the callback routine to return a continue-or-drop-connection return
code; this was necessary to allow the connection to be closed after
receiving a Cancel, rather than proceeding to launch a new backend...
Being a neatnik, I also made the iodone proc have a typechecked
parameter list.
* I deleted all code I could find that had to do with OOB.
* I made some edits to ensure that all signals mentioned in the code
are referred to symbolically not by numbers ("SIGUSR2" not "2").
I think Bruce may have already done at least some of the same edits;
I hope that merging these patches is not too painful.
I have implemented a framework of encoding translation between the
backend and the frontend. Also I have added a new variable setting
command:
SET CLIENT_ENCODING TO 'encoding';
Other features include:
Latin1 support more 8 bit cleaness
See doc/README.mb for more details. Note that the pacthes are
against May 30 snapshot.
Tatsuo Ishii
have > 20000 users and each (potentially) needs a separate database
which is > only accessible to them. Rather than having 20000 lines
in pg_hba.conf, > I've patched Postgres so that the special token
"sameuser" in the > database field of pg_hba.conf allows access
only to the username which > is connecting.
Attached you'll find a (big) patch that fixes make dep and make
depend in all Makefiles where I found it to be appropriate.
It also removes the dependency in Makefile.global for NAMEDATALEN
and OIDNAMELEN by making backend/catalog/genbki.sh and bin/initdb/initdb.sh
a little smarter.
This no longer requires initdb.sh that is turned into initdb with
a sed script when installing Postgres, hence initdb.sh should be
renamed to initdb (after the patch has been applied :-) )
This patch is against the 6.3 sources, as it took a while to
complete.
Please review and apply,
Cheers,
Jeroen van Vianen
yyerror ones from bison. It also includes a few 'enhancements' to
the C programming style (which are, of course, personal).
The other patch removes the compilation of backend/lib/qsort.c, as
qsort() is a standard function in stdlib.h and can be used any
where else (and it is). It was only used in
backend/optimizer/geqo/geqo_pool.c, backend/optimizer/path/predmig.c,
and backend/storage/page/bufpage.c
> > Some or all of these changes might not be appropriate for v6.3,
since we > > are in beta testing and since they do not affect the
current functionality. > > For those cases, how about submitting
patches based on the final v6.3 > > release?
There's more to come. Please review these patches. I ran the
regression tests and they only failed where this was expected
(random, geo, etc).
Cheers,
Jeroen
a while back I posted a patch for pg_ident, the patch worked but I didn't
diagnose the problem properly.
on my compiler(gcc2.7.2) this compiles with no errors...
char buf[1000]; if(buf != '\0') {
...but it doesn't compare '\0' with the first char of buf.
6.3 postmaster is supposed to work with pre 6.3 protocol. This is true
for little endian architecture servers. But for big endian machines
such as Sparc the backward compatibility function do not work.
Attached are patches to fix the problem.
seems that my last post didn't make it through. That's good
since the diff itself didn't covered the renaming of
pg_user.h to pg_shadow.h and it's new content.
Here it's again. The complete regression test passwd with
only some float diffs. createuser and destroyuser work.
pg_shadow cannot be read by ordinary user.
What it does:
It solves stupid problem with cyrillic charsets IP-based on-fly recoding.
take a look at /data/charset.conf for details.
You can use any tables for any charset.
Tables are from Russian Apache project.
Tables in this patch contains also Ukrainian characters.
Then run ./configure --enable-recode
I haven't had final confirmation from Peter yet, but the attached patch
needs to be applied for the Beta otherwise password and crypt
authentication just won't work.
It puts back the loop in libpq and also fixes a couple of problems with
maintaining compatability with pre-6.3 drivers.
Attached is the patch to fix the warning messages from my code. I also
fixed one which wasn't my code. Apart from the usual warnings about the
bison/yacc generated code I only have one other warning message. This
is in gramm.y around line 2234. I wasn't sure of the fix.
I've also replaced all the calls to free() in gramm.y to calls to
pfree(). Without these I was getting backend crashes with GRANT. This
might already have been fixed.
I've completed the patch to fix the protocol and authentication issues I
was discussing a couple of weeks ago. The particular changes are:
- the protocol has a version number
- network byte order is used throughout
- the pg_hba.conf file is used to specify what method is used to
authenticate a frontend (either password, ident, trust, reject, krb4
or krb5)
- support for multiplexed backends is removed
- appropriate changes to man pages
- the -a switch to many programs to specify an authentication service
no longer has any effect
- the libpq.so version number has changed to 1.1
The new backend still supports the old protocol so old interfaces won't
break.
o A new patch that contains the following changes:
-- The pg_pwd file is now cached in the postmaster's memory.
-- pg_pwd is reloaded when the postmaster detects a flag file creat()'ed
by a backend.
-- qsort() is used to sort loaded password entries, and bsearch() is
is used to find entries in the pg_pwd cache.
-- backends now copy the pg_user relation to pg_pwd.pid, and then
rename the temp file to be pg_pwd.
-- The delimiter for pg_pwd has been changed to a tab character.
tree "non-PORTNAME" dependent. Technically, anything that is PORTNAME
dependent should be able to be derived at compile time, through configure
or through gcc
Subject: [PORTS] Patches for Irix 6.4
I have worked out how to compile PostgreSQL on Irix 6.4 using the -n32 compiler
mode and version 7.1 of the C compiler. (The n32 compiler use 32 bits
addressing,
but allows access to all the instructions in the MIPS4 instruction set.)
There were several problems:
1) The ld command is not referenced as a macro in all the Makefiles. On
this platform, you have to include -n32 on all the ld commands. Makefiles
were changed as needed.
3) Lots of warnings are generated from the compiler. Since the regression
tests worked OK, I didn't attempt to fix them. If anyone wants the compilation
log, please let me know, and I'll email it to you.
The version of postgresql was 970602. Here is Makefile.custom:
CUSTOM_COPT = -O2 -n32
MK_NO_LORDER = 1
LD = ld -n32
CC += -n32
Subject: [PATCHES] pqcomprim.c patch
This is the patch by Robert Bruccoleri to fix the endian problem.
(Actually, it's the reverse of his patch. He must have gotten the
order wrong.)
Subject: [PATCHES] 970417: some large object patches
Two patches here, made against 970417. Both have to do with large
objects:
1. lobjfuncs was not initialized in PQconnectdb. This causes
failure later if large objects are used. (Someone already
caught this error in PQsetdb.)
2. Postgres functions lo_import and lo_export sometimes
produce garbage for the file names because the filename
strings aren't always terminated by \0. (VARDATA isn't
necessarily null terminated.)
Subject: [PATCHES] 970417: two more patches for large objects
Here are two more patches:
1. pg_getint doesn't properly set the status flag when
calling pqGetShort or pqGetLong. This is required when
accessing large objects via libpq. This, combined with
problem 1 above causes postgres to crash when postgres
tries to print out the message that the status was not
good.
2. ExceptionalCondition crashes when called with detail =
NULL. This patch prevents dereferencing the NULL.
invalid macro definitions, the compiler complains about:
"pqcomprim.c", line 48.9: 1506-275 (S) Unexpected text ';' ignored.
"pqcomprim.c", line 61.9: 1506-275 (S) Unexpected text ';' ignored.
The ';' terminating the macro definition ntoh_s(n) on line 27 and
ntoh_l(n) on line 28 should be removed.
Pointed out by: Olaf Mittelstaedt <MSTAEDT@va-sigi.va.fh-ulm.de>
FreeBSD
The Makefile(s) have all been cleaned up such that there is a single
LDFLAGS vs LD_ADD or LDADD or LDFLAGS or LDFLAGS_BE. The Makefile(s)
should be alot more straightforward then they were before...and
consistent
of endian.h. I figure that if it exists it's pretty sure that it has
the byte order information and we may catch some other ports without
any further testing.
From: "D'Arcy J.M. Cain" <darcy@druid.net>
Subject: [HACKERS] libpq/pqcomm stuff and Solaris byte order
I decided to go ahead with the required changes since no one else seems
to. I don't guarantee that it is perfect but with these changes the
package actually compiles. While I was at it I added to the Sparc
Solaris header to define the byte order. Note that NetBSD sets this
in the system headers so it wasn't required there.
In particular, someone may want to check whether I removed the correct
84 lines from backend/libpq/pqcomprim.c.
Subject: [HACKERS] auth.c for kerberos.
I made pgsql with eBones(international version of Kerberos4). The
following modification was needed. And I added read permition for
group to srvtab instead of running postmaster as root.
of common routines in pqcomprim.c (pq communication primitives).
Not all adapted to it yet, but it's a start.
- Rewritten some of those routines, to write/read bigger chunks of
data, precomputing stuff in buffers instead of sending out byte
by byte.
- As a consequence, I need to know the endianness of the machine.
Currently I rely on getting it from machine/endian.h, but this
may not be available everywhere? (Who the hell thought it was
a good idea to pass integers to the backend the other way around
than the normal network byte order? *argl*)
- Libpq looks in the environment for magic variables, and upon
establishing a connection to the backend, sends it queries
of the form "SET var_name TO 'var_value'". This needs a change
in the backend parser (Mr. Parser, are you there? :)
- Currently it looks for two Env-Vars, namely PG_DATEFORMAT
and PG_FLOATFORMAT. What else makes sense? PG_TIMEFORMAT?
PG_TIMEZONE?
From: "Martin J. Laubach" <mjl@wwx.vip.at>
Subject: [HACKERS] password authentication
This patch adds support for plaintext password authentication. To use
it, you add a line like
host all 0.0.0.0 0.0.0.0 password pg_pwd.conf
to your pg_hba.conf, where 'pg_pwd.conf' is the name of a file containing
the usernames and password hashes in the format of the first two fields
of a Unix /etc/passwd file. (Of course, you can use a specific database
name or IP instead.)
Then, to connect with a password through libpq, you use the PQconnectdb()
function, specifying the "password=" tag in the connect string and also
adding the tag "authtype=password".
I also added a command-line switch '-u' to psql that tells it to prompt
for a username and password and use password authentication.
The following patch to src/backend/libpq/pqpacket.c provides additional
checking for bad packet length data. It was tested with the Linux telnet
client, with netcat using the numbers.txt and by dumping random numbers
into the port.
Patch by: Alvaro Martinez Echevarria <alvaro@lander.es>
another one in Solaris' port-protos.h.
The following patch will bring inet_aton's prototype into scope for
Ultrix to silence a compilation warning.
If the intention is to have inet_aton's prototype in its own header
filer, the declaration in Solaris' port-protos.h should be removed.
If the declaration in port-protos.h is deemed to be the correct
place, a declaration should be added in Ultrix' port-protos.h
regards
Erik Bertelsen
At least the first two should be fixed before the final release of 6.0.
1) There is a mismatch between the type declared in the catalog for
the input/output attributes of pg_type and the actual type of
values stored in the table. The type of typinput, typoutput,
typsend and typreceive are declared oid (26) while the values are
regproc (24). The error was there also in previous versions but
nobody noticed it until an Assert has been added in ExecEvalVar.
The effect is that it is now impossible to replace the typoutput
of existing data types with new procs.
2) The identd hba fails after the first time because the data read
from the identd socket is not zero-terminated and strlen reports
an incorrect length if the stack contains garbage, which usually
happens after the first connection has been made.
3) The new initdb wants to create itself the data directory. This
implies that the parent directory must be writable by postgres and
this may not always be desirable. A better solution would be to
allow the directory to be created by root and then filled by initdb.
It would also nice to have some reasonable default for PGLIB and
PGDATA like the previous version did. This applies also to the
postmaster executable.
In particular, no more compiled-in default for PGDATA or LIBDIR. Commands
that need them need either invocation options or environment variables.
PGPORT default is hardcoded as 5432, but overrideable with options or
environment variables.
Tom Lane
Bruce Momjian
Marc G. Fournier
Vadim B. Mikheev
Thomas G. Lockhart
Bryan Henderson