Re: [HACKERS] TIMESTAMP and daylight savings time question

We figured the problem out. Our older version did not have the OS patch: http://www.postgresqlforums.com/wiki/2007_Daylight_Savings_Time From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dann Corbit Sent: Wednesday, March 12, 2008 6:06 PM To: p

Re: [HACKERS] Commit fest?

Tom Lane wrote: > Greg Smith <[EMAIL PROTECTED]> writes: > > Usefully organized > > content doesn't magically create itself, it takes work. > > What he said. > > It's worth pointing out here that a whole lot of what is in Bruce's > queue isn't patches or anything close to that, but discussions t

Re: [HACKERS] Commit fest?

Yep, Greg Smith hit the nail on the head. There were lots of complaints in the past that "we don't know how to help" so now almost every thread has a comment, and people can add their own comments, but still it is mostly Tom and me making comments and applying patches and adding TODO items. "Oh,

Re: [HACKERS] Commit fest?

Greg Smith wrote: > On Fri, 14 Mar 2008, Joshua D. Drake wrote: > > > http://momjian.us/mhonarc/patches/msg00155.html > > This patch is actually one I think I could review but I see nothing > > that allows a comment or login to allow comment or anything. :( > > To be specific, click on the "Threa

Re: [HACKERS] Commit fest?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 15 Mar 2008 00:22:09 -0300 Alvaro Herrera <[EMAIL PROTECTED]> wrote: > Joshua D. Drake wrote: > > > Thanks for that but I have tried multiple patches and I get nothing. > > This is what I did: > > > > browser: > > http://momjian.us/mhonarc/p

Re: [HACKERS] Commit fest?

Joshua D. Drake wrote: > Thanks for that but I have tried multiple patches and I get nothing. > This is what I did: > > browser: > http://momjian.us/mhonarc/patches/msg00155.html > click "Thread Index": > http://momjian.us/mhonarc/patches/thrd2.html#00162 Actually, "thread index" takes you to ht

Re: [HACKERS] Commit fest?

Greg Smith <[EMAIL PROTECTED]> writes: > Usefully organized > content doesn't magically create itself, it takes work. What he said. It's worth pointing out here that a whole lot of what is in Bruce's queue isn't patches or anything close to that, but discussions that he dropped into the queue un

Re: [HACKERS] Autovacuum vs statement_timeout

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> To me, the killer reason for statement_timeout = 0 during pg_dump >> is that without it, routine cron-driven dumps could fail, and the >> user might not notice until he really really needed that dump. > This concrete case if of cour

Re: [HACKERS] Commit fest?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 14 Mar 2008 21:28:30 -0400 (EDT) Greg Smith <[EMAIL PROTECTED]> wrote: > On Fri, 14 Mar 2008, Joshua D. Drake wrote: > > > http://momjian.us/mhonarc/patches/msg00155.html > > This patch is actually one I think I could review but I see nothing

Re: [HACKERS] Commit fest?

On Fri, 14 Mar 2008, Joshua D. Drake wrote: http://momjian.us/mhonarc/patches/msg00155.html This patch is actually one I think I could review but I see nothing that allows a comment or login to allow comment or anything. :( To be specific, click on the "Thread Index" button at the top of that

Re: [HACKERS] Commit fest?

On Fri, 14 Mar 2008, Andrew Dunstan wrote: I can't say I find this an advance - paging through 14 pages of subject headers with the odd comment isn't very productive. Bruce had said it was going to take him time to organize things better, and instead of waiting for that to complete he was ask

Re: [HACKERS] Autovacuum vs statement_timeout

Tom Lane wrote: > To me, the killer reason for statement_timeout = 0 during pg_dump > is that without it, routine cron-driven dumps could fail, and the > user might not notice until he really really needed that dump. This concrete case if of course valid, but if you take a step back, there are ab

Re: [HACKERS] PROC_VACUUM_FOR_WRAPAROUND doesn't work expectedly

