Re: [HACKERS] Constraint Exclusion + Joins?

"Brandon Black" <[EMAIL PROTECTED]> writes: > Is this sort of dynamic constraint exclusion on the radar? What sort of fantasy have you got in mind? It doesn't seem likely to me that testing constraints explicitly against each row from the other table would be a win compared to letting the indexes

Re: [HACKERS] Constraint Exclusion + Joins?

On 4/30/06, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: On Fri, 28 Apr 2006, Brandon Black wrote: > I dug around in CVS to have a look for this, and I did eventually find > it (well, I found the corresponding docs patch that removed the note > about not working for joins). I see it's in MAIN

Re: [HACKERS] Is a SERIAL column a "black box", or not?

Greg Stark <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> writes: >> One argument against it is that it'd break trying to log who-did-what >> by the expedient of having a column default CURRENT_USER: >> blame_me text default current_user > No reason there couldn't be a separate fu

Re: [HACKERS] Is a SERIAL column a "black box", or not?

Tom Lane <[EMAIL PROTECTED]> writes: > One argument against it is that it'd break trying to log who-did-what > by the expedient of having a column default CURRENT_USER: > blame_me text default current_user No reason there couldn't be a separate function that returns the _actual_ user rathe

Re: [HACKERS] InsertXLogFile in pg_resetxlog

Just to update everyone, I've refactored a good amount of the rebuild-control-values-from-WAL code and should have it ready for -patches tomorrow. -- Jonah H. Harris, Database Internals Architect EnterpriseDB Corporation 732.331.1324 ---(end of broadcast)-

Re: [HACKERS] Is a SERIAL column a "black box", or not?

On Mon, May 01, 2006 at 07:47:06PM -0400, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > I think a big point that's being missed here is that SERIAL *is* trying > > to be simple. If you need something more sophisticated or complex you > > shouldn't be using SERIAL at all, you shou

Re: [HACKERS] Is a SERIAL column a "black box", or not?

Sure, but there's no reason that would couldn't allow that with a true black-box SERIAL, either. In fact, you can do it today if you want, just by creating a wrapper around nextval(pg_get_serial_sequence()). Or just use lastval() Chris ---(end of broadcast)---

Re: [HACKERS] Is a SERIAL column a "black box", or not?

"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > On Mon, May 01, 2006 at 11:25:33AM -0400, Tom Lane wrote: >> [EMAIL PROTECTED] writes: >>> Ah. I was wondering about that. When I saw the first poster tag >>> 'SECURITY DEFINER' on the end of the expression I assumed it was >>> something that I didn't kn

Re: [HACKERS] Is a SERIAL column a "black box", or not?

"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > I think a big point that's being missed here is that SERIAL *is* trying > to be simple. If you need something more sophisticated or complex you > shouldn't be using SERIAL at all, you should be doing the stuff > yourself, by hand. I agree with this poin

Re: [HACKERS] Is a SERIAL column a "black box", or not?

Jim C. Nasby wrote: On Mon, May 01, 2006 at 11:25:33AM -0400, Tom Lane wrote: [EMAIL PROTECTED] writes: Ah. I was wondering about that. When I saw the first poster tag 'SECURITY DEFINER' on the end of the expression I assumed it was something that I didn't know you could do... :-) No, he was i

Re: [HACKERS] Is a SERIAL column a "black box", or not?

On Mon, May 01, 2006 at 11:25:33AM -0400, Tom Lane wrote: > [EMAIL PROTECTED] writes: > > Ah. I was wondering about that. When I saw the first poster tag > > 'SECURITY DEFINER' on the end of the expression I assumed it was > > something that I didn't know you could do... :-) > > No, he was inventi

Re: [HACKERS] Is a SERIAL column a "black box", or not?

On Sun, Apr 30, 2006 at 11:45:14AM +0200, Svenne Krap wrote: > Tom Lane wrote: > >In short, I think there's a reasonably good case to be made for losing the > >hidden dependency and re-adopting the viewpoint that saying SERIAL is > >*exactly* the same as making a sequence and then making a default

Re: [HACKERS] Logging pg_autovacuum

Larry Rosenman wrote: > Jim C. Nasby wrote: >> On Mon, May 01, 2006 at 12:28:21PM -0500, Larry Rosenman wrote: >>> Since both vacuum and autovacuum will be cutting stats records, do >>> we want to just have the autovacuum >>> stats record have the fact that it was autovacuum that did the >>> vacuum

Re: [HACKERS] Is a SERIAL column a "black box", or not?

On Sun, Apr 30, 2006 at 01:42:37PM +0300, Hannu Krosing wrote: > > I do see the benefits with regard to simplified implementation, and > > flexibility. > > > > As a compromise, I could see either choice being correct. I don't > > see either direction as being both user friendly and simple. > > Yo

