Re: [HACKERS] Recent vendor SSL renegotiation patches break PostgreSQL

2010-02-23 Thread Albe Laurenz
Tom Lane wrote: One way to deal with it would be to expose the whole renegotiation setting as a user configuratble option. So they can set *when* we renegotiate, which would also let them turn it off completely. >>> >>> Well, that might be a reasonable thing to do, because it's not

Re: [HACKERS] PG 9.0 and standard_conforming_strings

2010-02-02 Thread Albe Laurenz
Mark Mielke wrote: > On 01/29/2010 09:01 PM, Tom Lane wrote: > > Maybe. We concluded in the April 2009 thread that > > standard_conforming_strings = ON had gotten little or no field testing, > > and I don't see any strong reason to hope that it's gotten much more > > since then. > > Not to contra

Re: [HACKERS] true serializability and predicate locking

2010-01-07 Thread Albe Laurenz
Nicolas Barbier wrote: >> I don't know if such a thing would be easy to implement in >> PostgreSQL, but I had thought that the "standard" approach to >> implement predicate locking is like this: >> >> Whenever you touch (read) a data structure, you tag it with a lock >> that prevents anybody else f

Re: [HACKERS] true serializability and predicate locking

2010-01-07 Thread Albe Laurenz
Robert Haas wrote: > Jeff Davis wrote: > > I have a question regarding true serializability and predicate locking. > > There's some context on the wiki page: > > > > If you have the following DDL: > > > >  create table mytable(mycircle circle); > >  create index mytable_mycircle_idx on mytable > >

Re: [HACKERS] true serializability and predicate locking

2010-01-07 Thread Albe Laurenz
Kevin Grittner wrote: > Another interesting thing which crossed my mind (and I should > probably add a section for such things in the wiki) is that, given > the overhead and conflict implications of using table scans in > serializable transactions, we should perhaps try to discourage table > scans

Re: [HACKERS] Serializable Isolation without blocking

2010-01-01 Thread Albe Laurenz
Kevin Grittner wrote: >> It seems to me that the hard part of this problem is to describe >> the general mechanism by which conflicts will be detected, with >> specific references to the types of data structures that will be >> used to hold that information. > > Well, the general approach to tracki

Re: [HACKERS] A third lock method

2009-12-31 Thread Albe Laurenz
Bruce Momjian wrote: > I must be missing something but I thought the only problem with our > existing snapshot system was that you could see a row updated after your > snapshot was created, and that the solution to that was to abort the > transaction that would see the new row. Can you tell me wha

Re: [HACKERS] PATCH: Spurious "22" in hstore.sgml

2009-12-17 Thread Albe Laurenz
Magnus Hagander wrote: > On Wed, Dec 16, 2009 at 20:34, David E. Wheeler wrote: > > *** a/doc/src/sgml/hstore.sgml > > --- b/doc/src/sgml/hstore.sgml > > Heh, interesting. That clearly shouldn't be there. Applied. Does this count as catch-22? Yours, Laurenz Albe -- Sent via pgsql-hackers maili

Re: [HACKERS] Update on true serializable techniques in MVCC

2009-12-17 Thread Albe Laurenz
Robert Haas wrote: > > A predicate can include columns from an index plus others. > > Am I missing something? > > Hmm, interesting point. In that case you couldn't use the index to > enforce predicate locking under MVCC without disabling HOT. But there > will be other cases where that wouldn't h

Re: [HACKERS] Update on true serializable techniques in MVCC