Alvaro Herrera <[EMAIL PROTECTED]> writes: > Tom Lane escribió: >> The other problem with it is that it's running vacuum() in an >> indefinite-lifespan context. Perhaps that has something to do with >> the report we saw awhile back of autovac leaking memory ... > Hmm, I'm not sure which memory le

Re: [HACKERS] PROC_VACUUM_FOR_WRAPAROUND doesn't work expectedly

Tom Lane escribió: > "Pavan Deolasee" <[EMAIL PROTECTED]> writes: > > I also noticed that inside autovacuum_do_vac_analyze(), we save the old > > context (which is TopTransactionContext) and restore it back after vacuum() > > returns. But vacuum() might have started a new transaction invalidating t

Re: [HACKERS] Commit fest?

"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > O.k. I have got to be doing something wrong. I always leave javascript > on entirely. I am on this page: > http://momjian.us/mhonarc/patches/msg00155.html You can put comments on the top-level index pages --- actually they're at the level of threads

Re: [HACKERS] Commit fest?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 14 Mar 2008 20:09:26 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: > > Not it just looks like the same old patches threads :( > > The comment stuff seems to need Javascript :-( > >

Re: [HACKERS] Commit fest?

"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > Not it just looks like the same old patches threads :( The comment stuff seems to need Javascript :-( regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscript

Re: [HACKERS] Commit fest?

Andrew Dunstan <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> http://momjian.us/cgi-bin/pgpatches > I can't say I find this an advance - paging through 14 pages of subject > headers with the odd comment isn't very productive. A nice wiki table > with links to the discussions would be much nice

Re: [HACKERS] Commit fest?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 14 Mar 2008 19:58:49 -0400 Andrew Dunstan <[EMAIL PROTECTED]> wrote: > I can't say I find this an advance - paging through 14 pages of > subject headers with the odd comment isn't very productive. A nice > wiki table with links to the discuss

Re: [HACKERS] Commit fest?

Tom Lane wrote: "Joshua D. Drake" <[EMAIL PROTECTED]> writes: I was just curious what the status of the Commit Fest was? It's moving, but slowly. Bruce and I have been knocking items off the queue, but we could use some help with reviewing. http://momjian.us/cgi-bin/pgpatches Ple

Re: [HACKERS] PROC_VACUUM_FOR_WRAPAROUND doesn't work expectedly

"Pavan Deolasee" <[EMAIL PROTECTED]> writes: > I also noticed that inside autovacuum_do_vac_analyze(), we save the old > context (which is TopTransactionContext) and restore it back after vacuum() > returns. But vacuum() might have started a new transaction invalidating the > saved context. Do we s

Re: [HACKERS] Commit fest?

Gregory Stark <[EMAIL PROTECTED]> writes: >> It's moving, but slowly. Bruce and I have been knocking items off >> the queue, but we could use some help with reviewing. > Could you point me at a patch you think would make a good candidate? Or should > I just pick a random one? Pick things you fe

Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT

Gregory Stark <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> writes: >> Hmm. I find the whole thing fairly worrisome, because what it suggests >> is that Windows isn't actually allocating file space during smgrextend, >> which would mean that we'd be prone to running out of disk spac

[HACKERS] Re: [COMMITTERS] pgsql: Fix vacuum so that autovacuum is really not cancelled when doing

Devrim GÜNDÜZ wrote: > Hi, > > On Fri, 2008-03-14 at 17:26 +, Alvaro Herrera wrote: > > --- > > Fix vacuum so that autovacuum is really not cancelled when doing an > > emergency > > job (i.e. to prevent Xid wraparound problems.) Bug reported by ITAGAKI > > Takahiro in [EMAIL PROTECTE

Re: [HACKERS] Commit fest?

"Tom Lane" <[EMAIL PROTECTED]> writes: > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: >> I was just curious what the status of the Commit Fest was? > > It's moving, but slowly. Bruce and I have been knocking items off > the queue, but we could use some help with reviewing. Could you point me a

Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT

"Tom Lane" <[EMAIL PROTECTED]> writes: > "Zubkovsky, Sergey" <[EMAIL PROTECTED]> writes: >> The previous results were received on PG 8.3 version: >> "PostgreSQL 8.3.0, compiled by Visual C++ build 1400" > > Hmm. I find the whole thing fairly worrisome, because what it suggests > is that Wind

[HACKERS] Re: [COMMITTERS] pgsql: Fix vacuum so that autovacuum is really not cancelled when doing

Hi, On Fri, 2008-03-14 at 17:26 +, Alvaro Herrera wrote: > --- > Fix vacuum so that autovacuum is really not cancelled when doing an emergency > job (i.e. to prevent Xid wraparound problems.) Bug reported by ITAGAKI > Takahiro in [EMAIL PROTECTED], though I didn't use his > patch. >

Re: [HACKERS] Commit fest?

"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > I was just curious what the status of the Commit Fest was? It's moving, but slowly. Bruce and I have been knocking items off the queue, but we could use some help with reviewing. http://momjian.us/cgi-bin/pgpatches Please leave a comment if you'r

Re: [HACKERS] PROC_VACUUM_FOR_WRAPAROUND doesn't work expectedly

Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Does this look better? > > Yeah, works for me. Please apply. Applied to HEAD and 8.3. Thanks, Takahiro-san, for the report! -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company -

Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT

"Zubkovsky, Sergey" <[EMAIL PROTECTED]> writes: > The previous results were received on PG 8.3 version: > "PostgreSQL 8.3.0, compiled by Visual C++ build 1400" Hmm. I find the whole thing fairly worrisome, because what it suggests is that Windows isn't actually allocating file space during

[HACKERS] Commit fest?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I was just curious what the status of the Commit Fest was? As I recall it started on the 1st but I haven't seen much. Is something holding us up? Is there something I(we/community/cmd) can do to help? Sincerely, Joshua D. Drake - -- The Pos

Re: [HACKERS] PROC_VACUUM_FOR_WRAPAROUND doesn't work expectedly

Alvaro Herrera <[EMAIL PROTECTED]> writes: > Does this look better? Yeah, works for me. Please apply. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-h

Re: [HACKERS] PROC_VACUUM_FOR_WRAPAROUND doesn't work expectedly

Alvaro Herrera wrote: > Tom Lane wrote: > > That's really, really ugly. I'd rather see the flag passed down to > > vacuum_rel as a regular function argument. I realize you'll need > > to touch the signatures of a couple of levels of functions to do that, > > but a global variable for this seems

Re: [HACKERS] PROC_VACUUM_FOR_WRAPAROUND doesn't work expectedly

Alvaro Herrera <[EMAIL PROTECTED]> writes: > Okay, I'll do that instead. If I do it quickly, will it be present in > 8.3.1? I think it was already tagged so my guess is it won't. I think Marc is planning to rebundle this evening, so if you can get it done in the next few hours...

Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT

The previous results were received on PG 8.3 version: "PostgreSQL 8.3.0, compiled by Visual C++ build 1400" -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2008 7:19 PM To: Zubkovsky, Sergey Cc: [EMAIL PROTECTED]; pgsql-hackers@postgresql.org

Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT

[ moved to -hackers --- see original thread here http://archives.postgresql.org/pgsql-docs/2008-03/msg00039.php ] "Zubkovsky, Sergey" <[EMAIL PROTECTED]> writes: > Here is my example. Hmm ... on my Fedora machine I get the same result (704512) in all these cases, which is what I'd expect. (The e

Re: [HACKERS] PROC_VACUUM_FOR_WRAPAROUND doesn't work expectedly

Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > How about this other patch? > > That's really, really ugly. I'd rather see the flag passed down to > vacuum_rel as a regular function argument. I realize you'll need > to touch the signatures of a couple of levels of functions to d

Re: [HACKERS] PROC_VACUUM_FOR_WRAPAROUND doesn't work expectedly

Alvaro Herrera <[EMAIL PROTECTED]> writes: > How about this other patch? That's really, really ugly. I'd rather see the flag passed down to vacuum_rel as a regular function argument. I realize you'll need to touch the signatures of a couple of levels of functions to do that, but a global variabl

Re: [HACKERS] Data Recovery feature

[EMAIL PROTECTED] ("Amit jain") writes: > What are the Data Recovery feature available in postgreSQL apart > from pg_restore and PITR. If my Database has corrupted its not > starting which feature i can use for Data Recovery ? Any help > willbe highly appreciated. The primary mechanism for datab

Re: [HACKERS] PROC_VACUUM_FOR_WRAPAROUND doesn't work expectedly

ITAGAKI Takahiro wrote: > I found autovacuum can be canceled by blocked backends even if the vacuum > is for preventing XID wraparound in 8.3.0 and HEAD. Autovacuum sets > PROC_VACUUM_FOR_WRAPAROUND flag just before vacuum, but the flag will be > cleared at the beginning of vacuum; PROC_VACUUM_FOR_

Re: [HACKERS] Reducing Transaction Start/End Contention

Just started a blog session on my findings running Postgres 8.3(beta) on a mid range Sun Fire server. Second entry is about the time lost on LWLock handling. When concurrency increases you can see the ProcArrayLock wait queue to start and explode. http://blogs.sun.com/paulvandenbogaard/entr

Re: [HACKERS] Proposal for db level triggers

On Fri, Mar 14, 2008 at 3:44 AM, James Mansion <[EMAIL PROTECTED]> wrote: > > And if we use data update triggers to insert into a DELETE ROWS temp > table or an in-memory data > structure, the BEFORE COMMIT trigger is the place to do a bulk copy into > real table(s) or combine > rows into a B

Re: [HACKERS] PROC_VACUUM_FOR_WRAPAROUND doesn't work expectedly

On Fri, Mar 14, 2008 at 7:36 AM, ITAGAKI Takahiro <[EMAIL PROTECTED]> wrote: > > I tried to make a patch to exclude PROC_VACUUM_FOR_WRAPAROUND > from PROC_VACUUM_STATE_MASK and make autovacuum workers to clear > PROC_VACUUM_FOR_WRAPAROUND by themselves. Is it a reasonable solution? > > Looks go

Re: [HACKERS]COPY issue(gsoc project)

Hi Longlong, > > i think this is a better idea. > from *NikhilS * > http://archives.postgresql.org/pgsql-hackers/2007-12/msg00584.php > But instead of using a per insert or a batch insert substraction, I am > thinking that we can start off a subtraction and continue it till we > encounter a failu

Re: [HACKERS] bug in numeric_power() function

I also have a question here: isn't dpow enough for calculation? Why added numeric_power? "Tom Lane" <[EMAIL PROTECTED]> дÈëÏûÏ¢ÐÂÎÅ:[EMAIL PROTECTED] > "Richard Wang" <[EMAIL PROTECTED]> writes: >> I expected 0 ^ 123.3 to be 0, but it reported error as follows >> postgres=# select 0 ^ 123.3; >> ER

[HACKERS] File your tax with NETFILE today

Online Filing Tax Returns2007 File your tax with NETFILE today NETFILE is an electronic tax-filing service of CRA. This transmission service allows you to file your personal inc

Re: [HACKERS] Reducing Transaction Start/End Contention

Just started a blog session on my findings running Postgres 8.3(beta) on a mid range Sun Fire server. Second entry is about the time lost on LWLock handling. When concurrency increases you can see the ProcArrayLock wait queue to start and explode. http://blogs.sun.com/paulvandenbogaard/entr