imply 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
, 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
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 h
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
w to make that
work case-insensitively.
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
e are allowing 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
the most reasonable thing to do. 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@pos
slaves, and SQL window support.
I 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
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 b
Comments/objections?
Yeah, please fix 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
casting now.
Just my $0.02.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
ajor performance 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.!
Be
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 reall
d of course the user complained.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
r own 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
ing harder?
IMHO this is exactly what we want. It does only offer 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
chema changes (doesn't sound like a good 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
.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
r just disable
cost-delay, 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 Usen
earlier: it will be before end 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
point (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&
eep the behavior 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
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 sur
still, if we pretend that
there are no subtransaction, that command should too propage to the
outermost transaction on release, shouldn't it?
...
I believe that for consistencies sake, the "set transaction read only"
should have propagated to the outermost transaction on "
e migration for text search in
8.3 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
Michae
] The idea was born 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
-
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
just
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 ver
could 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 broa
ot;
somehow resets $? on windows, sometimes, 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
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
on_age".
Please lets have the unambiguous abbreviations. Please lets make it all
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)
quite arrogant. Most people here have tried to bring arguments and
reasoning... you put 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
hers.
I just see 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 colum
=> select 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
tch status says "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
apabilities
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
0 seconds, but I suppose one might want a smaller 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
Michae
e 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?
A DBA will usually 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:
; after
rebuilding the repository? (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 th
I understand, it's as simple as this (untested):
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
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 const
: 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
Micha
s at a time 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?
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
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
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
e bit of work 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
s now.
Sure a directory can be skipped. I am confused how it could change
expected files because it only formats C files.
As far as I understand, ecpg creates .c files.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 1: if posting/re
coding.
Even with psql 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
st bind, or right at
prepare.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 6: explain analyze is your friend
edStatement but
without a "prepare-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.
that
implements connection pooling using 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)
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,
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 Ct
his should be implemented as a "plugin". (Worst case scenario, but I 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
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 c
nce. If the theory 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,
Mich
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 fk
$ su
# echo $LOGNAME ; echo $USER
mip
mip
# exit
$ su -l
# echo $LOGNAME ; echo $USER
root
root
#
Of course, if you just want 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
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
RIGHTARG=text,
NEGATOR= ~~, RESTRICT=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 will
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
quot;nice display" output) is unaffected?
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
ement 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
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
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.
on,
the whole 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?
mmitting an enclosing transaction.
Using pg_restore directly 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 peo
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 p
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
duled vacuums for now.
I could send the index and table files off-list. This is the only
effected table right now. It is not updated frequently but is rather
static. I upgraded to 8.1.1 around Dec 21, there should have been near
zero updates since then until today.
Perhaps it's a problem wi
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
g the problem would
be a good thing.
Tom, 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 *
ould be a portable way
to detect overflow, no?
Best Regards,
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: H
ase
given on the command 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)---
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
r
readers 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 searche
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 fail
.
Just 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
or)?
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
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,
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,
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
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
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 befor
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
quot; (i.e. 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
ASE-8-1
Sorry, 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
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
recommend it. Also from 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
amount of transactions.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 6: explain analyze is your friend
s not append postgresql in that
case?
That would be the least invasive fix for the Windows case, I 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
installer project on
pgfoundry. pgxs should work.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
operator fails.
It comes down to the question if the query is valid syntax in the first
place. The answers PostgreSQL gives are correct nevertheless.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
here and see if it gives 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
GSQL;
I get:
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)-
1 - 100 of 189 matches
Mail list logo
