ON_ERROR_STOP or some variant by default?
Sounds reasonable, +1 from me.
Regards
Michael Paesold
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Am 19.08.2008 um 20:47 schrieb Tom Lane:
Bruce Momjian [EMAIL PROTECTED] writes:
Joshua Drake wrote:
Is our backpatch policy documented? It does not appear to be in
developer FAQ.
Seems we need to add it.
I'm not sure that I *want* a formal written-down backpatch policy.
Whether (and
, including a link to the documentation of GUC parameters.
As a kind of starting point for (new) users.
Best Regards
Michael Paesold
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
David E. Wheeler writes:
On Jul 17, 2008, at 03:45, Michael Paesold wrote:
Wouldn't it be possible to create a variant of regexp_replace, i.e.
regexp_replace(citext,citext,text), which would again lower-case
the first two arguments before passing the input to
regexp_replace(text,text
.
Wouldn't it be possible to create a variant of regexp_replace, i.e.
regexp_replace(citext,citext,text), which would again lower-case the
first two arguments before passing the input to
regexp_replace(text,text,text)?
Best Regards
Michael Paesold
--
Sent via pgsql-hackers mailing list (pgsql
a
nonstandard half-measure to drive our thinking, rather than solving
the
real problem which is column-level collations.
Wouldn't you still need per-database and per-table default collations?
At least MySQL does have such a concept.
Best Regards
Michael Paesold
--
Sent via pgsql-hackers mailing
. Regarding the log
messages about orphaned tables, it would be nice if you could add a
hint/detail message explaining how to cleanup those tables. If that's
possible.
Best Regards
Michael Paesold
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
don't think these people need guidance on how to manage the
project, they need some sort of way to feel comfortable saying will
pledge $Y for feature $X in a way that makes sense on both sides.
That's what I thought, too. That page just needs a different title.
Best Regards
Michael Paesold
this performance regression in the 8.3 branch. This
would affect most of the JDBC applications out there, I think.
Best Regards
Michael Paesold
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Am 01.04.2008 um 13:14 schrieb Dave Cramer:
On 1-Apr-08, at 6:25 AM, Michael Paesold wrote:
Am 01.04.2008 um 01:26 schrieb Tom Lane:
While testing the changes I was making to Pavel's EXECUTE USING
patch
to ensure that parameter values were being provided to the planner,
it became
Michael Paesold
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
fixes may sometimes slip in as bug fixes.)
If you all decide against that patch, we might as well just go for RC1. The
catalog changes seem rather trivial, and just a required initdb is no
reason for calling it another beta, IMHO.
Great work on that patch, btw.!
Best Regards
Michael Paesold
the user complained.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Alvaro Herrera wrote:
Michael Paesold wrote:
Simon Riggs wrote:
On Thu, 2007-10-25 at 13:41 -0300, Alvaro Herrera wrote:
...
FWIW I disagree with cancelling just any autovac work automatically; in
my patch I'm only cancelling if it's analyze, on the grounds that if
you have really bad luck
command aliases, e.g. hg cdiff
... to do -c diffs.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
more information when
you already got authentication right and therefore doesn't open an
information leak.
Not sure about the warning when creating a role with a password but
nologin. Could be useful.
Best Regards
Michael Paesold
---(end of broadcast
.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
idea anyway). In that case
they would better issue manual vacuums on such tables.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
, as Heikki suggested. There might be valid work-loads for both
options...
Btw., I am grateful you took up the work here, Simon.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
of beta that
people will complain about more than just restoring dumps. ;-)
So does this approach work for both analyze as well as vacuum?
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ
simple.
What about a new separate lock type for analyze? Couldn't that really
solve the issue? I know I'm just hand-waving here ;-)
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 4: Have you searched our list archives
(even when the maintenance
window ends too early... or perhaps any cleanup task started during a
maintenance window should keep it's maintenance priority?)
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 5: don't forget to increase your
sake, the set transaction read only
should have propagated to the outermost transaction on release s1.
Sounds reasonable to me. I understand SAVEPOINT/RELEASE come from the SQL
standard. So does the SQL standard say anything about this?
Best Regards
Michael Paesold
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
I don't think it's a very good idea to make SET TRANSACTION an alias for
SET LOCAL, because SET TRANSACTION has already got its own meaning in the
SQL spec - it sets transaction modes.
Yeah --- I'm not sure we could even do it without
as a benefit of getting into core and be dump-able.
I guess so. Especially if you change some functions, they will have to
change source code anyway. So you can as well cleanup all functions that
don't fit into a sound naming schema.
Best Regards
Michael Paesold
---(end
in the thread starting here (involving
Tom Lane, Joshua Drake, and Teodor Sigaev):
http://archives.postgresql.org/pgsql-hackers/2007-03/msg00912.php
with the conclusion here:
http://archives.postgresql.org/pgsql-hackers/2007-03/msg00936.php
Best Regards
Michael Paesold
---(end
than the list of
historic startup messages that were removed recently. Just my two €-cents.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
burning cycles. What about a threshold of 10 or 50, to have at least
some sanity limit? Even though the cost of vacuum of a small table is
low, it is still not free, IMHO, no?
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 9: In versions
provide numbers from production high use databases. We could
probably back those down a little and make more reasonable numbers.
Please do so. Perhaps others can also tell their typical settings.
Best Regards
Michael Paesold
---(end of broadcast
, under some circumstances?
Perhaps just move up the my $status.. one line up?
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 6: explain analyze is your friend
no compelling reason to comply with a certain standard here.
Best Regards
Michael Paesold
---(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
case-insensitive. After all this discussion, what about a straight
forward vote? Bruce, we had those before, no?
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http
it off with irrelevant anecdotes in the wrong context.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Marko Kreen wrote:
On 6/21/07, Michael Paesold [EMAIL PROTECTED] wrote:
Marko Kreen wrote:
Considering Postgres will never user either meter or mile
in settings, I don't consider your argument valid.
I don't see the value of having units globally unique (literally).
It's enough
length(n) from test;
length
100017
(1 row)
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
waiting on update from author:
http://archives.postgresql.org/pgsql-patches/2007-04/msg00331.php
Any updates on this?
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
in core.
Best Regards
Michael Paesold
---(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
naptime
for a very active system?
A PostgreSQL database on my laptop for testing. It should use as little
resources as possible while being idle. That would be a scenario for
naptime greater than 60 seconds, wouldn't it?
Best Regards
Michael Paesold
---(end
such.
+1 from me. In case of recovery, I think one should still get the full
output, no? It might be important information then.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http
not even learn about this issue until they are presented
with a failing restore.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about
? (This command would re-sync the trac database
with the repository.) Otherwise I would certainly expect such issues as
Alvaro describes.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
: Table has type numeric, but query expects numeric.
STATEMENT: UPDATE reminder SET reminder_charges='0' WHERE reminder_id=29362
reminder_charges is defined as:
reminder_charges | numeric(5,2) | not null
I guess this is a bug.
Best Regards
Michael Paesold
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
after upgrading from 8.1.5 to 8.1.7, I got errors in the server log when
updating decimal values using string constants.
Have you got a constraint or functional index on that column?
Yes.
Check constraints:
tc_reminder_charges
):
CREATE TABLE tab (
c DECIMAL(5,2) NOT NULL,
CHECK (c = 0)
);
INSERT INTO tab ('0');
Right?
Or at least:
UPDATE tab SET c='0';
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 6: explain analyze is your friend
in accumArrayResult(). Most of the rest of the
code deals with resizing arrays using a double it each time it has
to grow approach, I wonder why this is different?
Without reading the code, I guess that simply means O(n^2) runtime. This
should be fixed, then, right?
Best Regards,
Michael Paesold
be found!
Download PostgreSQL from the primary site
Read this if you would like to host a mirror.
Of course the primary FTP site is already unavailable (530 - maximum
number of users reached).
I get the same error for older releases, too. Can someone look into this?
Best Regards
Michael Paesold
Shane Ambler wrote:
Michael Paesold wrote:
Not being subscribed to any more appropriate list, I post this here on
hackers.
I just wanted to download the postgresql-8.0.9 tarball. The page I got
was this:
Choose a download mirror
Downloading: /source/v8.0.9/postgresql-8.0.9.tar.gz
We could
Magnus Hagander wrote:
Michael Paesold wrote:
I just wanted to download the postgresql-8.0.9 tarball. The
page I got was this:
Choose a download mirror
Downloading: /source/v8.0.9/postgresql-8.0.9.tar.gz
We could not query the database or no mirrors could be found!
Download PostgreSQL from
to
regenerate the links. I'll try to work on that.
I think it would also help if you would create reference runs for the
latest 8.0 and 8.1 releases on the new hardware.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 9: In versions below 8.0
there could be issues with existing scripts, but I see a
benefit at least.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Michael Paesold
---(end of broadcast)---
TIP 6: explain analyze is your friend
the JDBC API, i.e. it is an *internal*
pool running inside the app servers JVM. PG Admin cannot in any case
connect through this pool.
Best Regards
Michael Paesold
[1] http://sourceforge.net/projects/c3p0
---(end of broadcast)---
TIP 5: don't forget
-threshold[*] set. If it uses the unnamed-statement,
then I guess the proposed change would be a win.
Best Regards
Michael Paesold
[*] This option determines, after how many executes of a prepared
statement, the driver will switch to server-side prepares.
---(end
Joshua D. Drake wrote:
Thomas Hallgren wrote:
Couldn't we just install something that replaced invalid dates with a
randomly generated but otherwise correct dates? That way they would
become completely invisible. No one could even tell that the date was
invalid to start with.
No we can't,
Tom Lane wrote:
If we did this then RI checks would no longer be subvertible by rules
or user triggers.
Stephan Szabo writes:
I don't think that it'd really help because it's the actions that are
generally subvertible not the checks and since those are looking at the
potentially not indexed
is true, your index
creation should be much faster with a much lower setting for
maintenance_work_mem, so that it uses external sort.
See the discussion starting here:
http://archives.postgresql.org/pgsql-hackers/2006-02/msg00590.php
Best Regards,
Michael Paesold
Tom Lane writes:
Michael Paesold [EMAIL PROTECTED] writes:
Will this trigger still be called, so it can abort the delete?
We'd certainly still call triggers and check row-level constraints,
and any error would abort the whole statement (leaving A unmodified).
The case that I think we'd
wonder
wether we can make all people happy ever.)
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Alvaro Herrera wrote:
Michael Paesold wrote:
When you edit a multiline function in zsh, you can easily press
Control-C,
then type man zsh, return, and press up to continue editing the
function as it was left when you pressed Control-C.
Not sure about zsh's Ctrl-C, but in bash I press Esc
to question the use of id, that's a different
story.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
the validator upon function creation?
SET check_function_bodies = off;
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
=icnlikesel, JOIN=icnlikejoinsel );
LIKE is really not much more than syntactic sugar for the ~~ operator.
Hope this is useful.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Ron wrote:
I assume we have such?
You could look at the Sample Databases project on pgfoundry:
http://pgfoundry.org/projects/dbsamples/
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner
display output) is unaffected?
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Martijn van Oosterhout wrote:
On Fri, Feb 10, 2006 at 08:06:53PM +0100, Michael Paesold wrote:
A side affect of this newline patch is that all fields are now filled
with
white space up to the displayed column width, even for the last (or only
column).
My intention was to only change
that. The assumption one-connection-has-one-transaction
is probably pretty deeply burried in many backend components. Has this been
changed by the prepared-transactions stuff? I may be mistaken, which would
be very positive news.
Best Regards,
Michael Paesold
---(end
Joshua D. Drake wrote:
Tom Lane wrote:
What's the database's locale? This could be the same problem fixed in
8.0.6, if the locale has weird ideas about what string equality means.
lc_collate | C
lc_ctype | C
You don't user pl/perl, do you -- i.e.
Joshua D. Drake wrote:
Michael Paesold wrote:
You don't user pl/perl, do you -- i.e. I guess you read the latest
release notes and the thread here before that?
Yes I did. I didn't know that the person was running plPerl. I have
verified that they are. We are now going to check if upgrading
RELIABILITY changes would be no-ops, no?
Just as the CTAS optimization etc. only skip WAL if WAL archiving is turned
off.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http
into a database, it is not possible to get a
single transaction right now. One has to restore to a file and manually
added BEGIN/COMMIT. Just for that I think --single-transaction is a great
addition and a missing feature.
I think more people have a use-case for that.
Best Regards,
Michael Paesold
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
This is a theory. The whole database was loaded using pg_restore, I still
have the original dump so I will have a look at the dump now. The database
actually contains some plperl functions.
OK, I think I have reproduced the problem
Tom Lane wrote:
I wrote:
Michael Paesold [EMAIL PROTECTED] writes:
I am seeing a similar unique index bug here...
This is PostgreSQL 8.1.1 on RHEL 3, Intel Xeon (i686).
It looks like the problem is that index entries are being inserted out
of order.
After further investigation, it seems
to 8.1.1 around Dec 21, there should have been near
zero updates since then until today.
Perhaps it's a problem with multi-column unique indexes?
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Have you searched our list archives
,
Michael Paesold
[Tom, I removed you from CC: because your spam filter tends to eat my mail;
you should get it through the lists, though.]
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org
, you are building 7.3 for RedHat, do you see any similar regression
failures?
Best Regrads,
Michael Paesold
*** ./expected/horology.out Thu Sep 25 08:58:06 2003
--- ./results/horology.out Tue Dec 13 15:25:07 2005
***
*** 1755,1765
| Tue Dec 31 17:32:01 1996 PST
Tom Lane schrieb:
Michael Paesold [EMAIL PROTECTED] writes:
The tests fail for PST/PDT in 2034.
This probably indicates that you've got TZ data reflecting the new US
DST rules. We have not updated the pre-8.0 regression test results
to deal with that.
You're right as far as I can tell
Martijn van Oosterhout wrote:
What distribution? I've never seen this postgres database you speak
of. It certainly not on any systems I've used.
It's new in 8.1 and is used as the default connection database for createdb,
etc.
Best Regards,
Michael Paesold
---(end
line.
This does not work, if the postgres database is dropped in 8.1:
psql -l template1
psql -l -d template1
of course psql template1 will just work fine.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 2: Don't 'kill -9
nor writers will block waiting.
So only if you do full table locks in your application (using LOCK TABLE
statements), you will suffer from pg_dump backups.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Have you searched our list
for the record (and those interested): using 'CFLAGS=-O2
-mcpu=pentium4 -march=pentium4 -mfpmath=sse -msse2' actually passes the
regression tests.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Tom Lane wrote:
I wrote:
Michael Paesold [EMAIL PROTECTED] writes:
I am definatly not going to use -march=pentium4 in any production
system. Should I open a bug report with RedHat (gcc vendor)?
Yeah, but they'll probably want a smaller test case than Postgres fails
its regression tests
Using both PostgreSQL 8.1.0 and CVS current of Nov 7, 9:00 am CET I get
a regression failure in the interval tests. I am no export for the
interval type, but the expected 9 days 28 hours seem wrong, don't
they? The actual value seems to be the same.
Is it possible that this is broken on the
Michael Glaesemann wrote:
On Nov 7, 2005, at 17:24 , Michael Paesold wrote:
Using both PostgreSQL 8.1.0 and CVS current of Nov 7, 9:00 am CET I
get a regression failure in the interval tests. I am no export for
the interval type, but the expected 9 days 28 hours seem wrong,
don't
Michael Paesold wrote:
On Nov 7, 2005, at 17:24 , Michael Paesold wrote:
Using both PostgreSQL 8.1.0 and CVS current of Nov 7, 9:00 am CET I
get a regression failure in the interval tests. I am no export for
the interval type, but the expected 9 days 28 hours seem wrong,
don't
,
Michael Paesold
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
Robert Treat wrote:
ISTM even a GUC to enable/disable would have been better scheme than
what we have now; we are basically leaving no options for those who
found the old behavior useful, while what we had before would at least
let
Bruce Momjian wrote:
Michael Paesold wrote:
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
Robert Treat wrote:
ISTM even a GUC to enable/disable would have been better scheme than
what we have now; we are basically leaving no options for those who
found the old behavior useful
the old behavior useful, while what we had before would at least
let people switch back and forth.
I think Robert is right here and the new behaviour is a step backwards.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 9: In versions
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
Can you remember regressions in stable branches in the past?
Yes. Relax. If this were a data-corruption-in-the-backend issue,
I might feel that it mandates an immediate re-release. But it isn't
and it doesn't. You'll note
. for the next major bug fixes)
is not the correct answer here. IMHO, the latest released version should be
known best in all components.
Best Regards,
Michael Paesold
Bruce Momjian wrote:
Michael Fuhr wrote:
On Thu, Oct 13, 2005 at 09:49:20AM -0600, Michael Fuhr wrote:
ecpg in 8.0.4 seems
, this is a better URL:
http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1
Btw. I think the header Add proper sequence function dependencies for
DEFAULT is in the wrong font, i.e. it's all monospace.
Best Regards
Michael Paesold
---(end
am not sure how easy that is considering
schema.sequence.nextval.
Just a thought.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 6: explain analyze is your friend
a marketing statepoint -- having
back branches supported for a visible amount of time increases people's
confident in PostgreSQL and it's stability.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 6: explain analyze is your friend
Regards,
Michael Paesold
---(end of broadcast)---
TIP 6: explain analyze is your friend
on
pgfoundry. pgxs should work.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
guess, where
the default installation directory contains PostgreSQL.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
gives are correct nevertheless.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
the same result. If so I could
try to run with oprofile if you can give me a quick start.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
:
ERROR: syntax error at or near , at character 237
LINE 9: credit_cursor CURSOR (p_account integer, p_reference integ...
The same function works perfectly well in 7.4.8 and 8.0.3.
A bug?
Best Regards,
Michael Paesold
---(end of broadcast
Tom Lane wrote:
But the cmpb instruction in the 8.0 version of TAS would have done that,
and I think we've already established that the cmpb is a loss on most
machines (except maybe single-physical-CPU Xeons).
Note that this was a regular Pentium 4 system, not a Xeon.
Best Regards,
Michael
1 - 100 of 183 matches
Mail list logo
