[HACKERS] Connection Problem

2011-08-14 Thread Amir Abdollahi
Hello, I'm trying to add audit capability to Postgresql server. When the Postgresql server starts up, the server will start audit functions as a new subprocess thus the server will have 5 subprocesses instead of 4. I want to store logs in a database within the same Postgresql server [from

Re: [HACKERS] our buffer replacement strategy is kind of lame

2011-08-14 Thread Simon Riggs
On Sat, Aug 13, 2011 at 11:14 PM, Robert Haas robertmh...@gmail.com wrote: On Sat, Aug 13, 2011 at 4:40 PM, Greg Stark st...@mit.edu wrote: On Sat, Aug 13, 2011 at 8:52 PM, Robert Haas robertmh...@gmail.com wrote: and possibly we ought to put them all in a linked list so that the next guy who

Re: [HACKERS] our buffer replacement strategy is kind of lame

2011-08-14 Thread Simon Riggs
On Sat, Aug 13, 2011 at 11:14 PM, Robert Haas robertmh...@gmail.com wrote: I agree that something's missing. I'm quoting you completely out of context here, but yes, something is missing. We can't credibly do one test on usage count in shared buffers and then start talking about how buffer

Re: [HACKERS] our buffer replacement strategy is kind of lame

2011-08-14 Thread Robert Haas
On Sun, Aug 14, 2011 at 6:57 AM, Simon Riggs si...@2ndquadrant.com wrote: On Sat, Aug 13, 2011 at 11:14 PM, Robert Haas robertmh...@gmail.com wrote: On Sat, Aug 13, 2011 at 4:40 PM, Greg Stark st...@mit.edu wrote: On Sat, Aug 13, 2011 at 8:52 PM, Robert Haas robertmh...@gmail.com wrote: and

Re: [HACKERS] our buffer replacement strategy is kind of lame

2011-08-14 Thread Martijn van Oosterhout
On Sat, Aug 13, 2011 at 09:40:15PM +0100, Greg Stark wrote: On Sat, Aug 13, 2011 at 8:52 PM, Robert Haas robertmh...@gmail.com wrote: and possibly we ought to put them all in a linked list so that the next guy who needs a buffer can just pop one The whole point of the clock sweep

Re: [HACKERS] our buffer replacement strategy is kind of lame

2011-08-14 Thread Simon Riggs
On Sun, Aug 14, 2011 at 1:44 PM, Robert Haas robertmh...@gmail.com wrote: The big problem with this idea is that it pretty much requires that the work you mentioned in one of your other emails - separating the background writer and checkpoint machinery into two separate processes - to happen

Re: [HACKERS] our buffer replacement strategy is kind of lame

2011-08-14 Thread Simon Riggs
On Sun, Aug 14, 2011 at 1:44 PM, Robert Haas robertmh...@gmail.com wrote: On Sun, Aug 14, 2011 at 6:57 AM, Simon Riggs si...@2ndquadrant.com wrote: On Sat, Aug 13, 2011 at 11:14 PM, Robert Haas robertmh...@gmail.com wrote: On Sat, Aug 13, 2011 at 4:40 PM, Greg Stark st...@mit.edu wrote: On

Re: [HACKERS] our buffer replacement strategy is kind of lame

2011-08-14 Thread Robert Haas
On Sun, Aug 14, 2011 at 10:35 AM, Simon Riggs si...@2ndquadrant.com wrote: On Sun, Aug 14, 2011 at 1:44 PM, Robert Haas robertmh...@gmail.com wrote: The big problem with this idea is that it pretty much requires that the work you mentioned in one of your other emails - separating the

Re: [HACKERS] VACUUM FULL versus TOAST

2011-08-14 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: On 14.08.2011 01:13, Tom Lane wrote: I am thinking that the most reasonable solution is instead to fix VACUUM FULL/CLUSTER so that they don't change existing toast item OIDs when vacuuming a system catalog. They already do some

Re: [HACKERS] Connection Problem

