Re: [PATCHES] 64-bit CommandIds
Alvaro Herrera wrote: Bruce Momjian wrote: I think the case for it got a whole lot weaker in 8.3, with lazy consumption of CIDs. Agreed. Let's see if we get requests for it in = 8.3 releases. In the original submission message you find this text: : attached is our patch against HEAD which enables extending CommandIds : to 64-bit. This is for enabling long transactions that really do that : much non-read-only work in one transaction. Question for Hans-Juergen and Zoltan: have you tested 8.3 and do you still see the need for this? good morning, i have seen this problem two or three times within the past 2-3 years or so. so, it can basically happen in the field for some special purpose applications but i don't see this as an every day problem. it would be nice to have it in. we could also go for some special contrib module which could contain a patch along with some documentation but i am not quite sure how this fits in there. we would of course maintain the patch. many thanks, hans -- Cybertec Schönig Schönig GmbH PostgreSQL Solutions and Support Gröhrmühlgasse 26, A-2700 Wiener Neustadt Tel: +43/1/205 10 35 / 340 www.postgresql-support.de, www.postgresql-support.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Improve shutdown during online backup, take 4
Albe Laurenz [EMAIL PROTECTED] writes: That should work, but isn't it better if backup_label is removed only if we know we're going to shutdown cleanly? Why? That seems like an entirely arbitrary specification. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] 64-bit CommandIds
Hans-Juergen Schoenig [EMAIL PROTECTED] writes: Alvaro Herrera wrote: Question for Hans-Juergen and Zoltan: have you tested 8.3 and do you still see the need for this? i have seen this problem two or three times within the past 2-3 years or so. so, it can basically happen in the field for some special purpose applications but i don't see this as an every day problem. it would be nice to have it in. So these experiences were pre-8.3, right? The reason that I'm harping on that is that plpgsql does a CommandCounterIncrement for each expression it evaluates, whether or not there's any visible database access. As of 8.3 that won't cause consumption of CIDs, but before it did. I suspect that in a lot of real-world scenarios, CID consumption from triggers will be down by an order of magnitude. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Improve shutdown during online backup, take 4
Tom Lane wrote: Why? That seems like an entirely arbitrary specification. My resoning is that I think of smart/fast/immediate shutdown as three different things. For an immediate shutdown/crash thought it was best not to modify anything to facilitate an analysis of the problem. A fast shutdown that fails will end up as a crash or immediate shutdown. If you think that is is not important to only cancel backup mode if we are sure that the shutdown will be clean, we might as well also cancel online backup mode during an immediate shutdown. In that case, I'd agree that the call to CancelBackup() could be moved to WAIT_BACKUP (and executed only if it is no smart shutdown). It would have the advantage of having all backup mode related code in postmaster.c concentrated in one spot. Make a suggestion, and I'll implement it that way. Yours, Laurenz Albe -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] 64-bit CommandIds
Tom Lane wrote: Hans-Juergen Schoenig [EMAIL PROTECTED] writes: Alvaro Herrera wrote: Question for Hans-Juergen and Zoltan: have you tested 8.3 and do you still see the need for this? i have seen this problem two or three times within the past 2-3 years or so. so, it can basically happen in the field for some special purpose applications but i don't see this as an every day problem. it would be nice to have it in. So these experiences were pre-8.3, right? The reason that I'm harping on that is that plpgsql does a CommandCounterIncrement for each expression it evaluates, whether or not there's any visible database access. As of 8.3 that won't cause consumption of CIDs, but before it did. I suspect that in a lot of real-world scenarios, CID consumption from triggers will be down by an order of magnitude. regards, tom lane we found those problems when we dealt with stored procedures basically (during huge analysis and data modification transactions - rollup and materialize stuff, basically). i would think as well that it should have improved a lot. i have not tested with 8.3, however. on 8.2 it took something like 18 hours to reach that threshold - just to give you an impression. many thanks, hans -- Cybertec Schönig Schönig GmbH PostgreSQL Solutions and Support Gröhrmühlgasse 26, A-2700 Wiener Neustadt Tel: +43/1/205 10 35 / 340 www.postgresql-support.de, www.postgresql-support.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