Re: [HACKERS] Automatic free space map filling

On 5/1/06, Martijn van Oosterhout wrote: On Mon, May 01, 2006 at 01:19:30PM -0500, Jim C. Nasby wrote:> ISTM that tying this directly to maintenance_work_mem is a bit> confusing, since the idea is to keep vacuum transaction duration down so> that it isn't causing dead tuples to

Re: [HACKERS] InsertXLogFile in pg_resetxlog

On 5/1/06, Tom Lane <[EMAIL PROTECTED]> wrote: Definitely bad, very bad. Please put back the lock-checking code. That's what I was thinking. -- Jonah H. Harris, Database Internals Architect EnterpriseDB Corporation 732.331.1324 ---(end of broadcast)---

Re: [HACKERS] InsertXLogFile in pg_resetxlog

"Jonah H. Harris" <[EMAIL PROTECTED]> writes: > While refactoring the patch, I've noticed that this patch allowed > pg_resetxlog to proceed while the server could potentially be up... is > this the desired behavior or should we require the lock file to be > removed first (as it was prior to this pa

Re: [HACKERS] InsertXLogFile in pg_resetxlog

On 5/1/06, Jonah H. Harris <[EMAIL PROTECTED]> wrote: I just scanned it, and it's pretty ugly overall. Did one of you guys want to clean it up? If not, I'll do it today. While refactoring the patch, I've noticed that this patch allowed pg_resetxlog to proceed while the server could potentiall

Re: [HACKERS] Automatic free space map filling

On Mon, May 01, 2006 at 01:19:30PM -0500, Jim C. Nasby wrote: > ISTM that tying this directly to maintenance_work_mem is a bit > confusing, since the idea is to keep vacuum transaction duration down so > that it isn't causing dead tuples to build up itself. It seems like it > would be better to hav

Re: [HACKERS] Automatic free space map filling

"Jim C. Nasby" <[EMAIL PROTECTED]> writes: >>> Alvaro Herrera <[EMAIL PROTECTED]> writes: So for you it would certainly help a lot to be able to vacuum the first X pages of the big table, stop, release locks, create new transaction, continue with the next X pages, lather, rinse, repe

Re: [HACKERS] Automatic free space map filling

On Fri, Apr 28, 2006 at 03:58:16PM -0400, Bruce Momjian wrote: > Tom Lane wrote: > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > > So for you it would certainly help a lot to be able to vacuum the first > > > X pages of the big table, stop, release locks, create new transaction, > > > continue w

Re: [HACKERS] Logging pg_autovacuum

Jim C. Nasby wrote: > On Mon, May 01, 2006 at 12:28:21PM -0500, Larry Rosenman wrote: >> Since both vacuum and autovacuum will be cutting stats records, do we >> want to just have the autovacuum >> stats record have the fact that it was autovacuum that did the >> vacuum? >> >> Or, is there a way

Re: [HACKERS] CVSup server seems to be down

On Mon, 1 May 2006, Alvaro Herrera wrote: Hi, Since yesterday (at least), the CVSup server has been down: $ cvsup -g cvsup.pgsql Cannot connect to cvsup.postgresql.org: Connection refused Will retry at 14:08:50 I hope it has not been deprecated? nope, just upgrade postgresql.org to FreeBSD

Re: [HACKERS] Logging pg_autovacuum

On Mon, May 01, 2006 at 12:28:21PM -0500, Larry Rosenman wrote: > Since both vacuum and autovacuum will be cutting stats records, do we > want to just have the autovacuum > stats record have the fact that it was autovacuum that did the vacuum? > > Or, is there a way when vacuum is run by autovacuu

Re: [HACKERS] Logging pg_autovacuum

On Sat, Apr 29, 2006 at 10:05:51AM -0700, Mark Dilger wrote: > Should we make the whole postgres logging system configurable, similar to > log4j > (or log4perl) rather than special-casing the autovacuum logs? Do we want to > see > options added piecemeal to the conf file such as "autovacuum_mess

[HACKERS] CVSup server seems to be down

Hi, Since yesterday (at least), the CVSup server has been down: $ cvsup -g cvsup.pgsql Cannot connect to cvsup.postgresql.org: Connection refused Will retry at 14:08:50 I hope it has not been deprecated? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQ

Re: [HACKERS] Logging pg_autovacuum

On Thu, Apr 27, 2006 at 08:12:23PM +, Chris Browne wrote: > Having some ability to collect statistics about "we recovered 42 pages > from table foo at 12:45" would seem useful both from an immediate > temporal perspective where it could suggest whether specific tables > were being vacuumed too

Re: [HACKERS] Logging pg_autovacuum

Martijn van Oosterhout wrote: > On Fri, Apr 28, 2006 at 04:08:41PM -0400, Robert Treat wrote: >> The first is to add a column(s) to pg_class to hold last >> vaccum/analyze time >> for each table. The upsides would be that this puts the information >> in a readily accessable place that can be view

