Check nextval/currval permission in analyze.c.

Can't inherits from ...

sequences,...) and vc_delhilowstats(NULL->vrl_relid) ...

New funcs (nextval & currval) in pg_proc.h

Pointed out by: igor@cs.cs.miami.edu

Subject: [HACKERS] Small date patches (resubmitted)

Here a some small patches for the date/time code. They set the default
output format for the datetime type to the traditional Postgres
style, and fix a date debugging declaration. I submitted these
a couple of days ago, but they might have gotten lost...


NOTE: the second patch to dt.c is what I believe D'Arcy submitted as well,
      that I claimed was taken out...sorry D'Arcy, my fault :(

Subject: Re: [HACKERS] abstime "now" broken

Yes, I broke 'now' :( with an attempt at a bug fix involving
servers running in the UTC/GMT timezone. These patches fix
the problem, and have been tested in GMT (+00 hours),
PST (-08), and NZT (+12) timezones which exercized the code for
various cases including across day boundaries.  btw, this code
fixes the same type of problem for 'today', 'yesterday', 'tomorrow',
for DATETIME, ABSTIME, DATE and TIME types.

The bugfix itself is quite small, but I have accumulated other
changes in the datetime data type and include them here also.
One set of changes involves printing ISO-formatted dates and
is in response to the helpful information from Kurt Lidl regarding
ANSI SQL dates. I'll send another e-mail sometime soon discussing
more issues he has raised...

Reply-To: hackers@hub.org, Dan McGuirk <mcguirk@indirect.com>
To: hackers@hub.org
Subject: [HACKERS] tmin writeback optimization

I was doing some profiling of the backend, and noticed that during a certain
benchmark I was running somewhere between 30% and 75% of the backend's CPU
time was being spent in calls to TransactionIdDidCommit() from
HeapTupleSatisfiesNow() or HeapTupleSatisfiesItself() to determine that
changed rows' transactions had in fact been committed even though the rows'
tmin values had not yet been set.

When a query looks at a given row, it needs to figure out whether the
transaction that changed the row has been committed and hence it should pay
attention to the row, or whether on the other hand the transaction is still
in progress or has been aborted and hence the row should be ignored.  If
a tmin value is set, it is known definitively that the row's transaction
has been committed.  However, if tmin is not set, the transaction
referred to in xmin must be looked up in pg_log, and this is what the
backend was spending a lot of time doing during my benchmark.

So, implementing a method suggested by Vadim, I created the following
patch that, the first time a query finds a committed row whose tmin value
is not set, sets it, and marks the buffer where the row is stored as
dirty.  (It works for tmax, too.)  This doesn't result in the boost in
real time performance I was hoping for, however it does decrease backend
CPU usage by up to two-thirds in certain situations, so it could be
rather beneficial in high-concurrency settings.

#ifdef is looking for the wrong value.

Some systems require limits.h to define DBL_MIN.

From: "D'Arcy J.M. Cain" <darcy@druid.net>

our READ lock on pg_index and let others to create indices too !

tupleDesc->attrs[i]->attlen in fastgetiattr.

Remove 'unused variable' from dt.c

Subject: [HACKERS] backend/utils/adt/timestamp.c

Back to this timezone stuff.  The struct tm has a field (tm_gmtoff) which
is the offset from UTC (GMT is archaic BTW) in seconds.  Is this the
value you are looking for when you use timezone?  Note that this applies
to NetBSD but it does not appear to be in either ANSI C or POSIX.  This
looks like one of those things that is just going to have to be hand
coded for each platform.

Why not just store the values in UTC and use localtime instead of
gmtime when retrieving the value?

Also, you assume the time is returned as a 4 byte integer.  In fact,
there is not even any requirement that time be an integral value.  You
should use time_t here.

The input function seems unduly restrictive.  Somewhere in the sources
there is an input function that allows words for months.  Can't we do
the same here?

There is a standard function, difftime, for subtracting two times.  It
deals with cases where time_t is not integral.  There is, however, a
small performance hit since it returns a double and I don't believe
there is any system currently which uses anything but an integral for
time_t.  Still, this is technically the correct and portable thing to do.

The returns from the various comparisons should probably be a bool.