Re: [HACKERS] Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Lamar Owen writes: > In the environment of the general purpose OS upgrade, the RPM's > installation scripts cannot fire up a backend, nor can it assume one > is running or is not running, nor can the RPM installation scripts > fathom from the run-time environment whether they are being run from a > command line or from the OS upgrade (except on Linux Mandrake, which > allows such usage). I don't understand why this is so. It seems perfectly possible that some %preremovebeforeupdate starts a postmaster, runs pg_dumpall, saves the file somewhere, then the %postinstallafterupdate runs the inverse operation. Disk space is not a valid objection, you'll never get away without 2x storage. Security is not a problem either. Are you not upgrading in proper dependency order or what? Everybody does dump, remove, install, undump; so can the RPMs. Okay, so it's not as great as a new KDE starting up and asking "may I update your configuration files?", but understand that the storage format is optimized for performance, not easy processing by external tools or something like that. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] LIMIT in DECLARE CURSOR: request for comments
Tom Lane writes: > 1. If DECLARE CURSOR does not contain a LIMIT, continue to plan on the > basis of 10%-or-so fetch I'd say that normally you're not using cursors because you intend to throw away 80% or 90% of the result set, but instead you're using it because it's convenient in your programming environment (e.g., ecpg). There are other ways of getting only some rows, this is not it. So I think if you want to make optimization decisions based on cursors being used versus a "normal" select, then the only thing you can safely take into account is the network roundtrip and client processing per fetch, but that might be as random as anything. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Current CVS broken?
Peter Mount writes: > Did that, and it still doesn't substitute @abs_top_srcdir@ Hmm, if you have "configure" revision 1.74 then you should certainly get something for @abs_top_srcdir@. Try to remove config.cache and re-run configure by hand. Most odd... -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Data definition for aclitem Datatype
Luis Magaña writes: > What is the data definition for the aclitem datatype, I'm not able to found it >in the sources, I know is there but I was not able to find it. Thank you. src/backend/utils/adt/acl.c Don't use it though, it's slated to disappear soon. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Re: BIT/BIT VARYING status
Adriaan Joubert writes: > > 2. We don't handle and literals correctly; > > the scanner converts them into integers which seems quite at variance > > with the spec's semantics. > > This is still a problem that needs to be fixed. I have gotten the B'1001'-style syntax to work, but the zpbit_in function rejects the input. You need to change the *_in functions to accept input in the form of a string of only 1's and 0's. Also, the output functions should print 1's and 0's. I'm somewhat confused about the s; according to the standard they might also be a BLOB literal. I'd say we get the binary version working first, and then wonder about this. > Also, it the parser did not seem to be too happy about the 'position' > syntax, The parser converted 'position(a in b)' into 'strpos(b, a)'. I changed it so it converts it into 'position(b, a)' and aliased the other functions appropriately. I changed the order of your arguments for that. > I noticed that the substring syntax does not seem to work: Similar issue as above. Should work now. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] LIMIT in DECLARE CURSOR: request for comments
At 10:51 31/10/00 +0100, Peter Eisentraut wrote: >Tom Lane writes: > >> 1. If DECLARE CURSOR does not contain a LIMIT, continue to plan on the >> basis of 10%-or-so fetch > >I'd say that normally you're not using cursors because you intend to throw >away 80% or 90% of the result set, but instead you're using it because >it's convenient in your programming environment (e.g., ecpg). There are >other ways of getting only some rows, this is not it. Yes! >So I think if you want to make optimization decisions based on cursors >being used versus a "normal" select, then the only thing you can safely >take into account is the network roundtrip and client processing per >fetch, but that might be as random as anything. Which is why I like the client being able to ask the optimizer for certain kinds of solutions *explicitly*. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] Re: BIT/BIT VARYING status
Peter Eisentraut wrote: > > Adriaan Joubert writes: > > > > 2. We don't handle and literals correctly; > > > the scanner converts them into integers which seems quite at variance > > > with the spec's semantics. > > > > This is still a problem that needs to be fixed. > > I have gotten the B'1001'-style syntax to work, but the zpbit_in function > rejects the input. You need to change the *_in functions to accept input > in the form of a string of only 1's and 0's. Also, the output functions > should print 1's and 0's. > > I'm somewhat confused about the s; according to the standard > they might also be a BLOB literal. I'd say we get the binary version > working first, and then wonder about this. Peter, I think it is a problem if the B or X are dropped from the input, as that is the only way to determine whether it is a binary or hex string. Isn't it possible to just remove the quotes, or even do nothing? The current code expects a string of the form Bx or Xy. If the quotes are left in, I can easily modify the code, but guessing whether the string 1001 is hex or binary is an issue, and I seem to recall that the SQL standard requires both to be valid input. Also, on output, shouldn't we poduce B'' and X'y' to conform with the input strings? Adriaan
AW: [HACKERS] LIMIT in DECLARE CURSOR: request for comments
> >So I think if you want to make optimization decisions based on cursors > >being used versus a "normal" select, then the only thing you can safely > >take into account is the network roundtrip and client processing per > >fetch, but that might be as random as anything. > > Which is why I like the client being able to ask the > optimizer for certain kinds of solutions *explicitly*. Yes, something like: set optimization to [first_rows|all_rows] Andreas
Re: AW: [HACKERS] LIMIT in DECLARE CURSOR: request for comments
At 14:14 31/10/00 +0100, Zeugswetter Andreas SB wrote: >> >> Which is why I like the client being able to ask the >> optimizer for certain kinds of solutions *explicitly*. > >Yes, something like: > set optimization to [first_rows|all_rows] > That's one way that is usefull for affecting all subsequent statements, but it would be nice to also allow such things in each statement, eg. in comments: /*++optimizer: fast_start, no_seq_scan */ select... ie. make all settable values dynamically settable in a statement. The scope of the settings would probably have to depend on the abilities of the optimizer - eg. how would subselects and views be handled? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] Re: BIT/BIT VARYING status
Adriaan Joubert writes:
> Peter, I think it is a problem if the B or X are dropped from the input,
> as that is the only way to determine whether it is a binary or hex
> string.
Well, you just assume it's a binary string, because it's unclear as of yet
whether you're going to get to handle hex strings at all. However, I
changed the scanner to include a leading 'b', so now it works:
peter=# select B'1001';
?column?
--
X9
(1 row)
peter=# select B'1001' | b'11';
?column?
--
XC
(1 row)
The output definitely ought to be in binary though ("b1001").
You also might want to make the leading 'b' optional because this seems
confusing:
peter=# select cast ('1001' as bit);
ERROR: zpbit_in: 1001 is not a valid bitstring
> Also, on output, shouldn't we poduce B'' and X'y' to conform
> with the input strings?
If you did that, then your input function has to be prepared for values
like "B'1001'". (Think copy out/copy in.) I think the above plan should
work okay.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] Problem with 2 avcuums in parallel
Hello, there's really wierd trouble. When I run 2 vacuum's in parallel they hangs. Both. I use PostgreSQL from 7.0.x CVS (almost 7.0.3). Any ideas? Tom? -- Sincerely Yours, Denis Perchine -- E-Mail: [EMAIL PROTECTED] HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 --
Re: [HACKERS] Re: BIT/BIT VARYING status
Thanks Peter. I will download tomorrow when the new snapshot is
available. So how do we find out whether hex needs to be supported? I
see what you mean with ('1001' as bit), but shouldn't that be (B'1001'
as bit)? Certainly if hex values are allowed the first version is
ambiguous. I would have to make the error message a bit more sensible
though.
Adriaan
>
> > Peter, I think it is a problem if the B or X are dropped from the input,
> > as that is the only way to determine whether it is a binary or hex
> > string.
>
> Well, you just assume it's a binary string, because it's unclear as of yet
> whether you're going to get to handle hex strings at all. However, I
> changed the scanner to include a leading 'b', so now it works:
>
> peter=# select B'1001';
> ?column?
> --
> X9
> (1 row)
>
> peter=# select B'1001' | b'11';
> ?column?
> --
> XC
> (1 row)
>
> The output definitely ought to be in binary though ("b1001").
>
> You also might want to make the leading 'b' optional because this seems
> confusing:
>
> peter=# select cast ('1001' as bit);
> ERROR: zpbit_in: 1001 is not a valid bitstring
>
> > Also, on output, shouldn't we poduce B'' and X'y' to conform
> > with the input strings?
>
> If you did that, then your input function has to be prepared for values
> like "B'1001'". (Think copy out/copy in.) I think the above plan should
> work okay.
>
> --
> Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Data definition for aclitem Datatype
Hi: I'm wrinting a graphical interface that would manage users, groups and permissions on a postgresql database, that was the reason for me to ask for this datatype since it is in the pg_class table. If it is going to dissapear soon then what should I do ?, is there any other form to handle permissions rather than aclitem datatype ?. Thanks for your answer. Sincerely. -- Luis Magaña Gnovus Networks & Software www.gnovus.com Tel. +52 (7) 4422425 [EMAIL PROTECTED] Original message from: Peter Eisentraut >Luis Magaña writes: > >> What is the data definition for the aclitem datatype, I'm not able to found it >in the sources, I know is there but I was not able to find it. Thank you. > >src/backend/utils/adt/acl.c > >Don't use it though, it's slated to disappear soon. > >-- >Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ > >
[HACKERS] 7.0.2 crash (maybe linux kernel bug??)
Hi. Ive had a crash in postgresql 7.0.2. Looking at what happened, I actually suspect that this is a filesystem bug, and not a postgresql bug necessarily, but I wanted to report it here and see if anyone else had any opinions. The platform this happened on was linux (redhat 6.2), kernel 2.2.16 (SMP) dual pentium III 500MHz cpus, Mylex DAC960 raid controller running in raid5 mode. During regular activity, I got a kernel oops. Looking at the call trace from the kernel, as well as the EIP, I think maybe there is a bug here int the fs buffer code, and that htis is a linux kernel problem (not a postgresql problem). Bug I'm no expert here.. Does this sould correct looking at the kernel erros below? Sorry if this is off topic. I just want to make sure this is a kernel bug and not a postgresql bug. Mike The oopses: kernel: Unable to handle kernel NULL pointer dereference at virtual address 0134 kernel: current->tss.cr3 = 1a325000, %%cr3 = 1a325000 kernel: *pde = kernel: Oops: 0002 kernel: CPU:0 kernel: EIP:0010:[remove_from_queues+169/328] kernel: EFLAGS: 00010206 kernel: eax: 0100 ebx: 0002 ecx: df022e40 edx: efba76b8 kernel: esi: df022e40 edi: ebp: esp: da327ea4 kernel: ds: 0018 es: 0018 ss: 0018 kernel: Process postmaster (pid: 11527, process nr: 51, stackpage=da327000) kernel: Stack: df022e40 c012be79 df022e40 df022e40 1000 c0142cb8 c0142cc7 df022e40 kernel:ec247140 ffea ec0b026c da326000 df022e40 df022e40 df022e40 000a4000 kernel: da327f08 eff29200 1000 00a5 000a5000 kernel: Call Trace: [refile_buffer+77/184] [ext2_file_write+996/1584] [ext2_file_write+1011/1584] [kfree_skbmem+51/64] [__kfree_skb+162/168] [lockd:__insmod_lockd_O/lib/modules/2.2.16-3smp/fs/lockd.o_M394EA7+-76392/76] [handle_IRQ_event+90/140] kernel:[sys_write+240/292] [ext2_file_write+0/1584] [system_call+52/56] [startup_32+43/164] kernel: Code: 89 50 34 c7 01 00 00 00 00 89 02 c7 41 34 00 00 00 00 ff 0d kernel: Unable to handle kernel NULL pointer dereference at virtual address 0100 kernel: current->tss.cr3 = 1ba46000, %%cr3 = 1ba46000 kernel: *pde = kernel: Oops: kernel: CPU:1 kernel: EIP:0010:[find_buffer+104/144] kernel: EFLAGS: 00010206 kernel: eax: 0100 ebx: 0007 ecx: 00069dae edx: 0100 kernel: esi: 000d edi: 3006 ebp: 0005ce4b esp: e53a19f4 kernel: ds: 0018 es: 0018 ss: 0018 kernel: Process postmaster (pid: 5545, process nr: 37, stackpage=e53a1000) kernel: Stack: 0005ce4b 3006 00069dae c012b953 3006 0005ce4b 1000 c012bcc6 kernel:3006 0005ce4b 1000 3006 eff29200 3006 4e4b ef18c960 kernel:c0141ee7 3006 0005ce4b 1000 0005ce4b e53a1bb0 edc3c660 edc3c660 kernel: Call Trace: [get_hash_table+23/36] [getblk+30/324] [ext2_new_block+2291/2756] [getblk+271/324] [ext2_alloc_block+344/356] [block_getblk+305/624] [ext2_getblk+256/524] kernel:[ext2_file_write+1308/1584] [__brelse+19/84] [permission+36/248] [dump_seek+53/104] [dump_seek+53/104] [dump_write+48/84] [elf_core_dump+3104/3216] [do_IRQ+82/92] kernel:[tcp_write_xmit+407/472] [__release_sock+36/124] [tcp_do_sendmsg+2125/2144] [inet_sendmsg+0/144] [cprt+1553/20096] [cprt+1553/20096] [cprt+1553/20096] [do_signal+458/724] kernel:[force_sig_info+168/180] [force_sig+17/24] [do_general_protection+54/160] [error_code+45/52] [signal_return+20/24] kernel: Code: 8b 00 39 6a 04 75 15 8b 4c 24 20 39 4a 08 75 0c 66 39 7a 0c
Re: [HACKERS] 7.0.2 crash (maybe linux kernel bug??)
* Michael J Schout <[EMAIL PROTECTED]> [001031 11:22] wrote: > Hi. > > Ive had a crash in postgresql 7.0.2. Looking at what happened, I actually > suspect that this is a filesystem bug, and not a postgresql bug necessarily, > but I wanted to report it here and see if anyone else had any opinions. > > The platform this happened on was linux (redhat 6.2), kernel 2.2.16 (SMP) dual > pentium III 500MHz cpus, Mylex DAC960 raid controller running in raid5 mode. > > During regular activity, I got a kernel oops. Looking at the call trace from > the kernel, as well as the EIP, I think maybe there is a bug here int the fs > buffer code, and that htis is a linux kernel problem (not a postgresql > problem). > > Bug I'm no expert here.. Does this sould correct looking at the kernel erros > below? > > Sorry if this is off topic. I just want to make sure this is a kernel bug and > not a postgresql bug. > > Mike > > The oopses: > > kernel: Unable to handle kernel NULL pointer dereference at virtual address 0134 > kernel: current->tss.cr3 = 1a325000, %%cr3 = 1a325000 > kernel: *pde = > kernel: Oops: 0002 > kernel: CPU:0 > kernel: EIP:0010:[remove_from_queues+169/328] > kernel: EFLAGS: 00010206 > kernel: eax: 0100 ebx: 0002 ecx: df022e40 edx: efba76b8 > kernel: esi: df022e40 edi: ebp: esp: da327ea4 > kernel: ds: 0018 es: 0018 ss: 0018 > kernel: Process postmaster (pid: 11527, process nr: 51, stackpage=da327000) > kernel: Stack: df022e40 c012be79 df022e40 df022e40 1000 c0142cb8 c0142cc7 >df022e40 > kernel:ec247140 ffea ec0b026c da326000 df022e40 df022e40 df022e40 >000a4000 > kernel: da327f08 eff29200 1000 00a5 >000a5000 > kernel: Call Trace: [refile_buffer+77/184] [ext2_file_write+996/1584] >[ext2_file_write+1011/1584] [kfree_skbmem+51/64] [__kfree_skb+162/168] >[lockd:__insmod_lockd_O/lib/modules/2.2.16-3smp/fs/lockd.o_M394EA7+-76392/76] >[handle_IRQ_event+90/140] > kernel:[sys_write+240/292] [ext2_file_write+0/1584] [system_call+52/56] >[startup_32+43/164] > kernel: Code: 89 50 34 c7 01 00 00 00 00 89 02 c7 41 34 00 00 00 00 ff 0d > kernel: Unable to handle kernel NULL pointer dereference at virtual address 0100 Yes, your kernel basically segfaulted, I would get a traceback from your crashdump and discuss it with the kernel developers. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." > kernel: current->tss.cr3 = 1ba46000, %%cr3 = 1ba46000 > kernel: *pde = > kernel: Oops: > kernel: CPU:1 > kernel: EIP:0010:[find_buffer+104/144] > kernel: EFLAGS: 00010206 > kernel: eax: 0100 ebx: 0007 ecx: 00069dae edx: 0100 > kernel: esi: 000d edi: 3006 ebp: 0005ce4b esp: e53a19f4 > kernel: ds: 0018 es: 0018 ss: 0018 > kernel: Process postmaster (pid: 5545, process nr: 37, stackpage=e53a1000) > kernel: Stack: 0005ce4b 3006 00069dae c012b953 3006 0005ce4b 1000 >c012bcc6 > kernel:3006 0005ce4b 1000 3006 eff29200 3006 4e4b >ef18c960 > kernel:c0141ee7 3006 0005ce4b 1000 0005ce4b e53a1bb0 edc3c660 >edc3c660 > kernel: Call Trace: [get_hash_table+23/36] [getblk+30/324] >[ext2_new_block+2291/2756] [getblk+271/324] [ext2_alloc_block+344/356] >[block_getblk+305/624] [ext2_getblk+256/524] > kernel:[ext2_file_write+1308/1584] [__brelse+19/84] [permission+36/248] >[dump_seek+53/104] [dump_seek+53/104] [dump_write+48/84] [elf_core_dump+3104/3216] >[do_IRQ+82/92] > kernel:[tcp_write_xmit+407/472] [__release_sock+36/124] >[tcp_do_sendmsg+2125/2144] [inet_sendmsg+0/144] [cprt+1553/20096] [cprt+1553/20096] >[cprt+1553/20096] [do_signal+458/724] > kernel:[force_sig_info+168/180] [force_sig+17/24] >[do_general_protection+54/160] [error_code+45/52] [signal_return+20/24] > kernel: Code: 8b 00 39 6a 04 75 15 8b 4c 24 20 39 4a 08 75 0c 66 39 7a 0c
Re: [HACKERS] Restricting permissions on Unix socket
> I'd like to add an option or two to restrict the set of users that can > connect to the Unix domain socket of the postmaster, as an extra security > option. > > I imagine something like this: > > unix_socket_perm = 0660 > unix_socket_group = pgusers > > Obviously, permissions that don't have 6's in there don't make much sense, > but I feel this notation is the most intuitive way for admins. > > I'm not sure how to do the group thing, though. If I use chown(2) then > there's a race condition, but doing savegid; create socket; restoregid > might be too awkward? Any hints? > Just curious. What is a race condition? Bob Kernell Research Scientist Surface Validation Group Atmospheric Sciences Competency Analytical Services & Materials, Inc. email: [EMAIL PROTECTED] tel: 757-827-4631
RE: [HACKERS] Restricting permissions on Unix socket
Title: RE: [HACKERS] Restricting permissions on Unix socket Please take me off this list! I have received over 50 emails in the last 24 hours and I have no idea why I am getting them. Please look for email address [EMAIL PROTECTED] or [EMAIL PROTECTED] and take it out! Thanks! -Original Message- From: Robert Kernell [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 31, 2000 3:36 PM To: [EMAIL PROTECTED] Subject: Re: [HACKERS] Restricting permissions on Unix socket > I'd like to add an option or two to restrict the set of users that can > connect to the Unix domain socket of the postmaster, as an extra security > option. > > I imagine something like this: > > unix_socket_perm = 0660 > unix_socket_group = pgusers > > Obviously, permissions that don't have 6's in there don't make much sense, > but I feel this notation is the most intuitive way for admins. > > I'm not sure how to do the group thing, though. If I use chown(2) then > there's a race condition, but doing savegid; create socket; restoregid > might be too awkward? Any hints? > Just curious. What is a race condition? Bob Kernell Research Scientist Surface Validation Group Atmospheric Sciences Competency Analytical Services & Materials, Inc. email: [EMAIL PROTECTED] tel: 757-827-4631
[HACKERS] Contexts
I'm about to launch into an experiment that will do some new things inside the PG server. I'm sure to have a lot of problems, and one of them I can already tell is going to be difficult is the business of contexts: memory contexts, scan contexts and the like. Before I go around shooting myself in the foot, I would like to educate myself about how they work inside the current code. Does anyone know where best to look? It can be the code, better if it's a document. I'm happy to RTFM or RTFC, but I'd like to know where to start. ++ kevin -- Kevin O'Gorman (805) 650-6274 mailto:[EMAIL PROTECTED] Permanent e-mail forwarder: mailto:Kevin.O'[EMAIL PROTECTED] At school: mailto:[EMAIL PROTECTED] Web: http://www.cs.ucsb.edu/~kogorman/index.html Web: http://trixie.kosman.via.ayuda.com/~kevin/index.html "There is a freedom lying beyond circumstance, derived from the direct intuition that life can be grounded upon its absorption in what is changeless amid change" -- Alfred North Whitehead
[HACKERS] Query cache import?
I never saw much traffic regarding Karel's work on making stored proceedures: http://people.freebsd.org/~alfred/karel-pgsql.txt What happened with this? It looked pretty interesting. :( -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
RE: [HACKERS] WAL status update
> I believe that its just resting on Vadim again to give us the go ahead > ... which I believe its always been on his shoulders, no? :) > > Vadim? I think that at least 1 & 2 from WAL todo (checkpoints and port to machines without TAS) is required before beta. As well as more testing... Did anyone else test WAL recovery? Sorry guys but I can't do both testing and coding at the same time. WAL is the most complex thing I've ever did in project. MVCC was just child's game. Tom & Bruce are in summit anyway - let's wait them. And I'll do 1 & 2 in a few days. Vadim
RE: [HACKERS] WAL status update
> The first test did not go very well. I did a fresh compile, initdb, > started the postmaster, ran 'make installcheck' (sequential regression > tests), and sent a kill -QUIT to the postmaster during the > numeric test. > Then I restarted the postmaster and got a load of lines like > > REDO @ 0/434072; LSN 0/434100: prev 0/433992; xprev 0/433992; xid > 17278: Transaction - commit: 2000-10-31 23:21:29 > REDO @ 0/434100; LSN 0/434252: prev 0/434072; xprev 0/0; xid > 17279: Heap - insert: node 19008/1259; cid 0; tid 1/43 Is this *the last* output just before abort? I need to know in what stage abort occured. Could you look at core file too? > after which it finished with > > Startup failed - abort Vadim
[HACKERS] How to unsuscribe from this list?
Thanks for the info.
Re: [HACKERS] Query cache import?
On Tue, 31 Oct 2000, Alfred Perlstein wrote: > I never saw much traffic regarding Karel's work on making stored > proceedures: > > http://people.freebsd.org/~alfred/karel-pgsql.txt > > What happened with this? It looked pretty interesting. :( It's probably a little about me :-) ... well, My query cache is in usable state and it's efficient for all things those motivate me to work on this. some basic features: - share parsed plans between backends in shared memory - store plans to private backend hash table - use parameters for stored queries - better design for SPI - memory usage for saved plans - save plans "by key" The current query cache code depend on 7.1 memory management. After official 7.1 release I prepare patch with query cache+SPI (if not hit me over head, please ..) All what will doing next time not depend on me, *it's on code developers*. For example Jan has interesting idea about caching all plans which processing backend. But it's far future and IMHO we must go by small steps to Oracle's funeral :-) If I need the query cache in the my work (typical for some web+pgsql) or will some public interest I will continue on this, if not I freeze it. (Exists more interesting work like http://mape.jcu.cz ... sorry of advertising :-) Karel
Re: [HACKERS] Query cache import?
> My query cache is in usable state and it's efficient for all things > those motivate me to work on this. Well, you know, us application developers are lazy egoists, we want all of that without efforts on our side :) In fact, customers do that. They don't want to pay for both implementing query cache and re-writing applications. I suggest by your description that it shouldn't be a brain surgery to apply your caching to a stable server, so when I'll have a chance to put my hands on a busy discussion forum next time, it'd be nice to give it a whirl. -- contaminated fish and microchips huge supertankers on Arabian trips oily propaganda from the leaders' lips all about the future there's people over here, people over there everybody's looking for a little more air crossing all the borders just to take their share planning for the future Rainbow, Difficult to Cure
Re: [HACKERS] Query cache import?
* Karel Zak <[EMAIL PROTECTED]> [001031 16:18] wrote: > > On Tue, 31 Oct 2000, Alfred Perlstein wrote: > > > I never saw much traffic regarding Karel's work on making stored > > proceedures: > > > > http://people.freebsd.org/~alfred/karel-pgsql.txt > > > > What happened with this? It looked pretty interesting. :( > > It's probably a little about me :-) ... well, > > My query cache is in usable state and it's efficient for all > things those motivate me to work on this. > > some basic features: > > - share parsed plans between backends in shared memory > - store plans to private backend hash table > - use parameters for stored queries > - better design for SPI > - memory usage for saved plans > - save plans "by key" > > > The current query cache code depend on 7.1 memory management. After > official 7.1 release I prepare patch with query cache+SPI (if not > hit me over head, please ..) > > All what will doing next time not depend on me, *it's on code developers*. > > For example Jan has interesting idea about caching all plans which > processing backend. But it's far future and IMHO we must go by small > steps to Oracle's funeral :-) Well I'm just hoping that perl's $dbh->prepare() actually does a temporary stored proceedure so that I can shave cycles off of my thousands upon thousands of repeated queries. :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
Re: [HACKERS] Re: [GENERAL] Query caching
On Tue, 31 Oct 2000, Alfred Perlstein wrote: > * Steve Wolfe <[EMAIL PROTECTED]> [001031 13:47] wrote: > > > > > >(Incidentally, we've toyed around with developping a > > query-caching > > > > system that would sit betwen PostgreSQL and our DB libraries. > > > > > > Sounds amazing, but requires some research, I guess. However, in > > many > > > cases one would be more than happy with cahced connections. Of > > course, > > > cahced query results can be naturally added to that, but just > > connections > > > are OK to start with. Security > > > > To me, it doesn't sound like it would be that difficult of a project, at > > least not for the likes of the PostgreSQL developpers. It also doesn't seem > > like it would really introduce any security problems, not if it were done > > inside of PostgreSQL. Long ago, I got sidetracked from my endeavors in C, > > and so I don't feel that I'm qualified to do it. (otherwise, I would have > > done it already. : ) ) If you wanted it done in Perl or Object Pascal, I > > could help. : ) > > > > Here's a simple design that I was tossing back and forth. Please > > understand that I'm not saying this is the best way to do it, or even a good > > way to do it. Just a possible way to do it. I haven't been able to give it > > as much thought as I would like to. Here goes. > > > > > > Implementation > > > > [snip] > > Karel Zak <[EMAIL PROTECTED]> Implemented stored proceedures for > postgresql but still hasn't been approached to integrated them. someone has to approach him to integrate them? *raised eyebrow* Karel, where did things stand the last time this was brought up? We haven't gone beta yet, can you re-submit a patch for v7.1 before beta so that we can integrate the changes? *Maybe*, if possible, submit it such that its a compile time option, so that its there if someone like Alfred wants to be brave, but it won't zap everyone if there is a bug?
RE: [HACKERS] WAL status update
> > The first test did not go very well. I did a fresh compile, initdb, > > started the postmaster, ran 'make installcheck' (sequential > > regression tests), and sent a kill -QUIT to the postmaster during the > > numeric test. > > Then I restarted the postmaster and got a load of lines like > > > > REDO @ 0/434072; LSN 0/434100: prev 0/433992; xprev 0/433992; xid > > 17278: Transaction - commit: 2000-10-31 23:21:29 > > REDO @ 0/434100; LSN 0/434252: prev 0/434072; xprev 0/0; xid > > 17279: Heap - insert: node 19008/1259; cid 0; tid 1/43 > > Is this *the last* output just before abort? > I need to know in what stage abort occured. > Could you look at core file too? > > > after which it finished with > > > > Startup failed - abort Fixed. Thanks for pointing to the problem! Vadim
[HACKERS] WAL: postmaster won't start
It seems postmaster won't restart under WAL. What I have done so far
was creating some tables and inserting fairly large amount of tuples
(10 tuples) using pgbench.
Here is the test sequence:
pg_ctl -w stop
rm -fr /usr/local/pgsql/data
initdb
pg_ctl -w start
createdb test
./pgbench -i test
pg_ctl -w -m i stop
pg_ctl -w start
and postmaster does not return from automatic recovering job. Here are
last 2 lines from log:
Nov 1 12:38:46 srapc968-yotsuya postgres[14769]: [7] DEBUG: The DataBase system was
not properly shut down ^IAutomatic recovery is in progress...
Nov 1 12:38:46 srapc968-yotsuya postgres[14769]: [8] DEBUG: Redo starts at (0,
287536)
It seems that the recovery process is waiting for acquiring a lock.
Here is the backtrace from the process:
(gdb) where
#0 0x2ac4acae in __select () from /lib/libc.so.6
#1 0x2ac9f0ac in ?? ()
#2 0x80ea18c in LockBuffer (buffer=37, mode=2) at xlog_bufmgr.c:1995
#3 0x8082feb in XLogReadBuffer (extend=0, reln=0x82e92c8, blkno=1)
at xlogutils.c:215
#4 0x80781e4 in btree_xlog_delete (redo=1, lsn={xlogid = 0,
xrecoff = 23741124}, record=0x82980dc) at nbtree.c:1013
#5 0x80790fe in btree_redo (lsn={xlogid = 0, xrecoff = 23741124},
record=0x82980dc) at nbtree.c:1450
#6 0x80825b2 in StartupXLOG () at xlog.c:1452
#7 0x80850cd in BootstrapMain (argc=6, argv=0x7fffeffc) at bootstrap.c:349
#8 0x80e047a in SSDataBase (startup=1 '\001') at postmaster.c:2187
#9 0x80deb1a in PostmasterMain (argc=1, argv=0x7694) at postmaster.c:667
#10 0x80c3646 in main (argc=1, argv=0x7694) at main.c:112
Please let me know if you need more info.
--
Tatsuo Ishii
[HACKERS] Re: [GENERAL] Query caching
* Steve Wolfe <[EMAIL PROTECTED]> [001031 13:47] wrote: > > > >(Incidentally, we've toyed around with developping a > query-caching > > > system that would sit betwen PostgreSQL and our DB libraries. > > > > Sounds amazing, but requires some research, I guess. However, in > many > > cases one would be more than happy with cahced connections. Of > course, > > cahced query results can be naturally added to that, but just > connections > > are OK to start with. Security > > To me, it doesn't sound like it would be that difficult of a project, at > least not for the likes of the PostgreSQL developpers. It also doesn't seem > like it would really introduce any security problems, not if it were done > inside of PostgreSQL. Long ago, I got sidetracked from my endeavors in C, > and so I don't feel that I'm qualified to do it. (otherwise, I would have > done it already. : ) ) If you wanted it done in Perl or Object Pascal, I > could help. : ) > > Here's a simple design that I was tossing back and forth. Please > understand that I'm not saying this is the best way to do it, or even a good > way to do it. Just a possible way to do it. I haven't been able to give it > as much thought as I would like to. Here goes. > > > Implementation > [snip] Karel Zak <[EMAIL PROTECTED]> Implemented stored proceedures for postgresql but still hasn't been approached to integrated them. You can find his second attempt to get a response from the developers here: http://people.freebsd.org/~alfred/karel-pgsql.txt -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
Re: [HACKERS] Restricting permissions on Unix socket
* Peter Eisentraut <[EMAIL PROTECTED]> [001031 12:57] wrote: > I'd like to add an option or two to restrict the set of users that can > connect to the Unix domain socket of the postmaster, as an extra security > option. > > I imagine something like this: > > unix_socket_perm = 0660 > unix_socket_group = pgusers > > Obviously, permissions that don't have 6's in there don't make much sense, > but I feel this notation is the most intuitive way for admins. > > I'm not sure how to do the group thing, though. If I use chown(2) then > there's a race condition, but doing savegid; create socket; restoregid > might be too awkward? Any hints? Set your umask to 777 then go to town. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
[GENERAL] PostgreSQL 7.0.2-21 RPMset available.
After much too long a time, I have updated the RedHat RPMset on ftp.postgresql.org. The version is 7.0.2, release is 21. Please see the changelog for more information (rpm -q --changelog postgresql for installed packages, rpm -qp --changelog postgresql-7.0.2-21.i386.rpm for packages before installation). And please read the README.rpm placed in the doc dir (depends on your distribution as to where the doc dir is -- newer distributions are using /usr/share/doc instead of /usr/doc -- and the documentation in the README assumes, for better or for worse, the RedHat 7 layout). The big fix is the os.h dangling symlink in the -devel package. The source package will rebuild on both RedHat 7 and RedHat 6 -- and should rebuild with no trouble on TurboLinux 6 as well as Mandrake's 6 and 7. Don't try to install the RedHat 6 binary packages on RedHat 7 or TurboLinux -- please rebuild from the source RPM for non-RedHat 6 distributions until we get other binaries uploaded. ftp://ftp.postgresql.org/pub/binary/v7.0.2/RedHat-6.x/RPMS ftp://ftp.postgresql.org/pub/binary/v7.0.2/RedHat-6.x/SRPMS ftp://ftp.postgresql.org/pub/binary/v7.0.2/RedHat-6.x/unpacked -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[HACKERS] Restricting permissions on Unix socket
I'd like to add an option or two to restrict the set of users that can connect to the Unix domain socket of the postmaster, as an extra security option. I imagine something like this: unix_socket_perm = 0660 unix_socket_group = pgusers Obviously, permissions that don't have 6's in there don't make much sense, but I feel this notation is the most intuitive way for admins. I'm not sure how to do the group thing, though. If I use chown(2) then there's a race condition, but doing savegid; create socket; restoregid might be too awkward? Any hints? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
