On Tue, Apr 1, 2008 at 8:06 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Yeah, the lack of any formal testing of the extended-Query protocol
> is a real problem. I'm not sure of a good fix, but it bears some
> thinking about. Not only do we not have an automated way to notice
> if we broke funct
-hackers,
As I announced it a couple of months ago, apart from the boxes donated
to PostgreSQLFr (affected to the web team IIRC), Continuent also
donated 7 servers and a Gb/s switch to us for QA testing. It took some
time to set them up but they're now up and running and available.
These servers a
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> Another question is how we can be sure it doesn't happen again. The
> easiest way to test this is probably to have a JDBC test testing this
> exact feature in the future benchfarm. Any comment?
Yeah, the lack of any formal testing of the extended-Quer
On Tue, Apr 1, 2008 at 7:35 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Well, it's not like we have never before changed internal APIs in a
> minor update. (There have been security-related cases where we gave
> *zero* notice of such changes.) Nor am I willing to surrender the
> option to do so
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If anyone squawks we could think about a
>> faster update ...
> That assumes that someone working on using the planner hooks will read
> this thread - which might be reasonable - I guess they number of likely
> users is fairly small
"korry" <[EMAIL PROTECTED]> writes:
> Hmmm... I'm not crazy about libpq printing error messages to stderr.
Me neither, feel free to submit a patch.
The basic problem here is that the obvious fix involves feeding
the message to a PQnoticeProcessor callback, but these messages
occur during connec
Tom Lane wrote:
The main reason I wanted to make some noise about this is to find out
if anyone is actually trying to call eval_const_expressions (or
relation_excluded_by_constraints, which it turned out needed to change
also) from 8.3 add-on code. If anyone squawks we could think about a
fast
On Mon, Mar 31, 2008 at 2:36 AM, NikhilS <[EMAIL PROTECTED]> wrote:
> Hi Alex,
> I was taking a look at this patch to add the pg_dump related changes. Just
> wanted to give you a heads up as this patch crashes if we run "make
> installcheck". Seems there is an issue introduced in the CREATE TABLE
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> Still, the performance regression here is bad enough that I think there
>> is little choice. Comments/objections?
> I agree that we should update stable to fix this performance regression,
> given the gravity of
On Mon, Mar 31, 2008 at 7:02 PM, Rafael Martinez
<[EMAIL PROTECTED]> wrote:
> * Auto-tuning / auto-configuration
Perhaps. Though, people have been saying they were going to do it
since 2001, and yet nothing substantial exists.
> * Easy update-in-place - 'pgmigrator'
This should be upgrade-in-
* Tom Lane ([EMAIL PROTECTED]) wrote:
> The fix is simple: add PlannerInfo to eval_const_expressions's
> parameter list, as was done for estimate_expression_value. I am
> slightly hesitant to do this in a stable branch, since it would break
> any third-party code that might be calling that functio
"Rafael Martinez" <[EMAIL PROTECTED]> writes:
> * Update-in-place optimizations which enhance OLTP performance
> * Improve XML support
These made it into 8.3. There could be more enhancements and more XML support
but you're probably looking at the stuff which already made 8.3.
> * Elimination of
While testing the changes I was making to Pavel's EXECUTE USING patch
to ensure that parameter values were being provided to the planner,
it became painfully obvious that the planner wasn't actually *doing*
anything with them. For example
execute 'select count(*) from foo where x like $1'
David Fetter wrote:
I'd like to take a whack at making set-returning functions returning
SETOF RECORD a little more fun to use. Let's imagine that we have a
table foo and a function returning SETOF RECORD that can return foos.
The call might look something like:
SELECT a, b, c
FROM f(ROW OF foo
Hello
I am preparing a presentation about postgresql for GoOpen2008 [1] in
Norway. I am trying to guess some of the 'main' new features we could
expect to see in the next versions of postgresql.
After reading different documents on Internet, I have this list which I
plan to include in my presenta
Now libpq doesn't have any provision for DETAIL or HINT in its
locally-generated messages at the moment, so we can't just duplicate
the backend message, but we could do something like this example
from elsewhere in libpq:
if (stat_buf.st_mode & (S_IRWXG | S_IRWXO))
{
fprintf(std
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > James Mansion wrote:
> >> (confused) Why can't you use mmap of /dev/zero and inherit the fd
> >> into child processes?
>
> > This is what we do on win32 today. We don't use the sysv emulation
> > layer anymore.
>
> Did we ever find
James Mansion wrote:
I was looking at the notify processing in async.c and I noticed that
kill is called whether or not the
process has been signalled already, and whether or not 'this' process
has signalled the process.
It seems unecessary to me - especially if we are on Win32 and the
pgki
Magnus Hagander <[EMAIL PROTECTED]> writes:
> James Mansion wrote:
>> (confused) Why can't you use mmap of /dev/zero and inherit the fd
>> into child processes?
> This is what we do on win32 today. We don't use the sysv emulation
> layer anymore.
Did we ever find an interlock that makes the win32
James Mansion wrote:
> Tom Lane wrote:
> > Yeah, I would be far more interested in this patch if it avoided
> > needing SysV shmem at all. The problem is to find an adequate
> > substitute for the nattch-based interlock against live children of
> > a dead postmaster.
> >
> >
> (confused) Why ca
James Mansion <[EMAIL PROTECTED]> writes:
> I was looking at the notify processing in async.c and I noticed that
> kill is called whether or not the
> process has been signalled already, and whether or not 'this' process
> has signalled the process.
> It seems unecessary to me -
It's not that e
Pavel,
Honestly, I havn't dug into the real patch all that deeply but I did
notice a few minor issues which I've listed out below. The bigger
question I have for this patch, however, is just how close is it to
PL/pgSQL? If the differences are minor and far between would it be
more reas
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On Mon, Mar 31, 2008 at 9:02 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> It looks like there's no trivial way to get ANALYZE to do things that
>> way, though. heap_release_fetch() doesn't distinguish a DEAD line
>> pointer from an unused or redirected
Stephen Frost <[EMAIL PROTECTED]> writes:
> Right, I had an idea about that but didn't really want to clutter the
> response to the general idea with it. At least on Linux (I don't know
> if it's the case elsewhere..), creating a POSIX shm ends up creating an
> actual 'file' in /dev/shm/, which yo
The proposed EXECUTE USING patch represents a serious performance loss
compared to the traditional method of interpolating parameter values
into the query text, anytime the value of the parameter is important
for planning purposes. We have fixed that in the Protocol BIND message
context by providi
Tom Lane wrote:
Yeah, I would be far more interested in this patch if it avoided needing
SysV shmem at all. The problem is to find an adequate substitute for
the nattch-based interlock against live children of a dead postmaster.
(confused) Why can't you use mmap of /dev/zero and inherit the
Tom Lane wrote:
PFC <[EMAIL PROTECTED]> writes:
Do the parse tree store fully qualified "schema.table" or
"schema.function" ?
They store OIDs.
So, what happens if we reference a temporary table or something else
that requires resolution
down a search path?
I believe Microsoft a
On Mon, Mar 31, 2008 at 11:40 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Morris Goldstein" <[EMAIL PROTECTED]> writes:
> > Suppose I have a database with $PGDATA on /dev/sda, and a tablespace
> > directory on /dev/sdb. Will Postgres start successfully if /dev/sda is
> > mounted and /dev/sdb is not
I was looking at the notify processing in async.c and I noticed that
kill is called whether or not the
process has been signalled already, and whether or not 'this' process
has signalled the process.
It seems unecessary to me - especially if we are on Win32 and the pgkill
is implemented as
a
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Yeah, I would be far more interested in this patch if it avoided needing
> SysV shmem at all. The problem is to find an adequate substitute for
> the nattch-based interlock against live children of a dead postmaster.
Right, I had an idea about that but didn
* Dany DeBontridder ([EMAIL PROTECTED]) wrote:
> I often need in command line to get the code of function, so I make a
> patch for pg_dump, thanks this patch pg_dump is able to dump only one
> functions or all the functions.
First, a couple of general comments about the patch:
#1: You need to re
On Mon, Mar 31, 2008 at 9:02 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> [ Please see if you can stop using the "redirected dead" terminology ]
>
>
Apologies, will keep that in mind. Seems like a hang-over from the past :-)
> Yeah, I think I agree. The page pruning code is set up so that chan
Hello Heikki,
Although the solution could be implemented using views and functions and I am
implementing a reference application using this approach but TDE can greatly
reduce the design and maintenance complexcity. It would also take care of data
protection in backups and archives.
You are c
Stephen Frost <[EMAIL PROTECTED]> writes:
> Finding a way for POSIX shm to do what we need, including Tom's
> concerns, without depending on SvsV shm as a crutch work around, would
> make this change much more reasonable and could be justified as moving
> to a well defined POSIX standard, and means
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Montag, 31. März 2008 schrieb Tom Lane:
>> I've forgotten the context ... what's the whole query and plan again?
>> And which PG version exactly?
> Please see http://archives.postgresql.org/pgsql-hackers/2008-01/msg00048.php
Hm. Now that I think
Chris, et al,
(commit-fest consensus discussion)
* Chris Marcellino wrote:
> In case you haven't had enough, here is another version of the code
> to make Postgres use POSIX shared memory. Along with the issues that
> have already been addressed, this version ensures that orphaned
> backends
Am Montag, 31. März 2008 schrieb Tom Lane:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > OK, first results with this patch are in: The selectivity estimations are
> > adjusted nicely, but the cost calculation doesn't change at all. Before:
>
> I've forgotten the context ... what's the whole q
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> Seems like the redirected-dead line pointers are playing spoil-sport here.
> In this particular example, the deleted tuples may get truncated to
> redirected-dead line pointers. Analyze would report them as empty
> slots and not as dead tuples. So in t
PFC <[EMAIL PROTECTED]> writes:
> Do the parse tree store fully qualified "schema.table" or
> "schema.function" ?
They store OIDs.
> I mean, if table T is mentioned in a parse tree which is stored, and
> the
> table is later dropped and recreated... or a column dropped... what
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> However, we've got boatloads of stuff that needs discussion and
>> consensus-achievement. Please take a look at the queue
>> http://momjian.us/cgi-bin/pgpatches
> Alvaro tried to dump this list into:
> http://wik
[EMAIL PROTECTED] writes:
> Did you commit a patch already, do you want me to rerun the build?
Yes; no --- looks like it'll run by itself in an hour anyay.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> OK, first results with this patch are in: The selectivity estimations are
> adjusted nicely, but the cost calculation doesn't change at all. Before:
I've forgotten the context ... what's the whole query and plan again?
And which PG version exactly?
* Brendan Jurd <[EMAIL PROTECTED]> [080328 11:16]:
> On 29/03/2008, Aidan Van Dyk <[EMAIL PROTECTED]> wrote:
> > * Brendan Jurd <[EMAIL PROTECTED]> [080327 16:36]:
> > >
> > > Looking at the CVS logs, there was definitely commit action in that
> > > timeframe, but none of it is showing up on the
* Server restart and assorted like failover (you need to redo a
global prepare).
Hmm? He's proposing storing the info in a system catalog. That hardly
seems "volatile"; it'll certainly survive a server restart.
Yes, it's in a system catalog.
I agree with the point that th
Hello
I finished this patch.
Proposal: http://archives.postgresql.org/pgsql-hackers/2008-01/msg00696.php
It's compatible with PL/SQL (Oracle) and SQL/PSM (ANSI).
CASE statements is parsed and transformed to CASE expression and
statements paths. Result of CASE expression is used as index to arra
On Mon, Mar 31, 2008 at 1:33 PM, Stuart Brooks <[EMAIL PROTECTED]> wrote:
> I have a table with about 15 million rows which is constantly having
> tuples added to the head and deleted in blocks from the tail to maintain
> the size. The dead tuple count in pg_stat_user_tables tracks the deleted
>
Am Donnerstag, 6. März 2008 schrieb Tom Lane:
> What I propose doing about this is a small variant on Peter's original
> suggestion: compute the estimated selectivity for
> col = 'prefix'
> and clamp the result of prefix_selectivity to be at least that.
OK, first results with this patch ar
On Sun, 30 Mar 2008, Tom Lane wrote:
> Date: Sun, 30 Mar 2008 23:36:24 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], pgsql-hackers list
> Subject: Re: [HACKERS] jaguar is failing
>
> I wrote:
> > [EMAIL PROTECTED] writes:
> >> The only diff is that jaguar is compiling with -
On Sun, 30 Mar 2008, Tom Lane wrote:
> Date: Sun, 30 Mar 2008 15:37:51 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers list
> Subject: Re: [HACKERS] jaguar is failing
>
> [EMAIL PROTECTED] writes:
> > As you can see here:
> > http://www.pgbuildfarm.org/cgi-b
sanjay sharma wrote:
However there are certain fetures which are becoming key for putting postgres
in areas where strong regulatory compliance is required.TDE is very helpful in
storing data where there is strict privacy compliance requirement for example
e.Government and e.Health. All columns
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Well, it's the end of March, and I'm already starting to feel like we've
> been commit-festing forever :-(. At this point I see only one remaining
> patch that seems likely to go in without any further discussion --- that's
> Pavel's plpgsql EXECUTE USING
Hi Alex,
On Sun, Mar 30, 2008 at 7:10 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> (trimmed cc's)
>
> Find attached inherited_constraint_v2.patch
>
> Changes since v1:
> -rebased against latest HEAD
> -changed enum { Anum_pg_constraint_... } back into #define
> Anum_pg_constraint_...
> -remove
52 matches
Mail list logo