2011-08-14 Thread Tom Lane
Amir Abdollahi amirabd2...@yahoo.com writes: I'm trying to add audit capability to Postgresql server. When the Postgresql server starts up, the server will start audit functions as a new subprocess thus the server will have 5 subprocesses instead of 4. That doesn't sound like it's going to

Re: [HACKERS] our buffer replacement strategy is kind of lame

2011-08-14 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com writes: On Sat, Aug 13, 2011 at 11:14 PM, Robert Haas robertmh...@gmail.com wrote: I agree that something's missing. I'm quoting you completely out of context here, but yes, something is missing. We can't credibly do one test on usage count in shared buffers

[HACKERS] VACUUM FULL versus unsafe order-of-operations in DDL commands

2011-08-14 Thread Tom Lane
So, as the testing rolls on, I started to see some failures in various ALTER-FOREIGN-thingy commands. The cause proved to be that numerous places in foreigncmds.c do this: tuple = SearchSysCacheCopy(...); ... alter the tuple as needed ... rel = heap_open(target-catalog,

Re: [HACKERS] our buffer replacement strategy is kind of lame

2011-08-14 Thread Robert Haas
On Sun, Aug 14, 2011 at 1:11 PM, Tom Lane t...@sss.pgh.pa.us wrote: Simon Riggs si...@2ndquadrant.com writes: On Sat, Aug 13, 2011 at 11:14 PM, Robert Haas robertmh...@gmail.com wrote: I agree that something's missing. I'm quoting you completely out of context here, but yes, something is

Re: [HACKERS] WIP: Fast GiST index build

2011-08-14 Thread Alexander Korotkov
Hi! Thank you for your notes. On Fri, Aug 12, 2011 at 7:04 PM, Robert Haas robertmh...@gmail.com wrote: On Thu, Aug 11, 2011 at 6:21 AM, Alexander Korotkov aekorot...@gmail.com wrote: [ new patch ] Some random comments: - It appears that the noFollowFight flag is really supposed to be

Re: [HACKERS] VACUUM FULL versus unsafe order-of-operations in DDL commands

2011-08-14 Thread Robert Haas
On Sun, Aug 14, 2011 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote: So, as the testing rolls on, I started to see some failures in various ALTER-FOREIGN-thingy commands.  The cause proved to be that numerous places in foreigncmds.c do this:        tuple = SearchSysCacheCopy(...);        ...

Re: [HACKERS] VACUUM FULL versus TOAST

2011-08-14 Thread Tom Lane
I wrote: I am thinking that the most reasonable solution is instead to fix VACUUM FULL/CLUSTER so that they don't change existing toast item OIDs when vacuuming a system catalog. They already do some pretty ugly things to avoid changing the toast table's OID in this case, and locking down the

Re: [HACKERS] VACUUM FULL versus TOAST

2011-08-14 Thread Greg Stark
On Sun, Aug 14, 2011 at 5:15 PM, Tom Lane t...@sss.pgh.pa.us wrote: There would be some merit in your suggestion if we knew that all/most toasted columns would actually get fetched out of the catcache entry at some point.  Then we'd only be moving the cost around, and might even save something

Re: [HACKERS] our buffer replacement strategy is kind of lame

2011-08-14 Thread Greg Smith
On 08/12/2011 10:51 PM, Greg Stark wrote: If you execute a large batch delete or update or even just set lots of hint bits you'll dirty a lot of buffers. The ring buffer forces the query that is actually dirtying all these buffers to also do the i/o to write them out. Otherwise you leave them

Re: [HACKERS] Possible Bug in pg_upgrade

2011-08-14 Thread Bruce Momjian
Dave Byrne wrote: Beginning with commit 002c105a0706bd1c1e939fe0f47ecdceeae6c52d pg_upgrade will fail if there are orphaned temp tables in the current database with the message 'old and new databases postgres have a different number of relations' On line 41 of pg_upgrade/info.c pg_upgrade