I spent much of today going through here:
https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
Here's what I did:
* Committed patches for four of the items, hopefully resolving those items.
* Moved three items from open to either resolved or a new section
don't need fixing.
* Added
On Fri, Jun 26, 2015 at 04:23:28PM -0400, Robert Haas wrote:
https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
Here's what I did:
* Split up the remaining open items into sections.
* Added a comment with current status to many, but not all, of the
items. (I would have done them
On 09/30/2014 09:10 PM, Gregory Smith wrote:
On 9/29/14, 2:30 PM, Andres Freund wrote:
Can we explain those reasons in the form of documentation?
Yes. Try and benchmark it. It'll be hardware and workload dependant.
I missed this whole thing, and eventually I have to circle back to it.
I
On 09/30/2014 04:56 AM, Heikki Linnakangas wrote:
There seems to be no decisive consensus here. I'm going to put my foot
on the ground and go remove it, as I'm leaning towards that option, and
we need to get the release out. But if someone objects loudly enough to
actually write the
On 9/29/14, 2:30 PM, Andres Freund wrote:
Can we explain those reasons in the form of documentation?
Yes. Try and benchmark it. It'll be hardware and workload dependant.
I missed this whole thing, and eventually I have to circle back to it.
I could do it this week. Could you (or someone
On Sun, Sep 28, 2014 at 11:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
So, can we get Beta3 out now?
If nobody else steps up and says they want to do some performance
testing, I'll push the latest lengths+offsets patch tomorrow.
Are any of the other open
On Mon, Sep 29, 2014 at 5:53 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-29 11:50:19 -0400, Robert Haas wrote:
The items I see are:
- Remove xloginsert_slots/xloginsert_locks GUC - Not yet!!
The text seems to indicate that there's some disagreement on this
point. I don't
On 2014-09-29 11:50:19 -0400, Robert Haas wrote:
The items I see are:
- Remove xloginsert_slots/xloginsert_locks GUC - Not yet!!
The text seems to indicate that there's some disagreement on this
point. I don't have a strong opinion on whether or not to keep the
GUC, but if we're going to
Andres Freund wrote:
On 2014-09-29 11:50:19 -0400, Robert Haas wrote:
- pg_dump fails with --if-exists and blobs
This looks like a 9.4 regression.
Alvaro, IIRC you were looking at this one?
I am.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development,
Dne 29.9.2014 18:00 Magnus Hagander mag...@hagander.net napsal(a):
On Mon, Sep 29, 2014 at 5:53 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-09-29 11:50:19 -0400, Robert Haas wrote:
The items I see are:
- Remove xloginsert_slots/xloginsert_locks GUC - Not yet!!
The text
On 2014-09-29 11:28:07 -0700, Josh Berkus wrote:
On 09/29/2014 08:53 AM, Andres Freund wrote:
- Remove xloginsert_slots/xloginsert_locks GUC - Not yet!!
The text seems to indicate that there's some disagreement on this
point. I don't have a strong opinion on whether or not to keep
Robert Haas robertmh...@gmail.com writes:
The items I see are:
- Remove xloginsert_slots/xloginsert_locks GUC - Not yet!!
The text seems to indicate that there's some disagreement on this
point. I don't have a strong opinion on whether or not to keep the
GUC, but if we're going to remove
Andres Freund and...@2ndquadrant.com writes:
On 2014-09-29 14:44:42 -0400, Tom Lane wrote:
Personally I think a hardwired #define should be plenty. What's the
argument that users will need to tune this at runtime?
That right now it can make quite noticeable differences in
scalability. And
On 2014-09-29 16:35:12 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-09-29 16:16:38 -0400, Tom Lane wrote:
I wonder why it's a fixed constant at all, and not something like
wal_buffers / 8.
Because that'd be horrible performancewise on a system with many
On Tue, Sep 30, 2014 at 3:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The items I see are:
- Remove xloginsert_slots/xloginsert_locks GUC - Not yet!!
The text seems to indicate that there's some disagreement on this
point. I don't have a strong
Hi,
Many open items related to SR are listed on the wiki again.
http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
I clarify the status of those items.
Smart shutdown gets stuck - patch to fix from Fuji Masao
Robert is reviewing and testing the patch I submitted.
I believe that the
Bruce Momjian wrote:
In an attempt to move us toward 8.3 RC1 I have put all open item emails
into the patches queue:
http://momjian.postgresql.org/cgi-bin/pgpatches
FWIW it seems the only remaining issue is the ltree bug #3720:
On Wed, 5 Dec 2007, Alvaro Herrera wrote:
Bruce Momjian wrote:
In an attempt to move us toward 8.3 RC1 I have put all open item emails
into the patches queue:
http://momjian.postgresql.org/cgi-bin/pgpatches
FWIW it seems the only remaining issue is the ltree bug #3720:
In an attempt to move us toward 8.3 RC1 I have put all open item emails
into the patches queue:
http://momjian.postgresql.org/cgi-bin/pgpatches
--
Bruce Momjian [EMAIL PROTECTED]http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 5 Nov 2007 12:47:10 -0500 (EST)
Bruce Momjian [EMAIL PROTECTED] wrote:
In an attempt to move us toward 8.3 RC1 I have put all open item
emails into the patches queue:
http://momjian.postgresql.org/cgi-bin/pgpatches
It would be
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 5 Nov 2007 12:47:10 -0500 (EST)
Bruce Momjian [EMAIL PROTECTED] wrote:
In an attempt to move us toward 8.3 RC1 I have put all open item
emails into the patches queue:
Joshua D. Drake [EMAIL PROTECTED] writes:
On Mon, 5 Nov 2007 12:47:10 -0500 (EST)
Bruce Momjian [EMAIL PROTECTED] wrote:
In an attempt to move us toward 8.3 RC1 I have put all open item
emails into the patches queue:
http://momjian.postgresql.org/cgi-bin/pgpatches
It would be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 05 Nov 2007 18:57:39 +
Gregory Stark [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
On Mon, 5 Nov 2007 12:47:10 -0500 (EST)
Bruce Momjian [EMAIL PROTECTED] wrote:
In an attempt to move us toward 8.3 RC1 I
On Mon, 5 Nov 2007, Gregory Stark wrote:
How many developers have even jumped through the hoops to get wiki accounts?
According to
http://developer.postgresql.org/index.php?title=Special:Listusersgroup=pgdevlimit=500
there are currently 51 members of the group pgdev on the wiki.
--
Spare no
How many developers have even jumped through the hoops to get wiki accounts?
According to
http://developer.postgresql.org/index.php?title=Special:Listusersgroup=pgdevlimit=500
there are currently 51 members of the group pgdev on the wiki.
Well, a lot of those people aren't actually
--On Montag, September 04, 2006 23:58:35 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Updatable views are likewise dead --- we don't have a credible patch or
any short-term path to get one. I hope to see both of these items land
early in the 8.3 devel cycle, but for 8.2, nyet.
Yeah, i don't had
Am Dienstag, 5. September 2006 05:58 schrieb Tom Lane:
A couple of recently discussed FE/BE protocol issues are: not storing a
plan at all for unnamed-statement cases, and thus allowing bind
parameters to be treated as constants; allowing parameter types to go
unresolved rather than throwing
Am Dienstag, 5. September 2006 03:07 schrieb Bruce Momjian:
Here are the open items for 8.2:
http://momjian.postgresql.org/cgi-bin/pgopenitems
This host seems to be offline. What about using the wiki?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Hello,
On Wed, 2006-09-06 at 13:04 +0200, Peter Eisentraut wrote:
http://momjian.postgresql.org/cgi-bin/pgopenitems
This host seems to be offline.
It is suffering from a DNS problem.
What about using the wiki?
Wiki has the same problem, too.
Regards,
--
The PostgreSQL Company
Here are the open items for 8.2:
http://momjian.postgresql.org/cgi-bin/pgopenitems
This host seems to be offline. What about using the wiki?
The problem is with the postgresql.org DNS servers. Something weird is
afoot around the hub.org nameservers, from what I can tell. Servers
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Magnus
Hagander) wrote:
Here are the open items for 8.2:
http://momjian.postgresql.org/cgi-bin/pgopenitems
This host seems to be offline. What about using the wiki?
The problem is with the postgresql.org DNS servers.
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Dienstag, 5. September 2006 05:58 schrieb Tom Lane:
A couple of recently discussed FE/BE protocol issues are: not storing a
plan at all for unnamed-statement cases, and thus allowing bind
parameters to be treated as constants; allowing parameter
Peter Eisentraut wrote:
Am Dienstag, 5. September 2006 03:07 schrieb Bruce Momjian:
Here are the open items for 8.2:
http://momjian.postgresql.org/cgi-bin/pgopenitems
This host seems to be offline. What about using the wiki?
The host is fine. postgresql.org DNS is broken.
Bruce Momjian wrote:
Tom Lane wrote:
Had a bitmap-index patch arrived in my inbox this morning, as had been
promised to me for three weekends running, I might have been willing to
drop all else and review it. But, no patch. This item is dead for 8.2.
Do not even think of suggesting otherwise.
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Dienstag, 5. September 2006 05:58 schrieb Tom Lane:
A couple of recently discussed FE/BE protocol issues are: not storing a
plan at all for unnamed-statement cases, and thus allowing bind
parameters to be treated as constants;
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
A quickie: this item
Store only active XIDs in subtransaction cache
was already done:
I think Bruce is referring to the idea that you and I each arrived at
recently, ie removing subcommitted subxact XIDs from the PGPROC cache
if
Bruce Momjian wrote:
Here are the open items for 8.2:
http://momjian.postgresql.org/cgi-bin/pgopenitems
This list will be continually updated until we release 8.2.
Emacs code example not submitted Gregory Stark [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
This one is
On Mon, Sep 04, 2006 at 11:58:35PM -0400, Tom Lane wrote:
timezone changes: appendix B is out of date, and do we need a list at
all rather than telling people to look at the config file + system view?
Since I did the initial patch I also volunteer to submit documentation for
it. As far as the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Here are the open items for 8.2:
http://momjian.postgresql.org/cgi-bin/pgopenitems
Had a bitmap-index patch arrived in my inbox this morning, as had been
promised to me for three weekends running, I might have been willing to
Andrew Dunstan wrote:
Bruce Momjian wrote:
Here are the open items for 8.2:
http://momjian.postgresql.org/cgi-bin/pgopenitems
This list will be continually updated until we release 8.2.
Emacs code examplenot submitted Gregory Stark [EMAIL PROTECTED]
mailto:[EMAIL
We made pretty good progress today on the open-items list:
ISBN/EAN: I've reviewed this and fixed a couple small issues, it's ready
to commit as soon as the author indicates his assent to license
statement. I'll remove isbn_issn at the same time.
Altering view ownership doesn't work: fixed
Joachim Wieland wrote:
On Mon, Sep 04, 2006 at 11:58:35PM -0400, Tom Lane wrote:
timezone changes: appendix B is out of date, and do we need a list at
all rather than telling people to look at the config file + system view?
Since I did the initial patch I also volunteer to submit
Tom Lane wrote:
We made pretty good progress today on the open-items list:
ISBN/EAN: I've reviewed this and fixed a couple small issues, it's ready
to commit as soon as the author indicates his assent to license
statement. I'll remove isbn_issn at the same time.
Altering view ownership
[EMAIL PROTECTED] (Bruce Momjian) writes:
Here are the open items for 8.2:
http://momjian.postgresql.org/cgi-bin/pgopenitems
This list will be continually updated until we release 8.2.
I've got suggested patches for my item (e.g. - --with-openssl causing
contrib stuff to break on AIX);
Chris Browne wrote:
[EMAIL PROTECTED] (Bruce Momjian) writes:
Here are the open items for 8.2:
http://momjian.postgresql.org/cgi-bin/pgopenitems
This list will be continually updated until we release 8.2.
I've got suggested patches for my item (e.g. - --with-openssl causing
Bruce Momjian [EMAIL PROTECTED] writes:
Chris Browne wrote:
I've got suggested patches for my item (e.g. - --with-openssl causing
contrib stuff to break on AIX); a couple of instances of:
SHLIB_LINK = $(libpq) $(LIBS)
in contrib/dblink/Makefile and contrib/sslinfo seem to do the trick.
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Tom Lane) would
write:
Bruce Momjian [EMAIL PROTECTED] writes:
Chris Browne wrote:
I've got suggested patches for my item (e.g. - --with-openssl causing
contrib stuff to break on AIX); a couple of instances of:
SHLIB_LINK =
I should have a list of open items for 8.2 within 24 hours.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 2: Don't
Here are the open items for 8.2:
http://momjian.postgresql.org/cgi-bin/pgopenitems
This list will be continually updated until we release 8.2.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your
Bruce Momjian wrote:
Here are the open items for 8.2:
http://momjian.postgresql.org/cgi-bin/pgopenitems
This list will be continually updated until we release 8.2.
Thanks for the effort.
A quickie: this item
Store only active XIDs in subtransaction cache
was already done:
Bruce Momjian [EMAIL PROTECTED] writes:
Here are the open items for 8.2:
http://momjian.postgresql.org/cgi-bin/pgopenitems
Had a bitmap-index patch arrived in my inbox this morning, as had been
promised to me for three weekends running, I might have been willing to
drop all else and
Alvaro Herrera [EMAIL PROTECTED] writes:
A quickie: this item
Store only active XIDs in subtransaction cache
was already done:
I think Bruce is referring to the idea that you and I each arrived at
recently, ie removing subcommitted subxact XIDs from the PGPROC cache
if they hadn't stored any
Here are the open items. The only big one left is the handling of a
foreign key problem we have had for a while. We also have issues with
MSVC builds crashing and pg_config --pgxs on Win32 but they are being
actively discussed. I also have a dblink patch on hold.
I think it is time to start
Oh, let me add that this release has gone very smoothly. We are right
on schedule in release timing. I sometimes think the beta period is not
as productive as the development period, but going through it, I am
always reminded how much more polished our final product is because of
the hard work
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
Sent: 14 October 2005 12:57
To: PostgreSQL-development
Subject: [HACKERS] Open items
Has the interactive
documentation been
scanned and merged into the SGML?
Note that when
On Fri, 2005-14-10 at 13:08 +0100, Dave Page wrote:
Note that when we moderate this we now hide away most of the comments
that may suggest improvements for the docs and only leave the ones that
are actually helpful in their own right visible.
If someone wants access to these to review, please
pgindent run and committed.
---
Bruce Momjian wrote:
Here are the open items. The only big one left is the handling of a
foreign key problem we have had for a while. We also have issues with
MSVC builds crashing and
On Wed, Sep 28, 2005 at 06:07:02PM -0400, Neil Conway wrote:
On Wed, 2005-28-09 at 18:35 -0300, Marc G. Fournier wrote:
The problem isn't whether or not they should be changed, the problem is
that they were changed *during* beta AND *against* the direction that
discussion on these changes
On Fri, 2005-30-09 at 17:47 -0500, Jim C. Nasby wrote:
What's wrong with adding pg_cancel_backend(...) RETURNS int as an alias
for the one that returns boolean, and document that it's deprecated and
will be removed in the future.
You can't overload functions based on their return type alone.
Jim C. Nasby wrote:
On Wed, Sep 28, 2005 at 06:07:02PM -0400, Neil Conway wrote:
On Wed, 2005-28-09 at 18:35 -0300, Marc G. Fournier wrote:
The problem isn't whether or not they should be changed, the problem is
that they were changed *during* beta AND *against* the direction that
On Fri, Sep 30, 2005 at 06:58:05PM -0400, Bruce Momjian wrote:
We don't have the ability to have to functions that take the same
parameters and return different results because there is no facility to
decide which function to call based on what return value is expected,
because a simple query
We are basically on hold until we can resolve these items. We need a
beta3, but some of these items might require an initdb (ALTER SCHEMA
RENAME and ROLES), so until we resolve them, we can't go for beta3 and
can't get to an RC candidate. I know Tom is busy right now, but I know
we will get
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marc
G. Fournier
Sent: 28 September 2005 00:50
To: Tom Lane
Cc: Bruce Momjian; PostgreSQL-development; Neil Conway
Subject: Re: [HACKERS] Open items list for 8.1
IMHO, changes like
On Tue, 27 Sep 2005, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
fix ALTER SCHEMA RENAME for sequence dependency, or remove feature
I've posted a proposed patch to fix this. The patch requires an initdb
(to add new sequence functions), so if we do that
On Wed, 2005-28-09 at 18:35 -0300, Marc G. Fournier wrote:
The problem isn't whether or not they should be changed, the problem is
that they were changed *during* beta AND *against* the direction that
discussion on these changes went
I'm not sure what you mean: what is the direction that
Marc G. Fournier wrote:
On Tue, 27 Sep 2005, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
fix ALTER SCHEMA RENAME for sequence dependency, or remove feature
I've posted a proposed patch to fix this. The patch requires an initdb
(to add new
Bruce Momjian pgman@candle.pha.pa.us writes:
It was done quickly to complete it for beta2. Neil talked to Tom and me
about it before he made the change. Obviously we all guessed wrong on
this one.
Personally I had forgotten that pg_cancel_backend was in the previous
release and so there was a
Here is the open item list:
PostgreSQL 8.1 Open Items
=
Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems or
from http://www.postgresql.org/developer/beta.
Bugs
fix pg_dump --clean
Magnus Hagander wrote:
Changes
---
Win32 signal handling patch (Magnus)
Unless someone else steps up to doing this one, please remove it from
the list. I will not have time to dig into this patch before 8.1.
OK, what should the TODO item be?
--
Bruce Momjian
Changes
---
Win32 signal handling patch (Magnus)
Unless someone else steps up to doing this one, please
remove it from
the list. I will not have time to dig into this patch before 8.1.
OK, what should the TODO item be?
A link to the mail should be there, I guess (it's
Magnus Hagander wrote:
Changes
---
Win32 signal handling patch (Magnus)
Unless someone else steps up to doing this one, please
remove it from
the list. I will not have time to dig into this patch before 8.1.
OK, what should the TODO item be?
A link to the mail
The open items list has been reduced nicely:
PostgreSQL 8.1 Open Items
=
Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems or
from http://www.postgresql.org/developer/beta.
Changes
---
fix
Bruce Momjian wrote:
bump major library version number?
Were there any incompatible interface changes?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Peter Eisentraut wrote:
Bruce Momjian wrote:
bump major library version number?
Were there any incompatible interface changes?
No, I don't _think_ so, but we have been bitten by this before, not
because of API change but because of use of libpgport functions called
by libpq in one release
Bruce Momjian pgman@candle.pha.pa.us writes:
fix ALTER SCHEMA RENAME for sequence dependency, or remove feature
I've posted a proposed patch to fix this. The patch requires an initdb
(to add new sequence functions), so if we do that we may as well also
fix the 32/64bit risk mentioned here:
On Tue, 27 Sep 2005, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
fix ALTER SCHEMA RENAME for sequence dependency, or remove feature
I've posted a proposed patch to fix this. The patch requires an initdb
(to add new sequence functions), so if we do that we may as well also
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
fix ALTER SCHEMA RENAME for sequence dependency, or remove feature
I've posted a proposed patch to fix this. The patch requires an initdb
(to add new sequence functions), so if we do that we may as well also
fix the 32/64bit
Here are the open items for 8.1:
PostgreSQL 8.1 Open Items
=
Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems or
from http://www.postgresql.org/developer/beta.
Changes
---
Win32 signal
/contrib move to pgfoundry
Is this actually happening?
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG -
Joshua D. Drake wrote:
/contrib move to pgfoundry
Is this actually happening?
Josh has talked about it, but not sure where he is.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard
Bruce Momjian wrote:
Joshua D. Drake wrote:
/contrib move to pgfoundry
Is this actually happening?
Josh has talked about it, but not sure where he is.
Well pgFoundry isn't ready to have a load of code that is
that actively maintained put on it. It still needs to be moved to
its new
Joshua D. Drake wrote:
Bruce Momjian wrote:
Joshua D. Drake wrote:
/contrib move to pgfoundry
Is this actually happening?
Josh has talked about it, but not sure where he is.
Well pgFoundry isn't ready to have a load of code that is
that actively maintained put on it. It still
Joshua D. Drake [EMAIL PROTECTED] writes:
/contrib move to pgfoundry
Well pgFoundry isn't ready to have a load of code that is
that actively maintained put on it. It still needs to be moved to
its new servers.
The modules proposed to be moved out aren't actively maintained now;
if they were
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
/contrib move to pgfoundry
Well pgFoundry isn't ready to have a load of code that is
that actively maintained put on it. It still needs to be moved to
its new servers.
The modules proposed to be moved out
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
The modules proposed to be moved out aren't actively maintained now;
if they were we'd probably be keeping them in core.
Speaking as a pgFoundry admin, I would say if they aren't actively
maintained we don't want them either.
Changes
---
Win32 signal handling patch (Magnus)
Unless someone else steps up to doing this one, please remove it from
the list. I will not have time to dig into this patch before 8.1.
//Magnus
---(end of broadcast)---
TIP 9: In versions
Tom Lane wrote:
Speaking as a pgFoundry admin, I would say if they aren't actively
maintained we don't want them either. pgFoundry is not a dumping ground
for modules that are dying.
I didn't say they were dying --- the ones we thought were dead, we
already dropped. I was responding
Satoshi Nagayasu wrote:
Bruce Momjian wrote:
I am not sure what to do with this patch. It is missing dump
capability, there is no clause to disable all triggers on a table, and
it uses a table owner check when a super user check is required (because
of referential integrity).
Bruce Momjian pgman@candle.pha.pa.us writes:
Oh, and one trick for disabling triggers in a single session is to do
this:
BEGIN WORK;
ALTER TABLE xx DISABLE TRIGGER ALL
...
ALTER TABLE xx ENABLE TRIGGER ALL
COMMIT WORK;
In this case, the triggers are disabled
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Oh, and one trick for disabling triggers in a single session is to do
this:
BEGIN WORK;
ALTER TABLE xx DISABLE TRIGGER ALL
...
ALTER TABLE xx ENABLE TRIGGER ALL
COMMIT WORK;
In this case, the
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
... but everybody else is locked out completely, because the ALTER takes
an exclusive lock on the table. It's a bit misleading to describe that
as a local change.
The pre-8.1 method was to UPDATE pg_class.reltriggers = 0. Would
On Thu, Jun 30, 2005 at 10:11:56AM -0400, Rod Taylor wrote:
On Thu, 2005-06-30 at 23:02 +0900, Satoshi Nagayasu wrote:
The TODO item is about counting all temporary files, not sorts in
particular. Or at least that's what I thought it meant.
If the DBA have to improve the performance,
Tom Lane wrote:
My patch counts inittapes(), tuplesort_begin_heap() and
tuplesort_begin_index(), and collect them, and sum them through the
stat collector.
Hm, that doesn't seem like quite the right level to be counting at.
Shouldn't you be hacking fd.c to count operations on
Satoshi Nagayasu [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hm, that doesn't seem like quite the right level to be counting at.
Shouldn't you be hacking fd.c to count operations on FD_XACT_TEMPORARY
files?
Why do you think so?
I don't see tuplesort.c is good or not.
But all code of sort
The TODO item is about counting all temporary files, not sorts in
particular. Or at least that's what I thought it meant.
If the DBA have to improve the performance,
DBA will need to know about:
- Which SQL generate a disk sort?
- Size of sorts.
- Changing 'work_mem' value can reduce
On Thu, 2005-06-30 at 23:02 +0900, Satoshi Nagayasu wrote:
The TODO item is about counting all temporary files, not sorts in
particular. Or at least that's what I thought it meant.
If the DBA have to improve the performance,
DBA will need to know about:
- Which SQL generate a disk
* Rod Taylor ([EMAIL PROTECTED]) wrote:
On Thu, 2005-06-30 at 23:02 +0900, Satoshi Nagayasu wrote:
The TODO item is about counting all temporary files, not sorts in
particular. Or at least that's what I thought it meant.
If the DBA have to improve the performance,
DBA will need to
Euler Taveira de Oliveira [EMAIL PROTECTED] writes:
I think that moving rtree_gist, reindexdb, and/or userlock into core
would have to happen before feature freeze,
[snip]
Are you think in putting reindex at core? I was about to submit a
replacement of it but if it goes to bin/scripts (for
Hi Tom,
I think that moving rtree_gist, reindexdb, and/or userlock into core
would have to happen before feature freeze,
[snip]
Are you think in putting reindex at core? I was about to submit a
replacement of it but if it goes to bin/scripts (for example) I can
rearrange the patch. Could I?
Changes
---
integrated auto-vacuum (Alvaro)
ICU locale patch?
That would be Palle, and he's said he thinks he can have it in place in
time. I'll have to update it for win32 build specifics after that, but
that should be ok after the freeze, right?
Please consider removing the question
1 - 100 of 242 matches
Mail list logo