Re: [HACKERS] Initdb on Windows 2003

Thanks for the info, I shall indeed try this. One thing to mention is that I don't think the error occurs within initdb, it seams to be postgres.exe that dbinit starts. Regards James -Original Message- From: Andrew Dunstan [mailto:[EMAIL PROTECTED] Sent: 01 March 2006 16:26 To: Hugh

Re: [HACKERS] [SQL] Interval subtracting

Hannu Krosing schrieb: > Ühel kenal päeval, K, 2006-03-01 kell 14:36, kirjutas Scott Marlowe: > ... > But we do say both "quarter past three" (3 hours 15 min) and "quarter to > four" (4 hours -15 min) when talking about time. > but luckily we dont write it ;) Some people say (like ) this: quarter

Re: [HACKERS] Automatic free space map filling

On Thu, Mar 02, 2006 at 01:01:21AM -0500, Tom Lane wrote: > > Essentially, we would be folding the "find > > dead tuples and compress page" logic, which is currently in vacuum, back > > to insert. IMHO this is unacceptable from a performance PoV. > > That's the other problem: it's not apparent wh

Re: [HACKERS] [SQL] Interval subtracting

Ühel kenal päeval, K, 2006-03-01 kell 14:36, kirjutas Scott Marlowe: > > But it isn't '-2 months, -1 day'. I think what you are saying is what I > > am saying, that we should make the signs consistent. > > Pretty much. It just seems wrong to have different signs in what is > essentially a singl

Re: [HACKERS] Automatic free space map filling

Alvaro Herrera <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> That has nothing to do with it, because the space isn't actually free >> for re-use until vacuum deletes the tuple. > I think the idea is a different "free space map" of sorts, whereby a > transaction that obsoletes a tuple puts its b

Re: [HACKERS] Uninstall script errors

Michael Fuhr <[EMAIL PROTECTED]> writes: > ... I started to work on a patch but I wasn't sure how > to handle the chicken-and-egg situation of dropping a type and its > I/O functions. Is there any way to do that other than DROP TYPE > CASCADE? Should the uninstall scripts be doing that? DROP TY

Re: [HACKERS] display processing time?

On Wed, Mar 01, 2006 at 10:13:02PM -0600, John wrote: > adding -s will print the statistis and time. But I have no idea how to call > this using postmaster -o option. Anyone give me a hint? Thanks. postmaster -o -s [ other options ] Or you could enable log_statement_stats in postgresql.conf. --

[HACKERS] display processing time?

I have a question about how to display query time of postgres. I found this postgres [ -A { 0 | 1 } ] [ -B buffers ] [ -c name=value ] [ -d debug-level ] [ -D datadir ] [ -e ] [ -E ] [ -f { s | i | n | m | h } ] [ -F ] [ -i ] [ -L ] [ -N ] [ -o file-name ] [ -O ] [ -P ]

Re: [HACKERS] ipcclean in 8.1 broken?

Christopher Kings-Lynne wrote: I wonder if there could be a potential problem with using this approach - checking on $USER == root. Although it is a common practice, I think a superuser does not have to be root. Yes, like the 'toor' account in FreeBSD... (disabled by default though) Might

Re: [HACKERS] ipcclean in 8.1 broken?

