Re: [HACKERS] Defaulting psql to ON_ERROR_ROLLBACK=interactive
On 15.03.2017 16:38, Robert Haas wrote:
On Wed, Mar 15, 2017 at 2:29 AM, Peter van Hardenberg <p...@pvh.ca> wrote:
Ads and I were talking over breakfast about usability issues and he
mentioned transaction cancellation during interactive sessions as a serious
pain point.
I suggest we update the default of ON_ERROR_ROLLBACK to interactive for
10.0.
The last discussion I could find about this subject was in 2011 and while
there was concern about setting the default to "on" (as this would tamper
with the expected behaviour of scripts), I don't see any identification of a
problem that would be caused by setting it to "interactive" by default.
Well, then you'd get one behavior when you use psql interactively, and
another behavior when you use it from a script. And if you used a
client other than psql the behavior would be different from psql.
Plus, it's kinda surprising to have a client that, by default, is
sending secret commands to the server that you don't know about. And
it's a backward-incompatible change against previous releases. I
don't think any of that makes this the worst idea ever, but on balance
I still think it's better to just recommend to people that they
configure their .psqlrc with this setting if they want the behavior.
I'm not entirely convinced that psql should behave the same way no
matter how it is started.
Usually I put a \set ON_ERROR_STOP on the top of my scripts - something
I never do in interactive mode, just too lazy for that. Behaviour is
just different if I use psql in script mode.
Also if you paste something, you are still using it interactive - you
could as well just \i the script file.
However I agree that should be something which is announced, and maybe
changed a release later.
After further discussion, Peter will propose another solution soon.
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] to_date_valid()
On 08.09.2016 17:31, Peter Eisentraut wrote:
On 8/15/16 7:33 AM, Andreas 'ads' Scherbaum wrote:
postgres=# SELECT to_date('2011 12 18', ' MM DD');
to_date
2011-12-08
(1 row)
That is from the regression tests, and obviously handles the date
transformation wrong. My attempt catches this, because I compare the
date with the input date, and do not rely on a valid date only.
It's debatable what is correct here.
Using to_number, the behavior appears to be that a space in the pattern
ignores one character. For example:
test=# select to_number('123 456', '999 999');
to_number
---
123456
test=# select to_number('123 456', '999 999');
to_number
---
12356
Considering that, the above to_date result is not incorrect.
So just squashing the spaces and converting the value back is not a
correct approach to detecting overflow.
I think using ValidateDate() was the right idea. That is what we use
for checking date validity everywhere else.
ValidateDate() will tell you if it's a valid date. But not if the
transformation was correct:
postgres=# SELECT to_date('2011 12 18', ' MM DD');
to_date
2011-12-08
(1 row)
(with the patch from Artur)
Any idea how to solve this problem?
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] to_date_valid()
On 15.08.2016 13:44, Artur Zakirov wrote:
On 15.08.2016 14:33, Andreas 'ads' Scherbaum wrote:
Is it right and "true" way to validate date by extra transforming and
comparison?
Maybe validate date by using ValidateDate(). Attached sample patch.
This does not solve the problem at hand, and let's wrong dates/formats
slip through:
./buildclient.py -v -c demo-config-pg.yaml --run-configure --run-make
--run-install --no-clean-at-all --patch
'https://www.postgresql.org/message-id/95738e12-6ed6-daf5-9dcf-6336072e6b15%40postgrespro.ru'
postgres=# SELECT to_date('2011 12 18', ' MM DD');
to_date
2011-12-08
(1 row)
That is from the regression tests, and obviously handles the date
transformation wrong. My attempt catches this, because I compare the
date with the input date, and do not rely on a valid date only.
I suppose that your sample query is an another issue, not date validate
task. I sent the patch to the thread
https://www.postgresql.org/message-id/b2a39359-3282-b402-f4a3-057aae500...@postgrespro.ru
. It fixes formatting issues.
I thought that it is better to distinguish this issues to:
- validation of input date/timestmap string and input format string
- result date/timestamp validation
I was a bit confused when I've seen that you modified another function
in your patch, but tried it out nevertheless. After all, you answered
one of my emails, and I let my tool download your patch directly from
the website. The other thread you are mentioning is a different topic.
Anyway, what I'm trying to solve is validate that to_date() produces
valid and correct output. It does not, as of today.
Regards,
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] to_date_valid()
On 15.08.2016 10:24, Artur Zakirov wrote:
On 14.08.2016 01:52, Andreas 'ads' Scherbaum wrote:
Attached is a patch to "do the right thing". The verification is in
"to_date()" now, the extra function is removed. Regression tests are
updated - two or three of them returned a wrong date before, and still
passed. They fail now. Documentation is also updated.
Regards,
Is it right and "true" way to validate date by extra transforming and
comparison?
Maybe validate date by using ValidateDate(). Attached sample patch.
This does not solve the problem at hand, and let's wrong dates/formats
slip through:
./buildclient.py -v -c demo-config-pg.yaml --run-configure --run-make
--run-install --no-clean-at-all --patch
'https://www.postgresql.org/message-id/95738e12-6ed6-daf5-9dcf-6336072e6b15%40postgrespro.ru'
postgres=# SELECT to_date('2011 12 18', ' MM DD');
to_date
2011-12-08
(1 row)
That is from the regression tests, and obviously handles the date
transformation wrong. My attempt catches this, because I compare the
date with the input date, and do not rely on a valid date only.
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] to_date_valid()
On 27.07.2016 05:00, Joshua D. Drake wrote:
On 07/26/2016 06:25 PM, Peter Eisentraut wrote:
On 7/5/16 4:24 AM, Albe Laurenz wrote:
But notwithstanding your feeling that you would like your application
to break if it makes use of this behaviour, it is a change that might
make some people pretty unhappy - nobody can tell how many.
What is the use of the existing behavior? You get back an arbitrary
implementation dependent value. We don't even guarantee what the value
will be. If we changed it to return a different implementation
dependent value, would users get upset?
No they would not get upset because they wouldn't know.
Can we just do the right thing?
Attached is a patch to "do the right thing". The verification is in
"to_date()" now, the extra function is removed. Regression tests are
updated - two or three of them returned a wrong date before, and still
passed. They fail now. Documentation is also updated.
Regards,
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
to_date_valid.patch.gz
Description: application/gzip
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] to_date_valid()
On 27.07.2016 05:00, Joshua D. Drake wrote:
On 07/26/2016 06:25 PM, Peter Eisentraut wrote:
On 7/5/16 4:24 AM, Albe Laurenz wrote:
But notwithstanding your feeling that you would like your application
to break if it makes use of this behaviour, it is a change that might
make some people pretty unhappy - nobody can tell how many.
What is the use of the existing behavior? You get back an arbitrary
implementation dependent value. We don't even guarantee what the value
will be. If we changed it to return a different implementation
dependent value, would users get upset?
No they would not get upset because they wouldn't know.
Can we just do the right thing?
I'm in favour of fixing this, and update the documentation. But given
the discussions in the past, it seemed like people actually depend on
this behaviour. Hence the additional function.
if this is fixed, it's too late for the current beta. But it's a good
time to add a note in the release notes, and advise people that it will
be changed in the next release.
A workaround can be to rename the current function to something like
"to_date_legacy", or "to_date_oracle". And implement the checks in to_date.
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] sslmode=require fallback
On 14.07.2016 23:34, Magnus Hagander wrote: On Thu, Jul 14, 2016 at 11:27 PM, Tom Lane <t...@sss.pgh.pa.us <mailto:t...@sss.pgh.pa.us>> wrote: Greg Stark <st...@mit.edu <mailto:st...@mit.edu>> writes: > Well what's required to "configure SSL" anyways? If you don't have > verify-ca set or a root canal cert present then the server just needs a > certificate -- any certificate. Can the server just cons one up on demand > (or server startup or initdb)? Hmm, good old "snake oil certificate" approach. Yeah, we could probably have initdb create a cert all the time. I had memories of this taking an undue amount of time, but it seems pretty fast on a modern server. It can still take a very significant amount of time in some virtual environments, due to lack of entropy. And virtual environments aren't exactly uncommon these days... What expire time would you chose for the certificate? One year? Two years? Which tool is going to re-generate your new cert, once this one expires? You don't want to run initdb again ... Regards, -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] to_date_valid()
On 05.07.2016 04:33, David G. Johnston wrote: On Mon, Jul 4, 2016 at 8:39 PM, Andreas 'ads' Scherbaum <adsm...@wars-nicht.de <mailto:adsm...@wars-nicht.de>>wrote: On 04.07.2016 18:37, Pavel Stehule wrote: I don't know if the name "strict" is best, but the name "validate" is not good too. Current to_date does some validations too. Obviously not enough, because it allows invalid dates. I'd say that the current to_date() merely validates the input format for string parsing, and that the date is in range. But there is not much validation on the date itself. So the name can't be "strict" because of the conflict with "NULL" handling, and you don't like "valid" - what other options do you offer? We don't have to change the name...we could do something like how RegularExpressions work - like (?i) - and just add a new modifier code. '~-MI-DD' --that's a leading tilde, could be anything - even something like "HM-MI-DD" for "historical mode" Where to_timestamp() already uses HH for the hour? If you add another "H", that surely is confusing. It seems that fixing it is back on the table, possibly even for 9.6 since this is such a hideous bug - one that closely resembles a cockroach ;) 9.6 is already in Beta, people are testing their applications against it. This would be a huge break, plus an API change - something you don't add in a Beta. -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] to_date_valid()
On 05.07.2016 06:05, Pavel Stehule wrote: 2016-07-05 2:39 GMT+02:00 Andreas 'ads' Scherbaum <adsm...@wars-nicht.de <mailto:adsm...@wars-nicht.de>>: On 04.07.2016 18:37, Pavel Stehule wrote: I don't know if the name "strict" is best, but the name "validate" is not good too. Current to_date does some validations too. Obviously not enough, because it allows invalid dates. I'd say that the current to_date() merely validates the input format for string parsing, and that the date is in range. But there is not much validation on the date itself. So the name can't be "strict" because of the conflict with "NULL" handling, and you don't like "valid" - what other options do you offer? I have not - so third option looks best for me - it can be long name "only_correct_date", "only_valid_date", "only_valid_date_on_input" ... Then you don't have "to_date" in the function name, but still use "valid" in the name. How is that useful to remember the function? Where "to_date_valid" already gives you the idea that it is "to_date" with an additional "valid"ator. Don't make it overly complicated. -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] to_date_valid()
On 04.07.2016 18:37, Pavel Stehule wrote:
I don't know if the name "strict" is best, but the name "validate" is
not good too. Current to_date does some validations too.
Obviously not enough, because it allows invalid dates. I'd say that the
current to_date() merely validates the input format for string parsing,
and that the date is in range. But there is not much validation on the
date itself.
So the name can't be "strict" because of the conflict with "NULL"
handling, and you don't like "valid" - what other options do you offer?
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] to_date_valid()
On 04.07.2016 05:51, Pavel Stehule wrote:
2016-07-04 5:19 GMT+02:00 Pavel Stehule <pavel.steh...@gmail.com
<mailto:pavel.steh...@gmail.com>>:
2016-07-04 4:25 GMT+02:00 Craig Ringer <cr...@2ndquadrant.com
<mailto:cr...@2ndquadrant.com>>:
On 3 July 2016 at 09:32, Euler Taveira <eu...@timbira.com.br
<mailto:eu...@timbira.com.br>> wrote:
On 02-07-2016 22 <tel:02-07-2016%2022>:04, Andreas 'ads'
Scherbaum wrote:
> The attached patch adds a new function "to_date_valid()" which
will
> validate the date and return an error if the input and output
date do
> not match. Tests included, documentation update as well.
>
Why don't you add a third parameter (say, validate = true |
false)
instead of creating another function? The new parameter
could default to
false to not break compatibility.
because
SELECT to_date('blah', 'pattern', true)
is less clear to read than
SELECT to_date_valid('blah', 'pattern')
and offers no advantage. It's likely faster to use a separate
function too.
personally I prefer first variant - this is same function with
stronger check.
Currently probably we have not two similar function - one fault
tolerant and second stricter. There is only one example of similar
behave - parse_ident with "strict" option.
The three parameters are ok still - so I don't see a reason why we have
to implement new function. If you need to emphasize the fact so behave
should be strict, you can use named parameters
select to_date('blah', 'patter', strict => true)
The new function is not "strict", it just adds a validation step:
postgres=# select to_date_valid(NULL, NULL);
to_date_valid
---
(1 row)
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] to_date_valid()
On 04.07.2016 16:33, Amit Kapila wrote:
On Sun, Jul 3, 2016 at 6:34 AM, Andreas 'ads' Scherbaum
<adsm...@wars-nicht.de> wrote:
Hello,
we have customers complaining that to_date() accepts invalid dates, and
returns a different date instead. This is a known issue:
http://sql-info.de/postgresql/notes/to_date-to_timestamp-gotchas.html
On the other hand this leads to wrong dates when loading dates into the
database, because the database happily accepts invalid dates and ends up
writing something completely different into the table.
The attached patch adds a new function "to_date_valid()" which will validate
the date and return an error if the input and output date do not match.
Tests included, documentation update as well.
It seems that you are calling many additional function calls
(date_out, timestamp_in, etc.) to validate the date. Won't the
additional function calls make to_date much costlier than its current
implementation? I don't know if there is a better way, but I think it
is worth to consider, if we can find a cheaper way to detect validity
of date.
It certainly is costlier, and I'm open to suggestions how to improve the
performance. That is one of the reasons why I considered a separate
function, instead of adding this to to_date() and add even more overhead
there.
Note - Your patch is small (~13KB) enough that it doesn't need to zipped.
It's not about the small size, it's about websites like Gmail which
mingle up the linebreaks and then git fails. Ran into this problem on
the pgAdminIII list a while ago, ever since I just zip it and avoid the
trouble.
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] to_date_valid()
On 03.07.2016 07:05, Jaime Casanova wrote: El 2/7/2016 20:33, "Euler Taveira" <eu...@timbira.com.br <mailto:eu...@timbira.com.br>> escribió: > > On 02-07-2016 22:04, Andreas 'ads' Scherbaum wrote: > > The attached patch adds a new function "to_date_valid()" which will > > validate the date and return an error if the input and output date do > > not match. Tests included, documentation update as well. > > > Why don't you add a third parameter (say, validate = true | false) > instead of creating another function? The new parameter could default to > false to not break compatibility. > Shouldn't we fix this instead? Sounds like a bug to me. We don't usually want to be bug compatible so it doesn't matter if we break something. There are previous discussions about such a change, and this was rejected: https://www.postgresql.org/message-id/lbjf1v%24a2v%241%40ger.gmane.org https://www.postgresql.org/message-id/A737B7A37273E048B164557ADEF4A58B17C9140E%40ntex2010i.host.magwien.gv.at Hence the new function, which does not collide with the existing implementation. Regards, -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] to_date_valid()
Hello,
we have customers complaining that to_date() accepts invalid dates, and
returns a different date instead. This is a known issue:
http://sql-info.de/postgresql/notes/to_date-to_timestamp-gotchas.html
On the other hand this leads to wrong dates when loading dates into the
database, because the database happily accepts invalid dates and ends up
writing something completely different into the table.
The attached patch adds a new function "to_date_valid()" which will
validate the date and return an error if the input and output date do
not match. Tests included, documentation update as well.
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
to_date_valid.patch.gz
Description: application/gzip
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] TESTING in src/bin/pg_upgrade has incorrect documentation
Hi,
the TESTING file in src/bin/pg_upgrade talks about a "check.sh script",
but this seems to be a binary (check) now.
Regards,
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in intarray bench script
The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested The patch changes the benchmark tool in a way that the explain output is printed to standard out - what one would expect from the "-e" (explain) option. The new status of this patch is: Ready for Committer -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Small typo in a comment in pg_regress.c
Hi,
stumbled over this while looking into the source. Patch attached.
Regards,
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
index 416829d..343fd19 100644
--- a/src/test/regress/pg_regress.c
+++ b/src/test/regress/pg_regress.c
@@ -1329,7 +1329,7 @@ results_differ(const char *testname, const char *resultsfile, const char *defaul
if (platform_expectfile)
{
/*
- * Replace everything afer the last slash in expectfile with what the
+ * Replace everything after the last slash in expectfile with what the
* platform_expectfile contains.
*/
char *p = strrchr(expectfile, '/');
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pl/pgSQL, get diagnostics and big data
Hello,
thanks for reviewing the patch!
On 09.02.2016 20:32, Christian Ullrich wrote:
- Are there portability issues/Will it work on Windows/BSD etc.:
No, it will not work correctly on Windows when built with MSVC,
although it may work with MinGW.
+++ postgresql-9.5.0/src/backend/tcop/pquery.c
@@ -195,7 +195,7 @@
{
case CMD_SELECT:
snprintf(completionTag, COMPLETION_TAG_BUFSIZE,
- "SELECT %u", queryDesc->estate->es_processed);
+ "SELECT %lu", queryDesc->estate->es_processed);
%lu formats unsigned long. "long" is problematic in terms of
portability, because sizeof(long) is different everywhere. It is 32
bits on Windows and on 32-bit *nix, and 64 bits on 64-bit *nix.
I added the following line to the INSERT formatting in pquery.c:
queryDesc->estate->es_processed += 471147114711LL;
This number is 0x6DB28E70D7; so inserting one row should return
"INSERT 0 2995679448" (0xB28E70D8):
postgres=# insert into t1 values (0);
INSERT 0 2995679448
To fix this, I think it will be enough to change the format strings to
use "%zu" instead of "%lu". pg_snprintf() is selected by configure if
the platform's snprintf() does not support the "z" conversion. I tried
this, and it appears to work:
postgres=# insert into t1 values (0);
INSERT 0 471147114712
I have looked for other uses of "%lu", and found none that may cause
the same issue; apparently they are all used with values that clearly
have 32-bit type; actually, most of them are used to format error
codes in Windows-specific code.
Attached is a new version of the patch, with %lu replaced by %zu.
I re-ran all the tests, especially the long test with 2^32+x rows, and
it produces the same result as before.
Regards,
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
64bit_4.diff.gz
Description: application/gzip
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pl/pgSQL, get diagnostics and big data
On 01.02.2016 21:24, Andreas 'ads' Scherbaum wrote: Attached patch expands the row_count to 64 bit. Remembering an issue we had recently with clear text patches, attached is a gzipped version as well. Regards, -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project 64bit_3.diff.gz Description: application/gzip -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pl/pgSQL, get diagnostics and big data
Hello,
one of our customers approached us and complained, that GET DIAGNOSTICS
row_count returns invalid results if the number of rows is > 2^31. It's
a bit complicated to test for this case, so I set up a separate instance
with this patch, and inserted 2^32+x rows into a table. Internally,
row_count it's a signed integer, the resulting number is negative:
diagnostics=# select testfunc_pg((2^31 + 5)::bigint);
testfunc_pg
-
-2147433648
(1 row)
Going over 2^32 wraps around:
diagnostics=# select testfunc_pg((2^32 + 5)::bigint);
testfunc_pg
-
5
(1 row)
Attached patch expands the row_count to 64 bit.
diagnostics=# select testfunc_pg((2^32 + 5)::bigint);
testfunc_pg
-
4295017296
(1 row)
I hope, I covered all the places which count the result set.
Regards,
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
diff -ru postgresql-9.5.0.orig/src/backend/executor/spi.c postgresql-9.5.0/src/backend/executor/spi.c
--- postgresql-9.5.0.orig/src/backend/executor/spi.c 2016-01-04 22:29:34.0 +0100
+++ postgresql-9.5.0/src/backend/executor/spi.c 2016-01-27 01:30:06.099132294 +0100
@@ -36,7 +36,7 @@
#include "utils/typcache.h"
-uint32 SPI_processed = 0;
+uint64 SPI_processed = 0;
Oid SPI_lastoid = InvalidOid;
SPITupleTable *SPI_tuptable = NULL;
int SPI_result;
@@ -1994,7 +1994,7 @@
bool read_only, bool fire_triggers, long tcount)
{
int my_res = 0;
- uint32 my_processed = 0;
+ uint64 my_processed = 0;
Oid my_lastoid = InvalidOid;
SPITupleTable *my_tuptable = NULL;
int res = 0;
@@ -2562,7 +2562,7 @@
static bool
_SPI_checktuples(void)
{
- uint32 processed = _SPI_current->processed;
+ uint64 processed = _SPI_current->processed;
SPITupleTable *tuptable = _SPI_current->tuptable;
bool failed = false;
diff -ru postgresql-9.5.0.orig/src/backend/tcop/pquery.c postgresql-9.5.0/src/backend/tcop/pquery.c
--- postgresql-9.5.0.orig/src/backend/tcop/pquery.c 2016-01-04 22:29:34.0 +0100
+++ postgresql-9.5.0/src/backend/tcop/pquery.c 2016-01-30 12:11:56.573841810 +0100
@@ -195,7 +195,7 @@
{
case CMD_SELECT:
snprintf(completionTag, COMPLETION_TAG_BUFSIZE,
- "SELECT %u", queryDesc->estate->es_processed);
+ "SELECT %lu", queryDesc->estate->es_processed);
break;
case CMD_INSERT:
if (queryDesc->estate->es_processed == 1)
@@ -203,15 +203,15 @@
else
lastOid = InvalidOid;
snprintf(completionTag, COMPLETION_TAG_BUFSIZE,
- "INSERT %u %u", lastOid, queryDesc->estate->es_processed);
+ "INSERT %u %lu", lastOid, queryDesc->estate->es_processed);
break;
case CMD_UPDATE:
snprintf(completionTag, COMPLETION_TAG_BUFSIZE,
- "UPDATE %u", queryDesc->estate->es_processed);
+ "UPDATE %lu", queryDesc->estate->es_processed);
break;
case CMD_DELETE:
snprintf(completionTag, COMPLETION_TAG_BUFSIZE,
- "DELETE %u", queryDesc->estate->es_processed);
+ "DELETE %lu", queryDesc->estate->es_processed);
break;
default:
strcpy(completionTag, "???");
@@ -892,7 +892,7 @@
{
QueryDesc *queryDesc;
ScanDirection direction;
- uint32 nprocessed;
+ uint64 nprocessed;
/*
* NB: queryDesc will be NULL if we are fetching from a held cursor or a
diff -ru postgresql-9.5.0.orig/src/include/executor/spi.h postgresql-9.5.0/src/include/executor/spi.h
--- postgresql-9.5.0.orig/src/include/executor/spi.h 2016-01-04 22:29:34.0 +0100
+++ postgresql-9.5.0/src/include/executor/spi.h 2016-01-27 01:34:46.388245129 +0100
@@ -59,7 +59,7 @@
#define SPI_OK_UPDATE_RETURNING 13
#define SPI_OK_REWRITTEN 14
-extern PGDLLIMPORT uint32 SPI_processed;
+extern PGDLLIMPORT uint64 SPI_processed;
extern PGDLLIMPORT Oid SPI_lastoid;
extern PGDLLIMPORT SPITupleTable *SPI_tuptable;
extern PGDLLIMPORT int SPI_result;
diff -ru postgresql-9.5.0.orig/src/include/executor/spi_priv.h postgresql-9.5.0/src/include/executor/spi_priv.h
--- postgresql-9.5.0.orig/src/include/executor/spi_priv.h 2016-01-04 22:29:34.0 +0100
+++ postgresql-9.5.0/src/include/executor/spi_priv.h 2016-01-27 01:34:55.220056918 +0100
@@ -21,7 +21,7 @@
typedef struct
{
/* current results */
- uint32 processed; /* by Executor */
+ uint64 processed; /* by Executor */
Oid lastoid;
SPITupleTable *tuptable; /* tuptable currently being built */
diff -ru postgresql-9.5.0.orig/src/include/nodes/execnodes.h postgresql-9.5.0/src/include/nodes/execnodes.h
--- postgresql-9.5.0.orig/src/include/nodes/execnodes.h 2016-01-04 22:29:34.0 +0100
+++ postgresql-9.5.0/src/include/nodes/execnodes.h 2016-01-27 01:32:04.711625720 +0100
Re: [HACKERS] Small documentation fix in src/interfaces/ecpg/preproc/po/pt_BR.po
Hello, On 10/07/2015 05:18 PM, Euler Taveira wrote: On 06-10-2015 19:49, Andreas 'ads' Scherbaum wrote: When working on a script, I stumbled over a mistake in the pt_BR.po translation for ecpg. Patch attached. I've already fixed it in the translation git. It'll be available only in the next set of releases. Thank you. Care to commit the other one for zh_CN.po as well? Thanks, -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project diff --git a/src/bin/initdb/po/zh_CN.po b/src/bin/initdb/po/zh_CN.po index 3986eab..1dd6dcd 100644 --- a/src/bin/initdb/po/zh_CN.po +++ b/src/bin/initdb/po/zh_CN.po @@ -727,7 +727,7 @@ msgid "" "Report bugs to <pgsql-b...@postgresql.org>.\n" msgstr "" "\n" -"æ¥åéè¯¯è³ <pgql-b...@postgresql.org>.\n" +"æ¥åéè¯¯è³ <pgsql-b...@postgresql.org>.\n" #: initdb.c:2907 msgid "" -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Small documentation fix in src/bin/initdb/po/zh_CN.po
When working on a script, I stumbled over a mistake in the zh_CN.po translation for initdb. Patch attached. Regards, -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project diff --git a/src/bin/initdb/po/zh_CN.po b/src/bin/initdb/po/zh_CN.po index 3986eab..1dd6dcd 100644 --- a/src/bin/initdb/po/zh_CN.po +++ b/src/bin/initdb/po/zh_CN.po @@ -727,7 +727,7 @@ msgid "" "Report bugs to <pgsql-b...@postgresql.org>.\n" msgstr "" "\n" -"æ¥åéè¯¯è³ <pgql-b...@postgresql.org>.\n" +"æ¥åéè¯¯è³ <pgsql-b...@postgresql.org>.\n" #: initdb.c:2907 msgid "" -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Small documentation fix in src/interfaces/ecpg/preproc/po/pt_BR.po
When working on a script, I stumbled over a mistake in the pt_BR.po translation for ecpg. Patch attached. Regards, -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project diff --git a/src/interfaces/ecpg/preproc/po/pt_BR.po b/src/interfaces/ecpg/preproc/po/pt_BR.po index 804e201..1d855a3 100644 --- a/src/interfaces/ecpg/preproc/po/pt_BR.po +++ b/src/interfaces/ecpg/preproc/po/pt_BR.po @@ -313,7 +313,7 @@ msgstr "erro de sintaxe no comando EXEC SQL INCLUDE" #: pgc.l:1237 #, c-format msgid "internal error: unreachable state; please report this to <pgsql-b...@postgresql.org>" -msgstr "erro interno: estado inacessÃvel; por favor relato isso a <psql-b...@postgresql.org>" +msgstr "erro interno: estado inacessÃvel; por favor relato isso a <pgsql-b...@postgresql.org>" #: pgc.l:1362 #, c-format -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] documentation update for doc/src/sgml/func.sgml
On 09/14/2014 06:32 PM, Peter Eisentraut wrote: On 9/12/14 3:13 PM, Andreas 'ads' Scherbaum wrote: Of course a general rule how to link to WP would be nice ... I think Wikipedia links should be avoided altogether. We can assume that readers are technically proficient to look up general technical concepts on their own using a reference system of their choice. In cases where a link is warranted, it is better to construct a proper bibliographic citation to the primary source material, such as an IEEE standard or an academic paper, in a way that will stand the test of time. That's a clear statement, and makes sense. Should be written down somewhere, so it can be found again. Independent of that, it is actually not correct that we use the IEEE's rules, because we don't use any rules, that is up to the operating system/platform. While most platforms indeed do use the IEEE floating-point standard more less, some don't. Section 8.1.3 tries to point that out. New version attached, WP link removed, wording changed. Regards, -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 13c71af..d54cf58 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -924,6 +924,25 @@ /tgroup /table + para +For functions like round(), log() and sqrt() which run against +either fixed-precision (NUMERIC) or floating-point numbers (e.g. REAL), +note that the results of these operations will differ according +to the input type due to rounding. This is most observable with +round(), which can end up rounding down as well as up for +any #.5 value. productnamePostgreSQL/productname's handling +of floating-point values depends on the operating system, which +may or may not follow the IEEE floating-point standard. + /para + + para +The bitwise operators work only on integral data types, whereas +the others are available for all numeric data types. The bitwise +operators are also available for the bit string types +typebit/type and typebit varying/type, as +shown in xref linkend=functions-bit-string-op-table. + /para + para xref linkend=functions-math-random-table shows functions for generating random numbers. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] documentation update for doc/src/sgml/func.sgml
On 08/21/2014 12:35 PM, Fabien COELHO wrote: I do not understand why the last sentence in the first paragraph about bitwise ops is put there with rounding issues, which seem unrelated. It seems to me that it belongs to the second paragraph which is about bitwise operators. That's the part which came from Josh Berkus. We discussed this patch on IRC. Hmmm. I do think the last sentence belongs to the next paragraph. The identity of the author does not change my opinion on that point:-) If you have another argument, maybe. Attached is an updated version of the patch. The wikipedia link can be simplified to a much cleaner: http://en.wikipedia.org/wiki/IEEE_floating_point#Rounding_rules It can, but then you always refer to the latest version of the Wikipedia page, which might or might not be a good idea. The link in the patch points to the current version from yesterday, no matter how many changes are introduced afterwards. I doubt that IEEE floating point rounding rules are likely to change much, so referencing the latest version is both safe cleaner. Also, wikipedia would change its implementation from php to something else (well, unlikely, probably as unlikely as a change in IEEE fp rounding rules:-). It's really not about the IEEE changing something, but about someone changing the Wikipedia page. The way I linked it makes sure it always displays the same version of the page. Of course a general rule how to link to WP would be nice ... Regards, -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 13c71af..15742f8 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -924,6 +924,25 @@ /tgroup /table + para +For functions like round(), log() and sqrt() which run against +either fixed-precision (NUMERIC) or floating-point numbers (e.g. REAL), +note that the results of these operations will differ according +to the input type due to rounding. This is most observable with +round(), which can end up rounding down as well as up for +any #.5 value. We use the +a xmlns=http://en.wikipedia.org/w/index.php?title=IEEE_floating_pointoldid=622007055#Rounding_rules;IEEE's rules/a +for rounding floating-point numbers which can be machine-specific. + /para + + para +The bitwise operators work only on integral data types, whereas +the others are available for all numeric data types. The bitwise +operators are also available for the bit string types +typebit/type and typebit varying/type, as +shown in xref linkend=functions-bit-string-op-table. + /para + para xref linkend=functions-math-random-table shows functions for generating random numbers. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] documentation update for doc/src/sgml/func.sgml
On 08/21/2014 11:53 AM, Fabien COELHO wrote: attached is a small patch which updates doc/src/sgml/func.sgml. The change explains that functions like round() and others might behave different depending on your operating system (because of rint(3)) and that this is according to an IEEE standard. It also points out that #.5 is not always rounded up, as expected from a mathematical point of view. Applied on head read. I'm not a native English speaker, but the English looked right to me. Thanks. Comments: I'm not sure that the note that on the third line is useful. I do not understand why the last sentence in the first paragraph about bitwise ops is put there with rounding issues, which seem unrelated. It seems to me that it belongs to the second paragraph which is about bitwise operators. That's the part which came from Josh Berkus. We discussed this patch on IRC. The wikipedia link can be simplified to a much cleaner: http://en.wikipedia.org/wiki/IEEE_floating_point#Rounding_rules It can, but then you always refer to the latest version of the Wikipedia page, which might or might not be a good idea. The link in the patch points to the current version from yesterday, no matter how many changes are introduced afterwards. But yes: Also, I submitted docs with relevant wikipedia links which was stripped of these before committing. I'm wondering whether there is a general policy not to put external links from within the text in the documentation. There are very few of them, most in acronym.sgml. It would be nice to have a general rule how to handle external links. I would suggest to put relevant tags around functions and types, like: functionround()/ and typeNUMERIC/. Can do. Thanks, -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] documentation update for doc/src/sgml/func.sgml
Hi, attached is a small patch which updates doc/src/sgml/func.sgml. The change explains that functions like round() and others might behave different depending on your operating system (because of rint(3)) and that this is according to an IEEE standard. It also points out that #.5 is not always rounded up, as expected from a mathematical point of view. Regards, -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 13c71af..da30991 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -924,6 +924,25 @@ /tgroup /table + para +For functions like round(), log() and sqrt() which run against +either fixed-precision (NUMERIC) or floating-point numbers (e.g. REAL), +note that the results of these operations will differ according +to the input type due to rounding. This is most observable with +round(), which can end up rounding down as well as up for +any #.5 value. We use the +a xmlns=http://en.wikipedia.org/w/index.php?title=IEEE_floating_pointoldid=622007055#Rounding_rules;IEEE's rules/a +for rounding floating-point numbers which can be machine-specific. +The bitwise operators work only on integral data types, whereas +the others are available for all numeric data types. + /para + + para +The bitwise operators are also available for the bit string types +typebit/type and typebit varying/type, as +shown in xref linkend=functions-bit-string-op-table. + /para + para xref linkend=functions-math-random-table shows functions for generating random numbers. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch: iff - if
On 04/17/2014 12:33 PM, Nicolas Barbier wrote: 2014-04-17 Michael Paquier michael.paqu...@gmail.com: Is there no equivalent in German? For example in French there is ssi. gdw (genau dann, wenn) More likely that you see \equiv or: \leftrightarrow Regards, -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch: iff - if
On 04/16/2014 12:19 AM, Andreas 'ads' Scherbaum wrote: stumbled over a number of iff in the source where if is meant - not sure what the real story behind this is, but attached is a patch to fix the about 80 occurrences. Looks like I missed something in my math lessons ... -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-advocacy] GSoC 2014 - mentors, students and admins
Hi, On 01/28/2014 06:46 PM, Atri Sharma wrote: On Tue, Jan 28, 2014 at 11:04 PM, Thom Brown t...@linux.com mailto:t...@linux.com wrote: Hi all, Application to Google Summer of Code 2014 can be made as of next Monday (3rd Feb), and then there will be a 12 day window in which to submit an application. I'd like to gauge interest from both mentors and students as to whether we'll want to do this. And I'd be fine with being admin again this year, unless there's anyone else who would like to take up the mantle? Who would be up for mentoring this year? And are there any project ideas folk would like to suggest? I would like to bring up the addition to MADLIB algorithms again this year. I've spoken with the MADlib team at goivotal and they are ok to support this proposal. Therefore I offer to mentor this. Regards, -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] REMINDER: FOSDEM 2012 - PostgreSQL Devroom: Call for Speakers
Am 20.11.2011 23:54, schrieb Andreas 'ads' Scherbaum: FOSDEM 2012 - PostgreSQL Devroom: Call for Speakers The PostgreSQL project will have a Devroom at FOSDEM 2012, which takes place on February 4-5 in Brussels, Belgium. The Devroom will mainly cover topics for PostgreSQL users, developers and contributors. For more information about the event itself, please see the website at http://www.fosdem.org/2012/ . We are now accepting proposals for talks. Please note that we only accept talks in English. Each session will last 45 minutes (including discussion), and may be on any topic related to PostgreSQL. Suggested topic areas include: * Developing applications for PostgreSQL * Administering large scale PostgreSQL installations * Case studies and/or success stories of PostgreSQL deployments * PostgreSQL tools and utilities * PostgreSQL hacking * Community user groups * Tuning the server * Migrating from other systems * Scaling/replication * Benchmarking hardware * PostgreSQL related products Of course, we're happy to receive proposals for talks on other PostgreSQL related topics as well. Please use our conference website to submit your proposal: https://www.postgresql.eu/events/callforpapers/fosdem2012/ The deadline for submissions is December 20th, 2011. The schedule will be published and speakers will be informed by the end of the year. Please also note my email about hotel reservation: http://archives.postgresql.org/pgeu-general/2011-11/msg0.php Please keep in mind, that the Call for Speakers is open until December 20th. Only a few days left. Now it's a good time to submit your proposal ;-) -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] REMINDER: Hotel reservation for FOSDEM 2012 - Deadline: December 31th, 2011
Am 11.11.2011 16:14, schrieb Andreas 'ads' Scherbaum: like the last years we will have a devroom at FOSDEM 2012. We also look forward to have a booth. We made a group reservation in the Agenda Louise hotel: Hotel Agenda Louise rue de Florence 6 B-1000 Brussels Tel: + 32.2.539.00.31 Fax: + 32.2.539.00.63 www.hotel-agenda.com This time, as a good customer, we got a special price. From Friday to Sunday included: - 80 EUR per night and single room - 90 EUR per night and double room From Monday to Thursday included: - 106 EUR per night and single room - 120 EUR per night and single room Breakfast, taxes and services are included. If you would like to book a room, please send me an email. Include your name, email address, room type, arrival and leave date. Important: please send me this information until December 31th, 211! If you need a hotel room for FOSDEM, please don't forget to send me an email. Deadline is end of the year. Registrations after this date can not be considered. -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] FOSDEM 2012 - PostgreSQL Devroom: Call for Speakers
Hi all, FOSDEM 2012 - PostgreSQL Devroom: Call for Speakers The PostgreSQL project will have a Devroom at FOSDEM 2012, which takes place on February 4-5 in Brussels, Belgium. The Devroom will mainly cover topics for PostgreSQL users, developers and contributors. For more information about the event itself, please see the website at http://www.fosdem.org/2012/ . We are now accepting proposals for talks. Please note that we only accept talks in English. Each session will last 45 minutes (including discussion), and may be on any topic related to PostgreSQL. Suggested topic areas include: * Developing applications for PostgreSQL * Administering large scale PostgreSQL installations * Case studies and/or success stories of PostgreSQL deployments * PostgreSQL tools and utilities * PostgreSQL hacking * Community user groups * Tuning the server * Migrating from other systems * Scaling/replication * Benchmarking hardware * PostgreSQL related products Of course, we're happy to receive proposals for talks on other PostgreSQL related topics as well. Please use our conference website to submit your proposal: https://www.postgresql.eu/events/callforpapers/fosdem2012/ The deadline for submissions is December 20th, 2011. The schedule will be published and speakers will be informed by the end of the year. Please also note my email about hotel reservation: http://archives.postgresql.org/pgeu-general/2011-11/msg0.php -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Hotel reservation for FOSDEM 2012 - Deadline: December 31th, 2011
Hi all, like the last years we will have a devroom at FOSDEM 2012. We also look forward to have a booth. We made a group reservation in the Agenda Louise hotel: Hotel Agenda Louise rue de Florence 6 B-1000 Brussels Tel: + 32.2.539.00.31 Fax: + 32.2.539.00.63 www.hotel-agenda.com This time, as a good customer, we got a special price. From Friday to Sunday included: - 80 EUR per night and single room - 90 EUR per night and double room From Monday to Thursday included: - 106 EUR per night and single room - 120 EUR per night and single room Breakfast, taxes and services are included. If you would like to book a room, please send me an email. Include your name, email address, room type, arrival and leave date. Important: please send me this information until December 31th, 211! Thanks -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Small documentation enhancement for default_tablespace
Hello, last week someone raised in a german webforum the question why default_tablespace is not used for CREATE DATABASE. After a brief discussion on irc (thanks RhodiumToad) I added a note to the documentation mentioning this point. Patch attached. Bye -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project *** a/doc/src/sgml/config.sgml --- b/doc/src/sgml/config.sgml *** *** 4357,4362 COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv; --- 4357,4368 /para para + This variable is also not used for creating databases. Tablespace + information are copied from the template database (usually + literaltemplate1/literal) instead. +/para + +para For more information on tablespaces, see xref linkend=manage-ag-tablespaces. /para -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SHOW TABLES
On Thu, 15 Jul 2010 17:09:32 +0100 Thom Brown wrote: On 15 July 2010 17:07, Marc G. Fournier scra...@hub.org wrote: On Thu, 15 Jul 2010, Thom Brown wrote: If it's only a psql problem, why implement it as SQL? Is it just so we're not adding keywords specifically to psql? In that case, it shouldn't support QUIT. Personally, I think this is somethign that should go into the backend ... I'd like to be able to write perl scripts that talk to the backend without having to remember all the various system tables I need to query / join to get the same results as \d gives me in psql ... same for any interface language, really ... Isn't that what the information_schema catalog is for? Is there a way to query all databases from information_schema? Bye -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SHOW TABLES
On Thu, 15 Jul 2010 22:01:34 +0300 Peter Eisentraut wrote: On tor, 2010-07-15 at 19:21 +0200, Andreas 'ads' Scherbaum wrote: Is there a way to query all databases from information_schema? No. This got rejected before, because of not in the standard. In this case: no way to answer SHOW DATABASES by just using information_schema. At least this question requires using the system tables. Bye -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Streaming Rep - 2-phase backups and reducing time to full replication
On Thu, 24 Dec 2009 09:58:20 + Simon Riggs wrote: On Tue, 2009-12-22 at 15:33 -0600, decibel wrote: Dumb question: could the WAL streaming code be made to also ship base files? That would make setting up a streaming replica super-simple. That was a possible design, but that's not will be there for this release. I opposed adding the we do the base backup for you feature because there are many ways of doing a base backup and it would likely have restricted your options to do so. One issue that would cause is limiting the speed of the base backup to a single libpq connection, which would cause performance problems. So yes, super-simple, but not super-good for many big users. The big users will always have other options. But for normal users who just want to enable a replication - this feature would be awesome: the entire replication is done by the database. So +1 for integrating such a feature in a future version. Bye -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion
On Mon, 07 Dec 2009 20:20:45 -0500 Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: If we do need to do this, perhaps we should change the older parameter to be partition_exclusion. Yeah, if we do want to do something about this then changing the name of the existing GUC would be a lot less work. However, partition_exclusion seems to imply that it *only* applies to partitioned tables, which is not the case... It is less coding work - but it will for sure confuse the users. Bye -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Listen / Notify - what to do when the queue is full
On Wed, 18 Nov 2009 22:12:18 -0500 Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: (4) drop *old* notifications if the queue is full. Since everyone has made the point that LISTEN is not meant to be a full queueing system, I have no problem dropping notifications LRU-style. NO, NO, NO, a thousand times no! That turns NOTIFY into an unreliable signaling system, and if I haven't made this perfectly clear yet, any such change will be committed over my dead body. If we are unable to insert a new message into the queue, the correct recourse is to fail the transaction that is trying to insert the *new* message. Not to drop messages from already-committed transactions. Failing the current transaction still leaves things in a consistent state, ie, you don't get messages from aborted transactions but that's okay because they didn't change the database state. +1 And in addition i don't like the idea of having the sender sitting around until there's room for more messages in the queue, because some very old backends didn't remove the stuff from the same. So, yes, just failing the current transaction seems reasonable. We are talking about millions of messages in the queue ... Bye -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Listen / Notify - what to do when the queue is full
On Thu, 19 Nov 2009 14:23:57 +0100 Joachim Wieland wrote: On Thu, Nov 19, 2009 at 1:51 PM, Andreas 'ads' Scherbaum adsm...@wars-nicht.de wrote: And in addition i don't like the idea of having the sender sitting around until there's room for more messages in the queue, because some very old backends didn't remove the stuff from the same. The only valid reason why a backend has not processed the notifications in the queue must be a backend that is still in a transaction since then (and has executed LISTEN some time before). Yes, i know. The same backend is probably causing more trouble anyway (blocking vacuum, xid wraparound, ...). -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote: The same goes for other OSS projects. There's quite a few random OSS apps which were created on PG 7.4 and have never offered their users an upgrade path (Gnuworld comes to mind). They need an EOL announcement to get them motivated to upgrade. I know several customers who decided to move from 7.3 only after the EOL was announced. If 7.3 would not has see an EOL, they would never ever have moved to a newer version. We'd want to do a full publicity around this, including a how do I upgrade page and an what does EOL mean for an OSS project page. If this goes well, we could EOL 8.0 after 8.5 comes out, and thus decrease our maintenance burden. +1 -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Thu, 12 Nov 2009 15:23:06 -0500 Andrew Dunstan wrote: Andreas 'ads' Scherbaum wrote: On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote: The same goes for other OSS projects. There's quite a few random OSS apps which were created on PG 7.4 and have never offered their users an upgrade path (Gnuworld comes to mind). They need an EOL announcement to get them motivated to upgrade. I know several customers who decided to move from 7.3 only after the EOL was announced. If 7.3 would not has see an EOL, they would never ever have moved to a newer version. Nobody that I have seen is arguing against EOLing 7.4. True. But as Josh pointed out: some people/projects/companies need more motivation to actually consider an upgrade at all. What I and others have been arguing is necessary to do EOL right is a serious amount of notice, by way of press releases etc. We can't expect users to keep polling our web site to see if there's an EOL. That means we need to prepare for an EOL months or a year in advance, ISTM. Months. The software will not stop working once we announced the EOL. And yes, i'm +1 for having a rule for EOL, like 5 versions are supported. Bye -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Patch: create or replace language
Hello,
following this old discussion:
http://archives.postgresql.org/pgsql-patches/2008-03/msg00402.php
i modifies the patch to use the CREATE [OR REPLACE] LANGUAGE syntax.
If the patch is ok, i will add the documentation too.
Kind regards
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
PGDay.eu 2009 in Paris, Nov. 6/7, http://www.pgday.eu/
Index: src/backend/commands/proclang.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/commands/proclang.c,v
retrieving revision 1.87
diff -r1.87 proclang.c
84,86c84,94
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_OBJECT),
errmsg(language \%s\ already exists, languageName)));
---
if (!stmt-replace)
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_OBJECT),
errmsg(language \%s\ already exists, languageName)));
else
{
ereport(NOTICE,
(errmsg(language \%s\ already exists, skipping, languageName)));
return;
}
Index: src/backend/parser/gram.y
===
RCS file: /projects/cvsroot/pgsql/src/backend/parser/gram.y,v
retrieving revision 2.679
diff -r2.679 gram.y
2768c2768
CREATE opt_trusted opt_procedural LANGUAGE ColId_or_Sconst
---
CREATE opt_or_replace opt_trusted opt_procedural LANGUAGE ColId_or_Sconst
2771c2771,2772
n-plname = $5;
---
n-replace = $2;
n-plname = $6;
2779c2780
| CREATE opt_trusted opt_procedural LANGUAGE ColId_or_Sconst
---
| CREATE opt_or_replace opt_trusted opt_procedural LANGUAGE ColId_or_Sconst
2783,2787c2784,2789
n-plname = $5;
n-plhandler = $7;
n-plinline = $8;
n-plvalidator = $9;
n-pltrusted = $2;
---
n-replace = $2;
n-plname = $6;
n-plhandler = $8;
n-plinline = $9;
n-plvalidator = $10;
n-pltrusted = $3;
Index: src/include/nodes/parsenodes.h
===
RCS file: /projects/cvsroot/pgsql/src/include/nodes/parsenodes.h,v
retrieving revision 1.402
diff -r1.402 parsenodes.h
1570a1571
bool replace; /* T = replace if already exists */
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Changed error message for blocks by prepared transactions
On Mon, 22 Jun 2009 19:24:28 -0400 Tom Lane wrote: Andreas 'ads' Scherbaum adsm...@wars-nicht.de writes: the small attached patch changes the error message for a blocked database in case there are prepared transactions. Isn't this duplicative of the errdetail_busy_db code? And anyway I do not see a reason not to consider prepared transactions as other users. Because you know the details. Most other users check pg_stat_activity just to find out there is no other user connected. A prepared transaction is not a connected user, so the error message is still misleading. You are right with the errdetail_busy_db(), but that's only true for 8.4, not for earlier versions. In addition that's only true if you haven't supressed the hints like some scripts do (-q as example). Bye -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project PGDay.eu 2009 in Paris, Nov. 6/7, http://www.pgday.eu/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Changed error message for blocks by prepared transactions
Hello,
the small attached patch changes the error message for a blocked
database in case there are prepared transactions. The original message
accessed by other users is misleading.
Example:
- snip -
postgres=# begin;
BEGIN
postgres=# prepare transaction 'abc';
PREPARE TRANSACTION
postgres=# \c template1
psql (8.4rc1)
Sie sind jetzt verbunden mit der Datenbank »template1«.
template1=# alter database postgres rename to test;
ERROR: database postgres is being blocked by prepared transactions
DETAIL: There are 1 prepared transaction(s) using the database.
- snip -
Translation still pending, how to add new messages to the .po files?
Kind regards
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
PGDay.eu 2009 in Paris, Nov. 6/7, http://www.pgday.eu/
Index: src/backend/commands/dbcommands.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/commands/dbcommands.c,v
retrieving revision 1.225
diff -u -3 -p -r1.225 dbcommands.c
--- src/backend/commands/dbcommands.c 11 Jun 2009 14:48:55 - 1.225
+++ src/backend/commands/dbcommands.c 22 Jun 2009 21:50:23 -
@@ -501,11 +501,24 @@ createdb(const CreatedbStmt *stmt)
* throw one.
*/
if (CountOtherDBBackends(src_dboid, notherbackends, npreparedxacts))
- ereport(ERROR,
-(errcode(ERRCODE_OBJECT_IN_USE),
- errmsg(source database \%s\ is being accessed by other users,
- dbtemplate),
- errdetail_busy_db(notherbackends, npreparedxacts)));
+ {
+ if (npreparedxacts 0)
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_OBJECT_IN_USE),
+errmsg(source database \%s\ is being blocked by prepared transactions,
+ dbtemplate),
+ errdetail_busy_db(notherbackends, npreparedxacts)));
+ }
+ else
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_OBJECT_IN_USE),
+errmsg(source database \%s\ is being accessed by other users,
+ dbtemplate),
+ errdetail_busy_db(notherbackends, npreparedxacts)));
+ }
+ }
/*
* Select an OID for the new database, checking that it doesn't have a
@@ -799,11 +812,24 @@ dropdb(const char *dbname, bool missing_
* As in CREATE DATABASE, check this after other error conditions.
*/
if (CountOtherDBBackends(db_id, notherbackends, npreparedxacts))
- ereport(ERROR,
-(errcode(ERRCODE_OBJECT_IN_USE),
- errmsg(database \%s\ is being accessed by other users,
- dbname),
- errdetail_busy_db(notherbackends, npreparedxacts)));
+ {
+ if (npreparedxacts 0)
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_OBJECT_IN_USE),
+ errmsg(database \%s\ is being blocked by prepared transactions,
+ dbname),
+ errdetail_busy_db(notherbackends, npreparedxacts)));
+ }
+ else
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_OBJECT_IN_USE),
+ errmsg(database \%s\ is being accessed by other users,
+ dbname),
+ errdetail_busy_db(notherbackends, npreparedxacts)));
+ }
+ }
/*
* Remove the database's tuple from pg_database.
@@ -940,11 +966,24 @@ RenameDatabase(const char *oldname, cons
* As in CREATE DATABASE, check this after other error conditions.
*/
if (CountOtherDBBackends(db_id, notherbackends, npreparedxacts))
- ereport(ERROR,
-(errcode(ERRCODE_OBJECT_IN_USE),
- errmsg(database \%s\ is being accessed by other users,
- oldname),
- errdetail_busy_db(notherbackends, npreparedxacts)));
+ {
+ if (npreparedxacts 0)
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_OBJECT_IN_USE),
+ errmsg(database \%s\ is being blocked by prepared transactions,
+ oldname),
+ errdetail_busy_db(notherbackends, npreparedxacts)));
+ }
+ else
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_OBJECT_IN_USE),
+ errmsg(database \%s\ is being accessed by other users,
+ oldname),
+ errdetail_busy_db(notherbackends, npreparedxacts)));
+ }
+ }
/* rename */
newtup = SearchSysCacheCopy(DATABASEOID,
@@ -1077,11 +1116,24 @@ movedb(const char *dbname, const char *t
* As in CREATE DATABASE, check this after other error conditions.
*/
if (CountOtherDBBackends(db_id, notherbackends, npreparedxacts))
- ereport(ERROR,
-(errcode(ERRCODE_OBJECT_IN_USE),
- errmsg(database \%s\ is being accessed by other users,
- dbname),
- errdetail_busy_db(notherbackends, npreparedxacts)));
+ {
+ if (npreparedxacts 0)
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_OBJECT_IN_USE),
+ errmsg(database \%s\ is being blocked by prepared transactions,
+ dbname),
+ errdetail_busy_db(notherbackends, npreparedxacts)));
+ }
+ else
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_OBJECT_IN_USE),
+ errmsg(database \%s\ is being accessed by other users,
+ dbname),
+ errdetail_busy_db(notherbackends, npreparedxacts)));
+ }
+ }
/*
* Get old and new database paths
--
Sent via pgsql
[HACKERS] Small patch removing the crypt auth from sample pg_hba.conf
Hello, although the crypt auth functionality is removed i 8.4 i found a remnant in the sample pg_hba.conf file. The attached patch removes the keyword from the config file. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Index: src/backend/libpq/pg_hba.conf.sample === RCS file: /projects/cvsroot/pgsql/src/backend/libpq/pg_hba.conf.sample,v retrieving revision 1.66 diff -u -3 -p -r1.66 pg_hba.conf.sample --- src/backend/libpq/pg_hba.conf.sample 20 Nov 2008 11:48:26 - 1.66 +++ src/backend/libpq/pg_hba.conf.sample 31 Mar 2009 22:02:53 - @@ -34,7 +34,7 @@ # the number of significant bits in the mask. Alternatively, you can write # an IP address and netmask in separate columns to specify the set of hosts. # -# METHOD can be trust, reject, md5, crypt, password, gss, sspi, +# METHOD can be trust, reject, md5, password, gss, sspi, # krb5, ident, pam, ldap or cert. Note that password sends passwords # in clear text; md5 is preferred since it sends encrypted passwords. # -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Validating problem in the isn contrib module
On Fri, 06 Mar 2009 00:32:40 +0100 Bernd Helmle wrote:
--On Freitag, März 06, 2009 02:26:12 +0100 Andreas 'ads' Scherbaum
adsm...@wars-nicht.de wrote:
test=# select is_valid('978-3-937514-69-6'::isbn13);
ERROR: invalid check digit for ISBN number: 978-3-937514-69-6,
should be 7 ROW 1: select is_valid('978-3-937514-69-6'::isbn13);
According to the docs, this is intended behavior. If you want to validate
those values later or yourself, you have to use the weak mode:
No.
Straight from the source:
-- isn_weak(boolean) - Sets the weak input mode.
-- This function is intended for testing use only!
The validator function should use the weak mode for itself to return
'f' in case of invalid input. It cannot be the users job to make sure a
validator function is working as expected.
Bye
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Validating problem in the isn contrib module
On Fri, 6 Mar 2009 07:14:20 +0100 A. Kretschmer wrote: Nice advertisement for your book... Actually the example is copypaste from the .tex file ;-) Bye -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Validating problem in the isn contrib module
On Fri, 06 Mar 2009 10:50:41 + Gregory Stark wrote: Andreas 'ads' Scherbaum adsm...@wars-nicht.de writes: The validator function should use the weak mode for itself to return 'f' in case of invalid input. It cannot be the users job to make sure a validator function is working as expected. Well the input function is being called before the validator function ever gets a chance to act. The validator function receives an already-formed isbn13 datum. That's the problem. Is there an is_valid() which takes text input? Perhaps there should be -- though I think it would have to be isbn_is_valid() or something like that. I think that's the intention of the is_valid() function. However it's not working. And yes, a moe descriptive name would be fine. Bye -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Validating problem in the isn contrib module
On Fri, 06 Mar 2009 12:44:31 +0100 Bernd Helmle wrote: --On Freitag, März 06, 2009 11:32:14 +0100 Andreas 'ads' Scherbaum adsm...@wars-nicht.de wrote: I don't see anything that's not already documented. is_valid() checks the presence of the invalid (!) marker only. It looks like the author never intended is_valid() to be a check wether this ISBN is semantically correct, this is done by the input routines before. So this function is useless. If the syntax is valid, the check is already done and is_valid() returns true. If the syntax is invalid, PG will raise an error even before this function returns. The invalid marker is not checked at all. This leads back to my initial question: intended behaviour or just a bug? And how can one validate an ISBN without raising an error? Bye -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Validating problem in the isn contrib module
On Fri, 06 Mar 2009 10:27:52 -0500 Tom Lane wrote: Judging from the comments, is_valid (and the internal validity bit) were a bad design decision that the author later regretted, but felt he couldn't change for compatibility reasons. I'm not sure why not ... we make bigger incompatible changes than that all the time. Looks a bit ugly and the way this module handles the input is unusual. The way to validate an ISBN is exactly the same as it is for every other data type: feed the string to the input function and see if it throws an error. For the record here's a function which validates a text if it contains an ISBN-13, similar functions are possible for the other datatypes defined by isn: CREATE OR REPLACE FUNCTION validate_isbn13(TEXT) RETURNS BOOLEAN AS $$ DECLARE isbn_nr ALIAS FOR $1; weak_status BOOLEAN; isbn_status BOOLEAN; BEGIN -- make sure weak mode is off weak_status := isn_weak(FALSE); -- this will either return 'true' or throw an exception isbn_status := is_valid(isbn_nr::isbn13); weak_status := isn_weak(weak_status); RETURN isbn_status; EXCEPTION -- handle (only) the exception which is thrown by is_valid() WHEN invalid_text_representation THEN RETURN false; END; $$ LANGUAGE 'plpgsql'; Bye -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Validating problem in the isn contrib module
Hello all,
i'm playing around with the isn contrib module and ran into an
annoying problem. The module defines an is_valid() function which
obviously is intended to check the validity of an ISBN number. Makes
sense to have such a function because if the user mistyped the number
the application can raise an error.
Now it seems that instead of the application PostgreSQL is raising the
error:
test=# select is_valid('978-3-937514-69-7'::isbn13);
is_valid
--
t
(1 row)
test=# select is_valid('978-3-937514-69-6'::isbn13);
ERROR: invalid check digit for ISBN number: 978-3-937514-69-6,
should be 7 ROW 1: select is_valid('978-3-937514-69-6'::isbn13);
^
The first ISBN is valid and the validator function returns 't', that's
fine. The second ISBN is invalid, i mistyped one number. The expected
output is 'f', PG is not supposed to raise an error and break my entire
transaction.
Is this just a bug or is this intended behaviour. And if it's not a
bug, how can i validate an ISBN number in my application - without
raising an error?
Thank you kind regards
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for str_numth() in PG 7.4
On Tue, 13 Jan 2009 12:30:09 -0300 Alvaro Herrera wrote: The other cases were already handled, so Andreas' initial patch was enough -- applied. Thank you. Bye -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Patch for str_numth() in PG 7.4
Hello, even if 7.4 is almost at the end of it's lifetime i found a bug/problem on a fairly new laptop (not surprising: during upgrade tests). All timestamp regression tests failed, only th was emitted. I tracked the problem done to the function str_numth() in src/backend/utils/adt/formatting.c. The fix (attached) is easy: i stole the function code from the latest 8.0 version which looks fare more sane in handling the string pointers. Since this patch is easy enough (replacing one line with three lines of code), does not seem to break existing code and removes at least one bug i ask to include this patch into the next 7.4 release (i assume there will be at least one release if 7.4 reaches eol). Thanks kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors *** src/bin/psql/describe.c 2008-12-21 13:19:40.0 +0100 --- src/bin/psql/describe.c.orig 2008-12-21 02:16:31.0 +0100 *** *** 464,476 d.datctype as \%s\,\n, gettext_noop(Collation), gettext_noop(Ctype)); ! if (pset.sversion = 80100) ! appendPQExpBuffer(buf, ! pg_catalog.array_to_string(d.datacl, E'\\n') as \%s\, ! gettext_noop(Access Privileges)); ! else ! appendPQExpBuffer(buf, ! pg_catalog.array_to_string(d.datacl, '\\n') as \%s\, gettext_noop(Access Privileges)); if (verbose pset.sversion = 80200) appendPQExpBuffer(buf, --- 464,471 d.datctype as \%s\,\n, gettext_noop(Collation), gettext_noop(Ctype)); ! appendPQExpBuffer(buf, ! d.datacl as \%s\, gettext_noop(Access Privileges)); if (verbose pset.sversion = 80200) appendPQExpBuffer(buf, -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for str_numth() in PG 7.4
Hello all,
On Mon, 12 Jan 2009 22:55:32 +0100 Andreas 'ads' Scherbaum wrote:
I tracked the problem done to the function str_numth() in
src/backend/utils/adt/formatting.c. The fix (attached) is easy: i
stole the function code from the latest 8.0 version which looks fare
more sane in handling the string pointers.
Now with the correct patch attached, thanks to anyone who pointed this
out ;-)
Kind regards
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
diff -rc postgresql-7.4.23.orig/src/backend/utils/adt/formatting.c postgresql-7.4.23.patch/src/backend/utils/adt/formatting.c
*** postgresql-7.4.23.orig/src/backend/utils/adt/formatting.c 2007-06-29 03:52:14.0 +0200
--- postgresql-7.4.23.patch/src/backend/utils/adt/formatting.c 2009-01-12 22:39:47.0 +0100
***
*** 1444,1450
static char *
str_numth(char *dest, char *num, int type)
{
! sprintf(dest, %s%s, num, get_th(num, type));
return dest;
}
--- 1444,1452
static char *
str_numth(char *dest, char *num, int type)
{
! if (dest != num)
! strcpy(dest, num);
! strcat(dest, get_th(num, type));
return dest;
}
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [patch] Reformat permissions in \l+ (like \z does)
On Wed, 31 Dec 2008 13:08:20 -0500 Tom Lane wrote: Andreas 'ads' Scherbaum adsm...@wars-nicht.de writes: On Sun, 28 Dec 2008 18:19:48 -0500 Tom Lane wrote: If we're going to do this, shouldn't it happen uniformly for *all* ACL displays in describe.c? Makes sense, imho. Done. Oh, thanks. The updated patch was on my todo. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [patch] Reformat permissions in \l+ (like \z does)
On Sun, 28 Dec 2008 18:19:48 -0500 Tom Lane wrote: Andreas 'ads' Scherbaum adsm...@wars-nicht.de writes: the march 2008 commitfest added a patch[1] with extended information for \l+. The may 2008 commitfest added a patch[2] which reformats the permission output in \z. I like the new output in \z, but the \l+ output is still missing this feature. The attached patch solves this problem. If we're going to do this, shouldn't it happen uniformly for *all* ACL displays in describe.c? Makes sense, imho. I just stumbled over this one by checking the list of new patches for 8.4. Other opinions? Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [patch] Reformat permissions in \l+ (like \z does)
Hello, the march 2008 commitfest added a patch[1] with extended information for \l+. The may 2008 commitfest added a patch[2] which reformats the permission output in \z. I like the new output in \z, but the \l+ output is still missing this feature. The attached patch solves this problem. Kind regards 1: http://archives.postgresql.org/message-id/488c2fe3-a6c7-4cfa-bd3c-f0588da81...@tcpd.net 2: http://archives.postgresql.org/message-id/37ed240d0804170921h7a6b92fev65aeb99f658f8...@mail.gmail.com -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors *** src/bin/psql/describe.c 2008-12-21 13:19:40.0 +0100 --- src/bin/psql/describe.c.orig 2008-12-21 02:16:31.0 +0100 *** *** 464,476 d.datctype as \%s\,\n, gettext_noop(Collation), gettext_noop(Ctype)); ! if (pset.sversion = 80100) ! appendPQExpBuffer(buf, ! pg_catalog.array_to_string(d.datacl, E'\\n') as \%s\, ! gettext_noop(Access Privileges)); ! else ! appendPQExpBuffer(buf, ! pg_catalog.array_to_string(d.datacl, '\\n') as \%s\, gettext_noop(Access Privileges)); if (verbose pset.sversion = 80200) appendPQExpBuffer(buf, --- 464,471 d.datctype as \%s\,\n, gettext_noop(Collation), gettext_noop(Ctype)); ! appendPQExpBuffer(buf, ! d.datacl as \%s\, gettext_noop(Access Privileges)); if (verbose pset.sversion = 80200) appendPQExpBuffer(buf, -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] FOSDEM 2009 Call for Papers - deadline
Hello all, FOSDEM 2009 will take place february 7-8 2009 in Brussels, Belgium. We want to continue the great success from last year and again we have a booth, and a devroom together with the BSD groups. Please submit your talk(s) to [EMAIL PROTECTED] until 2009-01-02, include the topic and the length of the talk. You may choose between: - 50 minutes talk (~35 minutes talk + 15 minutes discussion) - 25 minutes talk (~15 minutes talk + 10 minutes discussion) - lightning talk (5 minutes, cut short) Every talk is welcome, from internal hacker discussion to real-world examples and presentations about new and shiny features. The talk committee consists of Gregory Stark, Koen Martens, Magnus Hagander and Andreas Scherbaum. More information are available at: http://wiki.postgresql.eu/wiki/FOSDEM_2009 Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Parsing of pg_hba.conf and authentication inconsistencies
Hello, On Sat, 02 Aug 2008 18:37:25 +0200 Magnus Hagander wrote: Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: We could catch some simple problems at file load time, perhaps, but those usually aren't the ones that cause trouble for people. It would catch things like typos, invalid CIDR address/mask and specifying an auth method that doesn't exist. This is the far most common errors I've seen - which ones are you referring to? it may not be the far most common error but of course it's a big problem. For the DBA: if the configfile is in a version control system you first have to edit the file again, search the error, submit the file and then restart the DB - if you got the syntax error during a database restart you are cursing all the time because the database is offline right now. For an newbie: as mentioned before, this guy doesn't even know where to look for an error, but the database is offline. Stupid Postgres, i want something else which is working. Of course a syntax check before or on startup cannot check for all errors, especially not for logic errors but if we can exclude any syntax error that would be a big help. For myself i don't care which tool is doing the check as long as it's possible to check the config at all. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses
On Fri, 13 Jun 2008 16:14:13 -0400 Alvaro Herrera wrote: Andrew Sullivan wrote: This is because DNS RRs have a TTL on them, so looking up the host at any moment other than when you're actually doing the authentication is prone to error. Perhaps the solution to this problem is to do the lookups and store the TTL of each answer. At the time of actually checking you need only get a new answer for those that expired. That's too much overhead in the postmaster. A better way would be some documentation how one can improve the DNS performance, like using an external DNS cache ect. I would also like to see a note that the DNS lookup could seriously slow down the authentication process. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Overhauling GUCS
On Thu, 05 Jun 2008 12:53:55 -0700 Ron Mayer wrote: Steve Atkins wrote: ... cross-platform (Windows, Linux, Solaris, OS X as a bare minimum) I wonder how cross-platform the tuning algorithm itself is. I could also imagine that decisions like do I let the OS page cache, or postgres's buffer cache get most of the memory are extremely OS dependent. But you can hide most of the internal stuff from the user, either by generating the config file for the platform the tool is running on or by an option like generate config for platform xyz. If you have cross-platform already in place, this should not be much overhead. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Core team statement on replication in PostgreSQL
On Mon, 02 Jun 2008 11:52:05 -0400 Chris Browne wrote: [EMAIL PROTECTED] (Andreas 'ads' Scherbaum) writes: On Thu, 29 May 2008 23:02:56 -0400 Andrew Dunstan wrote: Well, yes, but you do know about archive_timeout, right? No need to wait 2 hours. Then you ship 16 MB binary stuff every 30 second or every minute but you only have some kbyte real data in the logfile. This must be taken into account, especially if you ship the logfile over the internet (means: no high-speed connection, maybe even pay-per-traffic) to the slave. If you have that kind of scenario, then you have painted yourself into a corner, and there isn't anything that can be done to extract you from it. You are misunderstanding something. It's perfectly possible that you have a low-traffic database with changes every now and then. But you have to copy a full 16 MB logfile every 30 seconds or every minute just to have the slave up-to-date. Consider: If you have so much update traffic that it is too much to replicate via WAL-copying, why should we expect that other mechanisms *wouldn't* also overflow the connection? For some MB real data you copy several GB logfiles per day - that's a lot overhead, isn't it? If you haven't got enough network bandwidth to use this feature, then nobody is requiring that you use it. It seems like a perfectly reasonable prerequisite to say this requires that you have enough bandwidth. If you have a high-traffic database, then of course you need an other connection as if you only have a low-traffic or a mostly read-only database. But that's not the point. Copying an almost unused 16 MB WAL logfile is just overhead - especially because the logfile is not compressable very much because of all the leftovers from earlier use. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Core team statement on replication in PostgreSQL
On Thu, 29 May 2008 09:22:26 -0700 Steve Atkins wrote: On May 29, 2008, at 9:12 AM, David Fetter wrote: Either one of these would be great, but something that involves machines that stay useless most of the time is just not going to work. I have customers who are thinking about warm standby functionality, and the only thing stopping them deploying it is complexity and maintenance, not the cost of the HA hardware. If trivial-to-deploy replication that didn't offer read-only access of the slaves were available today I'd bet that most of them would be using it. Sure, have a similar customer. They are right now using a set of Perl-scripts which ship the logfiles to the slave, take care of the status, apply the logfiles, validate checksums ect ect. The whole thing works very well in combination with RedHat cluster software, but it took several weeks to implement the current solution. Not everyone wants to spend the time and the manpower to implement a simple replication. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Core team statement on replication in PostgreSQL
On Thu, 29 May 2008 18:29:01 -0400 Tom Lane wrote: Dimitri Fontaine [EMAIL PROTECTED] writes: While at it, would it be possible for the simple part of the core team statement to include automatic failover? No, I think it would be a useless expenditure of energy. Failover includes a lot of things that are not within our purview: switching IP addresses to point to the new server, some kind of STONITH solution to keep the original master from coming back to life, etc. Moreover there are already projects/products concerned with those issues. True words. Failover is not and should not be part of PostgreSQL. But PG can help the failover solution, as example: an easy-to-use interface about the current slave status comes into my mind. Other ideas might also be possible. It might be useful to document where to find solutions to that problem, but we can't take it on as part of core Postgres. Ack Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Core team statement on replication in PostgreSQL
On Thu, 29 May 2008 23:02:56 -0400 Andrew Dunstan wrote: Well, yes, but you do know about archive_timeout, right? No need to wait 2 hours. Then you ship 16 MB binary stuff every 30 second or every minute but you only have some kbyte real data in the logfile. This must be taken into account, especially if you ship the logfile over the internet (means: no high-speed connection, maybe even pay-per-traffic) to the slave. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Core team statement on replication in PostgreSQL
On Fri, 30 May 2008 16:22:41 -0400 (EDT) Greg Smith wrote: On Fri, 30 May 2008, Andreas 'ads' Scherbaum wrote: Then you ship 16 MB binary stuff every 30 second or every minute but you only have some kbyte real data in the logfile. Not if you use pg_clearxlogtail ( http://www.2ndquadrant.com/replication.htm ), which got lost in the giant March commitfest queue but should probably wander into contrib as part of 8.4. Yes, this topic was discussed several times in the past but to solve this it needs a patch/solution which is integrated into PG itself, not contrib. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Core team statement on replication in PostgreSQL
On Fri, 30 May 2008 17:05:57 -0400 Andrew Dunstan wrote: Andreas 'ads' Scherbaum wrote: On Thu, 29 May 2008 23:02:56 -0400 Andrew Dunstan wrote: Well, yes, but you do know about archive_timeout, right? No need to wait 2 hours. Then you ship 16 MB binary stuff every 30 second or every minute but you only have some kbyte real data in the logfile. This must be taken into account, especially if you ship the logfile over the internet (means: no high-speed connection, maybe even pay-per-traffic) to the slave. Sure there's a price to pay. But that doesn't mean the facility doesn't exist. And I rather suspect that most of Josh's customers aren't too concerned about traffic charges or affected by such bandwidth restrictions. Certainly, none of my clients are, and they aren't in the giant class. Shipping a 16Mb file, particularly if compressed, every minute or so, is not such a huge problem for a great many commercial users, and even many domestic users. The real problem is not the 16 MB, the problem is: you can't compress this file. If the logfile is rotated it still contains all the old binary data which is not a good starter for compression. So you may have some kB changes in the wal logfile every minute but you still copy 16 MB data. Sure, it's not so much - but if you rotate a logfile every minute this still transfers 16*60*24 = ~23 GB a day. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] triggers on prepare, commit, rollback... ?
On Tue, 20 May 2008 19:51:32 +0100 Sam Mason wrote: On Tue, May 20, 2008 at 01:20:48PM -0400, Greg Smith wrote: On Tue, 20 May 2008, Hannu Krosing wrote: Tell others that this trx failed, maybe log a failure ? OTOH, this can be implemented by a daemon that sits on tail -f logfile | grep ROLLBACK In order to follow the log files like that successfully in many environments, you need to stay in sync as the underlying log file changes (it might rotate every day for example). Unfortunately it's not as simple as just using tail. GNU tail provides the -F (or --follow=name) for just this reason. Not every system is GNU. Not every possible configuration uses the same logfile name for the next logfile. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Protection from SQL injection
On Tue, 29 Apr 2008 22:18:48 +0200 Thomas Mueller wrote: For PostgreSQL the 'disable literals' feature would be great publicity: PostgreSQL would be the first only major database that has a good story regarding SQL injection. Yes it's not the magic silver bullet, but databases like MS SQL Server, Oracle or MySQL would look really bad. I don't think so. Given the fact that enabling this feature by default would break almost all applications, you have to disable this by default. No use here because almost nobody will know about it. Oh, and i can see the headlines: New PostgreSQL feature breaks 99% applications. Forbidding literals will break absolutely every SQL-using application on the planet Well, it's optional. If a developer or admin wants to use it, he will know that it could mean some work. The developers and admins who know about this feature and want to use it are also the developers and admins who know about SQL injections. Eventually the code quality produced by this ppl is higher than average and less likely to have such basic faults. Even if the feature is not enabled, it's still good to have it. Huh? How this? Just because one can say We have a feature against SQL injections which will not be used by literally anyone? Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] get rid of psql welcome message
On Thu, 17 Apr 2008 15:58:10 +0200 Peter Eisentraut wrote: Mike Aubury wrote: Am I missing something.. $ psql -q testdb testdb=# This also quiets out a few other unrelated things. Like all \timing messages *grumble* -- Andreas 'ads' Scherbaum German PostgreSQL User Group -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] get rid of psql welcome message
On Thu, 17 Apr 2008 09:30:04 -0400 Stephen Frost wrote: * Peter Eisentraut ([EMAIL PROTECTED]) wrote: Around http://archives.postgresql.org/pgsql-patches/2008-01/msg00089.php it was proposed to truncate the psql welcome screen. What do you think about that? I'd recommend an option in .psqlrc to disable it, if possible. That would be in line with what alot of other splash-screen type things do. As long as the default is to display the welcome message, that's ok. Like Simon explained it would be no good if we change the default behavior. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Binary data type with other output method
On Wed, 26 Dec 2007 20:20:59 -0500 Andrew Dunstan wrote: Andreas 'ads' Scherbaum wrote: The reason for my question is: PHP (yes *grumble*) does not recognize boolean columns but instead makes a simple string from a PG boolean. So every time you select a boolean column in PHP, you cannot use expressions like: if (!$bool) because 't' and 'f' give TRUE in PHP. I was begged many times by our people coding PHP to find a workaround for this problem. The answer is surely to fix the PHP driver rather than trying to mangle Postgres. The Perl DBD::Pg driver does not suffer this problem, so it can certainly be worked around (in fact in DBD::Pg you get a choice if 1/0 or t/f values for booleans). This PHP driver is in use since years, do you really expect they will fix this bug and make thousands of applications fail? Everyone like Mark who posted an example earlier would have to change the PHP code if the variable is now a true/false boolean instead a 't'/'f' string. No, i don't expect a bugfix here. Newer drivers like PDO seems to behave correct but this will not help if you cannot use this driver. As i told earlier, this is really a PHP bug, since libpq knows the type of every returned row in PQftype. DBD::Pg and PHP PDO seems to use this information. Anyway, this does not help in my case. My question was if there is a shorter way to create a boolean type with another output than to recreate all the casts, operators ect. If not, i have to go with this approach but maybe someone else has a more elegant idea. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Binary data type with other output method
On Thu, 27 Dec 2007 08:52:15 -0500 Andrew Dunstan wrote: Andreas 'ads' Scherbaum wrote: On Wed, 26 Dec 2007 20:20:59 -0500 Andrew Dunstan wrote: This PHP driver is in use since years, do you really expect they will fix this bug and make thousands of applications fail? Everyone like Mark who posted an example earlier would have to change the PHP code if the variable is now a true/false boolean instead a 't'/'f' string. No, i don't expect a bugfix here. Newer drivers like PDO seems to behave correct but this will not help if you cannot use this driver. I don't see why it couldn't be switchable behaviour, just as it is in DBD::Pg. Maybe because the PHP folks don't care so much? I don't know. Already discussed this one on IRC but there's not so much love for fixing this issue, as far as i can see. Either i got: MySQL does this right in returning 0/1, so we don't care or i got other drivers fixed this problem, use this one. i considered this one but this would only bring 0/1 as input, not as output values, which is what i want. er, what? This domain would have input and output values of 0/1. Yes, but i will loose 't', 'true', 'f' and 'false', the usual input values in PostgreSQL beside '0' and '1'. It's not that the people don't use true/false, they use this a lot. But they expect boolean variable in PHP working like a bolean column in PG ... without casts, without extra workarounds in the code. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Binary data type with other output method
On Thu, 27 Dec 2007 11:39:29 -0500 Andrew Dunstan wrote: Andreas 'ads' Scherbaum wrote: i considered this one but this would only bring 0/1 as input, not as output values, which is what i want. er, what? This domain would have input and output values of 0/1. Yes, but i will loose 't', 'true', 'f' and 'false', the usual input values in PostgreSQL beside '0' and '1'. It's not that the people don't use true/false, they use this a lot. But they expect boolean variable in PHP working like a bolean column in PG ... without casts, without extra workarounds in the code. If your code is prepared to emit t/f but not accept it then that seems to violate Postel's admonition: Be *liberal* in what you *accept*, and *conservative* in what you send. Andrew: your workaround was to create a domain which would use 0/1 ... this idea will not behave like a boolean, because it does not accept 'true'/'false'. My replacement boolean type does accept all this input values and does emit 0/1 instead of 'f'/'t'. But since i have to create all the casts, operators and classes (like for boolean) again for my data type, i asked if someone know a more elegant way ... if not, i will use my data type. You can see the code here: http://andreas.scherbaum.la/writings/boolean.sql This are some hundred lines of SQL which are almost doubled from the boolean type. So maybe there's a way to avoid all this, but i haven't found one. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Binary data type with other output method
Hello, On Tue, 25 Dec 2007 20:11:45 -0500 Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I think you'd really need a separate type. But have you considered something simple like CREATE DOMAIN boolint AS int CHECK (value = 0 OR value = 1) i considered this one but this would only bring 0/1 as input, not as output values, which is what i want. The reason for my question is: PHP (yes *grumble*) does not recognize boolean columns but instead makes a simple string from a PG boolean. So every time you select a boolean column in PHP, you cannot use expressions like: if (!$bool) because 't' and 'f' give TRUE in PHP. I was begged many times by our people coding PHP to find a workaround for this problem. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Binary data type with other output method
On Wed, 26 Dec 2007 17:12:33 -0500 Mark Mielke wrote: Andreas 'ads' Scherbaum wrote: The reason for my question is: PHP (yes *grumble*) does not recognize boolean columns but instead makes a simple string from a PG boolean. So every time you select a boolean column in PHP, you cannot use expressions like: if (!$bool) because 't' and 'f' give TRUE in PHP. I was begged many times by our people coding PHP to find a workaround for this problem If you find a good solution, feel free to share. :-) I have had this annoy me for about 6 months now. I forget what configuration change I did, but booleans stopped working for exactly this reason (where they did work in the past). For lack of time or care, my PHP now has added === 't' ? true : false in various places... :-) It has worked once? Never seen this working in PHP. I know, that some other database drivers for PHP do a better job here, but pure PHP fails. Yes, i can cast every result in every query or i can use your workaround, but this is silly and a common source of errors. Since this is a logic error, not a syntax error, you never find out in the first place but only with debugging. Kind regards -- Andreas 'ads' Scherbaum Failure is not an option. It comes bundled with your Microsoft product. (Ferenc Mantfeld) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Binary data type with other output method
Hello all, i'm in the need to create a boolean datatype which returns an integer instead of the usual 't'/'f'. Before anyone starts to point me at casts: it's a lot overhead to cast some hundred occurances beside the source of trouble, if you forget one. And so i asked myself, if there is an easier way than my current approach. Right now i'm creating input/output functions, the datatype and a lot of casts and operators (350 lines SQL) just to get another output: CREATE FUNCTION boolean2_in(cstring) RETURNS boolean2 AS 'boolin' LANGUAGE internal STRICT; CREATE FUNCTION boolean2_out(boolean2) RETURNS cstring AS 'int2out' LANGUAGE internal STRICT; CREATE FUNCTION boolean2_recv(internal) RETURNS boolean2 AS 'boolrecv' LANGUAGE internal STRICT; CREATE FUNCTION boolean2_send(boolean2) RETURNS bytea AS 'boolsend' LANGUAGE internal STRICT; CREATE TYPE boolean2 ( input = boolean2_in, output = boolean2_out, receive = boolean2_recv, send = boolean2_send, internallength = 1, alignment = char, storage = plain, passedbyvalue ); CREATE CAST (boolean2 AS boolean) WITHOUT FUNCTION AS ASSIGNMENT; CREATE CAST (boolean AS boolean2) WITHOUT FUNCTION AS ASSIGNMENT; ... and so on. Can i have this in an easier way? Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Binary data type with other output method
Hello, On Tue, 25 Dec 2007 11:10:25 -0500 Andrew Dunstan wrote: Andreas 'ads' Scherbaum wrote: i'm in the need to create a boolean datatype which returns an integer instead of the usual 't'/'f'. Before anyone starts to point me at casts: it's a lot overhead to cast some hundred occurances beside the source of trouble, if you forget one. Do you really need a new datatype or just to change the output behaviour of the inbuilt type? That should be quite easy to do in just a few lines of code. Just another output behavior would be enough ... but without changing the PG source itself. Since the package comes with the distribution, there's no way to build PG from source. Kind regads -- Andreas 'ads' Scherbaum German PostgreSQL User Group ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Binary data type with other output method
Hello, On Tue, 25 Dec 2007 22:12:23 +0500 imad wrote: Why dont you provide a cast, I dont see an overhead in typbyval datatypes. I already have a cast from my type to PGs internal boolean ... or what do you mean? Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Status report on 8.3 release
Hello, On Thu, 29 Nov 2007 17:21:09 -0500 Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: So are there no plans for an additional beta? Yes, there are, but not till we do something about http://archives.postgresql.org/pgsql-hackers/2007-11/msg01302.php i would also like to test another Beta, if we do something about this problem: http://archives.postgresql.org/pgsql-hackers/2007-11/msg00960.php Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Status report on 8.3 release
On Fri, 30 Nov 2007 11:26:35 +1100 Brendan Jurd wrote: On Nov 30, 2007 11:10 AM, Andreas 'ads' Scherbaum [EMAIL PROTECTED] wrote: i would also like to test another Beta, if we do something about this problem: http://archives.postgresql.org/pgsql-hackers/2007-11/msg00960.php Hi Andreas, Tom's already committed the quote_literal(anyelement) function. http://archives.postgresql.org/pgsql-committers/2007-11/msg00530.php Ups, i've overseen this one. Forget my posting and i will keep testing the next beta ;-) Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] PG 7.3 is five years old today
On Tue, 27 Nov 2007 15:37:04 -0500 Tom Lane wrote: Andreas 'ads' Scherbaum [EMAIL PROTECTED] writes: On Tue, 27 Nov 2007 11:08:58 -0800 Joshua D. Drake wrote: Release 7.3.21 with and EOL addendum :). E.g; this is the last release of 7.3 and 7.3 is now considered unsupported. I know at least one customer who is using RHEL-3 and PG 7.3 on dozens machines worldwide. Are they running 7.3.20? Will they update to 7.3.21 promptly when we ship it? Or are they using whatever Red Hat includes in RHEL-3? (which is still 7.3.19 I believe) I'm not sure, which micro version they are using right now. I only know, they have 7.3.x, cause i already had to take care of this on some projects. One of the reasons for losing interest in frequent updates is that it seems most of the people we hear from who are running 7.3.x are running a pretty obsolete x. If we produce an update and no one actually installs it, we're just wasting time with make-work. I said: we should not disband support of 7.3 today, release a final version next week and that's it. Something like 3, 4 month of pre-announce seems to be ok for me and i don't think, this makes much difference. Kind regards -- Andreas 'ads' Scherbaum Failure is not an option. It comes bundled with your Microsoft product. (Ferenc Mantfeld) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] PG 7.3 is five years old today
On Tue, 27 Nov 2007 23:53:14 -0500 Robert Treat wrote: I also think we should be a bit more generous on the EOL notice. Saying one more update after 8.3 is akin to giving a 1 month EOL notice; not friendly at all imo. Set it for July 2008 and I think you have given plenty of notice (and given the lack of back patches, should be too much of a burden in that time either) +1 for that. Kind regards -- Andreas 'ads' Scherbaum Failure is not an option. It comes bundled with your Microsoft product. (Ferenc Mantfeld) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] PG 7.3 is five years old today
On Tue, 27 Nov 2007 11:08:58 -0800 Joshua D. Drake wrote: Release 7.3.21 with and EOL addendum :). E.g; this is the last release of 7.3 and 7.3 is now considered unsupported. I know at least one customer who is using RHEL-3 and PG 7.3 on dozens machines worldwide. Yes, they are moving to 8.2 but this will require some more month and eventually not all machines can just be updated to a newer OS/DB version. So i'm also for stopping support for 7.3 but not the way you proposed. If we have supported 7.3 up to now, there should be an official notice with a date, when support ends. This date should not be the next and final release some days after the notice ;-) Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] quote_literal(integer) does not exist
On Sat, 24 Nov 2007 21:17:39 -0500 Tom Lane wrote: Andreas 'ads' Scherbaum [EMAIL PROTECTED] writes: we have some plpgsql functions which use quote_literal() regardless of the data type. With Beta 3 this does not work anymore[1]. If you're unwilling to fix your application, you can hack around that for yourself. regression=# select quote_literal(42); ERROR: function quote_literal(integer) does not exist LINE 1: select quote_literal(42); ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. regression=# create function quote_literal(anyelement) returns text as $$ regression$# select pg_catalog.quote_literal($1 :: pg_catalog.text) regression$# $$ language sql; CREATE FUNCTION regression=# select quote_literal(42); quote_literal --- '42' (1 row) Already had a similar function in my test case, but yours is more elegant. I also think, that we will fix our applications or at least most of them. But that's not the point: more people will run into this problem and this looks like a showstopper for updating to 8.3. By the way, the function is named quote_literal(), not quote_text(). From my point of view i expect to get everything correctly quoted, what's feeded as input into this function. Given the fact, that previous versions accepted every input without notice about the implicit cast, i don't see not so much blame in the application. Kind regards -- Andreas 'ads' Scherbaum PostgreSQL User Group Germany ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] quote_literal(integer) does not exist
On Mon, 26 Nov 2007 06:35:20 +1100 Brendan Jurd wrote: On Nov 26, 2007 5:23 AM, Tom Lane [EMAIL PROTECTED] wrote: I'm all for the idea of making people conscious of text coercions in general, but in the *particular* case of quote_literal, having it only accept text is undesirable, unintuitive and most importantly, it will break apps which otherwise may have been able to enjoy a smooth transition to 8.3. I would argue that quote_literal should have been set up to accept anyelement in the very first place, and I'd guess that the original choice of text as an argument type was partially driven by the understanding that everything gets coerced to text, making it a de facto anyelement substitute. Or maybe anyelement wasn't available when it was introduced. Either way, if quote_literal() is all about safely stuffing variables into dynamic queries, the new behaviour is a regression. In context, it makes perfect sense to throw integers, numerics and whatever else at quote_literal and expect it to Just Work. The problem for me is: we expect and encourage people to do safe programming and now they have to debug their programs and remove some of the safe parts just to make PostgreSQL happy. As you said, that is not, what the average programmer expect. My feeling is that the change in text coercion behaviour has well illuminated that the text argument type for quote_literal isn't ideal. Great! Let's fix it. Yes, Tom Lane is right that the current behavior is broken. But the solution cannot be to exclude anything beside text but instead we should move forward to accept anything (at least, if it's possible). As a not-too-far-away example, I see that the proposed patch Pavel sent in arbitrarily decides to change quote_ident() too, which was not asked for and has got much less justification than changing quote_literal(). That sort of cowboy approach to semantics is not the way to proceed. I'd pass on changing quote_ident. It seems natural for it to take a text argument. I can imagine a lot of people using, say, quote_literal(int) in the field; I can't imagine the same for quote_ident. True. You can't even create a table who's name is just an integer or where the name starts with an integer, so in any way you already have to use quotes and you are aware of the problem. I can see your reluctance to force an initdb, but what's the greater mischief; forcing initdb in beta, or breaking applications on release? My personal perspective is that it's an easy choice ... avoid breaking the apps, that's what betas are for. Yeah, that's what a beta is for. We don't expect to have people running production systems with beta software so it needs an reinstall anyway after the release. Kind regards -- Andreas 'ads' Scherbaum PostgreSQL User Group Germany ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] quote_literal(integer) does not exist
Hello all, testing 8.3b3, i found out an interesting thing: we have some plpgsql functions which use quote_literal() regardless of the data type. With Beta 3 this does not work anymore[1]. Given the fact, that some functions do a lot of work, you (or at least we) don't want to look, if the data you just moving around is from type integer, text or something else. So in the past we just quoted everything which worked fine. I can understand, that enforcing a strict type checking is a fine thing. But given the fact, that PG did a lot of implicit typecasting in the past, removing this is not a real world solution. This will surely prevent some more people from upgrading to 8.3 because the previous fine-working applications will stop working on 8.3. A quote_literal() which can cope with any data type, maybe combined with a warning, would be a better way for a smooth upgrade. Kind regards 1: http://archives.postgresql.org/pgsql-hackers/2007-08/msg00697.php -- Andreas 'ads' Scherbaum PostgreSQL User Group Germany ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] New feature request: FlashBack Query
Hello, On Sat, 17 Feb 2007 06:49:42 -0800 (PST) RPK [EMAIL PROTECTED] wrote: PostgreSQL, already a mature database, needs to have more options for recovery as compared to proprietary databases. I just worked with Oracle's FlashBack query feature in Oracle 9i and FlashBack Table feature in 10g. Future versions of PostgreSQL must have similar features which enable users to bring Table(s) and/or Database(s) to a desired Time Stamp. There is a pgfoundry project which tries to achieve this: http://pgfoundry.org/projects/tablelog/ Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL Usergroup: http://www.pgug.de ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Problem with windows installer
On Thu, 04 Jan 2007 22:55:52 + Dave Page [EMAIL PROTECTED] wrote: Magnus Hagander wrote: See the FAQ at http://www.postgresql.org/docs/faqs.FAQ_windows.html#3.3 (question 3.3). I discussed this briefly with Robert on IM yesterday - he told me the account was installer created. Without a PC at the time I couldn't look into it further :-( We tried both, let the installer create the user (this works, he also added the service part) and create the user manually (and let the installer do the service part). In any case the installer stops at initdb. Bye -- Andreas 'ads' Scherbaum Failure is not an option. It comes bundled with your Microsoft product. (Ferenc Mantfeld) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Problem with windows installer
Hello all, a friend of mine ran into a problem installing PostgreSQL 8.0.9 on a Windows XP Pro machine. Before anyone is asking: it has to be a 8.0.x version and we even tried to install 8.2 and it did not work. Ok, the problem is: after installing all the files the installer wants to init the db and fails with the following error: Failed to create process for initdb: Anmeldung fehlgeschlagen: Dem Benutzer wurde der geforderte Anmeldetyp auf diesem Computer nicht erteilt. The german message means: Login failed: a requested login type was not given to the user on this computer. Since the message was returned in german and the installer was started in english, the message is generated by windows. The (imho) relevant part from the install log is here: - log - MSI (s) (A4:4C) [22:40:18:343]: Executing op: FileCopy(SourceName=readm~1.vac|README.vacuumlo,SourceCabKey=vacuumlotxt,DestName=README.vacuumlo,Attributes=0,FileSize=1449,PerTick=32768,,VerifyMedia=1,CheckCRC=0,,,InstallMode=58982400,HashOptions=0,HashPart1=-1578222883,HashPart2=1022240769,HashPart3=1742458498,HashPart4=808312946,,) MSI (s) (A4:4C) [22:40:18:343]: File: C:\Programme\PostgreSQL\8.0\doc\contrib\README.vacuumlo; To be installed; Won't patch;No existing file MSI (s) (A4:4C) [22:40:18:343]: Source for file 'vacuumlotxt' is compressed InstallFiles: File: README.vacuumlo, Directory: C:\Programme\PostgreSQL\8.0\doc\contrib\, Size: 1449 MSI (s) (A4:4C) [22:40:18:343]: Note: 1: 2318 2: C:\Programme\PostgreSQL\8.0\doc\contrib\README.vacuumlo MSI (s) (A4:4C) [22:40:18:343]: Executing op: CacheSizeFlush(,) MSI (s) (A4:4C) [22:40:18:343]: Executing op: InstallProtectedFiles(AllowUI=1) MSI (s) (A4:4C) [22:40:18:343]: Executing op: ActionStart(Name=SetPermissions,Description=Setting filesystem permissions...,) Action 22:40:18: SetPermissions. Setting filesystem permissions... MSI (s) (A4:4C) [22:40:18:343]: Executing op: CustomActionSchedule(Action=SetPermissions,ActionType=1025,Source=BinaryData,[EMAIL PROTECTED],CustomActionData=1033;C:\Programme\PostgreSQL\8.0\;C:\Programme\PostgreSQL\8.0\data\;NET1;postgres;uNDDZarK/UM%RmfmZdyBB=)t_~|Qet) MSI (s) (A4:84) [22:40:18:359]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI25.tmp, Entrypoint: [EMAIL PROTECTED] MSI (s) (A4:4C) [22:40:19:546]: Executing op: ActionStart(Name=RunInitdb,Description=Initializing database cluster (this may take a minute or two)...,) Action 22:40:19: RunInitdb. Initializing database cluster (this may take a minute or two)... MSI (s) (A4:4C) [22:40:19:546]: Executing op: CustomActionSchedule(Action=RunInitdb,ActionType=1025,Source=BinaryData,[EMAIL PROTECTED],CustomActionData=1033;C:\Programme\PostgreSQL\8.0\;C:\Programme\PostgreSQL\8.0\data\;5432;;C;SQL_ASCII;postgres;sick2468;NET1;postgres;uNDDZarK/UM%RmfmZdyBB=)t_~|Qet) MSI (s) (A4:BC) [22:40:19:562]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI26.tmp, Entrypoint: [EMAIL PROTECTED] MSI (c) (18:E0) [22:40:20:375]: Note: 1: 2205 2: 3: Error MSI (c) (18:E0) [22:40:20:375]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 2867 DEBUG: Error 2867: The error dialog property is not set The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2867. The arguments are: , , MSI (c) (18:E0) [22:40:20:390]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg Failed to create process for initdb: Anmeldung fehlgeschlagen: Dem Benutzer wurde der angeforderte Anmeldetyp auf diesem Computer nicht erteilt. MSI (s) (A4!E4) [22:40:52:421]: Note: 1: 2205 2: 3: Error MSI (s) (A4!E4) [22:40:52:421]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709 MSI (s) (A4!E4) [22:40:52:421]: Product: PostgreSQL 8.0 -- Failed to create process for initdb: Anmeldung fehlgeschlagen: Dem Benutzer wurde der angeforderte Anmeldetyp auf diesem Computer nicht erteilt. Action ended 22:40:52: InstallFinalize. Return value 3. MSI (s) (A4:4C) [22:40:52:421]: User policy value 'DisableRollback' is 0 MSI (s) (A4:4C) [22:40:52:421]: Machine policy value 'DisableRollback' is 0 - log - Has anyone an idea, what's going wrong here and how to fix this? Here are some ideas we already tried: - manual creating of the postgres user - remove all remnants of the installation including the created user - checking for being a windows superuser - testing the same package/version on two different systems, one XP Home and one XP Pro, works without errors - and yes, some reboots Thanks in advance for your help -- Andreas 'ads' Scherbaum Failure is not an option. It comes bundled with your Microsoft product. (Ferenc Mantfeld) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Catch the commit
On Thu, 30 Jun 2005 00:06:42 +0200 Andreas 'ads' Scherbaum [EMAIL PROTECTED] wrote: is it possible in a module to receive an event, get a trigger fired, get a function called or something like this when the current transaction is about to be committed? Background: In a module (tablelog) i need the latest possible timestamp before committing the data for the case, that there is more then one started transaction. If this happens and the second transaction is commited first, i have for the time the first transaction is going on invalid data in my log. To imagine the problem a little bit: tablelog() does logging of all changes on a table. Here an example: - start of transaction 1 - insert in transaction 1 - start of transaction 2 - insert in transaction 2 - commit transaction 2 - commit transaction 1 In the real world, if i look into the table between commit 2 and 1, i only would see the second insert. But since i have no idea, how to get the time of the commit, for now i log the current timestamp ( now() ). If i use the logged data later and restore the state of the table between the two commits, i see both inserts. Which is actually wrong. The problem only occurs if there are concurrent transactions and only, if a timestamp between the commits is requested. But since it exist, i cannot always be sure to return the correct data. Has anybody an idea about this? Kind regards -- Andreas 'ads' Scherbaum Failure is not an option. It comes bundled with your Microsoft product. (Ferenc Mantfeld) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Catch the commit
Hello, seems like a complicated question: is it possible in a module to receive an event, get a trigger fired, get a function called or something like this when the current transaction is about to be committed? Background: In a module (tablelog) i need the latest possible timestamp before committing the data for the case, that there is more then one started transaction. If this happens and the second transaction is commited first, i have for the time the first transaction is going on invalid data in my log. Has anybody an idea about this? kind regards -- Andreas 'ads' Scherbaum Failure is not an option. It comes bundled with your Microsoft product. (Ferenc Mantfeld) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