Re: [HACKERS] Is a SERIAL column a "black box", or not?

Bruno Wolff III <[EMAIL PROTECTED]> writes: > The summary is that I was suggesting that default expressions, triggers and > constraints should all run as the table owner instead of the invoker as > there was little use for them to need the access of the invoker, while there > was benefit in having

Re: [HACKERS] Is a SERIAL column a "black box", or not?

I went back to see if I could find the discussion about this in the past. It was less than I thought. Most it was me posting with some feedback from Rod Taylor. The thread started with the subject "What user to defaults execute as?" on general, but I mutated the subject to "setuid for defaults, con

Re: [HACKERS] InsertXLogFile in pg_resetxlog

On 5/1/06, Tom Lane <[EMAIL PROTECTED]> wrote: This certainly looks like it was written by someone who'd just learned about lists yesterday :-(. I wonder how many other problems there are in that resetxlog patch? I didn't bother to look at it at all myself. Anyone have time to review it? I ju

Re: [HACKERS] InsertXLogFile in pg_resetxlog

Martijn van Oosterhout writes: > May I propose the entire part of that function after the comment /* the > list is empty. */ be replaced with something like the following (or > whatever idiom people prefer for singly-linked lists): This certainly looks like it was written by someone who'd just le

Re: [HACKERS] Is a SERIAL column a "black box", or not?

[EMAIL PROTECTED] writes: > Ah. I was wondering about that. When I saw the first poster tag > 'SECURITY DEFINER' on the end of the expression I assumed it was > something that I didn't know you could do... :-) No, he was inventing syntax that doesn't exist. regards, tom la

Re: [HACKERS] Is a SERIAL column a "black box", or not?

On Mon, May 01, 2006 at 11:18:13AM -0400, Tom Lane wrote: > [EMAIL PROTECTED] writes: > > If the user is specifying the default expression, they can specify > > SECURITY DEFINER themselves, yes? > Not unless they write a wrapper function to be a security definer > and call nextval(). Ah. I was won

Re: [HACKERS] Is a SERIAL column a "black box", or not?

[EMAIL PROTECTED] writes: > If the user is specifying the default expression, they can specify > SECURITY DEFINER themselves, yes? Not unless they write a wrapper function to be a security definer and call nextval(). regards, tom lane ---(end of br

Re: [HACKERS] Is a SERIAL column a "black box", or not?

On Mon, May 01, 2006 at 10:29:12AM -0400, Tom Lane wrote: > A cheesy compromise would be to switch userid for default-evaluation > only if the expression contains any volatile functions. I find this > idea pretty ugly, but it would allow us to still behave per-spec > for CURRENT_USER while getting

Re: [HACKERS] RELKIND_SPECIAL

Alvaro Herrera <[EMAIL PROTECTED]> writes: > How about we remove RELKIND_SPECIAL? It was there only to support > the XactLockTable hack, but we don't need that anymore. Go for it. Don't forget to remove the documentation mentions (catalog.sgml at least). Might be a good idea to leave the code f

Re: [HACKERS] Is a SERIAL column a "black box", or not?

Bruno Wolff III <[EMAIL PROTECTED]> writes: > I suggested a long time ago that default expressions should always be > executed as the owner of the table. This got shot down, but I don't remember > if it was because people thought the idea was bad in itself or if it was > the work involved (which I

Re: [HACKERS] WITH/WITH RECURSIVE implementation discussion

On 5/1/06, Mark Cave-Ayland <[EMAIL PROTECTED]> wrote: The latest discussion I found related to this appears to be here: http://archives.postgresql.org/pgsql-hackers/2005-11/msg00564.php which indicates that Jonah is hoping to work on this for 8.2, but I don't see this item as being worked on in

[HACKERS] WITH/WITH RECURSIVE implementation discussion

Hi folks, Looking ahead at some of the projects I'll be working on in the future, I'm seeing that having an implementation of WITH/WITH RECURSIVE for working with tree structures is going to be a very useful feature and so would like to re-start the discussions on this to see whether this could be

Re: [HACKERS] inet increment with int

On Sat, Apr 29, 2006 at 10:24:48PM -0400, Bruce Momjian wrote: > > FYI, 8.2 will have this and more based on this applied patch: > > Add INET/CIDR operators: and, or, not, plus int8, minus int8, and inet > minus inet. I know, I'm already using it :-) Thanks, Patrick

[HACKERS] InsertXLogFile in pg_resetxlog

There's been some new code added to pg_resetxlog which is confusing enough that Coverity is convinced there's a possible memory leak in InsertXLogFile. I think it may actually be a bug. At the least this bit needs rewriting to make it clearer what it does. What I think happens is this: 1. Assume