2009-12-16 Thread Albe Laurenz
Nicolas Barbier wrote: >> Quote: [...] >> >> That sounds like it should actually work. > > That boils down to 2PL, using a granularity that is somewhere between > table locks and single-row locks (note that the latter doesn't > correctly enforce serializability, hence something more coarse which >

Re: [HACKERS] Update on true serializable techniques in MVCC

2009-12-16 Thread Albe Laurenz
Kevin Grittner wrote: > Just to make those who care aware of it, here is Michael Cahill's > Doctoral Thesis based on implementing Serializable Snapshot > Isolation in InnoDB using a refined version of the techniques > previously used in the Berkley DB (and previously discussed on this > list): >

Re: [HACKERS] Need a mentor, and a project.

2009-12-07 Thread Albe Laurenz
abindra wrote: > Next quarter I am planning to do an Independent Study course > where the main objective would be to allow me to get familiar > with the internals of Postgres by working on a project(s). I > would like to work on something that could possibly be > accepted as a patch. > > This

Re: [HACKERS] unknown libpq service entries ignored

2009-11-26 Thread Albe Laurenz
Peter Eisentraut wrote: > When using the "service" parameter in a libpq connection (e.g., psql > service=foo), and the service name is not defined in pg_service.conf, > then the setting is silently ignored and the connection proceeds with > whatever other settings and defaults apply. That does not

Re: [HACKERS] Rejecting weak passwords

2009-11-18 Thread Albe Laurenz
Tom Lane wrote: > Applied with some minor modifications. Aside from the added valuntil > parameter, I changed the "isencrypted" parameter to an int with some > #define'd values. It seems easily foreseeable that we'll replace the > MD5 encryption scheme someday, and it'd be good to ensure that thi

Re: [HACKERS] Rejecting weak passwords

2009-11-18 Thread Albe Laurenz
Itagaki Takahiro wrote: > Looks good. I change status of the patch to "Ready for Committer". Thanks for the help! > BTW, it might not be a work for this patch, we also need to > reject too long "VALID UNTIL" setting. If the password is > complex, we should not use the same password for a long tim

Re: [HACKERS] Rejecting weak passwords

2009-11-17 Thread Albe Laurenz
Heikki Linnakangas wrote: > I think it would better to add an explicit "isencrypted" parameter to > the check_password_hook function, rather than require the module to do > isMD5 on the password. Any imaginable check hook will need to know if > the password is in MD5 format, and the backend already

Re: [HACKERS] Rejecting weak passwords

2009-11-17 Thread Albe Laurenz
Itagaki Takahiro wrote: > I've reviewed your patch. The rough approach looks fine, > but I have some comments about function declarations and coding style. Thank you for taking the time! I think I addressed all the shortcomings you mentioned with the attached patches. I fixed the "{" alignment; I

Re: [HACKERS] TRIGGER with WHEN clause

2009-11-16 Thread Albe Laurenz
KaiGai Kohei wrote: > I'm uncertain how Oracle handles the condition on the statement > triggers. But it seems to me WHEN clause on the statement triggers > are nonsense. SQL> CREATE TRIGGER dummy BEFORE DELETE ON employees WHEN (1 = 1) 2 BEGIN 3 END; 4 / CREATE TRIGGER dummy BEFORE DELET

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

2009-11-11 Thread Albe Laurenz
Tom Lane wrote: >> The problem is that both _LARGE_FILES and _LARGE_FILE_API are #defined >> in this case, which makes #include fail. >> Does anyone have an idea how to best fix this problem in the >> source tree? I'm willing to implement and test. > > I've committed changes for this in CVS, plea

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

2009-11-10 Thread Albe Laurenz
I CC: this to the hackers list as it seems to be an old problem that was never fixed. See at the bottom. Alexandra Roy wrote: > This is a summary of what I have noticed concerning > PostgreSQL 8.3.8 compilation on AIX 5.3 TL9. > > 1. To do a successful 64-bit build, specify and execute: > > >

Re: [HACKERS] backup_label in a crash recovery

2009-11-03 Thread Albe Laurenz
Tom Lane wrote: > > I wonder why backup_label isn't automatically removed > > in normal crash recovery case. > > Removing it automatically could be catastrophic if done > incorrectly, no? > > It would be no less catastrophic if done incorrectly from outside the > postmaster; see for example the

Re: [HACKERS] backup_label in a crash recovery

2009-11-02 Thread Albe Laurenz
Fujii Masao wrote: > When a crash occurs before calling pg_stop_backup(), > the subsequent crash recovery causes the FATAL error > and outputs the following HINT message. > > If you are not restoring from a backup, try removing the file > \"%s/backup_label\"." > > I wonder why backup_label is

Re: [HACKERS] Rejecting weak passwords

2009-10-19 Thread Albe Laurenz
Peter Eisentraut wrote: >> I don't get why you need 'password' authentication for that. >> The point where the password should be checked is not when >> the user uses it to logon, but when he or she changes it. >> >> So in my opinion that should be: >> This facility will require to send new and ch

Re: [HACKERS] Rejecting weak passwords

2009-10-19 Thread Albe Laurenz
Bruce Momjian wrote: > Great, added to TODO: > > Allow server-side enforcement of password policies > > Password checks might include password complexity or non-reuse of > passwords. This facility will require the client to send the password to > the server in pl

Re: [HACKERS] Rejecting weak passwords

2009-10-15 Thread Albe Laurenz
Mark Mielke wrote: > Does Oracle really do password checks on the base SQL commands used to > change an Oracle password? That sounds silly. In Oracle you can write a stored procedure to check passwords; it is invoked whenever a user is created or altered. No matter how you change the password, O

Re: [HACKERS] Rejecting weak passwords

2009-10-11 Thread Albe Laurenz
I wrote: > Following the discussions in > http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php > and > http://archives.postgresql.org/pgsql-hackers/2009-10/msg00025.php , > here are patches for > > a) a hook in backend/commands/user.c that allows one to add >password checking func

Re: [HACKERS] Rejecting weak passwords

2009-10-09 Thread Albe Laurenz
Following the discussions in http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php and http://archives.postgresql.org/pgsql-hackers/2009-10/msg00025.php , here are patches for a) a hook in backend/commands/user.c that allows one to add password checking functions b) a contrib module

Re: [HACKERS] Rejecting weak passwords

2009-10-03 Thread Albe Laurenz
Bruce Momjian wrote: >Tom Lane wrote: >> > That said, it would still be good to have something actually *useful* >> > in contrib. A bit more than just comparing userid and password. >> > Perhaps at least being able to set the min length, and the requirement >> > on having >1 "character class"? >> >

Re: [HACKERS] Rejecting weak passwords

2009-10-01 Thread Albe Laurenz
Aidan Van Dyk wrote: > Can we have the check password hook function called in both the > plaintext/encrypted case, with a flag as to whether it's encrypted or > not? It will be called in both cases, and I figured that you can check yourself the same way that PostgreSQL does: If isMD5(password), th

Re: [HACKERS] Rejecting weak passwords

2009-10-01 Thread Albe Laurenz
Andrew Dunstan wrote: >>> So here's the patch. >>> I don't think there is documentation required; >>> correct me if I am wrong. >> >> How will people know how to use it, or that it's even there without at >> least a note in the docs somewhere? > > I'd prefer to have an example as a contrib module,

Re: [HACKERS] Rejecting weak passwords

2009-10-01 Thread Albe Laurenz
In the discussion following http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php the consensus was that a hook that allows you to implement a password checking routine as a module "would not hurt". So here's the patch. I don't think there is documentation required; correct me if I am

Re: [HACKERS] Rejecting weak passwords

2009-09-28 Thread Albe Laurenz
Tom Lane wrote: > > pgAdmin MD5's the passwords if you use the GUI to change them, or when > > add a user. It doesn't make any attempt to parse the SQL if you enter > > it yourself in the query tool though (nor is it going to). > > No, I wouldn't expect it to go that far. My point is just that >

Re: [HACKERS] Rejecting weak passwords

2009-09-28 Thread Albe Laurenz
Tom Lane wrote: > Actually there's a much bigger problem with asking the backend to reject > weak passwords: what ya gonna do with a pre-MD5'd string? Which is > exactly what the backend is going to always get, in a security-conscious > environment. You mean if the password is set with CREATE/ALT

[HACKERS] Rejecting weak passwords

2009-09-28 Thread Albe Laurenz
Dear hackers, I have been thinking about ways to have PostgreSQL reject weak passwords. I think the standard recommendation is "use PAM and LDAP", but that requires the user to change the password outside of PostgreSQL. And who would want to setup and maintain an LDAP server just for this? Since

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

2009-09-17 Thread Albe Laurenz
Tom Lane wrote: > > I don't see any reason why not breaking the user visible behavior of > > tuples CTID between any two major releases, > > > Am I completely wet here? > > Completely. This is a user-visible behavior that we have encouraged > people to rely on, and for which there is no easy sub

Re: [HACKERS] PQgetlength vs. octet_length()

2009-08-19 Thread Albe Laurenz
Greg Stark wrote: > If you use binary encoding then you don't have to deal with that. > Though I seem to recall there is still a gotcha you have to worry > about if there are nul bytes in your datum. I don't recall exactly > what that meant you had to do though. As far as I know, it only means tha

Re: [HACKERS] Split-up ECPG patches

2009-08-09 Thread Albe Laurenz
Tom Lane wrote: >>> So I'd like to see an actual case made >>> that there's a strong reason for not requiring FROM/IN in ecpg. >> >> I guess there's only one, compatibility. > > Yeah. Are there any other precompilers that actively reject FROM/IN > here? If we're just a bit more strict than the

Re: [HACKERS] RFD: Don't force plpgsql IN parameters to constant

2009-07-30 Thread Albe Laurenz
Tom Lane wrote: >>> Is there a reason we force plpgsql IN parameters to constant? > > Now having said all that, I'm not really in favor of Steve's > proposal --- it seems like it mostly would be encouraging dubious > programming practices. But it's hard to say that the arguments > against are mor

Re: [HACKERS] Maintenance Policy?

2009-07-13 Thread Albe Laurenz
Tom Lane wrote: >> I'd suggest that we publish an official policy, with the following dates >> for "EOL": > > But on the whole I think we should NOT have such a policy, at all. [...] > If someone wants a guaranteed EOL date, they ought to be contracting > with a commercial support company and pay

Re: [HACKERS] 8.3 PLpgSQL Can't Compare Records?

2009-07-07 Thread Albe Laurenz
David E. Wheeler wrote: > This code: > > CREATE OR REPLACE FUNCTION foo() returns boolean as $$ > DECLARE > have_rec record; > want_rec record; > BEGIN > have_rec := row(1, 2); > want_rec := row(3, 5); > RETURN have_rec IS DISTINCT FROM w

Re: [HACKERS] Problem with listen_addresses = '*' on 8.4beta2 on AIX

2009-06-12 Thread Albe Laurenz
Tom Lane wrote: > The code change is already made for RC1, but if you want to send in a > patch to improve the docs, feel free. I left it with just a vague > recommendation to update to the latest fixpack: > http://developer.postgresql.org/pgdocs/postgres/installation-platform-notes.html#INSTALLAT

Re: [HACKERS] Problem with listen_addresses = '*' on 8.4beta2 on AIX

2009-06-12 Thread Albe Laurenz
Tom Lane wrote: >> On Thu, Jun 11, 2009 at 9:50 AM, Tom Lane wrote: >>> Where are we on this? > >> waiting on a patch? Albe? (or should I do it myself?) > > I thought the proposed patch was just "remove the special case for AIX > in src/backend/libpq/ip.c". Yes. The only bugs at IBM that are l

Re: [HACKERS] Problem with listen_addresses = '*' on 8.4beta2 on AIX

2009-06-10 Thread Albe Laurenz
Merlin Moncure wrote: > I wrote: >> I can try, but I only have AIX 5.3 to test with, so I won't be able >> to test for bugs in other versions. >> >> I would need to know what the problems with getaddrinfo on AIX are. >> >> I'll also try to investigate known bugs in AIX' getaddrinfo. >> >> AIX 4.3 h

Re: [HACKERS] Problem with listen_addresses = '*' on 8.4beta2 on AIX

2009-06-10 Thread Albe Laurenz
Tom Lane wrote: > Drat. Okay, that easy solution probably won't fly. Anyone with AIX > access want to try to develop a patch that covers this case without > breaking the other ones? I can try, but I only have AIX 5.3 to test with, so I won't be able to test for bugs in other versions. I would n

[HACKERS] Problem with listen_addresses = '*' on 8.4beta2 on AIX

2009-06-09 Thread Albe Laurenz
Building 8.4beta2 on my AIX test machine works fine, but when I set listen_addresses = '*' in postgresql.conf, the server fails to start. This is what I get: LOG: 0: could not translate service "5432" to address: Hostname and service name not provided or found LOCATION: StreamServerPort, p

Re: [HACKERS] User-facing aspects of serializable transactions

2009-05-28 Thread Albe Laurenz
Kevin Grittner wrote: >> 1. implementation of the paper's technique sans predicate locking, >> that would avoid more serialization anomalies but not all? > > I saw that as a step along the way to support for fully serializable > transactions. If covered by a "migration path" GUC which defaulted

Re: [HACKERS] Serializable Isolation without blocking

2009-05-11 Thread Albe Laurenz
Kevin Grittner wrote: > > All the authors show with regard to predicate handling is > > handwaving, > > That is because predicate locking is a mature technology with many > known implementations. The best technique for any database product > will depend on that product, and their technique doesn

Re: [HACKERS] Serializable Isolation without blocking

2009-05-11 Thread Albe Laurenz
Kevin Grittner wrote: > > I still haven't actually read the paper so I should probably bow out > > from the conversation until I do. I was apparently already under > > one misapprehension as Laurenz just claimed the paper does not show > > how to prevent "phantoms" (phantom reads I assume?). Perha

Re: [HACKERS] Serializable Isolation without blocking

2009-05-07 Thread Albe Laurenz
Kevin Grittner wrote: > > What if there is an index on the "ishighlander" row? > > Then an index scan would find only one candidate to examine, > > and the other rows would not even be touched by the execution plan. > > I assume you're talking about this line of your function: > > SELECT coun

Re: [HACKERS] Serializable Isolation without blocking

2009-05-07 Thread Albe Laurenz
Kevin Grittner wrote: > > Where does T1 select rows that were modified by T0? It selects only > > one row, the one it modified itself, right? > > You have to select it to know whether to count it, right? We are getting closer. So an SIREAD lock is taken for every row that is examined during the

Re: [HACKERS] Serializable Isolation without blocking

2009-05-07 Thread Albe Laurenz
Kevin Grittner wrote: > > maybe I misunderstood something. > > > > Consider a function > > "makehighlander(personid integer) RETURNS void" > > defined like this: > > > >SELECT ishighlander INTO b FROM scots WHERE id=personid; > >IF b THEN > > RETURN; /* no need to do anything */ > >

Re: [HACKERS] Serializable Isolation without blocking

2009-05-07 Thread Albe Laurenz
Greg Stark wrote: > > So I think one would have to add intention locks for rows considered > > in the WHERE clause to guarantee true serializability. > > Does the paper explain how to deal with rows "considered" in the WHERE clause > which don't yet exist? Ie, "SELECT count(*) WHERE foo" needs to

Re: [HACKERS] Serializable Isolation without blocking

2009-05-07 Thread Albe Laurenz
Kevin Grittner wrote: > While discussing potential changes to PostgreSQL documentation of > transaction isolation levels, Emmanuel Cecchet pointed out an > intriguing new paper[1] on a new algorithm to provide true > serializable behavior in a MVCC based database, with no additional > blocking; alt

Re: [HACKERS] Problem with accesing Oracle from plperlu functionwhen using remote pg client.

2009-03-17 Thread Albe Laurenz
Tom Lane wrote: > > The solution to this is to change the following line in > > src/backend/postmaster/postmaster.c: > > We're not going to break a bunch of other applications in order to make > some undocumented, unsupported Oracle thingie work (until they change > it...). Got another solution?

Re: [HACKERS] problem with archive_command as suggested by documentation

2009-01-26 Thread Albe Laurenz
Peter Eisentraut wrote: >> I don't think that particular example is a good one since the whole >> point of the archive is that it should be off-server. If we're going to >> be exact about the example then we should give a more realistic one, >> like using scp. Unfortunately, there is no secure-remo

Re: [HACKERS] problem with archive_command as suggested by documentation

2009-01-22 Thread Albe Laurenz
Heikki Linnakangas wrote: > > The documentation states > > > > "The archive command should generally be designed to refuse to overwrite > > any pre-existing archive file." > > > > and suggests an archive_command like "test ! -f .../%f && cp %p .../%f". > > > > We ran into (small) problems with

[HACKERS] problem with archive_command as suggested by documentation

2009-01-22 Thread Albe Laurenz
The documentation states in http://www.postgresql.org/docs/current/static/continuous-archiving.html#BACKUP-ARCHIVING-WAL "The archive command should generally be designed to refuse to overwrite any pre-existing archive file." and suggests an archive_command like "test ! -f .../%f && cp %p .../%f

Re: [HACKERS] a small proposal for avoiding foot-shooting

2008-12-22 Thread Albe Laurenz
Tom Lane wrote: >> I propose that this behaviour be changed such that 'terse' is ignored >> for all log messages of FATAL or PANIC severity. >> [ on the strength of a single example ] > [...] > > It seems like it might be better to rephrase error messages to ensure > that anything really critical

Re: [HACKERS] Block-level CRC checks

2008-10-01 Thread Albe Laurenz
Jonah H. Harris wrote: I'd like to submit this for 8.4, but I want to ensure that -hackers at large approve of this feature before starting serious coding. >>> >>> IMHO, this is a functionality that should be enabled by default (as it >>> is on most other RDBMS). It would've prevented se

Re: [HACKERS] [PATCHES] Improve shutdown during online backup

2008-04-08 Thread Albe Laurenz
[what should happen if a smart shutdown request is received during online backup mode? I'll cc: the hackers list, maybe others have something to say to this] Heikki Linnakangas wrote: > Albe Laurenz wrote: >> Moreover, if Shutdown == SmartShutdown, new connections won't

Re: [HACKERS] Proposal: improve shutdown during online backup

2008-03-27 Thread Albe Laurenz
Greg Smith wrote: > > 1) On "pg_ctl stop|restart -m smart", check if online backup is > > in progress and do not shutdown in this case (treat the online > > backup like an open connection). > > As long as you give a warning as to the cause. While you're in there, I > think more output in gen

[HACKERS] Proposal: improve shutdown during online backup

2008-03-26 Thread Albe Laurenz
I'm referring to the discussion in this thread: http://archives.postgresql.org/pgsql-hackers/2007-11/msg00946.php As expressed in the thread, I think that there should not be a backup_label file in the data directory after a clean shutdown, because a) it's probably an oversight anyway (someone for

Re: [HACKERS] Proposal: wildcards in pg_service.conf

2008-02-28 Thread Albe Laurenz
Tom Lane wrote: >> I'd like to extend the libpq service file by allowing >> wildcards, e.g. like this: > >> [%] >> host=dbhost.mycompany.com >> dbname=% > >> Such an entry would match all service parameters, >> and all ocurrences of the wildcard right of a = would >> be replaced with the service

[HACKERS] Proposal: wildcards in pg_service.conf

2008-02-27 Thread Albe Laurenz
I'd like to extend the libpq service file by allowing wildcards, e.g. like this: [%] host=dbhost.mycompany.com dbname=% Such an entry would match all service parameters, and all ocurrences of the wildcard right of a = would be replaced with the service parameter. That implies that a [%] entry is

Re: [HACKERS] Table rewrites vs. pending AFTER triggers

2008-01-03 Thread Albe Laurenz
Gokulakannan Somasundaram wrote: > Can you please explain, any specific use-case where DDLs are > necessary within a transaction? SQL-Scripts that create database objects and should either succeed or have no effect. Yours, Laurenz Albe ---(end of broadcast)-

Re: [HACKERS] backup_label and server start

2007-11-21 Thread Albe Laurenz
Simon Riggs wrote: > On Wed, 2007-11-21 at 09:47 +, Peter Childs wrote: >> How about this, emit a warning on shutdown and fail to shutdown until >> the backup has finished. > > That would be reasonable for -m smart shutdown. > > We would then be treating the backup as a connection. > > ...bu

Re: [HACKERS] backup_label and server start

2007-11-21 Thread Albe Laurenz
Simon Riggs wrote: > That will make PITRs fail: > > 1. pg_start_backup() > 2. backup > 3. shutdown, removes backup_label > 4. pg_stop_backup() > > step 4 will now fail because of a missing backup_label file. Wait a minute: pg_stop_backup() will also fail in the current setup, because after reco

Re: [HACKERS] backup_label and server start

2007-11-21 Thread Albe Laurenz
Simon Riggs wrote: >> If somebody stops the postmaster while an online backup is >> in progress, there is no warning or nothing. Only the server >> will fail to restart. > > Well, it seems best not to do this. There is always a need > for a careful > procedure to manually shutdown a live server, i

Re: [HACKERS] backup_label and server start

2007-11-21 Thread Albe Laurenz
>> If the postmaster is stopped with 'pg_ctl stop' while an >> online backup is in progress, the 'backup_label' file will remain >> in the data directory. [...] >> the startup process will fail with a message like this: [...] >> PANIC: could not locate required checkpoint record >> HINT: If you a

[HACKERS] backup_label and server start

2007-11-20 Thread Albe Laurenz
If the postmaster is stopped with 'pg_ctl stop' while an online backup is in progress, the 'backup_label' file will remain in the data directory. There is no recovery.conf file present. When the server is started again, it attempts to recover from the checkpoint marked in the backup_label file ev

Re: [HACKERS] invalidly encoded strings

2007-09-11 Thread Albe Laurenz
Andrew Dunstan wrote: >> Instead of the code point, I'd prefer the actual encoding of >> the character as argument to chr() and return value of ascii(). > > And frankly, I don't know how to do it sanely anyway. A character > encoding has a fixed byte pattern, but a given byte pattern > doesn't h

Re: [HACKERS] invalidly encoded strings

2007-09-10 Thread Albe Laurenz
Tom Lane wrote: >> . for chr() under UTF8, it seems to be generally agreed >> that the argument should represent the codepoint and the >> function should return the correspondingly encoded character. >> If so, possible the argument should be a bigint to >> accommodate the full range of possible cod

Re: [HACKERS] [GENERAL] Undetected corruption of table files

2007-08-31 Thread Albe Laurenz
Jan Wieck wrote: > Computing a checksum just before writing the block will NOT detect any > faulty memory or Postgres bug that corrupted the block. You will have a > perfectly fine checksum over the corrupted data. > > A checksum only detects corruptions that happen between write and read. > Mo

Re: [HACKERS] [GENERAL] LDAP service lookup

2007-08-28 Thread Albe Laurenz
Dawid Kuroczko wrote: > [...] and it also would be valuable to > add into pg_service.conf.sample an example ldap:// stanza, so if > person opens the file, she will be enlightened. I like that idea. > And a missing feature. Or rather treat it as feature request. :-) > A "wildcard entry". I would

Re: [HACKERS] [GENERAL] Undetected corruption of table files

2007-08-28 Thread Albe Laurenz
Tom Lane wrote: Would it be an option to have a checksum somewhere in each data block that is verified upon read? > >>> That's been proposed before and rejected before. See the >>> archives ... > > I think > the prior discussions were around the same time WAL was initially put > in, a

Re: [HACKERS] [GENERAL] LDAP service lookup

2007-08-27 Thread Albe Laurenz
Dawid Kuroczko wrote: >>> Then again, apart from libpq I don't see it mentioned anywhere. [...] > Looking at the 8.3devel documentation... > > I think it should be mentioned in 18. Server Configuration. probably > somewhere in 18.3 Connections and Authentication, that there is > a possibility of u

Re: [HACKERS] [GENERAL] Undetected corruption of table files

2007-08-27 Thread Albe Laurenz
Tom Lane wrote: >> Would it be an option to have a checksum somewhere in each >> data block that is verified upon read? > > That's been proposed before and rejected before. See the archives ... I searched for "checksum" and couldn't find it. Could someone give me a pointer? I'm not talking about

Re: [HACKERS] Tsearch vs Snowball, or what's a source file?

2007-06-15 Thread Albe Laurenz
Tom Lane wrote: > Teodor Sigaev <[EMAIL PROTECTED]> writes: >> So, it's needed to change dictinitoption format of snowball dictionaries to >> point both stop-word file and language's name. > > Right. Is there any chance to get support for other languages than English and Russian into the tsearch

Re: [HACKERS] Getting parse Error at or near character "and"

2007-05-02 Thread Albe Laurenz
> Expecting a Quick response. Don't hold your breath. Please post questions like this to the JDBC and/or the 'general' mailing list. Yours, Laurenz Albe ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-04-06 Thread Albe Laurenz
Martijn van Oosterhout wrote: > So your implemntation is simply: > 1. Take number and make UTF-8 string > 2. Convert it to database encoding. Aah, now I can spot where the misunderstanding is. That's not what I mean. I mean that chr() should simply 'typecast' to "char". So when the database enco

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-04-05 Thread Albe Laurenz
Tatsuo Ishii wrote: > I think we need to continute design discussion, probably > targetting for 8.4, not 8.3. But isn't a simple fix for chr() and ascii(), which does not require a redesign, a Good Thing for 8.3 if possible? Something that maintains as much upward and/or Oracle compatibility as po

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-04-04 Thread Albe Laurenz
> When the database uses a single byte encoding, the chr function takes > the binary byte representation as an integer number between 0 and 255 > (e.g. ascii code). > When the database encoding is one of the unicode encodings it takes a > unicode code point. > This is also what Oracle does. Sorry,

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-04-04 Thread Albe Laurenz
me as > CHR(X USING NCHAR_CS). > > On http://www.oraclehome.co.uk/chr-function.htm it says that "To use > UTF8, you specify using nchar_cs in the argument list". Does this mean > that CHR(X) behaves as Tom Lane wants, and NCHR(X) behaves as Albe > Laurenz wants? Vice versa?

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-04-03 Thread Albe Laurenz
Andrew wrote: >> According to RFC 2279, the Euro, >> Unicode code point 0x20AC = 0010 1010 1100, >> will be encoded to 1110 0010 1000 0010 1010 1100 = 0xE282AC. >> >> IMHO this is the only good and intuitive way for CHR() and ASCII(). > > It is beyond ludicrous for functions like chr() or asc

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-04-03 Thread Albe Laurenz
Mark Dilger wrote: >>> In particular, in UTF8 land I'd have expected the argument of chr() >>> to be interpreted as a Unicode code point, not as actual UTF8 bytes >>> with a randomly-chosen endianness. >>> >>> Not sure what to do in other multibyte encodings. >> >> "Not sure what to do in other mu

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-03-16 Thread Albe Laurenz
Mario Weilguni wrote: > Is there anything I can do to help with this problem? Maybe implementing a new > GUC variable that turns off accepting wrong encoded sequences (so DBAs still > can turn it on if they really depend on it)? I think that this should be done away with unconditionally. Or does

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-03-13 Thread Albe Laurenz
Mario Weilguni wrote: >>> Steps to reproduce: >>> create database testdb with encoding='UTF8'; >>> \c testdb >>> create table test(x text); >>> insert into test values ('\244'); ==> Is akzepted, even if not UTF8. >> >> This is working as expected, see the remark in >> >> http://www.postgresql.org/

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-03-13 Thread Albe Laurenz
Mario Weilguni wrote: > Steps to reproduce: > create database testdb with encoding='UTF8'; > \c testdb > create table test(x text); > insert into test values ('\244'); ==> Is akzepted, even if not UTF8. This is working as expected, see the remark in http://www.postgresql.org/docs/current/static/s

Re: [HACKERS] Simple Column reordering

2007-02-23 Thread Albe Laurenz
Simon Riggs wrote: >>> I propose that at CREATE TABLE time, the column ordering is re-ordered >>> so that the table columns are packed more efficiently. This would be a >>> physical re-ordering, so that SELECT * and COPY without explicit column >>> definitions would differ from the original CREATE

Re: [HACKERS] to_char not IMMUTABLE?

2007-01-12 Thread Albe Laurenz
Mario Weilguni wrote: > > I had a problem when upgrading a database from 8.1.4 to 8.2.1: > Sorry, the error messages are in german. > > pg_restore: [archiver (db)] Error while PROCESSING TOC: > pg_restore: [archiver (db)] Error from TOC entry 1531; 1259 > 3477393 INDEX idx_inspektionen_dat_inspe

Re: [HACKERS] security definer default for some PL languages (SQL/PSM)?

2007-01-08 Thread Albe Laurenz
Peter Eisentraut wrote: >> SQL/PSM default for SQL procedures are SECURITY DEFINER (like views), > > I can't find this in the standard. Where did you get this > information? I only have a draft version of SQL:2003, which says in the 'Foundation' book, chapter 11.50 (""), about the "" (which can

Re: [HACKERS] unixware and --with-ldap

2006-12-18 Thread Albe Laurenz
>>> I have tried --with-thread-safety and configure fails on ldap check >>> because for some reason CTHREAD_FLAGS (-Kpthread for UW) is missing >>> on compile command, although present before that. I can't find why >> >> You mean PTHREAD_FLAGS, right? >> > Nope,I mean PTHREAD_CFLAGS witch is define

Re: [HACKERS] unixware and --with-ldap

2006-12-18 Thread Albe Laurenz
>>> If libldap_r.so does require the same libs, please add $EXTRA_LDAP_LIBS >>> to the 'LDAP_LIBS_FE="-lldap_r"' line as well. >> >> Actually, I did that in the patch-as-committed. It seems to me that >> it's probably harmless even if not needed. > > I have tried --with-thread-safety and configure

Re: [HACKERS] unixware and --with-ldap

2006-12-15 Thread Albe Laurenz
Martijn van Oosterhout wrote: >> I guess that adding $EXTRA_LDAP_LIBS to -lldap_r will be enough, >> judging from the evidence on Linux. > > Linux doesn't need the extra libraries, it's linked properly. Yes - what I mean is, libldap_r.so references only NEEDED libsasl.so.7 NEEDED li

Re: [HACKERS] unixware and --with-ldap

2006-12-15 Thread Albe Laurenz
Olivier PRENANT wrote: >> You left out the case where --enable_thread_safety is specified. >> In that case, the frontend has to be linked with libldap_r.so >> instead of libldap.so. > > Yes, this was on purpose, my goal is to try to make a second > patch when... > >> Does libldap_r.so _not_ requi

Re: [HACKERS] Security leak with trigger functions?

2006-12-15 Thread Albe Laurenz
Peter Eisentraut wrote: > Tom Lane wrote: >> Peter Eisentraut <[EMAIL PROTECTED]> writes: >>> Tom Lane wrote: The question in my mind is what privilege to check and when. >>> >>> By extrapolation of the SQL standard, I'd say we'd need to check >>> the EXECUTE privilege of the function at run t

Re: [HACKERS] unixware and --with-ldap

2006-12-15 Thread Albe Laurenz
> Here's the diff for configure.in that works for me. I have a concern about this patch: > if test "$enable_thread_safety" = yes; then > # on some platforms ldap_r fails to link without PTHREAD_LIBS > AC_CHECK_LIB(ldap_r, ldap_simple_bind, [], > [AC_MSG_ERRO

[HACKERS] Security leak with trigger functions?

2006-12-14 Thread Albe Laurenz
Permissions on a trigger function seem not to be checked, and I can execute a function for which I have no privileges. I consider this a security leak - or am I missing something? Here is a complete example: As superuser, create a trigger function that selects from pg_authid with SECURITY INVOKE

Re: [HACKERS] unixware and --with-ldap

2006-12-13 Thread Albe Laurenz
Olivier PRENANT wrote: >>> When I swithed to the newest version og pgbuildfarm, I noticed that >>> --with-ldap (now by defaut) didn't work on UnixWare. >>> >>> This is because, on Unixware, ldap needs lber and resolv. >> >> Or was libldap not linked against liblber and libresolv? > > Dunno! > Did'n

Re: [HACKERS] psql commandline conninfo

2006-12-12 Thread Albe Laurenz
Tom Lane wrote: >> We change libpq from time to time. Besides, how many DBs are there that >> match the name pattern /^conn:.*=/ ? My guess is mighty few. So I don't >> expect lots of surprise. > > Um, but how many DB names have an "=" in them at all? > > Basically what this proposal is about is

<    1   2   3   4   5   >