On Thu, 2009-02-05 at 09:28 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> >> We could avoid that by performing a good old startup checkpoint, but I
> >> quite like the fast failover time we get without it.
> >
> > ISTM it's either slow failover or (fast failover, but restart archive
>
On Thu, 2009-02-05 at 09:28 +0200, Heikki Linnakangas wrote:
> >> I've changed the way minRecoveryPoint is updated now anyway, so it no
> >> longer happens every XLogFileRead().
> >
> > Care to elucidate?
>
> I got rid of minSafeStartPoint, advancing minRecoveryPoint instead. And
> it's advan
Simon Riggs wrote:
We could avoid that by performing a good old startup checkpoint, but I
quite like the fast failover time we get without it.
ISTM it's either slow failover or (fast failover, but restart archive
recovery if crashes).
I would suggest that at end of recovery we write the last L
Tom Lane wrote:
Fujii Masao writes:
On Wed, Feb 4, 2009 at 8:35 PM, Heikki Linnakangas
wrote:
... I'm not sure why we in CVS HEAD we don't reset
FatalError until after the startup process is finished.
Which may repeat the recovery crash and reinitializing forever. To prevent
this problem,
Fujii Masao writes:
> On Wed, Feb 4, 2009 at 8:35 PM, Heikki Linnakangas
> wrote:
>> ... I'm not sure why we in CVS HEAD we don't reset
>> FatalError until after the startup process is finished.
> Which may repeat the recovery crash and reinitializing forever. To prevent
> this problem, unexpect
Hi Niranjan,
On Wed, Feb 4, 2009 at 6:21 PM, K, Niranjan (NSN - IN/Bangalore)
wrote:
>
>> - Do you use a packet filtering software (eg. firewall)?
>> If yes, what happens if you disabled such a software?
> Firewall was disabled
>
>> - Do you use SELinux?
>> If yes, what happens if you disable
2009/2/5 Bruce Momjian :
> Robert Haas wrote:
>> > I am not thrilled about inventing a new column for this, but how about
>> > a display like so:
>> >
>> > regression=# \df nth_value
>> >List of functions
>> > Schema | Name| Result data type | Argument data t
Dann Corbit wrote:
The LZMA SDK is granted to the public domain:
http://www.7-zip.org/sdk.html
I played with this but found the SDK extremely confusing and flat out horrible.
One personal dislike was the unnecessary use of C++; although it was the
horrible API that turned me off. I'm not
Hmm probably it's worth to try this. Has anybody try this before? If not, I
am interested to give it a try.
Regards,
Don
On Wed, Feb 4, 2009 at 11:25 PM, Gregory Stark wrote:
> Simon Riggs writes:
>
> > On Wed, 2009-02-04 at 10:55 +, Greg Stark wrote:
> >> Is this basically the same as our
This is what I understand from existing implementation:
- fix the merge fan in F, and number of tapes=F+1
- for each sorted run generated, we have a formula to determine which tape
it belongs to
- the sorted run is added to the end of the tape
- all sorted runs have been added to tape. There is alw
Good point. I would note this issue. Thanks for the advice :).
Regards,
Don
On Wed, Feb 4, 2009 at 6:09 PM, Simon Riggs wrote:
>
> On Wed, 2009-02-04 at 14:42 +0800, Don Marvick wrote:
>
> > 4. any other issue needs consideration?
>
> Most attempts to improve sorting further have fallen to not
Hi,
On Wed, Feb 4, 2009 at 8:35 PM, Heikki Linnakangas
wrote:
> Yes, and in fact I ran into it myself yesterday while testing. It seems that
> we should reset FatalError earlier, ie. when the recovery starts and
> bgwriter is launched. I'm not sure why we in CVS HEAD we don't reset
> FatalError u
On Wed, Feb 04, 2009 at 11:22:44PM +0100, Zdenek Kotala wrote:
> The main speed improvement is for varchar datatype. I think It should be
> mention here as well. IIRC, times are similar with B-Tree for integer
> datatype.
>
> Zdenek
>
> Kenneth Marshall pe v st 04. 02. 2009 v 13:57 -060
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Bruce Momjian
> Sent: Wednesday, February 04, 2009 3:28 PM
> To: Stanislav Lacko
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Is a plan for lmza commpre
Stanislav Lacko wrote:
> Hi.
>
> Is it in todo or in a plan to implement lmza commpression in pg_dump
> backups?
Nope, never heard anything about it.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard dri
On Wed, Feb 4, 2009 at 1:23 PM, Bruce Momjian wrote:
> Robert Treat wrote:
>> On Wednesday 21 January 2009 20:21:41 Bruce Momjian wrote:
>> > Alvaro Herrera wrote:
>> > > Robert Treat wrote:
>> > > > On Thursday 08 May 2008 00:27:10 Tino Wildenhain wrote:
>> > > > > David Fetter wrote:
>> > >
>> >
The main speed improvement is for varchar datatype. I think It should be
mention here as well. IIRC, times are similar with B-Tree for integer
datatype.
Zdenek
Kenneth Marshall píše v st 04. 02. 2009 v 13:57 -0600:
> I had submitted the documentation change as part of my
> hash function p
On Wed, 2009-02-04 at 14:53 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> >
> > On Tue, 2009-01-06 at 09:44 -0500, Tom Lane wrote:
> > > Simon Riggs writes:
> > > > It looks to me that generating a single error message while idle causes
> > > > the server to provide ErrorResponse, which the
On Wed, Feb 04, 2009 at 01:23:04PM -0500, Bruce Momjian wrote:
> Robert Treat wrote:
> > On Wednesday 21 January 2009 20:21:41 Bruce Momjian wrote:
> > > Alvaro Herrera wrote:
> > > > Robert Treat wrote:
> > > > > On Thursday 08 May 2008 00:27:10 Tino Wildenhain wrote:
> > > > > > David Fetter wrot
Hi.
Is it in todo or in a plan to implement lmza commpression in pg_dump
backups?
Thanks
Stano
--
Mgr.
Stano LACKO
mobil:
+421 908 175 753
fax.:
+421 2 555 72 676
e-mail: lacko@spacesystems.sk
On Wed, Feb 4, 2009 at 4:23 PM, Jeff Davis wrote:
> On Wed, 2009-02-04 at 14:40 -0500, Robert Haas wrote:
>> Well, there's nothing to force that plan to be invalidated when the
>> state of the pending list changes, is there?
>>
>
> Would it be unreasonable to invalidate cached plans during the pen
On Wed, 2009-02-04 at 14:40 -0500, Robert Haas wrote:
> Well, there's nothing to force that plan to be invalidated when the
> state of the pending list changes, is there?
>
Would it be unreasonable to invalidate cached plans during the pending
list cleanup?
Anyway, it just strikes me as strange
I had submitted the documentation change as part of my
hash function patch but it was removed as not relevant.
(It wasn't really.) I would basically remove the first
sentence:
Note: Hash index operations are not presently WAL-logged,
so hash indexes might need to be rebuilt with REINDEX
Simon Riggs wrote:
>
> On Tue, 2009-01-06 at 09:44 -0500, Tom Lane wrote:
> > Simon Riggs writes:
> > > It looks to me that generating a single error message while idle causes
> > > the server to provide ErrorResponse, which the client assumes is the end
> > > of the processing of that statement
Robert Haas wrote:
> > I am not thrilled about inventing a new column for this, but how about
> > a display like so:
> >
> > regression=# \df nth_value
> >List of functions
> > Schema | Name| Result data type | Argument data types
> > +---
On Wed, Feb 4, 2009 at 1:32 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> > 2009/1/10 Tom Lane :
>> >> Bruce Momjian writes:
>> >>> Uh, is this ready to be applied?
>> >>
>> >> I don't think any consensus has been reached on changing this behavior.
>> >
>> > I thing, so this is bug - RETURN Q
On Wed, Feb 4, 2009 at 1:39 PM, Jeff Davis wrote:
> On Mon, 2009-02-02 at 20:38 -0500, Tom Lane wrote:
>> Also, I really think it's a pretty bad idea to make index cost
>> estimation depend on the current state of the index's pending list
>> --- that state seems far too transient to base plan choi
On Wed, Feb 4, 2009 at 1:22 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> "Merlin Moncure" writes:
>> > Noticed another issue with 'client only' type installs in the
>> > Makefile. Shouldn't make install on libpq install postgres_ext.h in
>> > addition to the interface headers?
>>
>> I don't thi
Tom Lane wrote:
> The proximate cause of this complaint:
> http://archives.postgresql.org/pgsql-general/2008-12/msg00283.php
> seems to be that the polymorphic-type code doesn't consider a domain
> over an enum type to match an ANYENUM function argument.
>
> ISTM this is probably wrong: we need su
Hi,
indices.sgml contains this paragraph about hash indexes:
Note: Testing has shown PostgreSQL's hash indexes to perform no
better than B-tree indexes, and the index size and build time for hash
indexes is much worse. Furthermore, hash index operations are not
presently WAL-logged, so h
On Wed, Feb 4, 2009 at 12:33 PM, Robert Haas wrote:
>
> Still, the queries-limit.html page includes this statement: "OFFSET 0
> is the same as omitting the OFFSET clause." I don't see that there
> would be anything bad or confusing about changing it to read this way:
> "OFFSET 0 is the same as om
>>> Tom Lane wrote:
> That doesn't seem to be the only issue in your example, but it's
> definitely one of 'em.
FWIW, the pattern causing the problem here is a pretty common one in
court business logic: join (often outer join or an exists test) to a
set of candidate rows WHERE NOT EXISTS the sa
On Feb 4, 2009, at 10:04 AM, Svenne Krap wrote:
I have the same experience, I also go directly for the most technical
parts. But even I sometimes search and hit those narrative ones
Btw. there seems to be no section VI (i.e. non-narrative) page about
datatypes and functions... things there l
I wrote:
> Now, since I'm running without any stats, it might be that it's
> estimating similar costs for the one-key and two-key merges; but I don't
> see why that would happen for you. Off to do some debugging.
... well, actually, it's because I blew off applying any cost correction
for this ca
On Mon, 2009-02-02 at 20:38 -0500, Tom Lane wrote:
> Also, I really think it's a pretty bad idea to make index cost
> estimation depend on the current state of the index's pending list
> --- that state seems far too transient to base plan choices on.
I'm confused by this. Don't we want to base the
Robert Haas wrote:
> > 2009/1/10 Tom Lane :
> >> Bruce Momjian writes:
> >>> Uh, is this ready to be applied?
> >>
> >> I don't think any consensus has been reached on changing this behavior.
> >
> > I thing, so this is bug - RETURN QUERY has to supply FOR SELECT LOOP
> > RETURN NEXT pattern.
> >
Robert Treat wrote:
> On Wednesday 21 January 2009 20:21:41 Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Robert Treat wrote:
> > > > On Thursday 08 May 2008 00:27:10 Tino Wildenhain wrote:
> > > > > David Fetter wrote:
> > >
> > > Ref: http://archives.postgresql.org/pgsql-hackers/2008-05/ms
On Wed, 2009-02-04 at 19:03 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > * I think we are now renaming the recovery.conf file too early. The
> > comment says "We have already restored all the WAL segments we need from
> > the archive, and we trust that they are not going to go away ev
Tom Lane wrote:
> "Merlin Moncure" writes:
> > Noticed another issue with 'client only' type installs in the
> > Makefile. Shouldn't make install on libpq install postgres_ext.h in
> > addition to the interface headers?
>
> I don't think libpq's Makefile has any business doing that.
>
> Maybe w
>>> Tom Lane wrote:
> Hmm ... one of the things that struck me as odd was that it was doing
a
> merge join on just the countyNo, which is presumably very far from
> unique.
There are 72 possible values for any columns in that domain. In most
large tables, Milwaukee County (value 40) is used in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David E. Wheeler wrote:
> I think that all pages that seem to document particular features
> should cross-reference the reference pages in section VI, but not
> necessarily vice-versa. I don't think that's asking for a lot. If
> you're reading the narr
"Kevin Grittner" writes:
> Tom Lane wrote:
>> It would be worth checking whether you get the same plan without
>> the patch (you should, but let's check).
> Same plan.
Yeah, I just managed to reproduce a similar behavior in unpatched HEAD.
Now, since I'm running without any stats, it might be
On Feb 4, 2009, at 9:33 AM, Robert Haas wrote:
Just to play devil's advocate, I have used the PostgreSQL
documentation for years and have long understood that the references
pages are the place to go if you really need the nitty-gritty on how a
particular command works. I agree that you might no
Jeff Davis wrote:
> On Wed, 2009-02-04 at 11:11 -0500, Bruce Momjian wrote:
> > Well, with no one replying, :-(, I went ahead and added to the Read
> > Committed section of our manual to show a simple case where our read
> > committed mode produces undesirable results. I also did a little
> > clea
Robert Haas writes:
> Oh, dear. If this turns out to be my bug Tom will kick my ass!
Hmm ... one of the things that struck me as odd was that it was doing a
merge join on just the countyNo, which is presumably very far from
unique. Testing the query here with Kevin's schema but no data, I get
On Wed, 2009-02-04 at 11:11 -0500, Bruce Momjian wrote:
> Well, with no one replying, :-(, I went ahead and added to the Read
> Committed section of our manual to show a simple case where our read
> committed mode produces undesirable results. I also did a little
> cleanup at the same time.
We co
>>> Tom Lane wrote:
> It would be worth checking whether you get the same plan without
> the patch (you should, but let's check).
Same plan.
(Robert can relax, and David can forget about those tickets.)
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On Wed, Feb 4, 2009 at 12:22 PM, David E. Wheeler wrote:
>> In effect it does say that - perhaps not quite as explicitly as you might
>> have wanted. It says: "The information in this part is presented in a
>> narrative fashion in topical units. Readers looking for a complete
>> description of a p
On Feb 4, 2009, at 9:25 AM, Robert Haas wrote:
Oh, dear. If this turns out to be my bug Tom will kick my ass!
Can I buy tickets to this event?
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
On Wed, Feb 4, 2009 at 12:15 PM, Kevin Grittner
wrote:
Tom Lane wrote:
>> there's some sort of logic bug here someplace.
>
> Keep in mind that this is running with the patch that started this
> thread. I didn't try actually running this query on 8.4devel without
> the patch. Should I kill
Looked at this a bit ... do you think it's really a good idea to remove
the strategy number argument of comparePartial? The argument given in
the docs for it is that it might be needed to determine when to end the
scan, and that still seems plausible to me.
Strategy number is not removed, it's re
"Kevin Grittner" writes:
> Tom Lane wrote:
>> there's some sort of logic bug here someplace.
> Keep in mind that this is running with the patch that started this
> thread. I didn't try actually running this query on 8.4devel without
> the patch. Should I kill this query, revert the software
On Feb 4, 2009, at 5:25 AM, Andrew Dunstan wrote:
In effect it does say that - perhaps not quite as explicitly as you
might have wanted. It says: "The information in this part is
presented in a narrative fashion in topical units. Readers looking
for a complete description of a particular co
>>> Tom Lane wrote:
> there's some sort of logic bug here someplace.
Keep in mind that this is running with the patch that started this
thread. I didn't try actually running this query on 8.4devel without
the patch. Should I kill this query, revert the software to
pre-patch, and try it again
"Kevin Grittner" writes:
> Well, of the cases which are selected based on the other criteria,
> there would be about one CaseDispo row each. The main selection
> criterion is the Party.searchName, with various security limitations
> added. Where one or more CaseDispo rows exist (it's only includ
Simon Riggs wrote:
* I think we are now renaming the recovery.conf file too early. The
comment says "We have already restored all the WAL segments we need from
the archive, and we trust that they are not going to go away even if we
crash." We have, but the files overwrite each other as they arriv
I looked at this a little bit --- it needs proofreading ("VACUUME"?).
Sorry, VACUUME fixed
Do we really need an additional column in pgstat table entries in
order to store something that looks like it can be derived from the
other columns? The stats tables are way too big already.
It's not
>>> Tom Lane wrote:
> SELECT ... FROM "CaseDispo" "CD"
> WHERE (NOT (EXISTS
> (
> SELECT
> 1
> FROM
> "CaseDispo" "CD2"
> WHERE (
> ("CD2"."caseNo" = "CD"."caseNo")
> AND ("CD2"."countyNo" = "CD"."countyNo")
> AND ("CD2"."dispoDate" > "CD"."dispoDate"))
> )))
>
> which in fact the planner though
Kevin Grittner wrote:
> >>> Bruce Momjian wrote:
> > Well, with no one replying, :-(, I went ahead and added to the Read
> > Committed section of our manual to show a simple case where our read
> > committed mode produces undesirable results. I also did a little
> > cleanup at the same time.
> >
"Kevin Grittner" writes:
> Tom Lane wrote:
>> If you can attach to the backend with gdb, try "bt", then "cont",
>> then wait a few seconds, then control-C and "bt" again. Repeat
>> five or ten times and see if there's any consistency to the traces.
> Attached.
Hmm, it seems to be spending al
>>> Bruce Momjian wrote:
> Well, with no one replying, :-(, I went ahead and added to the Read
> Committed section of our manual to show a simple case where our read
> committed mode produces undesirable results. I also did a little
> cleanup at the same time.
>
> You can see the resulting text
Bruce Momjian wrote:
> The fundamental behavior above is that the S1 transaction is adding
> _and_ removing rows from the S2 query's result set; S2 is seeing the
> pre-query values that don't match its criteria and ignoring them and
> blocking on a later row that does match its criteria. Once S1
>>> Tom Lane wrote:
> If you can attach to the backend with gdb, try "bt", then "cont",
> then wait a few seconds, then control-C and "bt" again. Repeat
> five or ten times and see if there's any consistency to the traces.
Attached.
-Kevin
kgri...@athena:~> gdb /usr/local/pgsql-8.4devel-200
"Kevin Grittner" writes:
> It's been about 23 hours and it's still running. No apparent memory
> leakage. No significant disk activity. One CPU pegged (of the 16 on
> the machine).
Hmmm ... I wonder if it could be stuck in an infinite loop? It's
probably just a horribly bad plan choice, but .
Simon Riggs writes:
> On Wed, 2009-02-04 at 10:55 +, Greg Stark wrote:
>> Is this basically the same as our current algorithm but without
>> multiplexing the tapes onto single files? I have been wondering
>> whether we multiplex the tapes any better than filesystems can lay out
>> separate fi
On Wednesday 04 February 2009 8:41:55 am Svenne Krap wrote:
> Andrew Dunstan wrote:
> >> Me neither. I wonder how many other long term users (I have used pgsql
> >> for more than a decade - 6.2 was my first version if memory serves)
> >> and have never caught that nuance either.
> >>
> >> Maybe tha
Don Marvick writes:
> Since nobody replied, I would give it a try. I am going to implement the
> merge pattern described in Knuth Page 365 (5.4.9), essentially it is as
> follow:
> - create initial runs using replacement selection (basically this is as in
> the current implementation)
> - add enou
On Wed, Feb 4, 2009 at 10:12 AM, Greg Stark wrote:
> On Wed, Feb 4, 2009 at 3:07 PM, Kevin Grittner
> > It's been about 23 hours and it's still running.
>
> @snide(Gee, it sure would be nice if we continued with that
> explain-in-progress patch I had sent in earlier...:)
Agreed.
--
Jonah H. H
Greg Stark writes:
> Is this basically the same as our current algorithm but without
> multiplexing the tapes onto single files? I have been wondering
> whether we multiplex the tapes any better than filesystems can lay out
> separate files actually.
The reason for the multiplexing is so that spa
On Wed, Feb 4, 2009 at 3:07 PM, Kevin Grittner
> It's been about 23 hours and it's still running.
@snide(Gee, it sure would be nice if we continued with that
explain-in-progress patch I had sent in earlier...:)
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On Wed, 2009-02-04 at 10:55 +, Greg Stark wrote:
> Is this basically the same as our current algorithm but without
> multiplexing the tapes onto single files? I have been wondering
> whether we multiplex the tapes any better than filesystems can lay out
> separate files actually.
I don't thin
>>> I wrote:
Tom Lane wrote:
>> Can you let it run to completion? Without explain analyze results
>> it's going to be pretty difficult to isolate the problem.
>
> Barring some currently unforseen need to switch it into service to
> back the web site, yes.
It's been about 23 hours and i
Andrew Dunstan wrote:
>> Me neither. I wonder how many other long term users (I have used pgsql
>> for more than a decade - 6.2 was my first version if memory serves)
>> and have never caught that nuance either.
>>
>> Maybe that should be printed as a note on the "narrative description
>> pages"..
Svenne Krap wrote:
Rick Vernam wrote:
The reference documentation is *always* intended to be more complete and
more authoritative than the narrative description. If you don't think
so then you need to readjust your expectations.
very well, I did not know that.
expectations readjust
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rick Vernam wrote:
>> The reference documentation is *always* intended to be more complete and
>> more authoritative than the narrative description. If you don't think
>> so then you need to readjust your expectations.
> very well, I did not know that
Fujii Masao wrote:
On Fri, Jan 30, 2009 at 11:55 PM, Heikki Linnakangas
wrote:
The startup process now catches SIGTERM, and calls proc_exit() at the next
WAL record. That's what will happen in a fast shutdown. Unexpected death of
the startup process is treated the same as a backend/auxiliary pr
Is this basically the same as our current algorithm but without
multiplexing the tapes onto single files? I have been wondering
whether we multiplex the tapes any better than filesystems can lay out
separate files actually.
Or is there something else that's different here?
--
greg
--
Sent via
On Wed, 2009-02-04 at 14:42 +0800, Don Marvick wrote:
> 4. any other issue needs consideration?
Most attempts to improve sorting further have fallen to nothing because
of the lack of repeatable test results. In particular, coming up with
test cases *after* writing the code is a good way to get l
> - Do you use a packet filtering software (eg. firewall)?
> If yes, what happens if you disabled such a software?
Firewall was disabled
> - Do you use SELinux?
> If yes, what happens if you disabled SELinux?
SELinux is disabled.
> - Please run the following commands and report those result
On Tue, Feb 03, 2009 at 04:06:39PM -0300, Alvaro Herrera wrote:
> Note that spoonbill is still red. This animal is special because it
> uses some peculiar malloc flags.
Not just spoonbill, five of them are. Without access to a failing machine this
is difficult to debug. I found some missing error
Hi,
Thanks for the response.
I tried with the your sources and found the same issue.
I explain the steps that I followed, just to avoid any gaps in
understanding.
1) I assumes that the patch was already applied in your sources. So did
went ahead doing "configure", "make" and "make install"
2) Bui
Hi,
On Wed, Feb 4, 2009 at 4:17 PM, K, Niranjan (NSN - IN/Bangalore)
wrote:
> Thanks for the response.
> I tried with the your sources and found the same issue.
Thanks for the retesting!
> Could you please help. If you need any more symptoms, I can re-work.
May I ask you some questions?
- Do
82 matches
Mail list logo
