Hi,
I managed to get most of 8.3 built with VS2008EE last night. Ii had to
change some references to msbuild to vsbuild, which I guess is expected
but one compile issue surprised me.
I had to change
#ifdef IPV6_V6ONLY
at backend/libpq/pqcomm.c:386
to:
#if defined(IPV6_V6ONLY)
Are there any hints and tips anywhere on practical issues for testing
and debugging changes to a backend?
(eg how to run it up and feed it SQL ideally without running a
postmaster and execing a back end)
I'm using VS2008 on XP by choice, and I'd like to investigate supporting
something
James Mansion [EMAIL PROTECTED] writes:
Are there any hints and tips anywhere on practical issues for testing
and debugging changes to a backend?
hackers-list archives has a thread or three...
(eg how to run it up and feed it SQL ideally without running a
postmaster and execing a back end)
On Tue, Mar 11, 2008 at 12:41:35PM -0400, Tom Lane wrote:
If I create the same function on my computer running PostgreSQL 8.3.0 and
try
the \df+ then the Source Code shows:
\x09DECLARE
\x09\x09result text;
How about we move it to the wiki. AFAIK we can still lock it down to who
can edit it if we want to
You should confirm you can get the editing granularity you want before
making too many plans here if this is important. The features for locking
down things in Mediawiki are very
On Wed, Mar 12, 2008 at 7:21 AM, James Mansion
[EMAIL PROTECTED] wrote:
Are there any hints and tips anywhere on practical issues for testing
and debugging changes to a backend?
(eg how to run it up and feed it SQL ideally without running a
postmaster and execing a back end)
I'm using
Greg Smith [EMAIL PROTECTED] writes:
Will answer my own question now: the main useful protection available here is
Mediawiki's full protection, which makes pages so they can only be edited by
users with sysops privledges. So in order to make a protected page that, say,
mainly Bruce was
On Tue, 11 Mar 2008, Greg Smith wrote:
On Tue, 11 Mar 2008, Magnus Hagander wrote:
How about we move it to the wiki. AFAIK we can still lock it down to who
can edit it if we want to
You should confirm you can get the editing granularity you want before making
too many plans here if this is
Magnus Hagander wrote:
How about we move it to the wiki. AFAIK we can still lock it down to who
can edit it if we want to
You should confirm you can get the editing granularity you want before
making too many plans here if this is important. The features for locking
down things in
Bruce Momjian wrote:
Magnus Hagander wrote:
It's not. And I personally don't think it would be a problem.
But I think it'll be a lot easier to sell to those who prefer
textfiles in cvs (hello bruce!) if we can.
I don't care who edits it myself, though I can say I get perhaps one
patch
Alvaro Herrera wrote:
Bruce Momjian wrote:
Magnus Hagander wrote:
It's not. And I personally don't think it would be a problem.
But I think it'll be a lot easier to sell to those who prefer
textfiles in cvs (hello bruce!) if we can.
I don't care who edits it myself, though I can
Martijn van Oosterhout [EMAIL PROTECTED] writes:
The other alternative is to convert tabs to spaces on output. Can't
remember why we didn't do that.
Yeah. The idea I had was to invent a parameter specifying the number of
spaces a tab should expand to --- setting this to zero would give you
the
On Wed, Mar 12, 2008 at 10:27:06AM -0400, Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Magnus Hagander wrote:
It's not. And I personally don't think it would be a problem.
But I think it'll be a lot easier to sell to those who prefer
textfiles in cvs (hello
Magnus Hagander wrote:
If you change the text file, I will see the CVS update and update the
HTML --- I will never lose a change because my CVS sees your changes.
That seems like a lot of extra work that should be unnecessary.
I asked before for general reactions, so I will now turn that
I am reading discussion about improving count(*) performance. I have
also seen a TODO for this.
Many people have suggested TRIGGER based solution to the slow count(*)
problem. I looked at the following link which presents the solution
neatly.
http://www.varlena.com/GeneralBits/120.php
But how
On Wed, Mar 12, 2008 at 11:03:13AM -0400, Bruce Momjian wrote:
Magnus Hagander wrote:
If you change the text file, I will see the CVS update and update the
HTML --- I will never lose a change because my CVS sees your changes.
That seems like a lot of extra work that should be
Added to TODO:
* Add array_accum() and array_to_set() functions for arrays
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00464.php
---
Merlin Moncure wrote:
On 8/14/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
Let's move the TODO list to the wiki.
We need it to do a few things:
o We need to be able to pull a text and HTML copies for tarballs
Why? Even if we think the TODO list needs to appear in tarballs (which
is hardly a
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
Let's move the TODO list to the wiki.
We need it to do a few things:
o We need to be able to pull a text and HTML copies for tarballs
Why? Even if we think the TODO list needs to appear in tarballs
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Personally I think it would be just fine if we had only the wiki copy
and forgot about shipping it in tarballs.
The problem with not shipping the TODO file at all is that TODO gives
users a list of all known bugs/missing features in
Pavan Deolasee [EMAIL PROTECTED] writes:
I am sure this must have been discussed before.
Indeed. Apparently you didn't find the threads in which the idea of
having transactions enter delta entries was discussed? Solves both
the locking and the MVCC problems, at the cost that you need to make
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Personally I think it would be just fine if we had only the wiki copy
and forgot about shipping it in tarballs.
The problem with not shipping the TODO file at all is that TODO gives
users a list of all known
Tom Lane wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
I am sure this must have been discussed before.
Indeed. Apparently you didn't find the threads in which the idea of
having transactions enter delta entries was discussed? Solves both
the locking and the MVCC problems, at the cost
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Mar 12, 2008 at 11:03:13AM -0400, Bruce Momjian wrote:
We need it to do a few things:
Actually, the part of the current process that a wiki would fail to
reproduce is the emails that Bruce sends out about TODO changes.
Do we still want those,
On Wed, Mar 12, 2008 at 9:01 PM, Tom Lane [EMAIL PROTECTED] wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
I am sure this must have been discussed before.
Indeed. Apparently you didn't find the threads in which the idea of
having transactions enter delta entries was discussed? Solves
On Wed, Mar 12, 2008 at 11:36:52AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Mar 12, 2008 at 11:03:13AM -0400, Bruce Momjian wrote:
We need it to do a few things:
Actually, the part of the current process that a wiki would fail to
reproduce is the emails
Pavan Deolasee wrote:
I am reading discussion about improving count(*) performance. I have
also seen a TODO for this.
Many people have suggested TRIGGER based solution to the slow count(*)
problem. I looked at the following link which presents the solution
neatly.
On Wed, Mar 12, 2008 at 3:32 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Tom Lane wrote:
This seems to me to be nonsense. You've never maintained the
back-branch versions of the TODO list, so they're out of date anyway
--- ie, they don't account for problems discovered post-release.
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Actually, the part of the current process that a wiki would fail to
reproduce is the emails that Bruce sends out about TODO changes.
Do we still want those, and if so what would we do about it?
Magnus said you can subscribe to a changes
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Mar 12, 2008 at 11:03:13AM -0400, Bruce Momjian wrote:
We need it to do a few things:
Actually, the part of the current process that a wiki would fail to
reproduce is the emails that Bruce sends out about TODO changes.
Do
On Wed, Mar 12, 2008 at 9:14 PM, Mark Mielke [EMAIL PROTECTED] wrote:
If you are talking about automatically doing this for every table - I
have an objection that the performance impact seems unwarranted against
the gain. We are still talking about every insert or update updating
some
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Actually, the part of the current process that a wiki would fail to
reproduce is the emails that Bruce sends out about TODO changes.
Do we still want those, and if so what would we do about it?
Magnus said you can
Dave Page wrote:
On Wed, Mar 12, 2008 at 3:32 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Tom Lane wrote:
This seems to me to be nonsense. You've never maintained the
back-branch versions of the TODO list, so they're out of date anyway
--- ie, they don't account for problems
i have a request ??
Is there any intension of expanding Transaction support into PL/SQL.
this would simplify GUI/client code to know the if a function failed it
roll back the transaction. right now i have to pass back some kind
error message that i look for to see if the transaction
Pavan Deolasee wrote:
On Wed, Mar 12, 2008 at 9:14 PM, Mark Mielke [EMAIL PROTECTED] wrote:
If you are talking about automatically doing this for every table - I
have an objection that the performance impact seems unwarranted against
the gain. We are still talking about every insert or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 12 Mar 2008 12:10:27 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
It is a best effort with our limited resources.
Should we outsource it? It is user-facing :-p
If it was a service we could use for free, we could consider it.
Mark Mielke [EMAIL PROTECTED] writes:
Fine - once per transaction instead of once per insert. Still, if there
is overhead to this (updating a secondary summary table), does it really
make sense to have it for every table?
We certainly wouldn't accept a patch that imposed this overhead on
David BOURIAUD wrote:
Could it be possible to have a syntax that would allow to use create table
like to rename fields as well, for example :
create table any_lib like (some_lib including constraints) with names
(any_code, any_text);
What about coding a replace-stuff-function in pl/* ?
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 12 Mar 2008 12:39:06 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
If it was a service we could use for free, we could consider it.
https://launchpad.net/
http://www.sourceforge.net/
Those
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 12 Mar 2008 12:10:27 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
It is a best effort with our limited resources.
Should we outsource it? It is user-facing :-p
If it was a service we could use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 12 Mar 2008 12:39:06 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
If it was a service we could use for free, we could consider it.
https://launchpad.net/
http://www.sourceforge.net/
Those are a step backward --- they don't
On Wed, Mar 12, 2008 at 9:53 PM, Mark Mielke [EMAIL PROTECTED] wrote:
Fine - once per transaction instead of once per insert. Still, if there is
overhead to this (updating a secondary summary table), does it really make
sense to have it for every table? Most of my tables do not require
Bruce Momjian wrote:
Probably the biggest missing feature for the TODO is the ability to
summarize, group into labeled sections and subsections, and the ability
to move items around, with URL links to more detail. Effectively that
is all the TODO list is.
Oh, like a Wiki page.
--
Alvaro
Pavan Deolasee wrote:
On Wed, Mar 12, 2008 at 9:53 PM, Mark Mielke [EMAIL PROTECTED] wrote:
Fine - once per transaction instead of once per insert. Still, if there is
overhead to this (updating a secondary summary table), does it really make
sense to have it for every table? Most of my
Hackers,
As you may have noticed
(http://archives.postgresql.org/pgsql-general/2008-03/msg00470.php) we
now have a wiki at wiki.postgresql.org that is replacing techdocs
which unfortunately never worked quite as we had hoped in it's current
form.
It has been suggested by members of the web team
Hackers,
We need to update the SoC page:
http://www.postgresql.org/developer/summerofcode
... with new ideas and projects appropriate for PostgreSQL 8.4/8.5.
Please make suggestions. Thanks!
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Justin wrote:
i have a request ??
Is there any intension of expanding Transaction support into PL/SQL.
this would simplify GUI/client code to know the if a function failed it
roll back the transaction. right now i have to pass back some kind
error message that i look for to see if the
FYI, we decided we didn't want this additional capability.
---
Florian G. Pflug wrote:
Kevin Grittner wrote:
On Thu, Aug 23, 2007 at 3:01 PM, in message [EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
The only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 12 Mar 2008 17:16:33 +
Dave Page [EMAIL PROTECTED] wrote:
Hackers,
As you may have noticed
(http://archives.postgresql.org/pgsql-general/2008-03/msg00470.php) we
now have a wiki at wiki.postgresql.org that is replacing techdocs
Tom Lane [EMAIL PROTECTED] writes:
Mark Mielke [EMAIL PROTECTED] writes:
Fine - once per transaction instead of once per insert. Still, if there
is overhead to this (updating a secondary summary table), does it really
make sense to have it for every table?
We certainly wouldn't accept a
On Wed, Mar 12, 2008 at 10:25:53AM -0700, Joshua D. Drake wrote:
On Wed, 12 Mar 2008 17:16:33 +
Dave Page [EMAIL PROTECTED] wrote:
Hackers,
As you may have noticed
(http://archives.postgresql.org/pgsql-general/2008-03/msg00470.php) we
now have a wiki at wiki.postgresql.org that
Dave,
Any thoughts on whether thats a good or bad idea? Any objections?
Well, other than not breaking developer.postgresql.org links, sounds fine
to me.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Joshua D. Drake wrote:
It has been suggested by members of the web team that as the new site
has been setup on a dedicated VM and has been properly integrated with
the rest of our online infrastructure (unlike the current developer
wiki which is basically a quick 'n' dirty install on an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 12 Mar 2008 18:43:47 +0100
Magnus Hagander [EMAIL PROTECTED] wrote:
Based on your description of wiki.postgresql.org it is supposed to
be a replacement for techdocs.
To me, they have different purposes.
Well, we could just add a
On Wed, Mar 12, 2008 at 11:32:16AM -0400, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Personally I think it would be just fine if we had only the wiki copy
and forgot about shipping it in tarballs.
The problem with not shipping the
Joshua D. Drake wrote:
Like I said just observation. I like things compartmentalized but there
is also certainly an argument for redundant resources etc...
Are you saying that you want to keep postgresqldocs.org around?
--
Alvaro Herrera
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 12 Mar 2008 15:08:26 -0300
Alvaro Herrera [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
Like I said just observation. I like things compartmentalized but
there is also certainly an argument for redundant resources etc...
Are you
Magnus Hagander wrote:
On Wed, Mar 12, 2008 at 11:32:16AM -0400, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Personally I think it would be just fine if we had only the wiki copy
and forgot about shipping it in tarballs.
On Wed, 12 Mar 2008, Alvaro Herrera wrote:
That said, we have links to the developer wiki all over the web.
So +1 on moving the developer's wiki to the other one -- but only if the
original URLs continue to work (redirecting to the new site).
While the default URL formatting on the new wiki
On Wed, Mar 12, 2008 at 02:10:08PM -0400, Bruce Momjian wrote:
Magnus Hagander wrote:
On Wed, Mar 12, 2008 at 11:32:16AM -0400, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Personally I think it would be just fine if we had only
On Wed, 12 Mar 2008, Alvaro Herrera wrote:
Are you saying that you want to keep postgresqldocs.org around?
One thing at a time. The new PG wiki looks great, seems like the next
task is to consider merging the developer's content into there. I was
hoping to propose a plan for merging work
Gregory Stark wrote:
In an ideal world I would love to be able to do something like:
CREATE MATERIALIZED VIEW foo AS (select count(*) from bar) WITH INCREMENTAL
UPDATES;
and have that automatically create both a heap to store the count and another
to store the incremental changes. To do this
On Wed, Mar 12, 2008 at 1:19 PM, Josh Berkus [EMAIL PROTECTED] wrote:
Please make suggestions. Thanks!
Let me look at what's new on the TODO, but I'd also like to see some
of the last SoC projects improved, like xlogdump/xlogviewer and some
of the standby stuff. We should also ask Simon if he
Greg Smith [EMAIL PROTECTED] writes:
If all the pages get moved over with the same names (which doesn't seem
like it would be a problem), just changing developer.postgresql.org to
point to wiki.postgresql would seem to be sufficient to keep any existing
links working.
That's not exactly
On Wed, Mar 12, 2008 at 2:33 PM, Jonah H. Harris [EMAIL PROTECTED] wrote:
On Wed, Mar 12, 2008 at 1:19 PM, Josh Berkus [EMAIL PROTECTED] wrote:
Please make suggestions. Thanks!
Let me look at what's new on the TODO, but I'd also like to see some
of the last SoC projects improved, like
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 12 Mar 2008 14:51:06 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Greg Smith [EMAIL PROTECTED] writes:
If all the pages get moved over with the same names (which doesn't
seem like it would be a problem), just changing
Dave Page wrote:
As you may have noticed
(http://archives.postgresql.org/pgsql-general/2008-03/msg00470.php) we
now have a wiki at wiki.postgresql.org that is replacing techdocs
Victory! :)
It has been suggested by members of the web team that as the new site
has been setup on a dedicated
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
That's not exactly what I'd call keeping existing links working.
It is if we point developer. to wiki.
Will that break anything else (ie, is that webserver serving anything
but the wiki)?
On Wed, Mar 12, 2008 at 7:09 PM, Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
That's not exactly what I'd call keeping existing links working.
It is if we point developer. to wiki.
Will that break anything else (ie, is that
Added to TODO for Win32:
o Convert MSVC build system to remove most batch files
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00961.php
---
Andrew Dunstan wrote:
I want to overhaul
Added to TODO:
* Consider a special data type for regular expressions
http://archives.postgresql.org/pgsql-hackers/2007-08/msg01067.php
---
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Could similar logic
Tom's comment on this from the patch queue is that the standard assume
autocommit off, which affect some of your analysis below.
---
Simon Riggs wrote:
The SQL:2003 standard definition of SET TRANSACTION differs in major
Added to TODO:
* Expire published xmin for read-only and idle transactions
http://archives.postgresql.org/pgsql-hackers/2007-09/msg00343.php
---
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
As a fallout
Josh Berkus wrote:
Hackers,
We need to update the SoC page:
http://www.postgresql.org/developer/summerofcode
... with new ideas and projects appropriate for PostgreSQL 8.4/8.5.
Please make suggestions. Thanks!
--Josh
On last year's summer of code page,
On Wed, 12 Mar 2008, Josh Berkus wrote:
Hackers,
We need to update the SoC page:
http://www.postgresql.org/developer/summerofcode
... with new ideas and projects appropriate for PostgreSQL 8.4/8.5. Please
make suggestions. Thanks!
Several our TODO items
On Wed, Mar 12, 2008 at 7:52 PM, Merlin Moncure [EMAIL PROTECTED] wrote:
the read only standby would be what i'd most like to see.
+1 for this one.
Working on setting up a benchfarm could be a good idea too.
--
Guillaume
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Josh Berkus wrote:
We need to update the SoC page:
http://www.postgresql.org/developer/summerofcode
... with new ideas and projects appropriate for PostgreSQL 8.4/8.5.
Many of these items could be suitable:
http://wiki.postgresql.org/wiki/XML_Todo
--
Sent via pgsql-hackers mailing list
Is this a TODO?
---
Florian G. Pflug wrote:
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Currently, we do not assume that either the childXids array, nor the xid
cache in the proc array are sorted by
Is this a TODO? Tom's reply was:
Nonsense. Main transaction exit also takes an exclusive lock, and is
far more likely to be exercised in typical workloads than a
subtransaction abort.
In any case: there has still not been any evidence presented by anyone
that optimizing
Thanks for the feedback.
---
Florian G. Pflug wrote:
Bruce Momjian wrote:
Is this a TODO?
It's for from clear that avoing an exclusive ProcArray lock on subxact
abort will bring a measurable performance benefit, so
Bruce Momjian wrote:
Is this a TODO?
It's for from clear that avoing an exclusive ProcArray lock on subxact
abort will bring a measurable performance benefit, so probably not.
I've actually coded a prototype for this a few months ago, to
check if it would bring any benefit at all, though I
It appears that the older versions of PostgreSQL (7.x) do not consider
the daylight savings time when using TIMESTAMP WITH TIMEZONE but the
most recent versions do (8.x).
Can someone tell me the exact PostgreSQL version number where the
behavior changed?
On Wed, Mar 12, 2008 at 2:44 PM, Peter Eisentraut [EMAIL PROTECTED] wrote:
Josh Berkus wrote:
We need to update the SoC page:
http://www.postgresql.org/developer/summerofcode
... with new ideas and projects appropriate for PostgreSQL 8.4/8.5.
Can we add a project to implement
Pavan Deolasee [EMAIL PROTECTED] writes:
On Thu, Mar 6, 2008 at 6:53 AM, Tom Lane [EMAIL PROTECTED] wrote:
While working on the previously discussed refactoring of
heap_page_prune, I came to the realization that its use of
CacheInvalidateHeapTuple is not just a PANIC risk but simply wrong :-(
84 matches
Mail list logo