I wonder if there could be a potential problem with using this approach - checking on $USER == root. Although it is a common practice, I think a superuser does not have to be root. Yes, like the 'toor' account in FreeBSD... (disabled by default though) Chris ---(end o

Re: [HACKERS] ipcclean in 8.1 broken?

if [ "$USER" = 'root' -o "$LOGNAME" = 'root' ] Always fails because even tho $USER is set to 'pgsql' when su'ed, $LOGNAME is still root. This is on FreeBSD 4.9 It seems to work on Linux; apparently there are different behaviors of su. Do you have a suggestion for resolving this? Well all I

Re: [HACKERS] [SQL] Interval subtracting

Tom Lane wrote: Mark Dilger <[EMAIL PROTECTED]> writes: Tom Lane wrote: If so, one function or the other is cheating. That depends what you mean by cheating. The justify_hours function looks to see what answer justify_days would give, but does not actually change the data. I described t

Re: [HACKERS] [SQL] Interval subtracting

Mark Dilger <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> If so, one function or the other is cheating. > That depends what you mean by cheating. The justify_hours function > looks to see what answer justify_days would give, but does not > actually change the data. I described this all earlie

Re: [HACKERS] [SQL] Interval subtracting

Tom Lane wrote: Mark Dilger <[EMAIL PROTECTED]> writes: justify_days(justify_hours(...)) fixes *everything* in the most recently submitted patch, regardless of the convoluted case you invent. There is no data for which it won't work. If so, one function or the other is cheating. Per discu

Re: [HACKERS] [SQL] Interval subtracting

Mark Dilger <[EMAIL PROTECTED]> writes: > justify_days(justify_hours(...)) fixes *everything* in the most recently > submitted patch, regardless of the convoluted case you invent. There is no > data > for which it won't work. If so, one function or the other is cheating. Per discussion, justi

Re: [HACKERS] [SQL] Interval subtracting

Bruce Momjian wrote: Even if we had people do: justify_hours(justify_days(justify_hours())) I don't think that would do what we want in all cases. Consider '1 mon -1 hour'. That should be '29 days 23 hours' but neither existing function, even if modified, will allow us to return that.

Re: [HACKERS] [SQL] Interval subtracting

Tom Lane wrote: Mark Dilger <[EMAIL PROTECTED]> writes: This overall design seems more flexible than Tom's recent post in which he stated that justify_days should call justify_hours internally. AFAIR I said the exact opposite. regards, tom lane Tom Lane also wrote:

Re: [HACKERS] [SQL] Interval subtracting

Mark Dilger wrote: > Tom Lane wrote: > > Well, the question is whether justify_days has a sane definition that is > > different from this. Based on your example, I'm not seeing one. > > Backwards compatibility is probably more important than sanity. Let's just > deprecate the existing functions

Re: [HACKERS] [SQL] Interval subtracting

Mark Dilger <[EMAIL PROTECTED]> writes: > This overall design seems more flexible than Tom's recent post in which he > stated that justify_days should call justify_hours internally. AFAIR I said the exact opposite. regards, tom lane ---(end of bro

Re: [HACKERS] [SQL] Interval subtracting

Mark Dilger <[EMAIL PROTECTED]> writes: > Bruce Momjian wrote: >> If we do that, we should just call it justify_interval(). I am thinking >> this is the direction to go, and for people who want more control they >> use the justify_hours and justify_days, and those are left unchanged. > I agree.

Re: [HACKERS] [SQL] Interval subtracting

Bruce Momjian writes: >> Well, the question is whether justify_days has a sane definition that is >> different from this. Based on your example, I'm not seeing one. > Uh, justify days only deals with days <--> months conversions. There is > no processing for hours. I don't understand your comm

Re: [HACKERS] [SQL] Interval subtracting

Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> Based on that, I guess I have to change my vote: justify_hours should > >> still not look at the month (because it shouldn't use the month=30days > >> assumption), but justify_days should be changed to be effectively a > >> combinati

Re: [HACKERS] [SQL] Interval subtracting

Tom Lane wrote: Well, the question is whether justify_days has a sane definition that is different from this. Based on your example, I'm not seeing one. Backwards compatibility is probably more important than sanity. Let's just deprecate the existing functions and recommend that people use

Re: [HACKERS] [SQL] Interval subtracting

Bruce Momjian writes: > Tom Lane wrote: >> Based on that, I guess I have to change my vote: justify_hours should >> still not look at the month (because it shouldn't use the month=30days >> assumption), but justify_days should be changed to be effectively a >> combination of both functions --- tha

Re: [HACKERS] [SQL] Interval subtracting

Bruce Momjian wrote: If we do that, we should just call it justify_interval(). I am thinking this is the direction to go, and for people who want more control they use the justify_hours and justify_days, and those are left unchanged. I agree. Let's leave the existing functions alone. I can r

Re: [HACKERS] [SQL] Interval subtracting

Tom Lane wrote: > Bruce Momjian writes: > > Imagine this: > > > '1 mons -2 days -12:00:00' > > > Which sign do we head to for this? For justify_hours, if we don't look > > at the months it remains unchange, but calling justify_days we get: > > > '28 days -12:00:00' > > > which is wron

Re: [HACKERS] [SQL] Interval subtracting

Tom Lane wrote: > Mark Dilger <[EMAIL PROTECTED]> writes: > >>Am I correct that the second case should still have negative hours? > > > Yes... > > >>If so, then justify_hours(...) needs to examine the sign of the days >>and months portion of the interval while performing its work. > > > No, it sho

Re: [HACKERS] [SQL] Interval subtracting

Bruce Momjian writes: > Imagine this: > '1 mons -2 days -12:00:00' > Which sign do we head to for this? For justify_hours, if we don't look > at the months it remains unchange, but calling justify_days we get: > '28 days -12:00:00' > which is wrong (negative and positive). Ugh, t

Re: [HACKERS] pg_config, pg_service.conf, postgresql.conf ....

Bruce Momjian wrote: Mark Kirkwood wrote: What if we add an option to initdb to allow the user to specify the name and location of the postgresql.conf file? That is certainly a way to approach it, I see the tough bit being the parsing of postgresql.conf to figure out which parts of the globa

Re: [HACKERS] [SQL] Interval subtracting

A new patch is attached. Please note the regression differences. mark Index: src/backend/utils/adt/timestamp.c === RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/timestamp.c,v retrieving revision 1.160 diff --context=5 -

Re: [HACKERS] Status of INS/UPD/DEL RETURNING?

Gavin Sherry wrote: > On Wed, 1 Mar 2006, Bruce Momjian wrote: > > > Jonah H. Harris wrote: > > > Hey guys, > > > > > > What's the status of the current INSERT/UPDATE/DELETE RETURNING patch? Is > > > it ready to go or does it need to be cleaned up? > > > > Uh, I don't remember seeing any patch li

Re: [HACKERS] Status of INS/UPD/DEL RETURNING?

OK... I guess I'll go through the archives and see what Tom et al's comments were and work from there.  I tried to contact Omar a couple times via email and got no response. Thanks!On 3/1/06, Gavin Sherry <[EMAIL PROTECTED]> wrote: On Wed, 1 Mar 2006, Bruce Momjian wrote:> Jonah H. Harris wrote:>

Re: [HACKERS] Status of INS/UPD/DEL RETURNING?

On Wed, 1 Mar 2006, Bruce Momjian wrote: > Jonah H. Harris wrote: > > Hey guys, > > > > What's the status of the current INSERT/UPDATE/DELETE RETURNING patch? Is > > it ready to go or does it need to be cleaned up? > > Uh, I don't remember seeing any patch like that. Where is it? Omar Kilani se

Re: [HACKERS] Status of INS/UPD/DEL RETURNING?

http://candle.pha.pa.us/mhonarc/patches_hold/msg00014.html On 3/1/06, Bruce Momjian wrote: Jonah H. Harris wrote:> Hey guys,>> What's the status of the current INSERT/UPDATE/DELETE RETURNING patch?  Is> it ready to go or does it need to be cleaned up?Uh, I don't remember se

Re: [HACKERS] Status of INS/UPD/DEL RETURNING?

Jonah H. Harris wrote: > Hey guys, > > What's the status of the current INSERT/UPDATE/DELETE RETURNING patch? Is > it ready to go or does it need to be cleaned up? Uh, I don't remember seeing any patch like that. Where is it? -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http

[HACKERS] Status of INS/UPD/DEL RETURNING?

Hey guys, What's the status of the current INSERT/UPDATE/DELETE RETURNING patch?  Is it ready to go or does it need to be cleaned up? -- Jonah H. Harris, Database Internals ArchitectEnterpriseDB Corporation732.331.1324

Re: [HACKERS] [SQL] Interval subtracting

Bruce Momjian wrote: Mark Dilger wrote: Your proposal is that justify_hours borrows 24 hours from the days column in order to bring the -12 hours up to a positive 12 hours. Should it only do that if the days column is a positive number? What if it is negative? I think we all agree on the f

Re: [HACKERS] [SQL] Interval subtracting

Mark Dilger wrote: > Your proposal is that justify_hours borrows 24 hours from the days column in > order to bring the -12 hours up to a positive 12 hours. Should it only do > that > if the days column is a positive number? What if it is negative? > > I think we all agree on the following but

Re: [HACKERS] [SQL] Interval subtracting

Tom Lane wrote: Mark Dilger <[EMAIL PROTECTED]> writes: The current code (without the patch) behaves as follows: select justify_days(justify_hours('1 month 95 days -36:00:00'::interval)); justify_days - 4 mons 4 days -12:00:00 So? If we liked the c

Re: [HACKERS] [SQL] Interval subtracting

Mark Dilger <[EMAIL PROTECTED]> writes: > The current code (without the patch) behaves as follows: >select justify_days(justify_hours('1 month 95 days -36:00:00'::interval)); > justify_days >- > 4 mons 4 days -12:00:00 So? If we liked the current beha

Re: [HACKERS] [SQL] Interval subtracting

Tom Lane wrote: Mark Dilger <[EMAIL PROTECTED]> writes: Tom Lane wrote: I guess I would expect a good result to satisfy one of these three cases: * month > 0 and 0 <= day < 30 * month < 0 and -30 < day <= 0 * month = 0 and -30 < day < 30 If you believe that then "1 mon

Re: [HACKERS] [SQL] Interval subtracting

Mark Dilger <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> I guess I would expect a good result to satisfy one of these three >> cases: >> * month > 0 and 0 <= day < 30 >> * month < 0 and -30 < day <= 0 >> * month = 0 and -30 < day < 30 >> If you believe that then "1 month -95 days

Re: [HACKERS] [SQL] Interval subtracting

On Wed, 2006-03-01 at 14:27, Bruce Momjian wrote: > Scott Marlowe wrote: > > On Wed, 2006-03-01 at 14:18, Bruce Momjian wrote: > > > Stephan Szabo wrote: > > > > > justify_days doesn't currently do anything with this result --- it > > > > > thinks its charter is only to reduce day components that a

Re: [HACKERS] pg_config, pg_service.conf, postgresql.conf ....

Mark Kirkwood wrote: > > What if we add an option to initdb to allow the user to specify the name > > and location of the postgresql.conf file? > > That is certainly a way to approach it, I see the tough bit being the > parsing of postgresql.conf to figure out which parts of the global > include

Re: [HACKERS] pg_config, pg_service.conf, postgresql.conf ....

Bruce Momjian wrote: Lamar Owen wrote: On Monday 27 February 2006 21:09, Bruce Momjian wrote: One question I have is how this feature would be an improvement over just pointing pg_ctl at a postgresql.conf configuration file. That config file has the ability to specify most if not all server

Re: [HACKERS] [SQL] Interval subtracting

Hannu Krosing wrote: But unfortunately '2 mons -1 days' <> '1 mons 29 days' If I want something to happen 1 day less than two months from dome date, then the only way to say that consistently *is* '2 mons -1 days'. Correct me if I am wrong, but I thought that justify_days would only be called

Re: [HACKERS] [SQL] Interval subtracting

Tom Lane wrote: Bruce Momjian writes: I don't think we can accept a change that takes a negative and turns it into a positive and negative. Yeah, I find the patch's changes to the regression results pretty disturbing. Perhaps the correct definition ought to be like "if month part >= 0 then

Re: [HACKERS] [SQL] Interval subtracting

Hannu Krosing <[EMAIL PROTECTED]> writes: > But unfortunately '2 mons -1 days' <> '1 mons 29 days' > If I want something to happen 1 day less than two months from dome date, > then the only way to say that consistently *is* '2 mons -1 days'. Sure, but if you want to represent that then you don't p

Re: [HACKERS] [SQL] Interval subtracting

Tom Lane wrote: > Bruce Momjian writes: > > I don't think we can accept a change that takes a negative and turns it > > into a positive and negative. > > Yeah, I find the patch's changes to the regression results pretty > disturbing. > > Perhaps the correct definition ought to be like "if month

Re: [HACKERS] [SQL] Interval subtracting

Hannu Krosing wrote: > ?hel kenal p?eval, K, 2006-03-01 kell 15:18, kirjutas Bruce Momjian: > > Stephan Szabo wrote: > > > > justify_days doesn't currently do anything with this result --- it > > > > thinks its charter is only to reduce day components that are >= 30 days. > > > > However, I think a

Re: [HACKERS] [SQL] Interval subtracting

On Wed, 1 Mar 2006, Hannu Krosing wrote: > Ühel kenal päeval, K, 2006-03-01 kell 15:18, kirjutas Bruce Momjian: > > Stephan Szabo wrote: > > > > justify_days doesn't currently do anything with this result --- it > > > > thinks its charter is only to reduce day components that are >= 30 days. > > >

Re: [HACKERS] [SQL] Interval subtracting

Ühel kenal päeval, K, 2006-03-01 kell 15:18, kirjutas Bruce Momjian: > Stephan Szabo wrote: > > > justify_days doesn't currently do anything with this result --- it > > > thinks its charter is only to reduce day components that are >= 30 days. > > > However, I think a good case could be made that i

Re: [HACKERS] [SQL] Interval subtracting

Bruce Momjian writes: > I don't think we can accept a change that takes a negative and turns it > into a positive and negative. Yeah, I find the patch's changes to the regression results pretty disturbing. Perhaps the correct definition ought to be like "if month part >= 0 then the reduced day p

Re: [HACKERS] [SQL] Interval subtracting

Scott Marlowe wrote: > On Wed, 2006-03-01 at 14:18, Bruce Momjian wrote: > > Stephan Szabo wrote: > > > > justify_days doesn't currently do anything with this result --- it > > > > thinks its charter is only to reduce day components that are >= 30 days. > > > > However, I think a good case could be

Re: [HACKERS] pg_config, pg_service.conf, postgresql.conf ....

Christopher Browne wrote: [EMAIL PROTECTED] (Mark Kirkwood) wrote: Do you need name, value pairs? I was thinking that something like: # Postgres Cluster Registration # # PG_HOME PGDATA PORT /usr/local/pg7.4.1 /vol01/pggeo 5435 /usr/local/pg7.4.1 /vol01/pgicdmdb 5434 /usr/local/pg7.4

Re: [HACKERS] [SQL] Interval subtracting

On Wed, 2006-03-01 at 14:18, Bruce Momjian wrote: > Stephan Szabo wrote: > > > justify_days doesn't currently do anything with this result --- it > > > thinks its charter is only to reduce day components that are >= 30 days. > > > However, I think a good case could be made that it should normalize

Re: [HACKERS] [SQL] Interval subtracting

Stephan Szabo wrote: > > justify_days doesn't currently do anything with this result --- it > > thinks its charter is only to reduce day components that are >= 30 days. > > However, I think a good case could be made that it should normalize > > negative days too; that is, the invariant on its resul

Re: [HACKERS] [SQL] Interval subtracting

Mark Dilger wrote: >select justify_hours('-73 hours'::interval); > justify_hours >--- > -4 days +23:00:00 > >select justify_days('-62 days'::interval); > justify_days >-- > -3 mons +28 days > > > I find the last two results some

Re: [HACKERS] bug in 7.3.2

On Wed, Mar 01, 2006 at 10:17:04AM +0530, Suvarna wrote: > actually the number which are missing are in the range of 20-30 and at the > max only 3 transactions are going on at any given point in time. > So if 3 numbers are missing then it was understood the missing numbers are > very large. The nu

Re: [HACKERS] Automatic free space map filling

Ühel kenal päeval, T, 2006-02-28 kell 19:47, kirjutas Alvaro Herrera: > Hannu Krosing wrote: > > > Due to current implementation of vacuum, > > you have to abandon continuous vacuuming during vacuum of bigtable, but > > i have written and submitted to "patches" list a patch which allows > > vacuum

Re: [HACKERS] 8.2 Feature Freeze Rough Estimate

Jonah H. Harris wrote: > Bruce, > > I haven't had much time to finish up on the WITH recursive/hierarchical > query stuff yet, but was wondering when you see it having to be completed if > freeze is in August? Would May 1st be too late? Let us know when you start working on it and we will see it

Re: [HACKERS] 8.2 Feature Freeze Rough Estimate

Jonah H. Harris wrote: Bruce, I haven't had much time to finish up on the WITH recursive/hierarchical query stuff yet, but was wondering when you see it having to be completed if freeze is in August? Would May 1st be too late? Doesn't feature freeze mean that's when you have to have yo

Re: [HACKERS] FW: Rép. : Re: [PERFORM] Bad plan on a v

Gone On Wed, 1 Mar 2006, Jim Nasby wrote: Someone want to remove/suspend "Antoine Bajolet" <[EMAIL PROTECTED]> from the lists? He's sending these emails to the author of every list email (not sure if he's on more than just -perform). -Original Message- From: [EMAIL PROTECTED] [mailt

Re: [HACKERS] 8.2 Feature Freeze Rough Estimate

Bruce, I haven't had much time to finish up on the WITH recursive/hierarchical query stuff yet, but was wondering when you see it having to be completed if freeze is in August?  Would May 1st be too late? On 3/1/06, Bruce Momjian wrote: Robert Treat wrote:> I'm trying to p

[HACKERS] FW: Rép. : Re: [PERFORM] Bad plan on a v iew ([Congés])

Someone want to remove/suspend "Antoine Bajolet" <[EMAIL PROTECTED]> from the lists? He's sending these emails to the author of every list email (not sure if he's on more than just -perform). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Antoine Bajolet S

Re: [HACKERS] bug in 7.3.2

Hello Tom, thankyou for the reply but, actually the number which are missing are in the range of 20-30 and at the max only 3 transactions are going on at any given point in time. So if 3 numbers are missing then it was understood the missing numbers are very large. Regards, suvarna - Original

Re: [HACKERS] bug in 7.3.2

Hello Jonah,   No we are not caching the sequence In the transaction for the first time we use next val & then on we use curretn val.   Regards, Suvarna   - Original Message - From: Jonah H. Harris To: Suvarna Cc: pgsql-hackers@postgresql.org Sent: Tuesday, Febru

[HACKERS] PostgreSQL Anniversary Summit, Call for Contributions

PostgreSQL Anniversary Summit = Call for Contributions -- The PostgreSQL Anniversary Summit will take place on July 8 and 9, 2006, in Toronto, Canada. We are planning for a gathering of about 50 hackers, contributors, and other friends of the Pos

Re: [HACKERS] [SQL] Interval subtracting

On Wed, Mar 01, 2006 at 12:59:29PM -0500, Bruce Momjian wrote: > Good question. Should we restrict days to 0 - 30 or -30 - 30? The > current system does the later: > > test=> select justify_days('-45 days'); > justify_days > -- >-1 mons -15 days >

Re: [HACKERS] [SQL] Interval subtracting

Mark Dilger wrote: Tom Lane wrote: "Milen A. Radev" <[EMAIL PROTECTED]> writes: Milorad Poluga напи�а: SELECT '10 years 1 mons 1 days'::interval - '9 years 10 mons 15 days'::interval ?column?--- 3 mons -14 days Why not '2 mons 16 days' ? Please read the las

Re: [HACKERS] [SQL] Interval subtracting

Mark Dilger wrote: > Tom Lane wrote: > > "Milen A. Radev" <[EMAIL PROTECTED]> writes: > > > >>Milorad Poluga : > >> > SELECT '10 years 1 mons 1 days'::interval - '9 years 10 mons 15 > days'::interval > ?column? > --- > 3 mons -14 days > >

Re: [HACKERS] Automatic free space map filling

Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> How does an optimistic FSM entry avoid the need to run vacuum? > > > It ensures that all freed tuples are already in the FSM. > > That has nothing to do with it, because the space isn't actually free > for re-

Re: [HACKERS] 8.2 Feature Freeze Rough Estimate

Robert Treat wrote: > I'm trying to plan out a few postgresql related projects and could use some > intuition on when folks think the feature freeze for 8.2 is going to occur. I > thought it was going to be in Nov 06, but after talking to a couple of > people, I've also heard that Aug 06 and Feb

Re: [HACKERS] statement_cost_limit

I can see this as useful for newbies who don't want to accidentally overload the system. --- Simon Riggs wrote: > On Wed, 2006-03-01 at 11:47 -0500, Tom Lane wrote: > > Simon Riggs <[EMAIL PROTECTED]> writes: > > > A new par

Re: [HACKERS] Automatic free space map filling

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> How does an optimistic FSM entry avoid the need to run vacuum? > It ensures that all freed tuples are already in the FSM. That has nothing to do with it, because the space isn't actually free for re-use until vacuum deletes the tup

Re: [HACKERS] statement_cost_limit

On Wed, 2006-03-01 at 11:47 -0500, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > A new parameter that allows the administrator to place sensible limits > > on the size of queries executed. > > As I said when the idea was floated originally, I don't think this is a > very good idea

Re: [HACKERS] Automatic free space map filling

Tom Lane wrote: > How does an optimistic FSM entry avoid the need to run vacuum? It ensures that all freed tuples are already in the FSM. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked

Re: [HACKERS] pg_config, pg_service.conf, postgresql.conf ....

Lamar Owen wrote: > On Monday 27 February 2006 21:09, Bruce Momjian wrote: > > One question I have is how this feature would be an improvement over > > just pointing pg_ctl at a postgresql.conf configuration file. That > > config file has the ability to specify most if not all server > > parameter

Re: [HACKERS] [SQL] Interval subtracting

Tom Lane wrote: "Milen A. Radev" <[EMAIL PROTECTED]> writes: Milorad Poluga напи�а: SELECT '10 years 1 mons 1 days'::interval - '9 years 10 mons 15 days'::interval ?column? --- 3 mons -14 days Why not '2 mons 16 days' ? Please read the last paragraph in sect

Re: [HACKERS] Vacuum dead tuples that are "between" transactions

On Wed, 2006-03-01 at 10:22 -0600, Kevin Grittner wrote: > >>> On Tue, Feb 28, 2006 at 7:22 am, in message > <[EMAIL PROTECTED]>, Simon Riggs > <[EMAIL PROTECTED]> wrote: > > > > OTOH a few hackers discussed this recently and found that nobody > used > > serializable transactions (ST) except dur

Re: [HACKERS] Automatic free space map filling

Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > I'm not sure if I made myself clear. The idea is that you fill the > > free-space > > map early with opportunitistic entries in the hope that most updates and > > deletes go through "soon". That is, these entries will be invali

Re: [HACKERS] statement_cost_limit

Simon Riggs <[EMAIL PROTECTED]> writes: > A new parameter that allows the administrator to place sensible limits > on the size of queries executed. As I said when the idea was floated originally, I don't think this is a very good idea at all. The planner's estimates are sufficiently often wrong

Re: [HACKERS] pg_config, pg_service.conf, postgresql.conf ....

On Monday 27 February 2006 21:09, Bruce Momjian wrote: > One question I have is how this feature would be an improvement over > just pointing pg_ctl at a postgresql.conf configuration file. That > config file has the ability to specify most if not all server > parameters. The big problem is that

Re: [HACKERS] pg_config, pg_service.conf, postgresql.conf ....

On Monday 27 February 2006 19:59, Josh Berkus wrote: > > My frustration level often kills any desire to contribute to open > > source. Sometimes, I think that open source is doomed. The various > > projects I track and use are very frustrating, they remind me of > > dysfunctional engineering depart

[HACKERS] 8.2 Feature Freeze Rough Estimate

I'm trying to plan out a few postgresql related projects and could use some intuition on when folks think the feature freeze for 8.2 is going to occur. I thought it was going to be in Nov 06, but after talking to a couple of people, I've also heard that Aug 06 and Feb 07 seem to be possibilities

Re: [HACKERS] Vacuum dead tuples that are "between"

>>> On Tue, Feb 28, 2006 at 7:22 am, in message <[EMAIL PROTECTED]>, Simon Riggs <[EMAIL PROTECTED]> wrote: > > OTOH a few hackers discussed this recently and found that nobody used > serializable transactions (ST) except during pg_dump. I've not been able to keep up with all messages on these

Re: [PERFORM] [HACKERS] temporary indexes

>>> On Tue, Feb 28, 2006 at 3:02 pm, in message <[EMAIL PROTECTED]>, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote: > > Maybe it's just the way my twisted mind thinks, but I generally prefer > using a JOIN when possible... Definitely. But sometimes you don't want one row from a table for each quali

Re: [HACKERS] Automatic free space map filling

Peter Eisentraut <[EMAIL PROTECTED]> writes: > I'm not sure if I made myself clear. The idea is that you fill the > free-space > map early with opportunitistic entries in the hope that most updates and > deletes go through "soon". That is, these entries will be invalid for a > short time but

Re: [HACKERS] [ADMIN] Reg:lo_open error..pls help me

Michael Fuhr <[EMAIL PROTECTED]> writes: > On Wed, Mar 01, 2006 at 11:03:12AM -0500, Tom Lane wrote: >> Are you sure that's where it's failing? The fragment you showed looks >> fine as far as it goes. The most likely bet is you forgot to wrap it in >> a transaction (BEGIN/COMMIT commands), but th

Re: [HACKERS] Initdb on Windows 2003

(private email says leaving off --user=foo doesn't fix it ;-( ) Since you have apparently compiled your own, could you please try with the latest stable initdb.c code for your release? That is version 1.99.2.2 for release 8.1 or 1.73.4.3 for release 8.0. They are downloadable here: http://de

Re: [HACKERS] Automatic free space map filling

Am Montag, 27. Februar 2006 19:42 schrieb Tom Lane: > The free-space map is not the hard part of the problem. You still have > to VACUUM --- that is, wait until the dead tuple is not only committed > dead but is certainly dead to all onlooker transactions, and then remove > its index entries as we

[HACKERS] statement_cost_limit

On Tue, 2006-02-21 at 11:45 +1300, Mark Kirkwood wrote: > Simon Riggs wrote: > > A new parameter that allows the administrator to place sensible limits > > on the size of queries executed. > > > > This is useful for ad-hoc SQL access > > - when a very large table cannot realistically be sorted e

Re: [HACKERS] ipcclean in 8.1 broken?

Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > No-one has a comment on this? ipcclean has never been much more than beta-quality software; it doesn't pretend to be very portable. Having said that, I think the anti-root check is bogus. It was probably added in a fit of "let's make sure nob

Re: [HACKERS] Initdb on Windows 2003

<[EMAIL PROTECTED]> writes: > Below is an email thread regarding a possible bug in PostgreSQL on > Windows 2003. Any help or advice anyone can give on this would be much > appreciated. "Access is denied." is not a string that appears anywhere in the Postgres source code. My bet is some overenthus

Re: [HACKERS] ipcclean in 8.1 broken?

I wonder if there could be a potential problem with using this approach - checking on $USER == root. Although it is a common practice, I think a superuser does not have to be root. If I'm right here, a better technique could be executing `id`. Mike -Original Message- From: [EMAIL PROTE

Re: [HACKERS] Initdb on Windows 2003

Hi, 1. The command line passed is -D "c:\data" --user=McAfeePostgresUser 2. McAfeePostgresUser which is a local machine user with limited privileges. Though this problem occurs with any user account you create with non-administrator privileges. Thanks James -Original Message- From: Andr

Re: [HACKERS] pg_config, pg_service.conf, postgresql.conf ....

[EMAIL PROTECTED] (Mark Kirkwood) wrote: > Do you need name, value pairs? I was thinking that something like: > > # Postgres Cluster Registration > # > # PG_HOME PGDATA PORT > /usr/local/pg7.4.1 /vol01/pggeo 5435 > /usr/local/pg7.4.1 /vol01/pgicdmdb 5434 > /usr/local/pg7.4.1 /vol03/pg7

Re: [HACKERS] Initdb on Windows 2003

1. please show the EXACT initdb command line used. 2. Which Windows user was actually running initdb? cheers andrew > Hello all, > > Below is an email thread regarding a possible bug in PostgreSQL on > Windows 2003. Any help or advice anyone can give on this would be much > appreciated. > > A

Re: [HACKERS] ipcclean in 8.1 broken?

# [EMAIL PROTECTED] / 2006-03-01 12:49:13 +0100: > Am Dienstag, 28. Februar 2006 07:42 schrieb Christopher Kings-Lynne: > > I just tried using ipcclean in 8.1.3. It doesn't work when I su to the > > pgsql user. This part of the script: > > > > if [ "$USER" = 'root' -o "$LOGNAME" = 'root' ] > > >

Re: [HACKERS] ipcclean in 8.1 broken?

Am Dienstag, 28. Februar 2006 07:42 schrieb Christopher Kings-Lynne: > I just tried using ipcclean in 8.1.3. It doesn't work when I su to the > pgsql user. This part of the script: > > if [ "$USER" = 'root' -o "$LOGNAME" = 'root' ] > > Always fails because even tho $USER is set to 'pgsql' when su

  1   2   >