> 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.
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
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
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
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
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
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
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
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
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
>> 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
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
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
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
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)-
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
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):
>
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
>
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
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
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
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
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
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
> >
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
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
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
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
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
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
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
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
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
>
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
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,
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
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"?
>>
>
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
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
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
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
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
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
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
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:
>
>
>
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
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
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
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
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
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
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
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
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
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
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
[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
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
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?
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
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
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 */
> >
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Tom Lane wrote:
> I checked around with some kernel/glibc gurus in Red Hat, and the
> consensus seemed to be that we'd be better off to bypass fprintf() and
> just send message strings to stderr using write() --- ie, instead of
> elog.c doing
>
> fprintf(stderr, "%s", buf.data);
>
> d
Mario Weilguni wrote:
>> This has been been discussed before, but Oracle behaves differently,
and
>> IMHO in a more correct way.
>>
>> The following query returns NULL in PG:
>> SELECT NULL || 'fisk';
>>
>> But in Oracle, it returns 'fisk':
>> SELECT NULL || 'fisk' FROM DUAL;
>>
>> The latter seems
> [ Memo to hackers: why is it that log_min_error_statement = error
> isn't the default? ]
To avoid spamming the logs with every failed SQL statement?
Yours,
Laurenz Albe
---(end of broadcast)---
TIP 4: Have you searched our list archives?
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.
Is libldap a static library on that system?
Or do shared libraries on Unixware gener
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
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
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
> 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
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
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
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
>>> 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
>>> 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
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
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
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
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
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/
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
> Real time databases needs some other kinds of semantics and
> features that postgres don't have.
>
> Postgres don't supports real time constrains semantics in
> transactions. In other hands the concurrent transactions
> don't wok well based on priorities of task.
>
> The program scheduler o
Peter Eisentraut wrote:
> So assuming we allowed units in postgresql.conf, how would you report
> them with SHOW?
>
> 1. The way they were set (hard)
>
> 2. Without units (not user-friendly)
>
> 3. Always in base units (seconds or bytes)
>
> 4. The largest unit that gives an integer
>
> (4) s
Tom Lane wrote:
>> The point is until that last WAL file is backed up, the whole backup
is
>> useless. It isn't good policy to have a backup's value be contingent
on
>> some future event.
>
> You are assuming here that the continuous archiving process is
identical
> to the WAL part of the base-bac
Simon Riggs wrote:
> Patch included to implement xlog switching, using an xlog record
> "processing instruction" and forcibly moving xlog pointers.
>
> 1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL switch any more?
Lau
301 - 400 of 459 matches
Mail list logo