[HACKERS] limiting parallelism in "make check"
I recently posted a patch to pg_regress to limit parallelism for cygwin to a maximum of 10, so that "make check" could succeed. Tom preferred that this should be settable by the user explicitly rather than hard coded (and hidden), and not limited by platform, so that you could say make MAX_CONNECTIONS=10 check or pg_regress --max-connections=10 Adding these switches should be quite straightforward., and I'm prepared to do it. I think it's important that we can run "make check" everywhere. A slightly simpler alternative would be to provide "make serialcheck" which would run the serial schedule of tests in a temp installation. Thoughts? andrew
Re: [HACKERS] Slightly inconsistent behaviour in regproc?
Only regproc adds the unnecessary pg_catalog. qualification, why is that?
Er, I couldn't see the part of your example where that happened?
Basically, my question is why ::regproc alone always addes the catalogue
qualification in this case?
Rows below correspond to:
::regtype
::regtype
::regprocedure
::regproc
-[ RECORD 1 ]
castsource | "char"
casttarget | text
castfunc | text("char")
castfunc2 | pg_catalog.text
eg. Why is it not:
-[ RECORD 1 ]
castsource | "char"
casttarget | text
castfunc | text("char")
castfunc2 | text
Or even:
-[ RECORD 1 ]
castsource | pg_catalog."char"
casttarget | pg_catalog.text
castfunc | pg_catalog.text("char")
castfunc2 | pg_catalog.text
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Horology failures
Oops, I have two words for you, "yesterday" and "tomorrow". ;-) Seems the problem spans almost three days. --- Christopher Kings-Lynne wrote: > I thought you said that yesterday? > > Chris > > Bruce Momjian wrote: > > > Time zone changes --- will be OK tomorrow. > > > > --- > > > > Christopher Kings-Lynne wrote: > > > >>I'm still seeing Horology failures on FreeBSD 4.9... > >> > >>See attached diff. > >> > >>Chris > >> > > > > > >>*** ./expected/horology.out Thu Sep 25 14:58:06 2003 > >>--- ./results/horology.out Tue Oct 28 11:29:24 2003 > >>*** > >>*** 577,583 > >> SELECT (timestamp with time zone 'today' = (timestamp with time zone 'yesterday' > >> + interval '1 day')) as "True"; > >> True > >> -- > >>! t > >> (1 row) > >> > >> SELECT (timestamp with time zone 'today' = (timestamp with time zone 'tomorrow' > >> - interval '1 day')) as "True"; > >>--- 577,583 > >> SELECT (timestamp with time zone 'today' = (timestamp with time zone 'yesterday' > >> + interval '1 day')) as "True"; > >> True > >> -- > >>! f > >> (1 row) > >> > >> SELECT (timestamp with time zone 'today' = (timestamp with time zone 'tomorrow' > >> - interval '1 day')) as "True"; > >>*** > >>*** 589,595 > >> SELECT (timestamp with time zone 'tomorrow' = (timestamp with time zone > >> 'yesterday' + interval '2 days')) as "True"; > >> True > >> -- > >>! t > >> (1 row) > >> > >> SELECT (timestamp with time zone 'tomorrow' > 'now') as "True"; > >>--- 589,595 > >> SELECT (timestamp with time zone 'tomorrow' = (timestamp with time zone > >> 'yesterday' + interval '2 days')) as "True"; > >> True > >> -- > >>! f > >> (1 row) > >> > >> SELECT (timestamp with time zone 'tomorrow' > 'now') as "True"; > >> > >>== > >> > > > > > >>---(end of broadcast)--- > >>TIP 3: if posting/reading through Usenet, please send an appropriate > >> subscribe-nomail command to [EMAIL PROTECTED] so that your > >> message can get through to the mailing list cleanly > > > > > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Open items
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > We only have a few open items left. Can we finish them so we can move
> > toward final release?
>
> Okay, here's my two cents:
>
> > Allow superuser (dba?) the ability to turn off foreign key checks/all
> > constraints/triggers, not settable from postgresql.conf?
>
> We have seen a wide variety of proposals and opinions on this, ranging
> from "you can turn off the C in ACID anytime you want" to "you can
> suppress ALTER TABLE ADD FOREIGN KEY's cross-check ... and nothing else
> ... but only if you are superuser, mutter the right secret password, and
> spin three times widdershins". I am in the "three times widdershins"
> camp myself. But given the lack of consensus, I think the right
> short-term answer is to do nothing further. We can improve this more
> in future releases.
>
> > Move ANALYZE before foreign key creation?
>
> "Move"? pg_dump scripts don't issue ANALYZE at all. Again, I think
> this is not something to be introducing at the last minute.
I am grouping the above two items together --- I thought the idea was to
give people a way to load 7.4 in a fairly rapid manner --- we now have
the ability to do ALTER TABLE ADD CONSTRAINT, but it lacks ANALYZE
statistics, so it is kind of slow --- perhaps nothing can be done about
this. Should we try to gather some statistics before doing the ALTER
TABLE ADD CONSTRAINT queries if no stats exist? I am not advocating it,
but just asking. Should COPY update the row count? Would that help?
Also, if we want to improve this for 7.5, should we be modifying pg_dump
now to improve load times for later reloads? I think that was part of
the issue. Of course, we can do that in a minor release, but it is
better to hit it now.
Also, I find I use a lot of "---" in my emails because it seems the best
way to clearly communicate my intent, but I didn't realize how often I
am using sentence fragments. Hope that is OK with everyone. Full
sentences are so definate, while sentence fragments communicate the
uncertainty I have on many issues where I am looking for
concensus/opinions and don't want to state something in black and white.
> > Rename dump GUC variable to be more generic
>
> Sure, if we can agree on a name.
We have a few options here. Currently it is "check_function_bodies".
The ideas where validation mode:
> I think I'd prefer to keep foreign key check disabling separate. Or at
> least make it separately selectable. Maybe validation_mode could have
> multiple levels ("off", "safe", "risky")?
and an even more generic "restore_mode" where the restore_mode could
control even more things, such as doing an ANALYZE before an ALTER TABLE
ADD CONSTRAINT.
However, we also have the "check_constraints" floating out there that we
might add some day to disable constraints, so I can imagine us having
more than one knob to tune in restore situations.
What I am concerned about it adding "validation_mode" then needing to
add "restore_mode" later (for some other purpose) that will need to turn
off "validation_mode". In that case, we have conflicting GUC variables
and that is bad news.
After thinking for a while, I think validation is too important a
concept to be lumped into a restore_mode variable. Let's call it
validation_mode. Right now it controls only function bodies, but later
it can control constraint checking and perhaps other things, and of
course only for the super-user. It could have three values if you wish:
"off", "delay", and "on", where function bodies would really be a
"delay".
> > Document new --describe-config postgres option
>
> Go to it.
OK, I will get on it --- I will just mention it and say it is mostly
useful for admin tools.
> > Have gcc use -g, add --disable-debug, rename?
>
> Personally I don't like the idea of this behavior defaulting differently
> depending on which compiler you use. I can see the practical arguments
> for doing so, but it still rubs me the wrong way. Can anyone offer new
> arguments pro or con here?
You and I think don't like the inconsistency, while Jan likes the debug
where ever possible (gcc). There were a few others who liked the debug
for gcc by default.
I think if folks are debugging, they probably should turn off
optimization anyway to make sense of the output, and we are never going
to ship without optimization. What might be nice would be for
--enable-debug to turn off optimization as well so people can actually
make sense of the code in the debugger.
Basically, I don't like the debug because of:
inconsistency with non-gcc
binary bloat
binary bloat encourages strip, which is really bad
Usually function names are enough for us to take a guess on the cause.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square,
Re: [HACKERS] Horology failures
er, plus 3 hours, I think, i.e. just under 2 hours from now ... (unless you posted this in the future :-) ) [EMAIL PROTECTED] andrew]$ TZ=PST8PDT date Mon Oct 27 22:07:22 PST 2003 [EMAIL PROTECTED] andrew]$ date Tue Oct 28 01:07:28 EST 2003 [EMAIL PROTECTED] andrew]$ cheers andrew - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Christopher Kings-Lynne" <[EMAIL PROTECTED]> Cc: "Hackers" <[EMAIL PROTECTED]> Sent: Monday, October 27, 2003 11:16 PM Subject: Re: [HACKERS] Horology failures > Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > > I'm still seeing Horology failures on FreeBSD 4.9... > > Should stop at midnight Tuesday, PST8PDT time (about 45 minutes > from now) ... see prior discussion ... > > regards, tom lane > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Open items
what about my Privilege regression failure? I'm not sure why it's dying... LER --On Monday, October 27, 2003 23:32:45 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: We only have a few open items left. Can we finish them so we can move toward final release? Okay, here's my two cents: Allow superuser (dba?) the ability to turn off foreign key checks/all constraints/triggers, not settable from postgresql.conf? We have seen a wide variety of proposals and opinions on this, ranging from "you can turn off the C in ACID anytime you want" to "you can suppress ALTER TABLE ADD FOREIGN KEY's cross-check ... and nothing else ... but only if you are superuser, mutter the right secret password, and spin three times widdershins". I am in the "three times widdershins" camp myself. But given the lack of consensus, I think the right short-term answer is to do nothing further. We can improve this more in future releases. Move ANALYZE before foreign key creation? "Move"? pg_dump scripts don't issue ANALYZE at all. Again, I think this is not something to be introducing at the last minute. Rename dump GUC variable to be more generic Sure, if we can agree on a name. Document new --describe-config postgres option Go to it. Have gcc use -g, add --disable-debug, rename? Personally I don't like the idea of this behavior defaulting differently depending on which compiler you use. I can see the practical arguments for doing so, but it still rubs me the wrong way. Can anyone offer new arguments pro or con here? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] When the last vacuum occured? It's necessary to run
Thiago Fernandes Moesch wrote: It would be great for maintainance if every object had a timestamp of the last vaccum run on it. From time to time we're working with several databases and I can't tell wich one needs a new vacuum. Another important information would be the rate of disposable data in every table (like old and delete records) it would help was to determine if a vacuum is required. You could rather use autovacuum than adding timestamps to fields. HTH Shridhar ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Duplicating transaction information in indexes and
Tom Lane wrote: Shridhar Daithankar <[EMAIL PROTECTED]> writes: What are (more) reasons for not adding transaction information to index tuple, in addition to heap tuple? Cons are bloated indexes. The index tuple size will be close to 30 bytes minimum. And extra time to perform an update or delete, and extra time for readers of the index to process and perhaps update the extra copies of the row's state. And atomicity concerns, since you can't possibly update the row and all its index entries simultaneously. I'm not certain that the latter issue is insoluble, but it surely is a big risk. The additional information going in index, is available while updating the index, I assume. So extra time required is IO for pushing that page to disk. As far as updating each index row is concerned, I was under impression that all relevant indexes are updated when a row is updated. Isn't that right? On pro* side of this, no more vacuum required (at least for part of data that is being used. If data isn't used, it does not need vacuum anyway) and space bloat is stopped right in memory, without incurring overhead of additional IO vacuum demands. OK, no more vacuum required is "marketing speak" for it. It is not strictly true. I do not believe either of those claims. For starters, if you don't remove a row's index entries when the row itself is removed, won't that make index bloat a lot worse? When exactly *will* you remove the index entries ... and won't that process look a lot like VACUUM? If a heap row is removed and index rows are not removed, it would not make any difference because the index row would contain all the information to infer that it is dead and can be removed. The dead index row would be removed, when index page is fetched into buffer cache and being pushed out, just like a heap tuple. It would not need heap tuple(s) to clean the index page. The index bloat would not be any worse than current because all the information available in index itself, vacuum can clean the dead indexes as well. And yes, it is essentially vacuum. But with some differences. * It will operate on buffer pages only. Not on entire database objects. It makes it CPU bound operation and cheaper compared to IO incurred. If we assume CPU to be cheap enough, additional processing would not affect regular operation that much. * It will operate continuously unlike vacuum which needs a trigger. That could lower overall throughput a little but it would be much more consistent throughput rather than peaks and crests shown by triggered vacuum approach. * It will not clean up entire database objects but only pages in question. So some bloat might be left on disk, on indexes and on heaps. But whatever that gets used will be cleaned up. Assuming caching works normally, it will keep the data set clean for frequent use. * It is out of order in a sense, index and heap will not be cleaned in sync. The extra information in index is to make sure that this can happen. This will not really eliminate vacuum but would rather drive down significance of vacuum. Right now, a write/updateheavy database will die horribly if not vacuumed aggressively. Hopefully situation will be much better with such an approach. Bye Shridhar ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Slightly inconsistent behaviour in regproc?
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > Only regproc adds the unnecessary pg_catalog. qualification, why is that? Er, I couldn't see the part of your example where that happened? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Open items
Marc G. Fournier wrote: > > > > On Mon, 27 Oct 2003, Bruce Momjian wrote: > > > > > Marc G. Fournier wrote: > > > > > > > > > > > > On Mon, 27 Oct 2003, Bruce Momjian wrote: > > > > > > > > > Changes > > > > > --- > > > > > Allow superuser (dba?) the ability to turn off foreign key checks/all > > > > > constraints/triggers, not settable from postgresql.conf? > > > > > > > > feature, not bug fix, no? > > > > > > It became important when everyone realized that 7.4 would be first major > > > upgrade with full foreign key checking --- prior to that we did CREATE > > > CONSTRAINT TRIGGER that didn't check data. Basically, that's how it got > > > on the open item list. > > Altho important, it is still a feature, and as such, should not be > critical to holding up the release ... That's all I need --- a consensus that is isn't significant enough to be on this list. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Horology failures
I said: > Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: >> I'm still seeing Horology failures on FreeBSD 4.9... > Should stop at midnight Tuesday, PST8PDT time (about 45 minutes > from now) ... see prior discussion ... Argh ... make that "3 hours from now" ... you'd think I could remember the time shift between here and the Left Coast ... regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Open items
Bruce Momjian <[EMAIL PROTECTED]> writes: > We only have a few open items left. Can we finish them so we can move > toward final release? Okay, here's my two cents: > Allow superuser (dba?) the ability to turn off foreign key checks/all > constraints/triggers, not settable from postgresql.conf? We have seen a wide variety of proposals and opinions on this, ranging from "you can turn off the C in ACID anytime you want" to "you can suppress ALTER TABLE ADD FOREIGN KEY's cross-check ... and nothing else ... but only if you are superuser, mutter the right secret password, and spin three times widdershins". I am in the "three times widdershins" camp myself. But given the lack of consensus, I think the right short-term answer is to do nothing further. We can improve this more in future releases. > Move ANALYZE before foreign key creation? "Move"? pg_dump scripts don't issue ANALYZE at all. Again, I think this is not something to be introducing at the last minute. > Rename dump GUC variable to be more generic Sure, if we can agree on a name. > Document new --describe-config postgres option Go to it. > Have gcc use -g, add --disable-debug, rename? Personally I don't like the idea of this behavior defaulting differently depending on which compiler you use. I can see the practical arguments for doing so, but it still rubs me the wrong way. Can anyone offer new arguments pro or con here? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Open items
> On Mon, 27 Oct 2003, Bruce Momjian wrote: > > > Marc G. Fournier wrote: > > > > > > > > > On Mon, 27 Oct 2003, Bruce Momjian wrote: > > > > > > > Changes > > > > --- > > > > Allow superuser (dba?) the ability to turn off foreign key checks/all > > > > constraints/triggers, not settable from postgresql.conf? > > > > > > feature, not bug fix, no? > > > > It became important when everyone realized that 7.4 would be first major > > upgrade with full foreign key checking --- prior to that we did CREATE > > CONSTRAINT TRIGGER that didn't check data. Basically, that's how it got > > on the open item list. Altho important, it is still a feature, and as such, should not be critical to holding up the release ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Horology failures
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > I'm still seeing Horology failures on FreeBSD 4.9... Should stop at midnight Tuesday, PST8PDT time (about 45 minutes from now) ... see prior discussion ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open items
On Mon, 27 Oct 2003, Bruce Momjian wrote: > Marc G. Fournier wrote: > > > > > > On Mon, 27 Oct 2003, Bruce Momjian wrote: > > > > > Changes > > > --- > > > Allow superuser (dba?) the ability to turn off foreign key checks/all > > > constraints/triggers, not settable from postgresql.conf? > > > > feature, not bug fix, no? > > It became important when everyone realized that 7.4 would be first major > upgrade with full foreign key checking --- prior to that we did CREATE > CONSTRAINT TRIGGER that didn't check data. Basically, that's how it got > on the open item list. Have we heard anything about whether this is still as important given the other optimizations to the alter table case from people with large enough data sets to notice? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Horology failures
I thought you said that yesterday? Chris Bruce Momjian wrote: Time zone changes --- will be OK tomorrow. --- Christopher Kings-Lynne wrote: I'm still seeing Horology failures on FreeBSD 4.9... See attached diff. Chris *** ./expected/horology.out Thu Sep 25 14:58:06 2003 --- ./results/horology.out Tue Oct 28 11:29:24 2003 *** *** 577,583 SELECT (timestamp with time zone 'today' = (timestamp with time zone 'yesterday' + interval '1 day')) as "True"; True -- ! t (1 row) SELECT (timestamp with time zone 'today' = (timestamp with time zone 'tomorrow' - interval '1 day')) as "True"; --- 577,583 SELECT (timestamp with time zone 'today' = (timestamp with time zone 'yesterday' + interval '1 day')) as "True"; True -- ! f (1 row) SELECT (timestamp with time zone 'today' = (timestamp with time zone 'tomorrow' - interval '1 day')) as "True"; *** *** 589,595 SELECT (timestamp with time zone 'tomorrow' = (timestamp with time zone 'yesterday' + interval '2 days')) as "True"; True -- ! t (1 row) SELECT (timestamp with time zone 'tomorrow' > 'now') as "True"; --- 589,595 SELECT (timestamp with time zone 'tomorrow' = (timestamp with time zone 'yesterday' + interval '2 days')) as "True"; True -- ! f (1 row) SELECT (timestamp with time zone 'tomorrow' > 'now') as "True"; == ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open items
On Mon, Oct 27, 2003 at 07:45:53PM -0800, Joshua D. Drake wrote: > Hello, > > Well the reason I brought it up was the rather interesting discussion > that Jan had today about Vacuum. > I was wondering if we were going to explore that before the 7.4 release? I would expect that to be left for 7.5 ... ? -- Alvaro Herrera () ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open items
Joshua D. Drake wrote: > Hello, > > Well the reason I brought it up was the rather interesting discussion > that Jan had today about Vacuum. > I was wondering if we were going to explore that before the 7.4 release? No, I am afraid we are way past time time for that kind of addition. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Slightly inconsistent behaviour in regproc?
When you do this query:
SET SEARCH_PATH TO pg_catalog;
SELECT castsource::pg_catalog.regtype AS castsource,
casttarget::pg_catalog.regtype AS casttarget,
castfunc::pg_catalog.regprocedure AS castfunc,
castfunc::pg_catalog.regproc AS castfunc2 FROM pg_catalog.pg_cast ORDER
BY 1, 2;
Only regproc adds the unnecessary pg_catalog. qualification, why is that?
Results:
-[ RECORD 1 ]
castsource | "char"
casttarget | text
castfunc | text("char")
castfunc2 | pg_catalog.text
-[ RECORD 2 ]
castsource | "char"
casttarget | character
castfunc | bpchar("char")
castfunc2 | pg_catalog.bpchar
-[ RECORD 3 ]
castsource | name
casttarget | text
castfunc | text(name)
castfunc2 | pg_catalog.text
-[ RECORD 4 ]
castsource | name
casttarget | character
castfunc | bpchar(name)
castfunc2 | pg_catalog.bpchar
-[ RECORD 5 ]
castsource | name
casttarget | character varying
castfunc | "varchar"(name)
castfunc2 | pg_catalog."varchar"
-[ RECORD 6 ]
castsource | bigint
casttarget | smallint
castfunc | int2(bigint)
castfunc2 | pg_catalog.int2
-[ RECORD 7 ]
castsource | bigint
casttarget | integer
castfunc | int4(bigint)
castfunc2 | pg_catalog.int4
...
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Open items
Hello, Well the reason I brought it up was the rather interesting discussion that Jan had today about Vacuum. I was wondering if we were going to explore that before the 7.4 release? Sincerely, Joshua Drake Bruce Momjian wrote: Marc G. Fournier wrote: On Mon, 27 Oct 2003, Joshua D. Drake wrote: Hello, Based on the current open items... when do we expect release? As soon as the items are fixed? :) I am confused why we aren't wrapping up these items. I have waited for the people who proposed these ideas to jump in and do them, but I might start on them myself soon. -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Open items
Marc G. Fournier wrote: > > > On Mon, 27 Oct 2003, Joshua D. Drake wrote: > > > Hello, > > > > Based on the current open items... when do we expect release? > > As soon as the items are fixed? :) I am confused why we aren't wrapping up these items. I have waited for the people who proposed these ideas to jump in and do them, but I might start on them myself soon. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Horology failures
Time zone changes --- will be OK tomorrow. --- Christopher Kings-Lynne wrote: > I'm still seeing Horology failures on FreeBSD 4.9... > > See attached diff. > > Chris > > *** ./expected/horology.out Thu Sep 25 14:58:06 2003 > --- ./results/horology.outTue Oct 28 11:29:24 2003 > *** > *** 577,583 > SELECT (timestamp with time zone 'today' = (timestamp with time zone 'yesterday' + > interval '1 day')) as "True"; >True > -- > ! t > (1 row) > > SELECT (timestamp with time zone 'today' = (timestamp with time zone 'tomorrow' - > interval '1 day')) as "True"; > --- 577,583 > SELECT (timestamp with time zone 'today' = (timestamp with time zone 'yesterday' + > interval '1 day')) as "True"; >True > -- > ! f > (1 row) > > SELECT (timestamp with time zone 'today' = (timestamp with time zone 'tomorrow' - > interval '1 day')) as "True"; > *** > *** 589,595 > SELECT (timestamp with time zone 'tomorrow' = (timestamp with time zone > 'yesterday' + interval '2 days')) as "True"; >True > -- > ! t > (1 row) > > SELECT (timestamp with time zone 'tomorrow' > 'now') as "True"; > --- 589,595 > SELECT (timestamp with time zone 'tomorrow' = (timestamp with time zone > 'yesterday' + interval '2 days')) as "True"; >True > -- > ! f > (1 row) > > SELECT (timestamp with time zone 'tomorrow' > 'now') as "True"; > > == > > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Open items
On Mon, 27 Oct 2003, Joshua D. Drake wrote: > Hello, > > Based on the current open items... when do we expect release? As soon as the items are fixed? :) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Horology failures
I'm still seeing Horology failures on FreeBSD 4.9... See attached diff. Chris *** ./expected/horology.out Thu Sep 25 14:58:06 2003 --- ./results/horology.out Tue Oct 28 11:29:24 2003 *** *** 577,583 SELECT (timestamp with time zone 'today' = (timestamp with time zone 'yesterday' + interval '1 day')) as "True"; True -- ! t (1 row) SELECT (timestamp with time zone 'today' = (timestamp with time zone 'tomorrow' - interval '1 day')) as "True"; --- 577,583 SELECT (timestamp with time zone 'today' = (timestamp with time zone 'yesterday' + interval '1 day')) as "True"; True -- ! f (1 row) SELECT (timestamp with time zone 'today' = (timestamp with time zone 'tomorrow' - interval '1 day')) as "True"; *** *** 589,595 SELECT (timestamp with time zone 'tomorrow' = (timestamp with time zone 'yesterday' + interval '2 days')) as "True"; True -- ! t (1 row) SELECT (timestamp with time zone 'tomorrow' > 'now') as "True"; --- 589,595 SELECT (timestamp with time zone 'tomorrow' = (timestamp with time zone 'yesterday' + interval '2 days')) as "True"; True -- ! f (1 row) SELECT (timestamp with time zone 'tomorrow' > 'now') as "True"; == ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Open items
Hello, Based on the current open items... when do we expect release? Sincerely, Joshua Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open items
Marc G. Fournier wrote: > > > On Mon, 27 Oct 2003, Bruce Momjian wrote: > > > Changes > > --- > > Allow superuser (dba?) the ability to turn off foreign key checks/all > > constraints/triggers, not settable from postgresql.conf? > > feature, not bug fix, no? It became important when everyone realized that 7.4 would be first major upgrade with full foreign key checking --- prior to that we did CREATE CONSTRAINT TRIGGER that didn't check data. Basically, that's how it got on the open item list. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Open items
On Mon, 27 Oct 2003, Bruce Momjian wrote: > Changes > --- > Allow superuser (dba?) the ability to turn off foreign key checks/all > constraints/triggers, not settable from postgresql.conf? feature, not bug fix, no? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Open items
We only have a few open items left. Can we finish them so we can move toward final release? --- P O S T G R E S Q L 7 . 4 O P E NI T E M S Current at ftp://momjian.postgresql.org/pub/postgresql/open_items. Changes --- Allow superuser (dba?) the ability to turn off foreign key checks/all constraints/triggers, not settable from postgresql.conf? Move ANALYZE before foreign key creation? Rename dump GUC variable to be more generic Document new --describe-config postgres option Have gcc use -g, add --disable-debug, rename? Documentation Changes - -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Bruce Momjian wrote: Jan Wieck wrote: > In fact, even though I was debugging the backend regularly, I removed -g > and added it only when I wanted to debug. > It did somethimes in the past proove to be good luck to have symbols in a core file accidentially. If you want to find them in an arbitrary out of the box installation, they have to be in the default configuration. That they cannot be there if a non-gcc does not optimize the code then, sure. But I don't really see the confusion you're talking about. Nor do I see the importance of link-time when setting up a production system from sources. Do not mix up developer usage with DBA usage. You can ask a developer to use "--disable-debug", and when he complains about slow compiles it's still time to tell him. But if you expect a DBA to configure "--enable-debug" you will get core files that are plain useless and it's too late. What I would like to maintain is the best possible support capability (finding symbols wherever possible to do the aftermath of a crashed backend), while providing the best possible performance - with performance having priority. That this leads to different options used on different platforms and compilers, so be it. This leaves us with "--enable-debug" for non-gcc compilers, and adding "--disable-debug" for gcc compilers. Right now configure --help has: --enable-debug build with debugging symbols (-g) If people want to add --disable-debug, and document which is gcc and non-gcc, that is fine with me. Also, usually, you don't want to run the debugger on optimized code unless you are debugging a compiler issue, so maybe we should call it --debugging-symbols and --no-debugging-symbols to make it clear what the option does. I never "want" to run any debugger, I am sometimes "forced" to do so and then the more symbols I have the better. Debugging optimized code can lead to some confusion as the optimizer is allowed to reorder code execution or keep variables in registers instead of on the stack and thus, the flow of instructions is not in sync with the sourcecode, what makes it kinda hard sometimes to set breakpoints or to see what statements actually have NOT been executed already when looking at a file. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Defaults for GUC variables (was Re: [HACKERS] pg_ctl reports
However, you're not the first to get burnt by this mis-assumption, so maybe we should do something about it. The low-tech solution to this would be to stop listing the default values as commented-out entries, but just make them ordinary uncommented entries. That way people who think "undoing my edit will revert the change" would be right. I would be in favour of that way of doing things. I have always found it weird that defaults were commented out... Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] round() function wrong?
"scott.marlowe" <[EMAIL PROTECTED]> writes: > So it would appear to be that the automatic assumptions about what is > float and what is numeric changed from 7.2 to 7.3, i.e. it's assumed that > numeric is the input type. That's correct. Looking at the code, round(numeric) always rounds xxx.5 values away from zero (0.5 -> 1, -0.5 -> -1, etc). The behavior of round(float) is platform-dependent, but round-to-nearest-even is the rule used by IEEE compliant platforms. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Jan Wieck wrote: > > In fact, even though I was debugging the backend regularly, I removed -g > > and added it only when I wanted to debug. > > > > It did somethimes in the past proove to be good luck to have symbols in > a core file accidentially. If you want to find them in an arbitrary out > of the box installation, they have to be in the default configuration. > That they cannot be there if a non-gcc does not optimize the code then, > sure. But I don't really see the confusion you're talking about. Nor do > I see the importance of link-time when setting up a production system > from sources. Do not mix up developer usage with DBA usage. You can ask > a developer to use "--disable-debug", and when he complains about slow > compiles it's still time to tell him. But if you expect a DBA to > configure "--enable-debug" you will get core files that are plain > useless and it's too late. > > What I would like to maintain is the best possible support capability > (finding symbols wherever possible to do the aftermath of a crashed > backend), while providing the best possible performance - with > performance having priority. That this leads to different options used > on different platforms and compilers, so be it. This leaves us with "--enable-debug" for non-gcc compilers, and adding "--disable-debug" for gcc compilers. Right now configure --help has: --enable-debug build with debugging symbols (-g) If people want to add --disable-debug, and document which is gcc and non-gcc, that is fine with me. Also, usually, you don't want to run the debugger on optimized code unless you are debugging a compiler issue, so maybe we should call it --debugging-symbols and --no-debugging-symbols to make it clear what the option does. Also, we should encourage packages to use --no-debugging-symbols rather than 'strip'. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Bruce Momjian wrote: pgman wrote: Jan Wieck wrote: > >> >> > What Peter was advocating in that thread was that we enable -g by > >> >> > default *when building with gcc*. I have no problem with that, since > >> >> > there is (allegedly) no performance penalty for -g with gcc. However, > >> >> > the actual present behavior of our configure script is to default to -g > >> >> > for every compiler, and I think that that is a big mistake. On most > >> >> > non-gcc compilers, -g disables optimizations, which is way too high a > >> >> > price to pay for production use. > >> >> > >> >> You do realize that as of now, -g is the default for gcc? Was that the > >> >> intent? > >> > > >> > I was going to ask that myself. It seems strange to include -g by default --- > >> > we have --enable-debug, and that should control -g on all platforms. > >> > >> Could it be that there ought to be a difference between the defaults of > >> a devel CVS tree, a BETA tarball and a final "production" release? > > > > I am afraid that adds too much confusion to the debug situation. We > > have a flag to do -g; let people use it if they want it. > > > > Well, -g eats up some disk space, but for a gcc it doesn't need CPU > cycles or anything else. I doubt many people who pay the horrible > storage capacity overhead for PostgreSQL are that concerned about some > extra symbols stored with their binaries, but let's not argue about that > one. Well, people are stripping the executable, so some of them must care. In fact, if we enable -g by default for gcc, how do compile with default symbols? We would need another configure option. Strip is not the same as default symbols. Let me also add that on my old dual P3 550 256MB RAM -g significantly slowed down the build because linking took a long time, probably because it had to read in all those debug symbols for the link --- I remember the backend link taking quite a lot of time. In fact, even though I was debugging the backend regularly, I removed -g and added it only when I wanted to debug. It did somethimes in the past proove to be good luck to have symbols in a core file accidentially. If you want to find them in an arbitrary out of the box installation, they have to be in the default configuration. That they cannot be there if a non-gcc does not optimize the code then, sure. But I don't really see the confusion you're talking about. Nor do I see the importance of link-time when setting up a production system from sources. Do not mix up developer usage with DBA usage. You can ask a developer to use "--disable-debug", and when he complains about slow compiles it's still time to tell him. But if you expect a DBA to configure "--enable-debug" you will get core files that are plain useless and it's too late. What I would like to maintain is the best possible support capability (finding symbols wherever possible to do the aftermath of a crashed backend), while providing the best possible performance - with performance having priority. That this leads to different options used on different platforms and compilers, so be it. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Two serial numbers in one table
Here is what I am trying to do. I have a table with two fields, both of which
are supposed to contain a serial number. The first one is the primary key
and is setup to default to a sequence in the normal way. The second one can
be one of any number of sequences. The sequence to use is calculated at run
time and the next sequence is manually included (creating the sequence if
necessary.) Sometimes the sequence is left null. In those cases it is
supposed to use the first (primary) field.
I suppose I can add a rule on the select but this is a huge and busy table
with an index and selects on the second field. I would prefer if I could
create the actual value value during insert. I did try this:
ALTER TABLE certificate
ALTER COLUMN card_id
SET DEFAULT CURRVAL('certificate_certificate_id_seq');
This mostly works but it has two problems. The first is that it seems klugey
and I am not sure if I can depend on it happening in the correct order. The
second problem is that there are edge cases (albeit none that I can imagine
happening in our application) that causes it to either fail or put a previous
value into the field.
Is there a better way to do what I am trying to do?
--
D'Arcy J.M. Cain <[EMAIL PROTECTED]|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[HACKERS] Multiple database services and multiple versions on Red Hat Linux systems
Multiple database services and multiple versions on Red Hat Linux systems The way it works is that we require a specific service script for each database service (that is listening on each port). Each of these services has a init script in /etc/init.d and a corresponding configuration file in /etc/sysconfig. We use the 'chkconfig' utility to decide if each of those services will be activated on boot or not (it manipulates links under the /etc/init.c for each SysV run level). We currently support multiple versions running. I have myself half a dozen database services on my system with versions that range from 7.1 to 7.4. As each configuration file for each service points to the location of the proper binaries we have no problems dealing with this. For example: # cat /etc/sysconfig/rhdb-production PGDATA=/usr/local/pgsql73/data PGDATA2=/var/lib/pgsql2 PGDATA3=/var/lib/pgsql3 PGDATA4=/var/lib/pgsql4 PGENGINE=/home/fnasser/INST/pgsql73/bin PGPORT=5433 PGLOG=/var/log/rhdb/rhdb-production PGINITOPTIONS="--lc-messages=pt_BR" As you can see the PGENGINE points to a binary that I built myself. It is unfortunate that I can only have one RPM installed at a time. Oliver Elphick has suggested different package names for each version that has a different catalog number (i.e., we need a pg_dump + pg_restore and we can't use these version's postmaster to access other version's data areas). If we configure each of these packages with a different base path which includes the version and install, of course, to these versioned directories, we will end up with a setup similar to what I have on my system with the bakends I've built myself. It can be even a Java-like solution /usr/pgsql/postgresql71 /usr/pgsql/postgresql72 /usr/pgsql/postgresql73 /usr/pgsql/postgresql74 or have then scattered if the LSB so requires (I believe it does not address this case though). As the binaries have been configured with the versioned paths, all RPMs are normal (not relocatable) and the binaries will refer to the libraries and other files of the proper version. So by setting one's path, the user can use the version she or he seems fit. For Red Hat's users (and Debian's, I believe), the 'alternatives' utility can be used to direct links from /usr/bin and such to the chosen version files, so a default could be established and for such there would be no need to change the PATH variable. Also, the multiple versioning can be kept only on the server side. On the client side the latest version will suffice if it guarantees a (minimum) 2 version backwards compatibility (as we do with the JDBC driver). Besides the client side backaward compatibility, what the core postgresql team could also do to support this would be to add version checks and issue warnings on mismatches (or errors if used against a version too old). Also, make sure the path of the binary does imply in the location of the other files (i.e., the path from configure is always used, and not some hardcoded value). As you see, these goals can be achieved without any changes in the postgresql community sources. Regards to all, Fernando -- Fernando Nasser Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED] 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] pg_user
ivan wrote: hi can we change initdb when view pg_user is createing to : CREATE VIEW pg_user AS \ SELECT \ usename, \ usesysid, \ usecreatedb, \ usesuper, \ usecatupd, \ ''::text as passwd, \ valuntil, \ useconfig \ FROM pg_shadow WHERE usename = SESSION_USER; No, at least not without a complete proposal how to retain the current behaviour of pg_tables, pg_views, psql's \d and other places that rely on pg_user being able to display all users. It's the same thing with your /etc/passwd. chmod o-rwx /etc/passwd will hide the usernames but break many utilities. If you don't want someone to know all the logins, don't give him one. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Vacuum thoughts
Tom Lane wrote: Jan Wieck <[EMAIL PROTECTED]> writes: What happens instead is that vacuum not only evicts the whole buffer cache by forcing all blocks of said table and its indexes in, it also dirties a substantial amount of that and leaves the dirt to be cleaned up by all the other backends. [ thinks about that... ] Yeah, I believe you're right, because (plain) vacuum just does WriteBuffer() for any page that it modifies, which only marks the page dirty in buffer cache. It never does anything to force those pages to be written out to the kernel. So, if you have a large buffer cache, a lot of write work will be left over to be picked up by other backends. I think that pre-WAL the system used to handle this stuff differently, in a way that made it more likely that VACUUM would issue its own writes. But optimizations intended to improve the behavior for non-VACUUM cases have made this not so good for VACUUM. I like your idea of penalizing VACUUM-read blocks when they go back into the freelist. This seems only a partial solution though, since it doesn't directly ensure that VACUUM rather than some other process will issue the write kernel call for the dirtied page. Maybe we should resurrect a version of WriteBuffer() that forces an immediate kernel write, and use that in VACUUM. Also, we probably need something similar for seqscan-read blocks, but with an intermediate priority (can we insert them to the middle of the freelist?) Well, "partial solution" isn't quite what I would call it, and it surely needs integration with sequential scans. I really do expect the whole hack to fall apart if some concurrent seqscans are going on since it not really penalizes the VACUUM-read blocks but more the next caller of GetFreeBuffer(). In my test case that just happens to be VACUUM most of the time. I described it only to demonstrate the existence of potential. Since the whole point of the buffer cache is to avoid the real bad thing, I/O, I don't think that the trivial double-linked list that implements it today is adequate. I can't imagine it completely yet, but what I see vaguely is a cache policy that put's a block into the freelist depending on where it was coming from (cache, seqscan, indexscan, vacuum) and what it is (heap, toast, index). That plus the possibility for vacuum to cause it to be written to kernel immediately might do it. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] DETOASTing in custom memory context
tgl wrote: > strk <[EMAIL PROTECTED]> writes: > >> From whitin an aggregate sfunc I did: > > oldcontext = MemoryContextSwitchTo(fcinfo->flinfo->fn_mcxt); > > geom = (GEOMETRY *)PG_DETOAST_DATUM(datum); > > MemoryContextSwitchTo(oldcontext); > > > And later in aggregate's finalfunc: > > pfree(geom); > > > Result: > > segfault! > > > What's wrong with it ? > > Perhaps you wanted PG_DETOAST_DATUM_COPY(). Or possibly use > PG_FREE_IF_COPY() rather than an unconditional pfree, though > that would depend on just what your usage pattern is. Sure, how did I miss that ! PG_FREE_IF_COPY is unapplicable here since pfree() call is in a different function that the one DETOASTING it (finalfunc and sfunc respectively of an aggregate), but PG_DETOAST_DATUM_COPY() did at least force a copy and thus the context-switch... thanks, --strk; ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] When the last vacuum occured? It's necessary to run it now?
Hi, It would be great for maintainance if every object had a timestamp of the last vaccum run on it. From time to time we're working with several databases and I can't tell wich one needs a new vacuum. Another important information would be the rate of disposable data in every table (like old and delete records) it would help was to determine if a vacuum is required. Best regards, Thiago Fernandes Moesch --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.530 / Virus Database: 325 - Release Date: 22/10/2003 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Deadlock Detection
How do I find out in Embedded SQL that a transaction has been aborted due to a deadlock? The closes error message in sqlca seems to be: -401 (ECPG_TRANS): Error in transaction processing line %d. PostgreSQL signaled that we cannot start, commit, or rollback the transaction. but it does not seem to be informative enough. Similarly, how do I find if a transaction has been aborted due to nonserializability? Thanks, Moshe ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PostgreSQL on Novell Netware 6.5.
> > They stopped at 7.2.4 because "they're finishing some usefull APIs, > > which'll make the port much more "easy"." > > Will this involve using a Linux kernel ;) :) No, a NW kernel with a POSIX library. This'll be great, because you'll can run powerfull opensource software with an enterprise-class NOS. Another option... Clustering support (32 x 32), stable & consistent file system (Novell's Storage System, forget the old Tradition File System (very mature & stable, but it doesn't fit the current storage necessity)), security & stability (our servers is counting 700+ days). It's a valuable addition to the Novell community, but it's also an good addition to the PostgreSQL community, but of course, when everything is 100% done. ;) Regards, Eduardo ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Foreign Key bug -- 7.4b4
Gaetano Mendola wrote: Bruce Momjian wrote: I can confirm this bug in CVS. Dropping the pkey from table b in fact drops the unique index from it. The SPI plan cached to check if a row deleted from table a is still referenced from table b "can" (and in your case does) use an index scan on table b and is thereby corrupted by dropping the pkey. Switching to a generally non-cached model for all foreign key checks would be the only workaround at the moment, and I don't see us doing that as it would cause performance to suffer big times for everyone who's system doesn't have a permanent "what's the latest schema" contest going on. Since all caching procedural languages and all caching custom C functions suffer the same, the correct fix would be to let SPI_saveplan() maintain a hash table of all referenced system cache objects who's entries point to the referencing saved plans and then mark those plans for recompile at system cache invalidation. I will probably not do it today ... tomorrow doesn't look good either. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Vacuum thoughts
Jan Wieck <[EMAIL PROTECTED]> writes: > What happens instead is that vacuum not only evicts the whole buffer > cache by forcing all blocks of said table and its indexes in, it also > dirties a substantial amount of that and leaves the dirt to be cleaned > up by all the other backends. [ thinks about that... ] Yeah, I believe you're right, because (plain) vacuum just does WriteBuffer() for any page that it modifies, which only marks the page dirty in buffer cache. It never does anything to force those pages to be written out to the kernel. So, if you have a large buffer cache, a lot of write work will be left over to be picked up by other backends. I think that pre-WAL the system used to handle this stuff differently, in a way that made it more likely that VACUUM would issue its own writes. But optimizations intended to improve the behavior for non-VACUUM cases have made this not so good for VACUUM. I like your idea of penalizing VACUUM-read blocks when they go back into the freelist. This seems only a partial solution though, since it doesn't directly ensure that VACUUM rather than some other process will issue the write kernel call for the dirtied page. Maybe we should resurrect a version of WriteBuffer() that forces an immediate kernel write, and use that in VACUUM. Also, we probably need something similar for seqscan-read blocks, but with an intermediate priority (can we insert them to the middle of the freelist?) regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Vacuum thoughts
To add some medium-hard data to the discussion, I hacked a PG 7.3.4 a little. The system I am talking about below run's an artificial application that very well resembles the behaviour of a TPC-C benchmark implementation. Without vacuuming the database, it can just so sustain a factor 5 scaled database running with 50 simulated terminals. To free some bandwidth, the system is configured with scaling 4 and runs with 40 simulated terminals. In this configuration it can satisfy the responsetime requirements for 100% of all transactions when not vacuuming ... no surprise. The test driver takes 10 minute intervals and reports the percentage of transactions which qualify. If the database now is vacuumed simultaneously, the response time for transactions changes dramatically. A 10 minute interval hit by vacuum drops down from 100% to anything below 90%, I've seen it down to 75%. The system load given by a Linux 2.4 kernel jumps up from under 1.0 to anything between 5 and 8. So far, that is exactly what most DBA's are complaining about. A system that runs smoothly otherwise get's literally bogged down by any vacuum. Now I changed the cache policy. While a backend is running vacuum, a global flag is set. If this flag is set and a block is not found in the cache but must be read, it's buffer is marked BM_READ_BY_VACUUM. When the global flag is set, AddBufferToFreelist() inserts buffers so marked at the head of the freelist instead of adding them to the tail. In any case, the buffers BM_READ_BY_VACUUM flag is cleared. The effect of this simple hack is somewhat surprising. Not only can the system keep satisfying 97% or more of all transactions within time limits and the system load stays well below 2.0 (I've only seen 1.6 once), but very surprisingly VACUUM finishes about 20% faster too. I'm not a friend of jumping to conclusions, OTOH I have to try to make some sense out of it. So I would like the following be taken with a reasonable amount of salt. I think that the common theory, vacuum is similar to a sequential scan, just does not hold true for any table that is actually updated randomly. What happens instead is that vacuum not only evicts the whole buffer cache by forcing all blocks of said table and its indexes in, it also dirties a substantial amount of that and leaves the dirt to be cleaned up by all the other backends. The changes I've done above cause vacuum to work with as few shared buffers as possible for the data not already found in the cache. This avoids imposing unnecessary additional write overhead for regular backends, and causes the vacuum process to stay inside of a few virtual memory pages instead of running all over the place. I don't know how much the latter impacts the efficiency of the MMU, it might not be significant here. It is well possible that there is some other side effect in the buffer cache that impacts the behaviour of many backends doing few writes compared to one backend doing them en-gros. However, the test indicates that there is some low hanging fruit in the cache algorithm, and that it's not just a few little raspberries. Jan Tom Lane wrote: Shridhar Daithankar <[EMAIL PROTECTED]> writes: I was thinking about it. How about vacuuming a page when it is been pushed out of postgresql buffer cache? It is is memory so not much IO is involved. You keep ignoring the problem of removing index entries. To vacuum an individual page, you need to be willing to read in (and update) all index pages that reference the tuples-to-be-deleted. This is hardly tenable when the reason for pushing the page out of buffer cache was so that you could read in something else instead --- you don't have spare buffer slots, and you don't want to do all that I/O (and the associated WAL log entries) before you can read in the page you originally wanted. The latter point is really the crux of the problem. The point of having the VACUUM process is to keep maintenance work out of the critical path of foreground queries. Anything that moves even part of that maintenance work into the critical path is going to be a net loss. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] DETOASTing in custom memory context
strk <[EMAIL PROTECTED]> writes: >> From whitin an aggregate sfunc I did: > oldcontext = MemoryContextSwitchTo(fcinfo->flinfo->fn_mcxt); > geom = (GEOMETRY *)PG_DETOAST_DATUM(datum); > MemoryContextSwitchTo(oldcontext); > And later in aggregate's finalfunc: > pfree(geom); > Result: > segfault! > What's wrong with it ? Perhaps you wanted PG_DETOAST_DATUM_COPY(). Or possibly use PG_FREE_IF_COPY() rather than an unconditional pfree, though that would depend on just what your usage pattern is. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] pg_ctl reports succes when start fails
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: We can also try to come up with a better scheme for verifying that we have started properly - I will think about that. There have been previous suggestions for a "pg_ping" functionality, in which you could simply send a packet to the postmaster and it would answer back if it's open for business. You can approximate this by sending a deliberately invalid login packet, but it's not quite the same thing. I think there were some concerns about security though; check the archives. In any case, a C-code pg_ctl could eliminate most of the problems directly, simply because it wouldn't have to rely on psql. Right. The remaining cases would be fairly much those where the configuration is such that a connection is not possible. My feeling is that if people tie themselves down that tightly then they should also specify "no wait" with pg_ctl - it depends on how much we want to keep backwards compatibility with this behaviour. cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] DETOASTing in custom memory context
>From whitin an aggregate sfunc I did: oldcontext = MemoryContextSwitchTo(fcinfo->flinfo->fn_mcxt); geom = (GEOMETRY *)PG_DETOAST_DATUM(datum); MemoryContextSwitchTo(oldcontext); And later in aggregate's finalfunc: pfree(geom); Result: segfault! What's wrong with it ? NOTE that if I MemoryContextAllocate in fcinfo->flinfo->fn_mcxt and memcopy DETOASTED geom, everything works (ar at least it seems to) --strk; strk wrote: > Tom, thanks again for the quick answer and > sorry for the lame question about memor allocation. > > I hope this is acceptable: > Is there a way to make PG_DETOAST_DATUM and friends allocate > memory in a custom memory context ? > > Right now I'm DETOASTing, memcopying in a custom context > and pfreeing the DETOASTed datum, I'd like to avoid one > copy. > > TIA. > --strk; > > ---(end of broadcast)--- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Timestamp docs weirdness
Bruce Momjian <[EMAIL PROTECTED]> writes: > OK, do we want to put back the mention of these in the release notes? > The non-zulu ones sound pretty strange to me and might be better left > undocumented. AFAICS the updated docs are correct. Since the code behavior has not changed, there is no need for a release-notes entry, is there? >> Only the combination of both doesn't work: >> template1=# select 'allballs zulu'::timetz; >> ERROR: Bad time external representation 'allballs zulu' That's because 'allballs' is defined as '00:00:00 UTC', that is, it already defines a timezone. The above is a double specification of timezone and gets the same error as regression=# select '00:00:00 UTC UTC'::timetz; ERROR: invalid input syntax for type time with time zone: "00:00:00 UTC UTC" I see no bug here. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] DETOASTing in custom memory context
Tom, thanks again for the quick answer and sorry for the lame question about memor allocation. I hope this is acceptable: Is there a way to make PG_DETOAST_DATUM and friends allocate memory in a custom memory context ? Right now I'm DETOASTing, memcopying in a custom context and pfreeing the DETOASTed datum, I'd like to avoid one copy. TIA. --strk; ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Dreaming About Redesigning SQL
Anthony W. Youngman wrote: In article <[EMAIL PROTECTED]>, Lauri Pietarinen [EMAIL PROTECTED]> writes Anthony W. Youngman wrote: In article <[EMAIL PROTECTED]>, Lauri Pietarinen <[EMAIL PROTECTED]> writes Anthony W. Youngman wrote: Well, if it is normalised, how easy is it for you to change the customer_id of an order? Anyway, Incredibly easy. Just update the "customer_id" field of the invoice record. A single change to a single "row" And I presume the system will automatically move all related stuff (order details etc.) into the same block as the new customer? How long will that take? What if there is no room for it there? Well, I'd view an order as an entity. As such, I would give it its own FILE, and your question doesn't make sense. But then your formula for disk head movements does not make sense either! But if the system did move the stuff, it would be four disk accesses - read/write to delete the old entry, read/write to save the new. As for "enough room" - well - it'll fall over if we have a "disk full" (or it might not). "Not enough room" here means not enought room in the block of the customer (from which you were supposed to get all data in one read, or disk head movement). That would mean that your order information would be moved perhaps to another block and result in an extra head movement, or am I right? If we're indexed on order detail. If Hammer appears in N invoices, then T = (1+N) * ST * 1.05 for hammers, and the same for all the other products. Theory favours us, in that if a product appears X times in one invoice, that's one read for us and X for you, but hardware will probably help you more than us (that is, assuming thrashing cuts in) in that you stand a marginally higher chance of getting multiple instances of a product in any given read. So for each product you get T = (1+N) * ST * 1.05. Now, for our SQL-DBMS, presuming that we build indexes for detail and product: order_detail(product_id, qty, unit_price) = 20 bytes/row product(product_id, product_name) = 50 bytes/row With 2 disk reads I would get 8K/20 = 400 order detail rows and 8K/50 = 160 product rows Since all rows are in product_id order, no need for random disk reads so T = 1 + N/400 + P/160 (N=number of details, P=number of products) for ALL products and details. And, because of sequential prefetch, we probably would not have to wait for I/O's at all. Really, however you calculate it, it is an order of magnitude less than your alternative. And please don't tell me that using indexes is not fair or not in the spirit of the relational model ;-) Well, it does result in data being stored multiple times ;-) What on earth is wrong with that? Do you know how much 160GB of disk cost's today? I could ask: does your system work in, say 4KB? That's how much memory the first computer I used (a Wang 2000) had. Probably it would not work at all. In the 50's they did amazing things with hardly any compilers and very little memory. I am referring to Whirlwind. See http://www.cedmagic.com/history/whirlwind-computer.html. Could you have done that with MV? My point? Why are we discussing restrictions to memory and CPU speed of the 70's and 80's? If an SQL DBMS uses more memory and disk, and it is available, why complain about *that*. Im not impying that you cannot complain about other matters, e.g. ease of development etc. and you might even be right. Be it as it is, I am not trying to make you abandon your MV database. And while it maybe doesn't affect the result that much, you wanted the value? Where has that come from? From e.g. select p.product_id, product_name, sum(qty*unit_price) from product, order_detail od where p.product_id = od.product_id group by p.product_id, product_name This is the SQL statement that will result in 1 + N/400 + P/160 disk reads (if rows not found in cache) What if the price changed half way through the period you're calculating? Which price? The price that has already been paid by customer? :-) You've failed to answer your own question, so maybe I could match you ... How have I failed? And: what if I was just reading customer-data. Would the same formula apply (= (2+N)*ST*1.05)? Nope. If I understand you correctly, you want attributes that belong to the entity "customer", not the entity "invoice". T = ST * 1.05. (By the way, billing and/or invoice address (for example) are invoice attributes, not company attributes.) No, I want you to give me a list of all your customers. How many disk reads? T = N * 1.05 where N is the number of customers. What do you want to know about those customers? Address? Phone number*s*? Anything else? That's *all* at no extra cost. Well, no thanks. I just wanted their names this time. The relational alternative, with an index on customer_name, would be again an order of magnitune less disk reads.
[HACKERS] An interisting conundrum where tables have a column called "found"
I am putting together a DB that records information about a set of web
sites and how they link to one another. As one site refers to another, I
monitor the first site and then record when I find the referred site.
I have a table called sa_site like this:
ensa1.1: sa_site
Field
Type
Not Null
Default
site_id
bigint
NOT NULL
host_uri
character
varying(1024)
NOT NULL
found
timestamp
with time
zone
NOT NULL
I also have a function called add_site that adds the newly found site.
So far so good.
To test my code I wrote the INSERT statement by hand:
insert into sa_site (site_id, found, host_uri) values
(nextval('sa_site_id_seq'), 'now', 'www.endoid.net');
and everything worked fine when called from psql.
Then I added the code to my add_site function and got the following
error:
ensa1.1=> select add_site('www.endoid.net', 4, null );
WARNING: Error occurred while executing PL/pgSQL function add_site
WARNING: line 26 at SQL statement
ERROR: parser: parse error at or near "$1" at character 43
I looked and looked but couldn't find anything that could explain the
error. Then, being somewhat used to Oracle I tried renaming the "found"
column to "found_on". Oracle occasionally has discrepencies in its rules
for the naming of objects, so I thought that something *similar* might
be happening with PG. Anyways this change did work in my PL/pgSQL
function.
Could you guys figure out where a general description of "please don't
use keywords as column names even if you're allowed to at create time
because something somewhere will throw an unintellligable error" should
live on the site?
Hope this is of help,
/e
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Dreaming About Redesigning SQL
In article <[EMAIL PROTECTED]>, Lauri Pietarinen writes >Anthony W. Youngman wrote: > >>In article <[EMAIL PROTECTED]>, Lauri Pietarinen >><[EMAIL PROTECTED]> writes >> >> >>>Anthony W. Youngman wrote: >>> >>> >>> Fine. But MV *doesn't* *need* much of a cache. Let's assume both SQL and MV have the same amount of RAM to cache in - i.e. *not* *much*. I did say the spec said "extract maximum performance from the hardware available". >>>So what's wrong with gettng a machine with lots of memory? How much >>>does 2G of >>>memory for an Intel-box cost now a days? Is this some kind of new >>>ultimate sport, trying >>>to get along with as little memory as possible? >>> >>> >> >>I presume you didn't read the bit below ... what if you have SEVERAL >>tables, and EACH of them is a gigabyte or two in size? >> >OK, I get your point. Using technology to get you out of a hole is fine. Assuming it will be there if you need it is not. And actually, this is one of the factors hammering the MV model :-( Technology is now powerful enough to solve a lot of problems simply by using brute force. > >>>Well, if it is normalised, how easy is it for you to change the >>>customer_id of an order? Anyway, >>> >>> >> >>Incredibly easy. Just update the "customer_id" field of the invoice >>record. A single change to a single "row" >> >And I presume the system will automatically move all related stuff >(order details etc.) into >the same block as the new customer? How long will that take? What if >there is no room for it there? Well, I'd view an order as an entity. As such, I would give it its own FILE, and your question doesn't make sense. But if the system did move the stuff, it would be four disk accesses - read/write to delete the old entry, read/write to save the new. As for "enough room" - well - it'll fall over if we have a "disk full" (or it might not). > >>>if we stick to your example and even if we don't normalise using e.g. >>>clustering features of Oracle, >>>as Bob pointed out, we are getting at most the same number of I/O's. >>>So, answer to your >>>question: our formula is at least as good as yours. >>> >>> >> >>Except I think Bob said we could "optimise to favour *certain* >>transactions". I think actually ANY transaction benefits. You're relying >>on stuff that's outwith your theory, we're relying on stuff that's >>inherent to our model. >> >That certainly is not true. The theory says NOTHING about how data >should be arranged on disk. >You are talking about how modern SQL-databases behave. The DBMS is at >liberty to do whatever >it pleases with the data, even save it in a PICK database. Hey, wadda >you think? Would that be >a good idea? We get to keep our SQL but with the speed of PICK ;-) That would be nice ;-) But I think our two paragraphs don't connect. I was talking about MV ... > >> >>We let the hardware help us out if it can. There's a big difference. If >>you can't get the hardware, you're stuffed. We don't need it, so while >>we may have a hard time of it it's nowhere near as bad for us. >> >>And again, relational separates the physical from the logical. You're >>being hypocritical if you call upon the physical representation to help >>out with the (speed of the) logical presentation. >> >My goodness, no I'm not! Its the same as claiming that if you have a >drawing for a house, you >have to make that house out of paper?!? > >>>I want a list with all products with corresponding total sales, read >>> >>> >>>from order detail e.g. >> >> >>>Hammer 1$ >>>Nail 5000$ >>>Screw 1200$ >>> >>>How many disk reads (or head movements)? >>> >>> >> >>Actually, probably the same as you here. >> > >>If we're indexed on order >>detail. If Hammer appears in N invoices, then T = (1+N) * ST * 1.05 for >>hammers, and the same for all the other products. >> >>Theory favours us, in that if a product appears X times in one invoice, >>that's one read for us and X for you, but hardware will probably help >>you more than us (that is, assuming thrashing cuts in) in that you stand >>a marginally higher chance of getting multiple instances of a product in >>any given read. >> >So for each product you get T = (1+N) * ST * 1.05. > >Now, for our SQL-DBMS, presuming that we build indexes for detail and >product: > >order_detail(product_id, qty, unit_price) = 20 bytes/row >product(product_id, product_name) = 50 bytes/row > >With 2 disk reads I would get >8K/20 = 400 order detail rows and >8K/50 = 160 product rows > >Since all rows are in product_id order, no need for random disk reads so >T = 1 + N/400 + P/160 (N=number of details, P=number of products) >for ALL products and details. > >And, because of sequential prefetch, we probably would not have to wait >for I/O's at all. > >Really, however you calculate it, it is an order of magnitude less >than your alternative. > >And please don't tell me that using indexes is not fair or not i
Re: [HACKERS] Dreaming About Redesigning SQL
In article <[EMAIL PROTECTED]>, Marshall Spight <[EMAIL PROTECTED]> writes >"Bob Badour" <[EMAIL PROTECTED]> wrote in message news:W46dnf4tbfF1DwiiU- >[EMAIL PROTECTED] >> >> All physical structures will bias performance for some operations and >> against others. > >This strikes me as a succinct statement of the value of >data independence. One has the option (but not the >requirement) to adjust the physical structures the DBMS >uses while keeping the logical model (and therefor all >application code and queries, etc.) unchanged. > >Unless one has data independence, one does not have >this option; one will be locked into a particular >performance model. This is why I found the MV >guy's obvious pleasure at being able to precisely >describe the performance model for his DB as odd: >I thought it a deficit to be able to say what it was; >he thought it an asset. > When you park your car, do you put the chassis on the drive, the engine in the garage, and the wheels in the front garden? You may find my approach of keeping data together strange, I just find it extremely weird that you think it is an IMPROVEMENT to disassemble what is in the real world a single thing. I'm sure you would not be happy if I tried to disassemble YOU and store your head in one place, your legs and arms in another, etc etc. Can I refer you to something called "emergent complexity"? A scientific theory of how the whole can be greater than the sum of its parts? Harking to something else, I can't remember who said "the tuple is the fundamental unit of data". Apart from the fact that such a statement is not worth arguing with, I would compare that to the quark in physics. A strange beast that is known to exist, but can never be found in reality. And as a chemist, it is totally and utterly irrelevant to me. It pays to know it's there just in case in some strange circumstance it should be useful, but for the most part I can ignore it as just not part of my reality. Oh - and do you know why I was so pleased to describe the performance model for my db? For the same reason as I mentioned Huffman compression. It's impossible to prove that that Huffman is the most efficient algorithm, and indeed I pointed out that it isn't. It is, however, possible to prove that it is mathematically impossible for a more efficient algorithm to exist. I'm TOTALLY happy to be locked into a performance model, if I can PROVE that there are no other models that are more efficient. My ability with stats isn't good enough, but the figure bandied about is that there is room for about 5% improvement before we hit that mathematical limit. SQL has a HELL of a long way to go to catch up :-) Cheers, Wol -- Anthony W. Youngman - wol at thewolery dot demon dot co dot uk Witches are curious by definition and inquisitive by nature. She moved in. "Let me through. I'm a nosey person.", she said, employing both elbows. Maskerade : (c) 1995 Terry Pratchett ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_ctl reports succes when start fails
Andrew Dunstan <[EMAIL PROTECTED]> writes: > We can also try to come up with a better scheme for verifying that we > have started properly - I will think about that. There have been previous suggestions for a "pg_ping" functionality, in which you could simply send a packet to the postmaster and it would answer back if it's open for business. You can approximate this by sending a deliberately invalid login packet, but it's not quite the same thing. I think there were some concerns about security though; check the archives. In any case, a C-code pg_ctl could eliminate most of the problems directly, simply because it wouldn't have to rely on psql. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Help!!! FreeSpaceMap hashtalble out of memory.
"Yurgis Baykshtis" <[EMAIL PROTECTED]> writes: > In pgerr.log this always go together: > WARNING: ShmemAlloc: out of memory > ERROR: FreeSpaceMap hashtable out of memory If you have a large number of tables in your database, it might be that you need to increase max_locks_per_transaction. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Dreaming About Redesigning SQL
In article <[EMAIL PROTECTED]>, Anthony W. Youngman <[EMAIL PROTECTED]> writes >>Really, however you calculate it, it is an order of magnitude less >>than your alternative. >> >>And please don't tell me that using indexes is not fair or not in the >>spirit of the >>relational model ;-) > >Well, it does result in data being stored multiple times ;-) > >And while it maybe doesn't affect the result that much, you wanted the >value? Where has that come from? What if the price changed half way >through the period you're calculating? :-) You've failed to answer your >own question, so maybe I could match you ... Whoops - sorry - I did notice after I wrote this that you included price in your index. But it does seem strange indexing on a composite field like that ... Cheers, Wol -- Anthony W. Youngman - wol at thewolery dot demon dot co dot uk Witches are curious by definition and inquisitive by nature. She moved in. "Let me through. I'm a nosey person.", she said, employing both elbows. Maskerade : (c) 1995 Terry Pratchett ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Dreaming About Redesigning SQL
"Lauri Pietarinen" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Anthony W. Youngman wrote: > > >In article <[EMAIL PROTECTED]>, Anthony W. Youngman > ><[EMAIL PROTECTED]> writes > > But it does seem strange indexing on a composite field > >like that ... > > > But why does it seem strange? He only knows one product and only a handful of recipes for using that product. Everything else seems strange because it lies outside the tightly confined cognitive box from which he views the world. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Dreaming About Redesigning SQL
"Christopher Browne" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Anthony W. Youngman" <[EMAIL PROTECTED]> wrote: > > In article <[EMAIL PROTECTED]>, Marshall Spight > > <[EMAIL PROTECTED]> writes > >>Unless one has data independence, one does not have > >>this option; one will be locked into a particular > >>performance model. This is why I found the MV > >>guy's obvious pleasure at being able to precisely > >>describe the performance model for his DB as odd: > >>I thought it a deficit to be able to say what it was; > >>he thought it an asset. > >> > > When you park your car, do you put the chassis on the drive, the > > engine in the garage, and the wheels in the front garden? > > When I park my car, I don't particularly _care_ whether it runs on > propane, diesel, gasoline, ethanol, or batteries. Christopher, You have to remember who you are talking to; Wol is ignorant and stupid. A car is a physical artifact just as the physical representation of a datum is a physical artifact. Physical independence is the equivalent to having a door from the hallway to the garage, a door from the kitchen to the garage, a door from the back yard to the garage, and car access to the driveway--and an identical car parked in the back alley just for convenience. Wol's analogies are dumb because they reflect his intelligence. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Dreaming About Redesigning SQL
Anthony W. Youngman wrote: In article <[EMAIL PROTECTED]>, Anthony W. Youngman <[EMAIL PROTECTED]> writes Really, however you calculate it, it is an order of magnitude less than your alternative. And please don't tell me that using indexes is not fair or not in the spirit of the relational model ;-) Well, it does result in data being stored multiple times ;-) And while it maybe doesn't affect the result that much, you wanted the value? Where has that come from? What if the price changed half way through the period you're calculating? :-) You've failed to answer your own question, so maybe I could match you ... Whoops - sorry - I did notice after I wrote this that you included price in your index. OK! But it does seem strange indexing on a composite field like that ... But why does it seem strange? regards, Lauri ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Dreaming About Redesigning SQL
"Lauri Pietarinen" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Anthony W. Youngman wrote: > > >In article <[EMAIL PROTECTED]>, Lauri Pietarinen >[EMAIL PROTECTED]> writes > > > >>Anthony W. Youngman wrote: > >>>In article <[EMAIL PROTECTED]>, Lauri Pietarinen > >>><[EMAIL PROTECTED]> writes > >>> > Anthony W. Youngman wrote: > >>> > >>>If we're indexed on order > >>>detail. If Hammer appears in N invoices, then T = (1+N) * ST * 1.05 for > >>>hammers, and the same for all the other products. > >>> > >>>Theory favours us, in that if a product appears X times in one invoice, > >>>that's one read for us and X for you, but hardware will probably help > >>>you more than us (that is, assuming thrashing cuts in) in that you stand > >>>a marginally higher chance of getting multiple instances of a product in > >>>any given read. > >>> > >>> > >>> > >>So for each product you get T = (1+N) * ST * 1.05. > >> > >>Now, for our SQL-DBMS, presuming that we build indexes for detail and > >>product: > >> > >>order_detail(product_id, qty, unit_price) = 20 bytes/row > >>product(product_id, product_name) = 50 bytes/row > >> > >>With 2 disk reads I would get > >>8K/20 = 400 order detail rows and > >>8K/50 = 160 product rows > >> > >>Since all rows are in product_id order, no need for random disk reads so > >>T = 1 + N/400 + P/160 (N=number of details, P=number of products) > >>for ALL products and details. > >> > >>And, because of sequential prefetch, we probably would not have to wait > >>for I/O's at all. > >> > >>Really, however you calculate it, it is an order of magnitude less > >>than your alternative. > >> > >>And please don't tell me that using indexes is not fair or not in the > >>spirit of the > >>relational model ;-) > >> > >> > > > >Well, it does result in data being stored multiple times ;-) > > > What on earth is wrong with that? Do you know how much 160GB of disk > cost's today? Lauri, Remember who you are talking to. Wol is ignorant and stupid. Somehow he thinks managed redundancy at the physical level is non-relational because normalization seeks to reduce redundancy at the logical level. You have to keep in mind that the man is totally incompetent to comprehend simple english let alone basic principles of data management. Regards, Bob ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Dreaming About Redesigning SQL
"Anthony W. Youngman" <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]>, Marshall Spight > <[EMAIL PROTECTED]> writes >>Unless one has data independence, one does not have >>this option; one will be locked into a particular >>performance model. This is why I found the MV >>guy's obvious pleasure at being able to precisely >>describe the performance model for his DB as odd: >>I thought it a deficit to be able to say what it was; >>he thought it an asset. >> > When you park your car, do you put the chassis on the drive, the > engine in the garage, and the wheels in the front garden? When I park my car, I don't particularly _care_ whether it runs on propane, diesel, gasoline, ethanol, or batteries. (Well, at home, they don't allow propane cars in the parking garage, but that's a case where details HAVE to emerge.) I don't need to care whether the car uses a 4 cylinder engine, 6, 8, 12, or perhaps evades having cylinders at all. I frankly have NO IDEA how many RPMs the engine gets to, nor do I know how many times the wheels turn in the average minute. These are all details I don't NEED to know in order to park the car, and are pretty much irrelevant to the average need to drive an automobile. I consider it a Good Thing that my database has a query optimizer that makes it unnecessary for me to worry about the details of how indexes will be used. Occasionally some anomaly comes up that requires that I dig into details, but most of the time, the abstractions allow me to ignore these details, and allows me to spend my time worrying about optimizing the things that actually need it, as opposed to chasing after irrelevant improvements. -- select 'cbbrowne' || '@' || 'cbbrowne.com'; http://cbbrowne.com/info/linux.html ASSEMBLER is a language. Any language that can take a half-dozen keystrokes and compile it down to one byte of code is all right in my books. Though for the REAL programmer, assembler is a waste of time. Why use a compiler when you can code directly into memory through a front panel. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
pgman wrote: > Jan Wieck wrote: > > >> >> > What Peter was advocating in that thread was that we enable -g by > > >> >> > default *when building with gcc*. I have no problem with that, since > > >> >> > there is (allegedly) no performance penalty for -g with gcc. However, > > >> >> > the actual present behavior of our configure script is to default to -g > > >> >> > for every compiler, and I think that that is a big mistake. On most > > >> >> > non-gcc compilers, -g disables optimizations, which is way too high a > > >> >> > price to pay for production use. > > >> >> > > >> >> You do realize that as of now, -g is the default for gcc? Was that the > > >> >> intent? > > >> > > > >> > I was going to ask that myself. It seems strange to include -g by default --- > > >> > we have --enable-debug, and that should control -g on all platforms. > > >> > > >> Could it be that there ought to be a difference between the defaults of > > >> a devel CVS tree, a BETA tarball and a final "production" release? > > > > > > I am afraid that adds too much confusion to the debug situation. We > > > have a flag to do -g; let people use it if they want it. > > > > > > > Well, -g eats up some disk space, but for a gcc it doesn't need CPU > > cycles or anything else. I doubt many people who pay the horrible > > storage capacity overhead for PostgreSQL are that concerned about some > > extra symbols stored with their binaries, but let's not argue about that > > one. > > Well, people are stripping the executable, so some of them must care. > In fact, if we enable -g by default for gcc, how do compile with default > symbols? We would need another configure option. Strip is not the same > as default symbols. Let me also add that on my old dual P3 550 256MB RAM -g significantly slowed down the build because linking took a long time, probably because it had to read in all those debug symbols for the link --- I remember the backend link taking quite a lot of time. In fact, even though I was debugging the backend regularly, I removed -g and added it only when I wanted to debug. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: Defaults for GUC variables (was Re: [HACKERS] pg_ctl reports
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > > Shouldn't it revert to the default value? > > No, not unless you think the postmaster should react to comments in the > postgresql.conf file, which is rather against my idea of a comment. > > However, you're not the first to get burnt by this mis-assumption, > so maybe we should do something about it. > > The low-tech solution to this would be to stop listing the default > values as commented-out entries, but just make them ordinary uncommented > entries. That way people who think "undoing my edit will revert the > change" would be right. > > Or we could try to make it actually work the way you seem to be > expecting. The only implementation I can think of is to reset GUC > variables to defaults just before scanning the .conf file ... -- I have to say we never had any problems or misconception with how it currently works, but if this has to be changed I'd rather vote for the low-tech solution. Mike. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Call for port reports (Win32 Client)
Windows client port list updated: http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html --- Dave Page wrote: > Yup, that works fine (just a few warnings about ERROR being redefined). > > Thanks, Dave. > > > -Original Message- > > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > > Sent: 27 October 2003 02:50 > > To: Dave Page > > Cc: PostgreSQL-development > > Subject: Re: [HACKERS] Call for port reports (Win32 Client) > > > > > > This is all fixed in CVS --- would you try that? > > > > -- > > - > > > > Dave Page wrote: > > > > > > > > > > -Original Message- > > > > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > > > > Sent: 26 October 2003 01:35 > > > > To: Dave Page > > > > Cc: PostgreSQL-development > > > > Subject: Re: [HACKERS] Call for port reports > > > > > > > > > NMAKE : fatal error U1077: > > > > 'C:\PROGRA~1\MICROS~3\VC98\BIN\NMAKE.EXE' : > > > > > return co > > > > > de '0x2' > > > > > Stop. > > > > > > > > I am confused why strings.h is being included because there is a > > > > test around it: > > > > > > > > #ifdef HAVE_STRINGS_H > > > > #include > > > > #endif > > > > > > > > Any ideas? > > > > > > Yesh I forgot to remove the cygwin pg_config.h before > > compiling. Sorry > > > :-) > > > > > > Anyway, I now get the error below which is not surprising > > as Windows > > > doesn't have pthreads, or pwd.h as standard. > > > > > > Regards, Dave. > > > > > > C:\cygwin\usr\local\src\postgresql-7.4beta5\src>nmake /f win32.mak > > > > > > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > > > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > > > > > cd include > > > if not exist pg_config.h copy pg_config.h.win32 pg_config.h > > > cd .. > > > cd interfaces\libpq > > > nmake /f win32.mak > > > > > > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > > > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > > > > > Building the Win32 static library... > > > > > > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nma03408. > > > getaddrinfo.c > > > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmb03408. > > > inet_aton.c > > > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmc03408. > > > crypt.c > > > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmd03408. > > > path.c > > > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nme03408. > > > dllist.c > > > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmf03408. > > > md5.c > > > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmg03408. > > > ip.c > > > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmh03408. > > > thread.c > > > ..\..\include\utils/elog.h(37) : warning C4005: 'ERROR' : macro > > > redefinition > > > C:\PROGRA~1\MICROS~3\VC98\INCLUDE\wingdi.h(93) : > > see previous > > > definition of 'ERROR' > > > ..\..\port\thread.c(17) : fatal error C1083: Cannot open > > include file: > > > 'pthread. > > > h': No such file or directory > > > NMAKE : fatal error U1077: 'cl.exe' : return code '0x2' > > > Stop. > > > NMAKE : fatal error U1077: > > 'C:\PROGRA~1\MICROS~3\VC98\BIN\NMAKE.EXE' : > > > return co > > > de '0x2' > > > Stop. > > > > > > C:\cygwin\usr\local\src\postgresql-7.4beta5\src> > > > > > > ---(end of > > > broadcast)--- > > > TIP 4: Don't 'kill -9' the postmaster > > > > > > > -- > > Bruce Momjian| http://candle.pha.pa.us > > [EMAIL PROTECTED] | (610) 359-1001 > > + If your life is a hard drive, | 13 Roberts Road > > + Christ can be your backup.| Newtown Square, > > Pennsylvania 19073 > > > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Duplicating transaction information in indexes and performing in memory vacuum
Shridhar Daithankar <[EMAIL PROTECTED]> writes: > What are (more) reasons for not adding transaction information to > index tuple, in addition to heap tuple? > Cons are bloated indexes. The index tuple size will be close to 30 > bytes minimum. And extra time to perform an update or delete, and extra time for readers of the index to process and perhaps update the extra copies of the row's state. And atomicity concerns, since you can't possibly update the row and all its index entries simultaneously. I'm not certain that the latter issue is insoluble, but it surely is a big risk. > On pro* side of this, no more vacuum required (at least for part of > data that is being used. If data isn't used, it does not need vacuum > anyway) and space bloat is stopped right in memory, without incurring > overhead of additional IO vacuum demands. I do not believe either of those claims. For starters, if you don't remove a row's index entries when the row itself is removed, won't that make index bloat a lot worse? When exactly *will* you remove the index entries ... and won't that process look a lot like VACUUM? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Jan Wieck wrote: > >> >> > What Peter was advocating in that thread was that we enable -g by > >> >> > default *when building with gcc*. I have no problem with that, since > >> >> > there is (allegedly) no performance penalty for -g with gcc. However, > >> >> > the actual present behavior of our configure script is to default to -g > >> >> > for every compiler, and I think that that is a big mistake. On most > >> >> > non-gcc compilers, -g disables optimizations, which is way too high a > >> >> > price to pay for production use. > >> >> > >> >> You do realize that as of now, -g is the default for gcc? Was that the > >> >> intent? > >> > > >> > I was going to ask that myself. It seems strange to include -g by default --- > >> > we have --enable-debug, and that should control -g on all platforms. > >> > >> Could it be that there ought to be a difference between the defaults of > >> a devel CVS tree, a BETA tarball and a final "production" release? > > > > I am afraid that adds too much confusion to the debug situation. We > > have a flag to do -g; let people use it if they want it. > > > > Well, -g eats up some disk space, but for a gcc it doesn't need CPU > cycles or anything else. I doubt many people who pay the horrible > storage capacity overhead for PostgreSQL are that concerned about some > extra symbols stored with their binaries, but let's not argue about that > one. Well, people are stripping the executable, so some of them must care. In fact, if we enable -g by default for gcc, how do compile with default symbols? We would need another configure option. Strip is not the same as default symbols. > The other compiler flags like -O are much more important because the out > of the box configuration is the one we're allways blamed for. If it's > too hard to teach autoconf the difference between gcc and non-gcc, then > rip it. Sure, we can do it, but it is a question of consistency. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Defaults for GUC variables (was Re: [HACKERS] pg_ctl reports succes when start fails)
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: >>> The latter...why won't it affect the postmaster state? >> >> Because it's a *comment*. > Shouldn't it revert to the default value? No, not unless you think the postmaster should react to comments in the postgresql.conf file, which is rather against my idea of a comment. However, you're not the first to get burnt by this mis-assumption, so maybe we should do something about it. The low-tech solution to this would be to stop listing the default values as commented-out entries, but just make them ordinary uncommented entries. That way people who think "undoing my edit will revert the change" would be right. Or we could try to make it actually work the way you seem to be expecting. The only implementation I can think of is to reset GUC variables to defaults just before scanning the .conf file (but only if their prior value came from the .conf file, which fortunately is something we keep track of). The trouble with this is that any error in scanning the .conf file could leave you with unexpectedly reverted values for later entries, because they'd not be reached. Or we could just document the behavior better... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Aggregate detoasted arguments lifetime
strk <[EMAIL PROTECTED]> writes: > My question is: if I write in the "state" array > pointers to DETOASTED input args, > will I find them intact at finalfunc time ? No, not without pushups. You are called in a short-lived memory context. You could allocate query-lifetime memory in fcinfo->fn_mcxt, but it's then your responsibility to ensure there are no undesirable memory leaks. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Bruce Momjian wrote: Jan Wieck wrote: Bruce Momjian wrote: > Peter Eisentraut wrote: >> Tom Lane writes: >> >> > What Peter was advocating in that thread was that we enable -g by >> > default *when building with gcc*. I have no problem with that, since >> > there is (allegedly) no performance penalty for -g with gcc. However, >> > the actual present behavior of our configure script is to default to -g >> > for every compiler, and I think that that is a big mistake. On most >> > non-gcc compilers, -g disables optimizations, which is way too high a >> > price to pay for production use. >> >> You do realize that as of now, -g is the default for gcc? Was that the >> intent? > > I was going to ask that myself. It seems strange to include -g by default --- > we have --enable-debug, and that should control -g on all platforms. Could it be that there ought to be a difference between the defaults of a devel CVS tree, a BETA tarball and a final "production" release? I am afraid that adds too much confusion to the debug situation. We have a flag to do -g; let people use it if they want it. Well, -g eats up some disk space, but for a gcc it doesn't need CPU cycles or anything else. I doubt many people who pay the horrible storage capacity overhead for PostgreSQL are that concerned about some extra symbols stored with their binaries, but let's not argue about that one. The other compiler flags like -O are much more important because the out of the box configuration is the one we're allways blamed for. If it's too hard to teach autoconf the difference between gcc and non-gcc, then rip it. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Aggregate detoasted arguments lifetime
Dear pg-hackers, Making an aggregate I want to stuff all input values (detoasted) in an array and process them all togheter with finalfunc. This is because in order to process them a conversion is involved and I'm trying to reduce the number of conversions to the lowest possible. My question is: if I write in the "state" array pointers to DETOASTED input args, will I find them intact at finalfunc time ? TIA --strk; ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Duplicating transaction information in indexes and performing in memory vacuum
Hi, Last week, there was a thread whether solely in memory vacuum can be performed or not.(OK, that was a part of thread but anyways) I suggested that a page be vacuumed when it is pushed out of buffer cache. Tom pointed out that it can not be done as index tuples stote heap tuple id and depend upon heap tuple to find out transaction information. I asked is it feasible to add transaction information to index tuple and the answer was no. I searched hackers archive and following is only thread I could come up in this context. http://archives.postgresql.org/pgsql-hackers/2000-09/msg00513.php http://archives.postgresql.org/pgsql-hackers/2001-09/msg00409.php The thread does not consider vacuum at all. What are (more) reasons for not adding transaction information to index tuple, in addition to heap tuple? Cons are bloated indexes. The index tuple size will be close to 30 bytes minimum. On pro* side of this, no more vacuum required (at least for part of data that is being used. If data isn't used, it does not need vacuum anyway) and space bloat is stopped right in memory, without incurring overhead of additional IO vacuum demands. Given recent trend of pushing PG higher and higher in scale (From performance list traffic, that is), I think this could be worthwhile addition. So what are the cons I missed so far? Bye Shridhar ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Question about read interval type in binary format
Hello: In src/backend/utils/adt/timestamp.c, interval_send looks like what you are looking for. Thanks :) -- Best regards Carlos Guzmán Álvarez Vigo-Spain ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Proposed structure for coexisting major versions
On Sun, 2003-10-26 at 17:24, Oliver Elphick wrote: > If it were possible to have two separate versions of the PostgreSQL > packages installed simultaneously, it would be simple to do database > upgrades by dumping from the old version and uploading to the new. You'd need some mechanism to prevent concurrent modifications of the source DB during the upgrade process, wouldn't you? -Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Call for port reports
On Sat, 2003-10-25 at 21:29, Bruce Momjian wrote: > configure --enable-debug will use -g for the compile, and with > optimization. I'm just curious: would there be any benefit to using -g3 when --enable-debug is specified and -g3 is supported by gcc? From the gcc man page: -glevel [...] Request debugging information and also use level to specify how much information. The default level is 2. Level 1 produces minimal information, enough for making backtraces in parts of the program that you don't plan to debug. This includes descriptions of functions and external variables, but no information about local variables and no line numbers. Level 3 includes extra information, such as all the macro defini- tions present in the program. Some debuggers support macro expan- sion when you use -g3. Note that in order to avoid confusion between DWARF1 debug level 2, and DWARF2, neither -gdwarf nor -gdwarf-2 accept a concatenated debug level. Instead use an additional -glevel option to change the debug level for DWARF1 or DWARF2. -Neil ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] BEGIN vs START TRANSACTION
Christopher Kings-Lynne wrote: >> I think because START TRANSACTION is SQL standard? However, I thought >> BEGIN WORK was SQL standard, and we don't support READ ONLY there >> either --- hmmm. > > > BEGIN is no part of the SQL standard. The only way to begin a > transaction under the SQL standard is START TRANSACTION. These IMHO means push people to not use BEGIN anymore. Regards Gaetano Mendola ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] BEGIN vs START TRANSACTION
On Sun, 2003-10-26 at 19:22, Gaetano Mendola wrote: > Hi all, > why START TRANSACTION READ ONLY is allowed > and not BEGIN READ ONLY ? As Chris KL points out, it's not required by the standard (since BEGIN isn't part of the standard to begin with). I suppose we could add it, but it seems a little pointless -- "BEGIN ; SET ..." seems just as good. -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for port reports (Win32 Client)
Yup, that works fine (just a few warnings about ERROR being redefined). Thanks, Dave. > -Original Message- > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > Sent: 27 October 2003 02:50 > To: Dave Page > Cc: PostgreSQL-development > Subject: Re: [HACKERS] Call for port reports (Win32 Client) > > > This is all fixed in CVS --- would you try that? > > -- > - > > Dave Page wrote: > > > > > > > -Original Message- > > > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > > > Sent: 26 October 2003 01:35 > > > To: Dave Page > > > Cc: PostgreSQL-development > > > Subject: Re: [HACKERS] Call for port reports > > > > > > > NMAKE : fatal error U1077: > > > 'C:\PROGRA~1\MICROS~3\VC98\BIN\NMAKE.EXE' : > > > > return co > > > > de '0x2' > > > > Stop. > > > > > > I am confused why strings.h is being included because there is a > > > test around it: > > > > > > #ifdef HAVE_STRINGS_H > > > #include > > > #endif > > > > > > Any ideas? > > > > Yesh I forgot to remove the cygwin pg_config.h before > compiling. Sorry > > :-) > > > > Anyway, I now get the error below which is not surprising > as Windows > > doesn't have pthreads, or pwd.h as standard. > > > > Regards, Dave. > > > > C:\cygwin\usr\local\src\postgresql-7.4beta5\src>nmake /f win32.mak > > > > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > > > cd include > > if not exist pg_config.h copy pg_config.h.win32 pg_config.h > > cd .. > > cd interfaces\libpq > > nmake /f win32.mak > > > > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > > > Building the Win32 static library... > > > > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nma03408. > > getaddrinfo.c > > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmb03408. > > inet_aton.c > > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmc03408. > > crypt.c > > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmd03408. > > path.c > > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nme03408. > > dllist.c > > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmf03408. > > md5.c > > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmg03408. > > ip.c > > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmh03408. > > thread.c > > ..\..\include\utils/elog.h(37) : warning C4005: 'ERROR' : macro > > redefinition > > C:\PROGRA~1\MICROS~3\VC98\INCLUDE\wingdi.h(93) : > see previous > > definition of 'ERROR' > > ..\..\port\thread.c(17) : fatal error C1083: Cannot open > include file: > > 'pthread. > > h': No such file or directory > > NMAKE : fatal error U1077: 'cl.exe' : return code '0x2' > > Stop. > > NMAKE : fatal error U1077: > 'C:\PROGRA~1\MICROS~3\VC98\BIN\NMAKE.EXE' : > > return co > > de '0x2' > > Stop. > > > > C:\cygwin\usr\local\src\postgresql-7.4beta5\src> > > > > ---(end of > > broadcast)--- > > TIP 4: Don't 'kill -9' the postmaster > > > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, > Pennsylvania 19073 > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Bruce Momjian wrote: > Well, we don't want to use debug for non-gcc (no optimization) so do we > do -g for gcc, and then --enable-debug does nothing. Seems people can > decide for themselves. But doesn't --enable-debug turn off optimization? It's really a question of what the default behavior should be for each option. Clearly for non-gcc compilers, the default should be -O only since they probably can't simultaneously handle -g. But gcc builds are an exception, one which I think is worth considering. Hence my opinion that for gcc builds, the default should be -g and -O. -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
