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_up

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 beh

Re: [HACKERS] VACUUM FULL versus TOAST

2011-08-14 Thread Greg Stark
On Sun, Aug 14, 2011 at 5:15 PM, Tom Lane 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 on repeated ac

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

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 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(...); > >        ... alter the t

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 wrote: > On Thu, Aug 11, 2011 at 6:21 AM, Alexander Korotkov > wrote: > > [ new patch ] > > Some random comments: > > - It appears that the "noFollowFight" flag is really supposed to be > called "noFollowRight". > Fixed

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 wrote: > Simon Riggs writes: >> On Sat, Aug 13, 2011 at 11:14 PM, Robert Haas 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

[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 Tom Lane
Simon Riggs writes: > On Sat, Aug 13, 2011 at 11:14 PM, Robert Haas 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 bu

Re: [HACKERS] Connection Problem

2011-08-14 Thread Tom Lane
Amir Abdollahi 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 lead to a very well-pe

Re: [HACKERS] VACUUM FULL versus TOAST

2011-08-14 Thread Tom Lane
Heikki Linnakangas 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 pretty ugly things to >> avoid

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 wrote: > On Sun, Aug 14, 2011 at 1:44 PM, Robert Haas 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 in

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 wrote: > On Sun, Aug 14, 2011 at 6:57 AM, Simon Riggs wrote: >> On Sat, Aug 13, 2011 at 11:14 PM, Robert Haas wrote: >>> On Sat, Aug 13, 2011 at 4:40 PM, Greg Stark wrote: On Sat, Aug 13, 2011 at 8:52 PM, Robert Haas wrote: > and possibly w

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 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 first.  So I'm pro

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 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 algorithm is to appro

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 wrote: > On Sat, Aug 13, 2011 at 11:14 PM, Robert Haas wrote: >> On Sat, Aug 13, 2011 at 4:40 PM, Greg Stark wrote: >>> On Sat, Aug 13, 2011 at 8:52 PM, Robert Haas wrote: and possibly we ought to put them all in a linked list so that the n

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 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 management is all wron

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 wrote: > On Sat, Aug 13, 2011 at 4:40 PM, Greg Stark wrote: >> On Sat, Aug 13, 2011 at 8:52 PM, Robert Haas 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

[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 audit