Re: [HACKERS] Proposal: Select ... AS OF Savepoint

2007-11-04 Thread Simon Riggs
On Mon, 2007-11-05 at 11:58 +0530, Gokulakannan Somasundaram wrote: > The idea was to write a syncpoint every N seconds where we > record the > time and a snapshot of what's in progress. > > What exactly is getting recorded here? Will the Syncpoint be similar > to the Und

Re: [HACKERS] Proposal: Select ... AS OF Savepoint

2007-11-04 Thread Gokulakannan Somasundaram
On 11/4/07, Simon Riggs <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-11-02 at 13:40 +0100, Hans-Juergen Schoenig wrote: > > > > > > I think Simon Riggs is already working on that idea. This one is > > > fairly easy to implement. I think these are some of the features > > > only a time-stamp based da

Re: [HACKERS] type money causes unrestorable dump

2007-11-04 Thread D'Arcy J.M. Cain
On Sun, 04 Nov 2007 20:38:11 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: > "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes: > > Hmm. I think I like Tom's version better. However, since my primary > > goal here is to remove the deprecation I will let you guys duke it out > > over the additional clause

Re: [HACKERS] Proposal: real procedures again (8.4)

2007-11-04 Thread Bruce Momjian
This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Pavel Stehule wrote: > Hello, > > I found lot of discus about this topic. > > http://www.postgresql.org/docs/faqs.T

Re: [HACKERS] should I worry?

2007-11-04 Thread Tom Lane
I wrote: >> Hmm, this is messier than I thought. What evidently has happened is >> that at one time or another, one of the two tables involved in an FK >> relationship has been dropped and re-created. If you'd had proper >> FK constraints the constraints would have gone away cleanly, but with >>

Re: [HACKERS] type money causes unrestorable dump

2007-11-04 Thread Tom Lane
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes: > Hmm. I think I like Tom's version better. However, since my primary > goal here is to remove the deprecation I will let you guys duke it out > over the additional clause. :-) Just pick the wording you like and commit it; we've spent more than eno

Re: [HACKERS] should I worry?

2007-11-04 Thread Tom Lane
I wrote: > Hmm, this is messier than I thought. What evidently has happened is > that at one time or another, one of the two tables involved in an FK > relationship has been dropped and re-created. If you'd had proper > FK constraints the constraints would have gone away cleanly, but with > these

Re: [HACKERS] type money causes unrestorable dump

2007-11-04 Thread D'Arcy J.M. Cain
On Sun, 4 Nov 2007 17:24:10 -0500 (EST) Bruce Momjian <[EMAIL PROTECTED]> wrote: > D'Arcy J.M. Cain wrote: > > + > > +Since the output of this data type is locale-sensitive, it may not > > +work to load money data into a database that has a different > > +setting of lc_monetary. To

Re: [HACKERS] "bad key in cancel request"

2007-11-04 Thread Neil Conway
On Sun, 2007-11-04 at 11:06 -0500, Tom Lane wrote: > No, if it's intended for the log it should be LOG. Your other proposals > are actually *less* likely to get to where the DBA could see them. Good point. I suggested WARNING because that suggests that something is awry, whereas LOG is used for r

Re: [HACKERS] type money causes unrestorable dump

2007-11-04 Thread Bruce Momjian
D'Arcy J.M. Cain wrote: > + > +Since the output of this data type is locale-sensitive, it may not > +work to load money data into a database that has a different > +setting of lc_monetary. To avoid problems, before > +restoring a dump make sure lc_monetary has the same or > +

Re: [PATCHES] [HACKERS] Text <-> C string

2007-11-04 Thread Bruce Momjian
This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Brendan Jurd wrote: > As discussed on -hackers, I'm trying to get rid of some redundant code > by creating a widely u

Re: [HACKERS] should I worry?

2007-11-04 Thread Tom Lane
> On Sun, 4 Nov 2007, Tom Lane wrote: >> Would it be possible for you to send me (off-list) all of the CREATE >> CONSTRAINT TRIGGER commands appearing in the dump? > [done] Hmm, this is messier than I thought. What evidently has happened is that at one time or another, one of the two tables invo

Re: [HACKERS] Test lab

2007-11-04 Thread Stefan Kaltenbrunner
Greg Smith wrote: > On Sat, 3 Nov 2007, Stefan Kaltenbrunner wrote: > >> there is the various dbt workloads,sysbench, jans tpc-w >> implementation, hell even pgbench > > The DBT workloads are good for simulating disk-bound operations, but I > don't think they're sufficient by themselves for detec

Re: [HACKERS] Test lab

2007-11-04 Thread Simon Riggs
On Fri, 2007-11-02 at 10:42 -0700, Joshua D. Drake wrote: > The test lab is finally starting to come to fruition. We (the > community) have been donated hardware via MyYearbook and Hi5. It is my > understanding that we may also have some coming from HP. > > We are currently setting up a Trac for

Re: [HACKERS] Test lab

2007-11-04 Thread Simon Riggs
On Fri, 2007-11-02 at 17:25 -0700, Mark Wong wrote: > On Fri, 02 Nov 2007 15:20:27 -0400 > Tom Lane <[EMAIL PROTECTED]> wrote: > > > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: > > > My question is -hackers, is who wants first bite and what do they > > > want :) > > > > Something I'd like to h

Re: [HACKERS] [GENERAL] AutoVacuum Behaviour Question

