On Tue, 2009-04-21 at 09:59 -0700, David Fetter wrote:
On Tue, Apr 21, 2009 at 12:25:50PM +0100, Simon Riggs wrote:
No, removing trigger file as soon as a non-existant file is
requested still seems simpler than deleting it whenever a timeline
history file is requested.
If you do
Hi,
On Tue, Apr 21, 2009 at 4:33 PM, Fujii Masao masao.fu...@gmail.com wrote:
Here is the revised patch; If stats_temp_directory indicates the symlink,
we pursue the chain of symlinks and create the referenced directory.
BTW, this patch is useful also as the foundation for improving
creation
Hi,
In archive recovery, the last applied WAL segment may not have
.ready file in spite of not having been archived yet. Then, this
segment is not archived until a future checkpoint creates .ready
file. It's a little dangerous that there is the WAL segment which
is not archived for a while.
to...@tuxteam.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 21, 2009 at 01:26:33PM -0400, Bruce Momjian wrote:
[...]
I merged the entries into one line:
\df[antwS+] [PATTERN] list (only agg/normal/trigger/window) functions
I didn't feel I had room
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Apr 22, 2009 at 08:32:20AM -0400, Bruce Momjian wrote:
[...]
True, but the problem is that the brackets don't correspond [...]
Yes, right. Still, square brackets seem (to me) to provide some visual
cue. But I admit that this is already
Ghislain ROUVIGNAC wrote:
Stopping and starting does not seem to fix the problem.
I stopped and started my Windows server today.
The problem reappeared the second time I launched my db update scripts.
OK, so you have a reproducible case, which is good for debugging but bad
for you. ;-)
I
to...@tuxteam.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Apr 22, 2009 at 08:32:20AM -0400, Bruce Momjian wrote:
[...]
True, but the problem is that the brackets don't correspond [...]
Yes, right. Still, square brackets seem (to me) to provide some visual
cue.
Bruce Momjian br...@momjian.us writes:
If I can get someone else to say they prefer brackets over parentheses in
\? I will make the change. Right now we have:
\df[antwS+] [PATTERN] list (only agg/normal/trigger/window) functions
With brackets it would be:
\df[antwS+] [PATTERN]
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
If I can get someone else to say they prefer brackets over parentheses in
\? I will make the change. Right now we have:
\df[antwS+] [PATTERN] list (only agg/normal/trigger/window) functions
With brackets it would be:
Alvaro Herrera alvhe...@commandprompt.com writes:
Still, my original proposal was \df[antw][S+]. The extra brackets are
obviously redundant, but if we're about providing cues, this is a good
cue IMO. It allows the [S+] to match the other lines.
I'm for that too. Bruce was complaining that
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Still, my original proposal was \df[antw][S+]. The extra brackets are
obviously redundant, but if we're about providing cues, this is a good
cue IMO. It allows the [S+] to match the other lines.
I'm for that too. Bruce
Robert Campbell rrc...@gmail.com writes:
I found the problem: it's a permissions issue.
Hmm ... I wonder why initdb is saying No such file or directory then.
Maybe we are incorrectly translating some Windows error code number?
[ for pgsql-hackers: see thread here:
Which leads me to the same conclusion: anything as complicated as CASE
is the wrong design. But perhaps for slightly different reasons.
What I like about the sql CASE is, that it is expression based, and thus
allows full flexibility in partitioning and is highly self documenting.
Do we need
Zeugswetter Andreas OSB sIT andreas.zeugswet...@s-itsolutions.at writes:
Which leads me to the same conclusion: anything as complicated as CASE
is the wrong design. But perhaps for slightly different reasons.
What I like about the sql CASE is, that it is expression based, and thus
allows
Hi,
Starting a new thread related to synchronization of the data files, WAL
etc.. between Primary and standby servers in Synchronous replication
patch.
Use case: Whenever the primary and standby are out of sync due to
network problems.
Existing handling is to prepare the standby by
1)
On Tue, 2009-04-21 at 14:51 -0400, Tom Lane wrote:
The partitioning
rules should be simple enough that they can easily be applied at
runtime to determine which partition to look in.
+1
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via
On Wed, Apr 22, 2009 at 11:34 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The KISS principle applies with a vengeance here. I think we should
make the partitioning stuff handle only the simplest cases but do those
well. Anybody who wants something more complex can still try to tackle
it via the
On Wed, Apr 22, 2009 at 10:13 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2009/4/21 Brendan Jurd dire...@gmail.com:
numstr = orgnum = (char *) palloc(MAXDOUBLEWIDTH + 1);
if (Num.pre != 1)
ereport(ERROR,
Nickolay b...@doci.in.ua writes:
[ install contrib/xml2 and run this function twice: ]
CREATE OR REPLACE FUNCTION bbb()
RETURNS xml AS
$BODY$
BEGIN
execute 'select public.xml_encode_special_chars(''1+1'')';
return 'vHello/v';
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE
The pgsql-admin list has just seen another instance where careless use
of prepared transactions brought down a database, and the DBA (who had
no idea what a prepared transaction even was) had no idea how to fix it.
It seems to me we need to do something about making that stuff less
DBA-unfriendly.
Tom Lane wrote:
Anyway, maybe question zero is whether anyone else thinks this is
important enough to justify extra work in the area.
One thing that has already changed is that DROP DATABASE reports N
users and M prepared transactions, so there is more of a hint.
Another thing we could do is
On Wed, 2009-04-22 at 13:48 -0400, Tom Lane wrote:
One line of thought is just to raise the visibility of old prepared
transactions somehow. I don't think I want to go as far as, say, making
every session-start issue WARNINGs about every prepared xact that's more
than a few minutes old. But
Joshua D. Drake wrote:
On Wed, 2009-04-22 at 13:48 -0400, Tom Lane wrote:
The main
objection to just setting max_prepared_transactions to zero by default
is that it would kill our ability to test the feature in the standard
regression tests.
That kills it for me. Unless we want to change
Joshua D. Drake j...@commandprompt.com writes:
On Wed, 2009-04-22 at 13:48 -0400, Tom Lane wrote:
Another line of thought is that prepared xacts are inherently a bad
thing to be using if you have not done careful setup of a lot of
external infrastructure (in particular, have a transaction
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Anyway, maybe question zero is whether anyone else thinks this is
important enough to justify extra work in the area.
Yes. For every user that complains on the list, there are a dozen other
quiet ones who have been bit by the same.
The
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I think we should change the way we test it. Could we simply make
max_prepared_transactions = 0 the default, but put
max_prepared_transactions = 5 into the config file in make check?
That only works for make check, not make
Heikki Linnakangas wrote:
I think we should change the way we test it. Could we simply make
max_prepared_transactions = 0 the default, but put
max_prepared_transactions = 5 into the config file in make check?
That seems like the best alternative, it doesn't seem right to build
extra
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I think we should change the way we test it. Could we simply make
max_prepared_transactions = 0 the default, but put
max_prepared_transactions = 5 into the config file in make check?
That only works for make
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
That only works for make check, not make installcheck.
Configuration affects what can be tested in installcheck, that's quite
natural. I would be happy with simply adding an alternative expected
output file for
On Wed, 2009-04-22 at 11:00 -0700, Joshua D. Drake wrote:
Then perhaps a setting like max_stale_prepared_transaction_age and once
that threshold is met it will autorollback?
I think that defeats the safety of prepared transactions in many cases.
Let's say you PREPARE TRANSACTION on two systems,
Jeff Davis pg...@j-davis.com writes:
On Wed, 2009-04-22 at 11:00 -0700, Joshua D. Drake wrote:
Then perhaps a setting like max_stale_prepared_transaction_age and once
that threshold is met it will autorollback?
I think that defeats the safety of prepared transactions in many cases.
Let's say
On Wed, 2009-04-22 at 13:53 -0400, Alvaro Herrera wrote:
Another thing we could do is make autovacuum log something about those,
similar to what it does to temp tables. And if one of them gets too
near Xid wraparound, kill it.
As I said in my reply to Joshua, I don't think killing a prepared
Tom Lane wrote:
Does a prepared xact still block vacuum cleanup in HEAD, or has that
been fixed since 8.2?
It still does. A prepared xact is just like a idle-in-transaction
backend as far as vacuum is concerned.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent
On Wed, 2009-04-22 at 21:58 +0300, Heikki Linnakangas wrote:
Tom Lane wrote:
Does a prepared xact still block vacuum cleanup in HEAD, or has that
been fixed since 8.2?
It still does. A prepared xact is just like a idle-in-transaction
backend as far as vacuum is concerned.
I thought idle
Jeff Davis wrote:
On Wed, 2009-04-22 at 21:58 +0300, Heikki Linnakangas wrote:
Tom Lane wrote:
Does a prepared xact still block vacuum cleanup in HEAD, or has that
been fixed since 8.2?
It still does. A prepared xact is just like a idle-in-transaction
backend as far as vacuum is concerned.
I wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Configuration affects what can be tested in installcheck, that's quite
natural. I would be happy with simply adding an alternative expected
output file for min_prepared_xacts=0 case. Like we've done for xml test
cases,
Fujii Masao wrote:
In archive recovery, the last applied WAL segment may not have
.ready file in spite of not having been archived yet. Then, this
segment is not archived until a future checkpoint creates .ready
file. It's a little dangerous that there is the WAL segment which
is not archived
On Wed, 2009-04-22 at 15:49 -0400, Tom Lane wrote:
I wrote:
Warning about very old prepared transactions is something that we
could think about doing as well; it doesn't have to be either-or.
I think the need for it would decrease quite a bit if they weren't
enabled by default, though.
Joshua D. Drake j...@commandprompt.com writes:
On Wed, 2009-04-22 at 15:49 -0400, Tom Lane wrote:
Comments? Anyone seriously opposed to making the default be zero?
I am not opposed to making the default zero. I am also +1 on adding the
warnings.
What I think we could/should do about that
On Wed, Apr 22, 2009 at 2:58 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Tom Lane wrote:
Does a prepared xact still block vacuum cleanup in HEAD, or has that
been fixed since 8.2?
It still does. A prepared xact is just like a idle-in-transaction backend as
far as
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 22, 2009 at 2:58 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It still does. A prepared xact is just like a idle-in-transaction backend as
far as vacuum is concerned.
Is that really necessary? It's true that you can't
Hi,
I just noticed (!) that Make accepts an argument-less -j option, which
it takes to mean use as many parallel jobs as possible. As far as I
see in our pg_restore code, we don't even accept an argumentless -j
option; was this deviation from the Make precedent on purpose, or were
we just not
Alvaro Herrera wrote:
Hi,
I just noticed (!) that Make accepts an argument-less -j option, which
it takes to mean use as many parallel jobs as possible. As far as I
see in our pg_restore code, we don't even accept an argumentless -j
option; was this deviation from the Make precedent on
Alvaro Herrera wrote:
Hi,
I just noticed (!) that Make accepts an argument-less -j option, which
it takes to mean use as many parallel jobs as possible. As far as I
see in our pg_restore code, we don't even accept an argumentless -j
option; was this deviation from the Make precedent on
Bruce Momjian br...@momjian.us writes:
Alvaro Herrera wrote:
I just noticed (!) that Make accepts an argument-less -j option, which
it takes to mean use as many parallel jobs as possible.
An unlimited pg_restore -j seems pretty scary.
Yeah. Even if Make has a sane way to estimate how many
On Thursday 23 April 2009 01:26:04 Alvaro Herrera wrote:
I just noticed (!) that Make accepts an argument-less -j option, which
it takes to mean use as many parallel jobs as possible. As far as I
see in our pg_restore code, we don't even accept an argumentless -j
option; was this deviation
GCC 4.4 produces a bunch of new compiler warnings against 8.4; see attached
output. Some of these are related to our old friend fastgetattr(), but it's a
bit too late for me to make sense of it now.
As we have grown accustomed to warnings-free builds, it would be nice to fix
these.
if that's without -O3, than please retry it with. It will give even
more.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Apr 22, 2009 at 5:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 22, 2009 at 2:58 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It still does. A prepared xact is just like a idle-in-transaction backend as
far as
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 22, 2009 at 5:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think we've already milked what we can from that, since a prepared
xact is treated exactly like an open one with no snapshot. The point
is that whatever rows it's written are still
On Wed, Apr 22, 2009 at 8:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 22, 2009 at 5:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think we've already milked what we can from that, since a prepared
xact is treated exactly like an open one with
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Yeah. Even if Make has a sane way to estimate how many jobs it should
use, I'm not sure that pg_restore does. (The most obvious heuristic
for Make is to try to find out how many CPUs there are --- but at
least it's running on the same machine it's going
On Wed, Apr 22, 2009 at 9:21 PM, Robert Haas robertmh...@gmail.com wrote:
Maybe I'm just dumb, but I don't get it. If I start a transaction and
do SELECT * FROM foo and then wait around for an hour or two while
someone else makes changes to foo and then do SELECT * FROM foo
again, I expect to
Eric B. Ridge e...@tcdi.com writes:
I loaded a copy of a production database into PG 8.4b1 and immediately
saw that all of our queries were significantly slower compared to v8.1.
Some investigation showed that the use of non-IMMUTABLE PL/PGSQL
functions as view columns, when these views
Robert Haas robertmh...@gmail.com writes:
Maybe I'm just dumb, but I don't get it. If I start a transaction and
do SELECT * FROM foo and then wait around for an hour or two while
someone else makes changes to foo and then do SELECT * FROM foo
again, I expect to see the same rows I saw the
Hi,
On Thu, Apr 23, 2009 at 4:51 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
In archive recovery, the last applied WAL segment may not have
.ready file in spite of not having been archived yet. Then, this
segment is not archived until a future
56 matches
Mail list logo
