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
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
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
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
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
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
for
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
[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
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 wondering
[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 lane
Martijn van Oosterhout kleptog@svana.org 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
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
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,
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 them
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 viewed from
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
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/
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
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 autovacuum
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
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 when vacuum
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 with the next
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, repeat.
Bruce and I
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 have
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 potentially
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 patch)?
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
On 5/1/06, Martijn van Oosterhout kleptog@svana.org 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
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.
You can be
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?
Or, is
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
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
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 point in
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 know you could
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
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 should be
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
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
rather
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 function that
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 but
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 do
41 matches
Mail list logo