2007-11-04 Thread Tom Lane
Alvaro Herrera <[EMAIL PROTECTED]> writes: No, it isn't. Please add a TODO item about it: * Prevent long-lived temp tables from causing frozen-Xid advancement starvation >> > Jeff Amiel wrote: >> Can somebody explain this one to me? because of our auditing technique, we >> have m

Re: [HACKERS] Intel x64 vs AMD x64 pgdata

2007-11-04 Thread Joshua D. Drake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 04 Nov 2007 19:28:46 +0100 Zdenek Kotala <[EMAIL PROTECTED]> wrote: > Joshua D. Drake wrote: > > > > > x86_64 is x86_64, regardless of intel or amd. > > Not exactly, ask kernel guys ;-). But for user space yes. For the context of the discu

Re: [HACKERS] Intel x64 vs AMD x64 pgdata

2007-11-04 Thread Zdenek Kotala
Joshua D. Drake wrote: x86_64 is x86_64, regardless of intel or amd. Not exactly, ask kernel guys ;-). But for user space yes. Zdenek ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www

Re: [HACKERS] "bad key in cancel request"

2007-11-04 Thread Tom Lane
Neil Conway <[EMAIL PROTECTED]> writes: > ereport(DEBUG2, > (errmsg_internal("bad key in cancel request for process %d", > backendPID))); > I think this ought to be logged at a higher level than DEBUG2: for one > thing, it is a potential security issue the DBA might wa

Re: [HACKERS] Test lab

2007-11-04 Thread Greg Smith
On Sat, 3 Nov 2007, Stefan Kaltenbrunner wrote: there is the various dbt workloads,sysbench, jans tpc-w implementation, hell even pgbench The DBT workloads are good for simulating disk-bound operations, but I don't think they're sufficient by themselves for detecting performance regressions

Re: [HACKERS] type money causes unrestorable dump

2007-11-04 Thread D'Arcy J.M. Cain
On Sat, 03 Nov 2007 15:47:40 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > Greg's objection caused me to rethink that. Doing it would be a problem > when transporting dump files across platforms: what if the appropriate > locale name is spelled differently on the new machine? We should > probably l

Re: [HACKERS] should I worry?

2007-11-04 Thread Tom Lane
[EMAIL PROTECTED] writes: > I've tried it and got those logs: BTW, is that a complete list of the NOTICEs you got? I'd expect to see exactly two "ignoring" messages for each "converting" message, and it's a bit worrisome that that's not what you seem to have. Another thing that's strange is that

Re: [HACKERS] should I worry?

2007-11-04 Thread Tom Lane
[EMAIL PROTECTED] writes: > I've got two problems: > Looking at the errors, ISTM foreign statement is the over way round : > levt_tevt_cod is in ligne_evt NOT in type_evt No, that's just how we've worded FK violation errors for some time. The real question is how did FK violations get into your d

Re: [HACKERS] should I worry?

2007-11-04 Thread ohp
Dear Tom, On Sat, 3 Nov 2007, Tom Lane wrote: > Date: Sat, 03 Nov 2007 21:21:20 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: Heikki Linnakangas <[EMAIL PROTECTED]>, > pgsql-hackers list > Subject: Re: [HACKERS] should I worry? > > [EMAIL PROTECTED] writes: > > Is

Re: [HACKERS] Segmentation fault using digest from pg_crypto

2007-11-04 Thread Bruce Momjian
Marko Kreen wrote: > On 8/24/07, Manuel Sugawara <[EMAIL PROTECTED]> wrote: > > Tom Lane <[EMAIL PROTECTED]> writes: > > > Manuel Sugawara <[EMAIL PROTECTED]> writes: > > >> "Marko Kreen" <[EMAIL PROTECTED]> writes: > > >>> In 8.0 the pgcrypto functions were non-strict and checked for NULLs. > > >>

Re: [HACKERS] Proposal: Select ... AS OF Savepoint

2007-11-04 Thread Simon Riggs
On Fri, 2007-11-02 at 13:40 +0100, Hans-Juergen Schoenig wrote: > > > > I think Simon Riggs is already working on that idea. This one is > > fairly easy to implement. I think these are some of the features > > only a time-stamp based database can implement. I think database > > standards were form

Re: [HACKERS] xlogdump

2007-11-04 Thread Simon Riggs
On Fri, 2007-11-02 at 10:54 +, Gregory Stark wrote: > Incidentally I would like to call xlog.c:RecordIsValid() which is currently a > static function. Any objection to exporting it? It doesn't depend on any > external xlog.c state. You'll have some fun with that because most of the stuff in x

Re: [HACKERS] Asynchronous commit documentation gap

2007-11-04 Thread Simon Riggs
On Fri, 2007-11-02 at 11:13 +0100, Florian Weimer wrote: > The documentation doesn't really tell how to disable synchronous > commits for a single commit. I believe the correct command is > > SET LOCAL synchronous_commit TO OFF; > > just before the COMMIT statement. Yes, in fact anywhere with

[HACKERS] "bad key in cancel request"

2007-11-04 Thread Neil Conway
I noticed that processCancelRequest() emits a log message at DEBUG2 when it receives a cancel request with a bad key or for a non-existent PID. For example, ereport(DEBUG2, (errmsg_internal("bad key in cancel request for process %d", backendPID))); I think this ought