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.
> >
> >
Hi,
On Tue, Apr 21, 2009 at 4:33 PM, Fujii Masao 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 of log_directory. Att
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.
Attac
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 f
-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 adv
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. ;-)
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 visu
Bruce Momjian 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] list [only agg/
Tom Lane wrote:
> Bruce Momjian 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[
Alvaro Herrera 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 it'd make the column
wide
Tom Lane wrote:
> Alvaro Herrera 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 th
Robert Campbell 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:
http://archives.postgresql.org/pgsql-novice/
> 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 nee
Zeugswetter Andreas OSB sIT 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 full flexibility in partitioning
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) Deleting
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 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 existing facilit
On Wed, Apr 22, 2009 at 10:13 AM, Pavel Stehule wrote:
> 2009/4/21 Brendan Jurd :
>> numstr = orgnum = (char *) palloc(MAXDOUBLEWIDTH + 1);
>> if (Num.pre != 1)
>> ereport(ERROR,
>> (errcode(ERRCODE_SYNTAX_
"Nickolay" 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 'Hello';
> END;
> $BODY$
> LANGUAGE 'plpgsql' VOLATILE STRICT SECUR
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
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.
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 th
"Joshua D. Drake" 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 monitor
>> running
-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 m
Heikki Linnakangas 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 installcheck. We'd really have
t
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 co
Tom Lane wrote:
Heikki Linnakangas 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 installcheck.
Conf
Heikki Linnakangas 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 min_prepared_xacts=0 case. Lik
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 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 you PREPAR
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 prepare
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 vi
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 thoug
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
I wrote:
> Heikki Linnakangas 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, for example, though that's
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 for
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" 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 for 8.4 is to impr
On Wed, Apr 22, 2009 at 2:58 PM, 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.
Is that r
Robert Haas writes:
> On Wed, Apr 22, 2009 at 2:58 PM, Heikki Linnakangas
> 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 vacuum away any
> rows whose xmin is that of the
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 f
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
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 purp
Bruce Momjian 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 jobs it sh
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 deviati
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.
reloptions.
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 wrote:
> Robert Haas writes:
>> On Wed, Apr 22, 2009 at 2:58 PM, Heikki Linnakangas
>> 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 y
Robert Haas writes:
> On Wed, Apr 22, 2009 at 5:44 PM, Tom Lane 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 in-doubt and cannot be
>> frozen,
On Wed, Apr 22, 2009 at 8:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Apr 22, 2009 at 5:44 PM, Tom Lane 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
* 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 go
On Wed, Apr 22, 2009 at 9:21 PM, Robert Haas 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 see the same
"Eric B. Ridge" 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 are joine
Robert Haas 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 first time, which
Hi,
On Thu, Apr 23, 2009 at 4:51 AM, Heikki Linnakangas
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 checkpoint creates .ready
>> file.
I setup more locale testing on gothic moth and citext regression test
fails.
See
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_moth&dt=2009-04-22%2020:06:01
Problem is here:
---
SELECT citext_cmp('B'::citext, 'a'::citext) AS one;
one
57 matches
Mail list logo
