Re: [HACKERS] Renaming '2010-Next' to '2010-6' in the commitfest app
On Thu, May 20, 2010 at 12:51 AM, Selena Deckelmann selenama...@gmail.com wrote: Can we get that commitfest renamed? And if I should know how to do that, can you inform me how? I thought we agreed on 2009-07? Anyhow, you just hit Edit CommitFest. It requires admin privileges, which I have now given you. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade docs
On 05/19/2010 05:16 PM, Bruce Momjian wrote: Andres Freund wrote: On Wednesday 19 May 2010 22:39:32 Bruce Momjian wrote: There are some limitations when migrating from 8.3 to 8.4, but not when migrating from 8.3 to 9.0, because we added a feature to 9.0. Can you give a specific example? Didnt the 'name' alignment change? Uh, the heading above that item is: titleLimitations in migrating emphasisfrom/ PostgreSQL 8.3/title What is unclear there? It covers going to 8.4 and 9.0. well the wording makes it kinda unclear on what happens if you go FROM 8.4 to 9.0. If there are no known limits we might want to add a small note saying so. If there are some we might want to restructure the paragraph a bit... Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Renaming '2010-Next' to '2010-6' in the commitfest app
Robert Haas robertmh...@gmail.com writes: On Thu, May 20, 2010 at 12:51 AM, Selena Deckelmann selenama...@gmail.com wrote: Can we get that commitfest renamed? And if I should know how to do that, can you inform me how? I thought we agreed on 2009-07? Yeah, I thought the agreement was to keep the same target dates as for last year's commitfests. 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-hackers
Re: [HACKERS] Renaming '2010-Next' to '2010-6' in the commitfest app
On 05/20/2010 07:21 AM, Robert Haas wrote: On Thu, May 20, 2010 at 12:51 AM, Selena Deckelmann selenama...@gmail.com wrote: Can we get that commitfest renamed? And if I should know how to do that, can you inform me how? I thought we agreed on 2009-07? Anyhow, you just hit Edit CommitFest. It requires admin privileges, which I have now given you. s/2009/2010 ? Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Renaming '2010-Next' to '2010-6' in the commitfest app
On Thu, May 20, 2010 at 9:26 AM, Stefan Kaltenbrunner ste...@kaltenbrunner.cc wrote: On 05/20/2010 07:21 AM, Robert Haas wrote: On Thu, May 20, 2010 at 12:51 AM, Selena Deckelmann selenama...@gmail.com wrote: Can we get that commitfest renamed? And if I should know how to do that, can you inform me how? I thought we agreed on 2009-07? Anyhow, you just hit Edit CommitFest. It requires admin privileges, which I have now given you. s/2009/2010 ? Err, yeah. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Renaming '2010-Next' to '2010-6' in the commitfest app
On Thu, May 20, 2010 at 9:24 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Thu, May 20, 2010 at 12:51 AM, Selena Deckelmann selenama...@gmail.com wrote: Can we get that commitfest renamed? And if I should know how to do that, can you inform me how? I thought we agreed on 2009-07? Yeah, I thought the agreement was to keep the same target dates as for last year's commitfests. Yes! However, we were going to do a reviewfest starting June 15. Is there a way for me to specify that differently? It would be very helpful to be able to use the commitfest app for the reviewfest. -selena -- http://chesnok.com/daily - me -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Renaming '2010-Next' to '2010-6' in the commitfest app
On Thu, May 20, 2010 at 11:54 AM, Selena Deckelmann selenama...@gmail.com wrote: On Thu, May 20, 2010 at 9:24 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Thu, May 20, 2010 at 12:51 AM, Selena Deckelmann selenama...@gmail.com wrote: Can we get that commitfest renamed? And if I should know how to do that, can you inform me how? I thought we agreed on 2009-07? Yeah, I thought the agreement was to keep the same target dates as for last year's commitfests. Yes! However, we were going to do a reviewfest starting June 15. Is there a way for me to specify that differently? It would be very helpful to be able to use the commitfest app for the reviewfest. Does it need to actually be called a reviewfest there? Can't we just keep using the system like before, calling it commitfest? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Renaming '2010-Next' to '2010-6' in the commitfest app
On Thu, May 20, 2010 at 11:54 AM, Selena Deckelmann selenama...@gmail.com wrote: On Thu, May 20, 2010 at 9:24 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Thu, May 20, 2010 at 12:51 AM, Selena Deckelmann selenama...@gmail.com wrote: Can we get that commitfest renamed? And if I should know how to do that, can you inform me how? I thought we agreed on 2009-07? Yeah, I thought the agreement was to keep the same target dates as for last year's commitfests. Yes! However, we were going to do a reviewfest starting June 15. Is there a way for me to specify that differently? It would be very helpful to be able to use the commitfest app for the reviewfest. Well, if you really want to make that CommitFest 2010-06 and have a separate one called 2010-07, I guess you could. But if you do that, then you'll end up having to move all the patches from one to the next (since none of them are actually going to be committed), which sounds like extra work to me. I think it would be simpler just to manage the whole thing using 2010-07. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Renaming '2010-Next' to '2010-6' in the commitfest app
Selena Deckelmann selenama...@gmail.com writes: On Thu, May 20, 2010 at 9:24 AM, Tom Lane t...@sss.pgh.pa.us wrote: Yeah, I thought the agreement was to keep the same target dates as for last year's commitfests. Yes! However, we were going to do a reviewfest starting June 15. Is there a way for me to specify that differently? It would be very helpful to be able to use the commitfest app for the reviewfest. I think the easiest way to deal with it is just to say that we're hoping to get an early start on the commitfest by beginning reviewing early on the already-submitted patches. There's nothing stopping anyone from working on those patches in advance of the nominal commitfest start date. (Of course, we can't actually commit any of them until the 9.0 branch is made; which is why I think it's a July commitfest not a June one.) 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-hackers
[HACKERS] ExecutorCheckPerms() hook
In yesterday's development meeting, we talked about the possibility of a basic SE-PostgreSQL implementation that checks permissions only for DML. Greg Smith offered the opinion that this could provide much of the benefit of SE-PostgreSQL for many users, while being much simpler. In fact, SE-PostgreSQL would need to get control in just one place: ExecCheckRTPerms. This morning, Stephen Frost and I worked up a quick patch showing how we could add a hook here to let a hypothetical SE-PostgreSQL module get control in the relevant place. The attached patch also includes a toy contrib module showing how it could be used to enforce arbitrary security policy. I don't think that this by itself would be quite enough framework for a minimal SE-PostgreSQL implementation - for that, you'd probably need an object-labeling facility in core which SE-PostgreSQL could leverage - or else some other way to determine which the label associated with a given object - but I think that plus this would be enough. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company executor_check_perms.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Renaming '2010-Next' to '2010-6' in the commitfest app
On Thu, May 20, 2010 at 12:03 PM, Tom Lane t...@sss.pgh.pa.us wrote: Selena Deckelmann selenama...@gmail.com writes: On Thu, May 20, 2010 at 9:24 AM, Tom Lane t...@sss.pgh.pa.us wrote: Yeah, I thought the agreement was to keep the same target dates as for last year's commitfests. Yes! However, we were going to do a reviewfest starting June 15. Is there a way for me to specify that differently? It would be very helpful to be able to use the commitfest app for the reviewfest. I think the easiest way to deal with it is just to say that we're hoping to get an early start on the commitfest by beginning reviewing early on the already-submitted patches. There's nothing stopping anyone from working on those patches in advance of the nominal commitfest start date. (Of course, we can't actually commit any of them until the 9.0 branch is made; which is why I think it's a July commitfest not a June one.) Yeah, I get that. A nice feature would be to allow for reviewfests to occur and then be transitioned into a commitfest inside the application without too much trouble. My fear is that people won't be as motivated to work on patches without a clear transition between phases, but that could certainly be unfounded. I'll just do my best to set expectations among the reviewers and patch authors that nothing will be committed/looked at by committers until July. -selena -- http://chesnok.com/daily - me -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ExecutorCheckPerms() hook
Robert Haas robertmh...@gmail.com writes: In yesterday's development meeting, we talked about the possibility of a basic SE-PostgreSQL implementation that checks permissions only for DML. Greg Smith offered the opinion that this could provide much of the benefit of SE-PostgreSQL for many users, while being much simpler. In fact, SE-PostgreSQL would need to get control in just one place: ExecCheckRTPerms. This morning, Stephen Frost and I worked up a quick patch showing how we could add a hook here to let a hypothetical SE-PostgreSQL module get control in the relevant place. The attached patch also includes a toy contrib module showing how it could be used to enforce arbitrary security policy. Hm, I think you need to ignore RT entries that have no requiredPerms bits set. (Not that it matters too much, unless you were proposing to actually commit this contrib module.) 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-hackers
Re: [HACKERS] ExecutorCheckPerms() hook
On Thu, May 20, 2010 at 12:32 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: In yesterday's development meeting, we talked about the possibility of a basic SE-PostgreSQL implementation that checks permissions only for DML. Greg Smith offered the opinion that this could provide much of the benefit of SE-PostgreSQL for many users, while being much simpler. In fact, SE-PostgreSQL would need to get control in just one place: ExecCheckRTPerms. This morning, Stephen Frost and I worked up a quick patch showing how we could add a hook here to let a hypothetical SE-PostgreSQL module get control in the relevant place. The attached patch also includes a toy contrib module showing how it could be used to enforce arbitrary security policy. Hm, I think you need to ignore RT entries that have no requiredPerms bits set. (Not that it matters too much, unless you were proposing to actually commit this contrib module.) Well, that's an easy change - just out of curiosity, how do we end up with RT entries with no requiredPerm bits set? As for committing it, I would definitely like to commit the actual hook. If we want the hook without the contrib module that's OK with me, although I generally feel it's useful to have examples of how hooks can be used, which is why I took the time to produce a working example. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Fwd: PGBuildfarm member polecat Branch HEAD Status changed from StartDb-C:2 failure to StartDb-C:3 failure
And another one (different compiler): Process: postgres [48669] Path:/usr/local/src/build-farm-3.2/builds/HEAD/inst/bin/postgres Identifier: postgres Version: ??? (???) Code Type: X86-64 (Native) Parent Process: postgres [48015] Date/Time: 2010-05-19 18:06:37.908 -0600 OS Version: Mac OS X 10.6.3 (10D573) Report Version: 6 Interval Since Last Report: 397326 sec Crashes Since Last Report: 11 Per-App Crashes Since Last Report: 3 Anonymous UUID: 77053C10-A2B5-4078-A796-5862E233A1AC Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x, 0x Crashed Thread: 0 Dispatch queue: com.apple.main-thread Application Specific Information: abort() called Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x7fff88268886 __kill + 10 1 libSystem.B.dylib 0x7fff88308eae abort + 83 2 postgres0x00010039f998 errfinish + 882 3 postgres0x000100066ec2 UpdateControlFile + 286 4 postgres0x00010006bd67 CreateCheckPoint + 409 5 postgres0x00010006b779 ShutdownXLOG + 154 6 postgres0x000100244999 BackgroundWriterMain + 1022 7 postgres0x000100098fe8 AuxiliaryProcessMain + 1864 8 postgres0x00010025240a StartChildProcess + 285 9 postgres0x00010024ff0e reaper + 402 10 libSystem.B.dylib 0x7fff8827a80a _sigtramp + 26 11 libSystem.B.dylib 0x7fff8825e286 select$DARWIN_EXTSN + 10 12 postgres0x00010024e46a ServerLoop + 164 13 postgres0x00010024dc83 PostmasterMain + 4203 14 postgres0x0001001c73f8 main + 556 15 postgres0x00011324 start + 52 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x rbx: 0x rcx: 0x7fff5fbfeab8 rdx: 0x rdi: 0xbe1d rsi: 0x0006 rbp: 0x7fff5fbfead0 rsp: 0x7fff5fbfeab8 r8: 0x000101002890 r9: 0x7fff5fbfe970 r10: 0x7fff882648ca r11: 0x0202 r12: 0x r13: 0x r14: 0x r15: 0x rip: 0x7fff88268886 rfl: 0x0202 cr2: 0x52df4556 Binary Images: 0x1 -0x1005aafe7 +postgres ??? (???) FC69B957-D4BB-B3B0-1880-21EEE14A3AF9 /usr/local/src/build-farm-3.2/builds/HEAD/inst/bin/postgres 0x1007c8000 -0x1008e9fff +libxml2.2.dylib 10.7.0 (compatibility 10.0.0) CC8AA05E-419A-8855-CA51-3E988F6AF074 /opt/local/lib/libxml2.2.dylib 0x10091a000 -0x10095bfef +libssl.0.9.8.dylib 0.9.8 (compatibility 0.9.8) E95CC9C8-7EA2-49DC-8ADB-38ABB54ADCD4 /opt/local/lib/libssl.0.9.8.dylib 0x10096f000 -0x100a81ff7 +libcrypto.0.9.8.dylib 0.9.8 (compatibility 0.9.8) 869559F9-EF7E-94F5-6810-2D4B9163F7A0 /opt/local/lib/libcrypto.0.9.8.dylib 0x100ae4000 -0x100af8ff7 +libz.1.dylib 1.2.5 (compatibility 1.0.0) CED4D01F-2054-94F0-E944-962F279BC84C /opt/local/lib/libz.1.dylib 0x100afc000 -0x100bf8ff7 +libiconv.2.dylib 8.0.0 (compatibility 8.0.0) D674866F-82E0-B1ED-4A97-9B8ED4EE6C3B /opt/local/lib/libiconv.2.dylib 0x7fff5fc0 - 0x7fff5fc3bdef dyld 132.1 (???) B633F790-4DDB-53CD-7ACF-2A3682BCEA9F /usr/lib/dyld 0x7fff803aa000 - 0x7fff803abff7 com.apple.TrustEvaluationAgent 1.1 (1) 51867586-1C71-AE37-EAAD-535A58DD3550 /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent 0x7fff81525000 - 0x7fff81537fe7 libsasl2.2.dylib 3.15.0 (compatibility 3.0.0) 76B83C8D-8EFE-4467-0F75-275648AFED97 /usr/lib/libsasl2.2.dylib 0x7fff81865000 - 0x7fff8189dff7 libssl.0.9.8.dylib 0.9.8 (compatibility 0.9.8) FAB9687F-0A86-A13F-7644-CE02E71140DB /usr/lib/libssl.0.9.8.dylib 0x7fff82491000 - 0x7fff82495ff7 libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) 95718673-FEEE-B6ED-B127-BCDBDB60D4E5 /usr/lib/system/libmathCommon.A.dylib 0x7fff8491e000 - 0x7fff84a2dfe7 libcrypto.0.9.8.dylib 0.9.8 (compatibility 0.9.8) 826C2437-F760-E049-1719-9C69A3BAA4B0 /usr/lib/libcrypto.0.9.8.dylib 0x7fff8549d000 - 0x7fff854befff libresolv.9.dylib 40.0.0 (compatibility 1.0.0) 1AE68BBB-6536-125C-DE2A-13CA916D0EC4 /usr/lib/libresolv.9.dylib 0x7fff86bad000 - 0x7fff86beafff com.apple.LDAPFramework 2.0 (120.1) 16383FF5-0537-6298-73C9-473AEC9C149C /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP 0x7fff86e61000 - 0x7fff86e72ff7 libz.1.dylib 1.2.3 (compatibility 1.0.0) C1154E2E-B1CB-1FAD-77ED-B139BA1AB073
[HACKERS] Fwd: PGBuildfarm member colugos Branch HEAD Status changed from OK to StartDb-C:3 failure
If anyone is interested, I think this failure was accompanied by the following: Process: postgres [35159] Path: /usr/local/src/build-farm-3.2_llvm/builds/HEAD/inst/bin/postgres Identifier: postgres Version: ??? (???) Code Type: X86-64 (Native) Parent Process: postgres [35036] Date/Time: 2010-05-19 17:12:19.213 -0600 OS Version: Mac OS X 10.6.3 (10D573) Report Version: 6 Interval Since Last Report: 394069 sec Crashes Since Last Report: 10 Per-App Crashes Since Last Report: 2 Anonymous UUID: 77053C10-A2B5-4078-A796-5862E233A1AC Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x, 0x Crashed Thread: 0 Dispatch queue: com.apple.main-thread Application Specific Information: abort() called Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x7fff88268886 __kill + 10 1 libSystem.B.dylib 0x7fff88308eae abort + 83 2 postgres0x0001004cd513 errfinish + 1059 3 postgres0x00010008ae1e UpdateControlFile + 382 4 postgres0x000100091f93 CreateCheckPoint + 659 5 postgres0x0001000917c1 ShutdownXLOG + 193 6 postgres0x0001002fa042 BackgroundWriterMain + 1378 7 postgres0x0001000d0139 AuxiliaryProcessMain + 1993 8 postgres0x00010030c924 StartChildProcess + 356 9 postgres0x000100309ab9 reaper + 489 10 libSystem.B.dylib 0x7fff8827a80a _sigtramp + 26 11 libSystem.B.dylib 0x7fff8825e286 select$DARWIN_EXTSN + 10 12 postgres0x0001003076cc ServerLoop + 364 13 postgres0x000100306a04 PostmasterMain + 5588 14 postgres0x00010025cd0b main + 667 15 postgres0x00010da4 start + 52 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x rbx: 0x7fff5fbff0e0 rcx: 0x7fff5fbfe548 rdx: 0x rdi: 0x8957 rsi: 0x0006 rbp: 0x7fff5fbfe560 rsp: 0x7fff5fbfe548 r8: 0x000101002890 r9: 0x7fff5fbfe438 r10: 0x7fff882648ca r11: 0x0202 r12: 0x r13: 0x r14: 0x r15: 0x rip: 0x7fff88268886 rfl: 0x0202 cr2: 0x000100536050 Binary Images: 0x1 -0x1006eafef +postgres ??? (???) 20ED8627-555A-780D-6CD7-B7AACBD814EC /usr/local/src/build-farm-3.2_llvm/builds/HEAD/inst/bin/postgres 0x100917000 -0x100a38fff +libxml2.2.dylib 10.7.0 (compatibility 10.0.0) CC8AA05E-419A-8855-CA51-3E988F6AF074 /opt/local/lib/libxml2.2.dylib 0x100a69000 -0x100aaafef +libssl.0.9.8.dylib 0.9.8 (compatibility 0.9.8) E95CC9C8-7EA2-49DC-8ADB-38ABB54ADCD4 /opt/local/lib/libssl.0.9.8.dylib 0x100abe000 -0x100bd0ff7 +libcrypto.0.9.8.dylib 0.9.8 (compatibility 0.9.8) 869559F9-EF7E-94F5-6810-2D4B9163F7A0 /opt/local/lib/libcrypto.0.9.8.dylib 0x100c33000 -0x100c47ff7 +libz.1.dylib 1.2.5 (compatibility 1.0.0) CED4D01F-2054-94F0-E944-962F279BC84C /opt/local/lib/libz.1.dylib 0x100c4b000 -0x100d47ff7 +libiconv.2.dylib 8.0.0 (compatibility 8.0.0) D674866F-82E0-B1ED-4A97-9B8ED4EE6C3B /opt/local/lib/libiconv.2.dylib 0x7fff5fc0 - 0x7fff5fc3bdef dyld 132.1 (???) B633F790-4DDB-53CD-7ACF-2A3682BCEA9F /usr/lib/dyld 0x7fff803aa000 - 0x7fff803abff7 com.apple.TrustEvaluationAgent 1.1 (1) 51867586-1C71-AE37-EAAD-535A58DD3550 /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent 0x7fff81525000 - 0x7fff81537fe7 libsasl2.2.dylib 3.15.0 (compatibility 3.0.0) 76B83C8D-8EFE-4467-0F75-275648AFED97 /usr/lib/libsasl2.2.dylib 0x7fff81865000 - 0x7fff8189dff7 libssl.0.9.8.dylib 0.9.8 (compatibility 0.9.8) FAB9687F-0A86-A13F-7644-CE02E71140DB /usr/lib/libssl.0.9.8.dylib 0x7fff82491000 - 0x7fff82495ff7 libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) 95718673-FEEE-B6ED-B127-BCDBDB60D4E5 /usr/lib/system/libmathCommon.A.dylib 0x7fff8491e000 - 0x7fff84a2dfe7 libcrypto.0.9.8.dylib 0.9.8 (compatibility 0.9.8) 826C2437-F760-E049-1719-9C69A3BAA4B0 /usr/lib/libcrypto.0.9.8.dylib 0x7fff8549d000 - 0x7fff854befff libresolv.9.dylib 40.0.0 (compatibility 1.0.0) 1AE68BBB-6536-125C-DE2A-13CA916D0EC4 /usr/lib/libresolv.9.dylib 0x7fff86bad000 - 0x7fff86beafff com.apple.LDAPFramework 2.0 (120.1) 16383FF5-0537-6298-73C9-473AEC9C149C /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP 0x7fff86e61000 - 0x7fff86e72ff7 libz.1.dylib 1.2.3
[HACKERS] Snapshot Materialized Views - GSoC
First of all, I really appreciate you gave me change to participate on GSoC. It's great chance for me. For this summer I have plan to make patch inplementing snapshot materialized views (MV). I believe it will not be end of effort to implement more of MV. But I / we need discuss MV syntax and exact behaviour so I have some questions about that for all of you: a) relkind for materialized view in pg_class? - I'm voting for char 'm' quite obvious why, but not sure about alias: 1 - RELKIND_MVIEW 2 - RELKIND_MATVIEW or any other ideas? b) create MV syntax? - CREATE MATERIALIZED VIEW mvname AS ..., I think it is quite obvious to do so, but I had to ask c) refresh command syntax? 1 - ALTER MATERIALIZED VIEW mvname REFRESH or 2 - REFRESH MATERIALIZED VIEW mvname d) what to do when someone use INSERT, UPDATE or DELETE against MV? 1 - raise error? - I prefer this option 2 - let commands change MV? (no chance to let changes propagate to source tables, not for this summer :) if pg lets user to DML against MV, I expect that triggers should work too e) what to do when someone drop table or column? - it behave like it was a classic view. Fire error and hint - CASCADE option will remove MV ERROR: cannot drop table adresa because other objects depend on it DETAIL: materialized view adresa_mv depends on table adresa HINT: Use DROP ... CASCADE to drop the dependent objects too. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ExecutorCheckPerms() hook
Robert Haas robertmh...@gmail.com writes: On Thu, May 20, 2010 at 12:32 PM, Tom Lane t...@sss.pgh.pa.us wrote: Hm, I think you need to ignore RT entries that have no requiredPerms bits set. (Not that it matters too much, unless you were proposing to actually commit this contrib module.) Well, that's an easy change - just out of curiosity, how do we end up with RT entries with no requiredPerm bits set? Inheritance child tables look like that now, per the discussion awhile back that a SELECT on the parent shouldn't require any particular permission on the individual child tables. IIRC there are some other cases involving views too, but those are probably just optimizations (ie not do duplicate permissions checks) rather than something that would result in a user-visible behavioral issue. As for committing it, I would definitely like to commit the actual hook. If we want the hook without the contrib module that's OK with me, although I generally feel it's useful to have examples of how hooks can be used, which is why I took the time to produce a working example. +1 on committing the hook. As for the contrib module, it doesn't strike me that there's much of a use-case for it as is. I think it's enough that it's available in the -hackers archives. 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-hackers
Re: [HACKERS] Snapshot Materialized Views - GSoC
2010/5/20 Pavel baro...@seznam.cz: d) what to do when someone use INSERT, UPDATE or DELETE against MV? 1 - raise error? - I prefer this option +1, FWIW 2 - let commands change MV? (no chance to let changes propagate to source tables, not for this summer :) if pg lets user to DML against MV, I expect that triggers should work too no, if you don't propagate then you don't have a view of the tables the MV comes from... error if you'll not implement propagation now -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fwd: PGBuildfarm member colugos Branch HEAD Status changed from OK to StartDb-C:3 failure
Robert Creager r...@logicalchaos.org writes: If anyone is interested, I think this failure was accompanied by the following: [ apparent PANIC in UpdateControlFile ] Hmm, do you have the panic message in the postmaster log? So far as I can tell, the postmaster log isn't captured anywhere in the buildfarm report of this event. (Which seems like a buildfarm bug.) Given that polecat has already run a couple of later buildfarm iterations, I'm not too hopeful that you do have that log file. Was there any special environment here, like running out of disk space? 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-hackers
Re: [HACKERS] Clarifications of licences on pgfoundry
On 05/18/2010 01:57 AM, Simon Riggs wrote: I notice that there are more than a few projects on pgfoundry that are marked as BSD licence but then the project files don't contain any mention of the licence details. In some cases, projects are also clearly marked Copyright of people or organizations. yeah, this is due to one of many bugs with gForge. The submitter is required to choose a license on submission of a project request ... but that information is then discarded and doesn't end up in the project page. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fwd: PGBuildfarm member colugos Branch HEAD Status changed from OK to StartDb-C:3 failure
Robert Creager rob...@logicalchaos.org writes: On May 20, 2010, at 11:54 AM, Tom Lane wrote: Was there any special environment here, like running out of disk space? Not that I'm aware of. I did empty trash sometime yesterday after noticing I was around 1Gb of free disk. Not sure if that correlates or not. Maybe on failure buildfarm should could disk usage of the disk it's on and add that to the report? I'm just guessing, but it seems like a system-level condition like being out of disk space would explain concurrent similar failures for both of your animals. A quick look at UpdateControlFile shows that it definitely will PANIC if it gets any sort of failure while trying to write pg_control. It would be interesting to know what sort of failure it got, but I'm not going to (ahem) panic about it. It's annoying though that the buildfarm script didn't capture the relevant log file in this particular failure case. Andrew, can we get that fixed? 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-hackers
Re: [HACKERS] Clarifications of licences on pgfoundry
On 05/20/2010 01:58 PM, Josh Berkus wrote: On 05/18/2010 01:57 AM, Simon Riggs wrote: I notice that there are more than a few projects on pgfoundry that are marked as BSD licence but then the project files don't contain any mention of the licence details. In some cases, projects are also clearly marked Copyright of people or organizations. yeah, this is due to one of many bugs with gForge. The submitter is required to choose a license on submission of a project request ... but that information is then discarded and doesn't end up in the project page. huh? that does not make any sense at all - the licence the submitter chooses _IS_ displayed on the main overview page of the project (see for example: http://pgfoundry.org/projects/pgbouncer/). Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Clarifications of licences on pgfoundry
huh? that does not make any sense at all - the licence the submitter chooses _IS_ displayed on the main overview page of the project (see for example: http://pgfoundry.org/projects/pgbouncer/). That doesn't happen automatically -- after acceptance, the project owner needs to select a license a second time. That's why so many projects have no license. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fwd: PGBuildfarm member colugos Branch HEAD Status changed from OK to StartDb-C:3 failure
On May 20, 2010, at 11:54 AM, Tom Lane wrote: Robert Creager r...@logicalchaos.org writes: If anyone is interested, I think this failure was accompanied by the following: [ apparent PANIC in UpdateControlFile ] Hmm, do you have the panic message in the postmaster log? So far as I can tell, the postmaster log isn't captured anywhere in the buildfarm report of this event. (Which seems like a buildfarm bug.) 'Course not. Given that polecat has already run a couple of later buildfarm iterations, I'm not too hopeful that you do have that log file. Was there any special environment here, like running out of disk space? Not that I'm aware of. I did empty trash sometime yesterday after noticing I was around 1Gb of free disk. Not sure if that correlates or not. Maybe on failure buildfarm should could disk usage of the disk it's on and add that to the report? I've updated my OSX clients to keep error builds. Later, Rob -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Clarifications of licences on pgfoundry
On Thu, May 20, 2010 3:06 pm, Josh Berkus wrote: huh? that does not make any sense at all - the licence the submitter chooses _IS_ displayed on the main overview page of the project (see for example: http://pgfoundry.org/projects/pgbouncer/). That doesn't happen automatically -- after acceptance, the project owner needs to select a license a second time. That's why so many projects have no license. How to do that is far from clear. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fwd: PGBuildfarm member colugos Branch HEAD Status changed from OK to StartDb-C:3 failure
On Thu, May 20, 2010 2:12 pm, Tom Lane wrote: It's annoying though that the buildfarm script didn't capture the relevant log file in this particular failure case. Andrew, can we get that fixed? It was captured, but apparently had no new content - not surprising if it ran out of space. cheers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [RFC][PATCH]: CRC32 is limiting at COPY/CTAS/INSERT ... SELECT + speeding it up
Hi,
I started to analyze XLogInsert because it was the major bottleneck when
creating some materialized view/cached tables/whatever.
Analyzing it I could see that content of the COMP_CRC32 macro was taking most
of the time which isn't immediately obvious when you profile because it
obviously doesn't show up as a separate function.
I first put it into functions to make it easier to profile. I couldn't measure
any difference for COPY, CTAS and a simple pgbench run on 3 kinds of hardware
(Core2, older Xeon, older Sparc systems).
I looked a bit around for faster implementations of CRC32 and found one in
zlib. After adapting it (pg uses slightly different computation (non-
inverted)) I found that it increases the speed of the CRC32 calculation itself
3 fold.
It does that by not only using one lookup table but four (one for each byte of
a word). Those four calculations are independent and thus are considerably
faster on somewhat recent hardware.
Also it does memory lookups in 4 byte steps instead of 1 byte as the pg
version (thats only about ~8% benefit in itself).
I wrote a preliminary patch which includes both, the original implementation
and the new one switchable via an #define.
I tested performance differences in a small number of scenarios:
- CTAS/INSERT ... SELECT (8-30%)
- COPY (3-20%)
- pgbench (no real difference unless directly after a checkpoint)
Setup:
CREATE TABLE blub (ai int, bi int, aibi int);
CREATE TABLE speedtest (ai int, bi int, aibi int);
INSERT ... SELECT:
Statement:
INSERT INTO blub SELECT a.i, b.i, a.i *b.i FROM generate_series(1, 1)
a(i), generate_series(1, 1000) b(i);
legacy crc:
11526.588
11406.518
11412.182
11430.245
zlib:
9977.394
9945.408
9840.907
9842.875
COPY:
Statement:
('blub' enlarged here 4 times, as otherwise the variances were to large)
COPY blub TO '/tmp/b' BINARY;
...
CHECKPOINT;TRUNCATE speedtest; COPY speedtest FROM '/tmp/b' BINARY;
legacy:
44835.840
44832.876
zlib:
39530.549
39365.109
39295.167
The performance differences are bigger if the table rows are significantly
bigger.
Do you think something like that is sensible? If yes, I will make it into a
proper patch and such.
Thanks,
Andres
INSERT ... SELECT profile before patch:
20.22% postgres postgres [.] comp_crc32
5.77% postgres postgres [.] XLogInsert
5.55% postgres postgres [.] LWLockAcquire
5.21% postgres [kernel. [k] copy_user_generic_string
4.64% postgres postgres [.] LWLockRelease
4.39% postgres postgres [.] ReadBuffer_common
2.75% postgres postgres [.] heap_insert
2.22% postgres libc-2.1 [.] memcpy
2.09% postgres postgres [.] UnlockReleaseBuffer
1.85% postgres postgres [.] hash_any
1.77% postgres [kernel. [k] clear_page_c
1.69% postgres postgres [.] hash_search_with_hash_value
1.61% postgres postgres [.] heapgettup_pagemode
1.50% postgres postgres [.] PageAddItem
1.42% postgres postgres [.] MarkBufferDirty
1.28% postgres postgres [.] RelationGetBufferForTuple
1.15% postgres postgres [.] ExecModifyTable
1.06% postgres postgres [.] RelationPutHeapTuple
After:
9.97% postgres postgres [.] comp_crc32
5.95% postgres [kernel. [k] copy_user_generic_string
5.94% postgres postgres [.] LWLockAcquire
5.64% postgres postgres [.] XLogInsert
5.11% postgres postgres [.] LWLockRelease
4.63% postgres postgres [.] ReadBuffer_common
3.45% postgres postgres [.] heap_insert
2.54% postgres libc-2.1 [.] memcpy
2.03% postgres postgres [.] UnlockReleaseBuffer
1.94% postgres postgres [.] hash_search_with_hash_value
1.84% postgres postgres [.] hash_any
1.73% postgres [kernel. [k] clear_page_c
1.68% postgres postgres [.] PageAddItem
1.62% postgres postgres [.] heapgettup_pagemode
1.52% postgres postgres [.] RelationGetBufferForTuple
1.47% postgres postgres [.] MarkBufferDirty
1.30% postgres postgres [.] ExecModifyTable
1.23% postgres postgres [.] RelationPutHeapTuple
From f8ec18769e581cf039535730d2088466c461d8f6 Mon Sep 17 00:00:00 2001
From: Andres Freund and...@anarazel.de
Date: Thu, 29 Apr 2010 22:19:08 +0200
Subject: [PATCH] Preliminary patch using an improved out of line crc32 computation for
the xlog.
---
src/backend/access/transam/xlog.c | 66 +-
src/backend/utils/hash/pg_crc.c | 142 -
src/include/utils/pg_crc.h|9 ++-
3 files changed, 180 insertions(+), 37 deletions(-)
diff --git a/src/backend/access/transam/xlog.c
[HACKERS] ERROR: GIN indexes do not support whole-index scans
Could anyone advise as to how to avoid this error? I'll describe the table
and query below.
The database contains a table 'tinytm_segments', which has two text columns,
'source_text' and 'target_text'. These are used to store sentences and their
translations. The language of the text is specified with typical
two-character identifiers ('en', 'fr' etc.) stored in two further columns,
'source_lang_code' and 'target_lang_code'. Translation in either direction
can be stored, so for a given row, source_text may contain English and
target_text French (with the corresponding values in source_lang_code and
target_lang_code), or the other way round.
The application needs to search for (say) French sentences containing a
given substring and retrieve any English translation found (or whatever
other language combination and direction). To perform better with large
datasets, full text indices are defined, such as these:
-- Index English text
CREATE INDEX tu_target_text_en_idx ON tinytm_segments USING
gin(to_tsvector('english', target_text)) where target_lang_code = 'en';
CREATE INDEX tu_source_text_en_idx ON tinytm_segments USING
gin(to_tsvector('english', source_text)) where source_lang_code = 'en';
-- Index French text
CREATE INDEX tu_source_text_fr_idx ON tinytm_segments USING
gin(to_tsvector('french', source_text)) where source_lang_code = 'fr';
CREATE INDEX tu_target_text_fr_idx ON tinytm_segments USING
gin(to_tsvector('french', target_text)) where target_lang_code = 'fr';
To retrieve (say) sentences that have been translated from French, where the
French contains a given substring, a query like this can then be issued:
SELECT * FROM tinytm_segments WHERE
source_lang_code='fr' AND
to_tsvector('french', source_text) @@ plainto_tsquery('french', 'rien du
tout') AND lower(source_text) LIKE '%rien du tout%'
However, that will return sentences translated into whatever language. The
error occurs when trying to retrieve only sentences translated from French
into English, using a query like this:
SELECT * FROM tinytm_segments WHERE
source_lang_code='fr' AND
to_tsvector('french', source_text) @@ plainto_tsquery('french', 'rien du
tout') AND lower(source_text) LIKE '%rien du tout%'
AND target_lang_code='en'
Why would adding target_lang_code='en' cause this error?
Environment: PostgreSQL 8.4 on Windows (installed with one-click installer),
default text search config used.
Thanks in advance for any information.
Kevin.
Re: [HACKERS] [RFC][PATCH]: CRC32 is limiting at COPY/CTAS/INSERT ... SELECT + speeding it up
Andres, * Andres Freund (and...@anarazel.de) wrote: Statement: INSERT INTO blub SELECT a.i, b.i, a.i *b.i FROM generate_series(1, 1) a(i), generate_series(1, 1000) b(i); legacy crc: zlib: Is this legacy crc using the function-based calls, or the macro? Do you have statistics for the zlib approach vs unmodified PG? Do you think something like that is sensible? If yes, I will make it into a proper patch and such. I think that in general we're typically looking for ways to improve performance, yes.. :) Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [RFC][PATCH]: CRC32 is limiting at COPY/CTAS/INSERT ... SELECT + speeding it up
Hi Stephen, On Thursday 20 May 2010 22:39:26 Stephen Frost wrote: * Andres Freund (and...@anarazel.de) wrote: Statement: INSERT INTO blub SELECT a.i, b.i, a.i *b.i FROM generate_series(1, 1) a(i), generate_series(1, 1000) b(i); legacy crc: Is this legacy crc using the function-based calls, or the macro? Do you have statistics for the zlib approach vs unmodified PG? 'legacy' is out of line as well. I couldn't find a real performance difference above noise between out of line (function) and inline (macro). If anything out of line was a bit faster (instruction cache usage could cause that). So vanilla-zlib should be the same as legacy-zlib Greetings, Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unexpected data beyond EOF during heavy writes
Hello everyone, We are seeing the following error message occasionally in the postgres logs: 2010-05-13 23:49:03 PDT ERROR: unexpected data beyond EOF in block 4106698 of relation custom_discoveryprofile 2010-05-13 23:49:03 PDT HINT: This has been seen to occur with buggy kernels; consider updating your system. What's your storage? -- It is NetApp storage - a FAS3070 running Data ONTAP 7.3.2 Here are the mount options server:/vol/sw on /x/eng/sw type nfs (rw,intr,hard,rsize=32768,wsize=32768,nfsvers=3,timeo=600,tcp,nointr,addr=xx.xx. xx.xx) Thanks, Tony Sullivan
Re: [HACKERS] ERROR: GIN indexes do not support whole-index scans
Kevin Flanagan kevi...@linkprior.com writes: Why would adding target_lang_code='en' cause this error? Hard to tell without seeing the index definitions for this table. Also could we see the EXPLAIN plans for both queries? (If possible ... I'm not sure whether you'd get this error just from EXPLAINing the problem query.) Environment: PostgreSQL 8.4 on Windows (installed with one-click installer), 8.4.what-exactly? 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-hackers
Re: [HACKERS] Unexpected data beyond EOF during heavy writes
Excerpts from Tony Sullivan's message of jue may 20 16:54:17 -0400 2010: Hello everyone, We are seeing the following error message occasionally in the postgres logs: 2010-05-13 23:49:03 PDT ERROR: unexpected data beyond EOF in block 4106698 of relation custom_discoveryprofile 2010-05-13 23:49:03 PDT HINT: This has been seen to occur with buggy kernels; consider updating your system. What's your storage? This was added here http://archives.postgresql.org/message-id/20060925220110.76b6a9fb...@postgresql.org in response to these two: http://thread.gmane.org/gmane.comp.db.postgresql.admin/18807 http://thread.gmane.org/gmane.comp.db.postgresql.general/74532 We (at Command Prompt) researched this recently for another setup and the common point you both have is NetApp. I then wondered about a bug in NetApp driver or NFS client implementation. -- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] Postgres stats collector showing high disk I/O
Excerpts from Justin Pasher's message of jue may 20 16:10:53 -0400 2010: Whenever I clear out the stats for all of the databases, the file shrinks down to 1MB. However, it only takes about a day for it to get back up to ~18MB and then the stats collector process start the heavy disk writing again. I do know there are some tables in the database that are filled and emptied quite a bit (they are used as temporary queue tables). The code will VACUUM FULL ANALYZE after the table is emptied to get the physical size back down and update the (empty) stats. A plain ANALYZE is also run right after the table is filled but before it starts processing, so the planner will have good stats on the contents of the table. Would this lead to pg_stat file bloat like I'm seeing? Would a CLUSTER then ANALYZE instead of a VACUUM FULL ANALYZE make any difference? The VACUUM FULL code was setup quite a while back before the coders knew about CLUSTER. I wonder if we should make pgstats write one file per database (plus one for shared objects), instead of keeping everything in a single file. That would reduce the need for reading and writing so much. -- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unexpected data beyond EOF during heavy writes
On Thu, May 20, 2010 at 3:19 PM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote: We (at Command Prompt) researched this recently for another setup and the common point you both have is NetApp. I then wondered about a bug in NetApp driver or NFS client implementation. It's definitely not (just) NetApp, though it may be their NFS -- or NFS in general; I couldn't say. I can't speak to their NFS implementation, beyond having generally heard good things about it, but I've run PostgreSQL on filers for years, and have never seen that message. Granted, I've only been iSCSI- or fibre-attached (or had the storage path abstracted away by some form of virtualization), so I haven't seen every possible use-case. In general, though, I'd be pretty wary of running postgres on an NFS mount. I know a lot of people run Oracle that way, but at the filesystem level, there are some vast differences between the two. Has anyone ever seen this message on non-NetApp NFS? rls -- :wq -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] Postgres stats collector showing high disk I/O
Alvaro Herrera alvhe...@alvh.no-ip.org writes: Excerpts from Justin Pasher's message of jue may 20 16:10:53 -0400 2010: Whenever I clear out the stats for all of the databases, the file shrinks down to 1MB. However, it only takes about a day for it to get back up to ~18MB and then the stats collector process start the heavy disk writing again. I wonder if we should make pgstats write one file per database (plus one for shared objects), instead of keeping everything in a single file. That would reduce the need for reading and writing so much. Well, the real problem here is the OP is running 8.1, so he isn't getting the benefit of any of the subsequent changes to reduce the stats file I/O. I suspect the bloat also comes from a subsequently-fixed bug, but not totally sure about that yet. 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-hackers
Re: [HACKERS] Unexpected data beyond EOF during heavy writes
Rosser Schwarz rosser.schw...@gmail.com writes: Has anyone ever seen this message on non-NetApp NFS? It's been seen on non-NFS storage: http://archives.postgresql.org/pgsql-admin/2006-09/msg00096.php I don't believe we implicated NFS in the other original report, either. However, it's certainly possible that there's a similar bug in the NFS stack too on some platforms. 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-hackers
Re: [HACKERS] ecmascript 5 DATESTYLE
On May 19, 2010, at 4:31 AM, Mike Fowler wrote: Pavel Stehule wrote: 2010/5/19 Peter Eisentraut pete...@gmx.net: On tis, 2010-05-18 at 18:26 -0400, Ben Hockey wrote: ecmascript 5 is the most recent specification for JavaScript and i would think that having a DATESTYLE format to simplify interoperability with JavaScript applications would be highly desirable. Note that we haven't got any other datestyles that are intended to support interoperability with some language. It is usually the job of the client driver to convert PostgreSQL data (plural of datum) to the appropriate type and format for the client environment or language. Is there any reason why JavaScript would be different? I wouldn't be keen to see dedicated language specific handling of date/datetime formats. It would lead to an explosion of functions with new languages needing adding as and when their users jumped up and down on us. However a generic format could be very useful and would give the opportunity for people who need a language specific short cut the opportunity to do a CREATE FUNCTION wrapping the generic one with a hard coded format specifier. Other platforms have generic support for this kind of task, for example SQLServer: http://msdn.microsoft.com/en-us/library/ms187928.aspx . I wouldn't recommend the SQLServer way, I think numeric format specifiers are clumsy. Perhaps a mechanism like Java which is nicely summarized here: http://java.sun.com/j2se/1.5.0/docs/api/java/text/SimpleDateFormat.html i think that http://unicode.org/reports/tr35/#Date_Format_Patterns is very similar to (maybe the same as) the java simple date format but the unicode link gives a more complete explanation of exactly how the formatters will be interpreted - ie y will represent the full representation of the year but yy will represent the 2 digit form of the year, etc.. just thought i'd share the reference since it provides a powerful way to generically specify date formats and is possibly something that many people might already be familiar with. thanks for looking into adding this feature. custom formats for parsing and formatting of dates would certainly be the better option if it can be done securely. thanks, ben.. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Row-level Locks SERIALIZABLE transactions, postgres vs. Oracle
On May 19, 2010, at 2:15 , Florian Pflug wrote: On May 17, 2010, at 3:30 , Robert Haas wrote: On Sun, May 16, 2010 at 9:07 PM, Florian Pflug f...@phlo.org wrote: On May 14, 2010, at 22:54 , Robert Haas wrote: On Thu, May 13, 2010 at 5:39 PM, Tom Lane t...@sss.pgh.pa.us wrote: Florian Pflug f...@phlo.org writes: All in all, I believe that SHARE and UPDATE row-level locks should be changed to cause concurrent UPDATEs to fail with a serialization error. I don't see an argument for doing that for FOR SHARE locks, and it already happens for FOR UPDATE (at least if the row actually gets updated). AFAICS this proposal mainly breaks things, in pursuit of an unnecessary and probably-impossible-anyway goal of making FK locking work with only user-level snapshots. After giving this considerable thought and testing the behavior at some length, I think the OP has it right. One thing I sometimes need to do is denormalize a copy of a field, e.g. snipped example I've whipped up a quick and still rather dirty patch that implements the behavior I proposed, at least for the case of conflicts between FOR UPDATE locks and updates. With the patch, any attempt to UPDATE or FOR UPDATE lock a row that has concurrently been FOR UPDATE locked will cause a serialization error. (The same for an actually updated row of course, but that happened before too). While this part of the patch was fairly straight forward, make FOR SHARE conflict too seems to be much harder. The assumption that a lock becomes irrelevant after the transaction(s) that held it completely is built deeply into the multi xact machinery that powers SHARE locks. That machinery therefore assumes that once all members of a multi xact have completed the multi xact is dead also. But my proposal depends on a SERIALIZABLE transaction being able to find if any of the lockers of a row are invisible under it's snapshot - for which it'd need any multi xact containing invisible xids to outlive its snapshot. Thanks for putting this together. I suggest adding it to the open CommitFest - even if we decide to go forward with this, I don't imagine anyone is going to be excited about changing it during beta. https://commitfest.postgresql.org/action/commitfest_view/open Will do. Thanks for the link. Here is an updated version that works for SHARE locks too. Forgetting to run make check before sending a patch is bad, as I just proved :-( For the archives' and the commitfest app's sake, here is a version that actually passes the regression tests. To make up for it, I also did some testing with a custom pgbench script schema and proved the effectiveness of this patch. I ran this with pgbench -s 10 -j 10 -c 10 -t 1000 -n -f fkbench.pgbench on both HEAD and HEAD+patch. The former errors out quickly with database inconsistent while the later completes the pgbench run without errors. The patch still needs more work, at least on the comments documentation side of things, but I'm going to let this rest now while we're in beta. Patch, pgbench script and schema attached. serializable_lock_consistency.patch Description: Binary data fkbench.init.sql Description: Binary data fkbench.pgbench Description: Binary data best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ecmascript 5 DATESTYLE
On Thu, May 20, 2010 at 9:25 PM, Ben Hockey neonstalw...@gmail.com wrote: thanks for looking into adding this feature. custom formats for parsing and formatting of dates would certainly be the better option if it can be done securely. Well, Pavel expressed a concern about SQL injection, but I can't see why that would be a problem. If having multiple date formats is insecure, then we are already insecure. If it's not, then I don't see why having user-definable formats would be any more insecure than having formats from a fixed list. In any case, I can't see the connection to SQL injection - it seems like the worst case scenario is that some client gets confused about what the date format is and some dates get misinterpreted. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC][PATCH]: CRC32 is limiting at COPY/CTAS/INSERT ... SELECT + speeding it up
On Thu, May 20, 2010 at 4:27 PM, Andres Freund and...@anarazel.de wrote: I looked a bit around for faster implementations of CRC32 and found one in zlib. After adapting it (pg uses slightly different computation (non- inverted)) I found that it increases the speed of the CRC32 calculation itself 3 fold. But zlib is not under the PostgreSQL license. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Why SELECT keyword on parser is written as SELECTME ?
All, I was trying to implement some database language into PostgreSQL. Let's say an SQL command that using local language as it's command. I know it's not standard, but it's not the issue for me. I made a lot modification in scan.l and gram.y and related file in parser (src/backend/parser). So far my modified code was compiled well, and PostgreSQL can run normaly, of course without ability to use SQL command to Database, but it can check validty of SQL command structure. After i modified the parser, compile and running PostgreSQL. My modified PostgreSQL, identified select keyword as invalid keyword but selectme keyword is valid. Using unmodified PostgreSQL, select keyword was valid but selectme keyword was invalid. I just wonder why select keyword token in PostgreSQL is identified as selectme (at src/backend/parser/keywords.c)? Whats it's the different between select and selectme ? Thank You. -- Mohammad Heykal Abdillah heykal.abdil...@gmail.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why SELECT keyword on parser is written as SELECTME ?
On Thu, May 20, 2010 at 11:41 PM, Mohammad Heykal Abdillah heykal.abdil...@gmail.com wrote: I just wonder why select keyword token in PostgreSQL is identified as selectme (at src/backend/parser/keywords.c)? Whats it's the different between select and selectme ? The string selectme doesn't appear anywhere in my copy of the PostgreSQL source code, with any capitalization, or in any previous version of keywords.c, in any capitalization. I think this must be something you changed in your copy. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why SELECT keyword on parser is written as SELECTME ?
On Kam, 2010-05-20 at 23:50 -0400, Robert Haas wrote: The string selectme doesn't appear anywhere in my copy of the PostgreSQL source code, with any capitalization, or in any previous version of keywords.c, in any capitalization. I think this must be something you changed in your copy. Ah, you right!! Sorry for my mistake, after download new version and my version (8.3.7) again. There is no selectme keyword. It's seem in my previous copy i have made modification but i forgot to take note, since it never failed when compile. Once again, thank you. -- Mohammad Heykal Abdillah heykal.abdil...@gmail.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC][PATCH]: CRC32 is limiting at COPY/CTAS/INSERT ... SELECT + speeding it up
On Friday 21 May 2010 05:40:03 Robert Haas wrote: On Thu, May 20, 2010 at 4:27 PM, Andres Freund and...@anarazel.de wrote: I looked a bit around for faster implementations of CRC32 and found one in zlib. After adapting it (pg uses slightly different computation (non- inverted)) I found that it increases the speed of the CRC32 calculation itself 3 fold. But zlib is not under the PostgreSQL license. Yes. But: 1. the zlib license shouldn't be a problem in itself - pg_dump also already links to zlib 2. I planned to ask Mark Adler whether he would support relicising those bits. I have read some other discussions where he was supportive of doing such a thing 3. Given that idea was posted publically on the usenet it is not hard to produce an independent implementation. So I do not see any big problems there... Or am I missing something? Greetings, Andres /* zlib.h -- interface of the 'zlib' general purpose compression library version 1.2.2, October 3rd, 2004 Copyright (C) 1995-2004 Jean-loup Gailly and Mark Adler This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. Jean-loup Gailly jl...@gzip.org Mark Adler mad...@alumni.caltech.edu */ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
