Fujii Masao wrote:
On Thu, Mar 26, 2009 at 12:48 AM, Guillaume Smet
guillaume.s...@gmail.com wrote:
On Wed, Mar 25, 2009 at 2:59 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
I find it hard to imagine a use case for the existing default
behavior.
I thought a bit about it and I think
On Wednesday 25 March 2009 23:55:06 Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Josh Berkus wrote:
That was 6 months ago. I doubt anyone remembers it. Make another
announcement, so that when people get the unsubscribed announcement,
they're not confused.
Done.
On Thu, Mar 26, 2009 at 2:51 AM, Fujii Masao masao.fu...@gmail.com wrote:
What does the default mean? You mean that new trigger should use
the existing trigger option character (-t)?
Yes, that's my point.
I understand it seems weird to switch the options but I'm pretty sure
a lot of persons
Hi.
Here is a patch for pg_dump Commenting on a composite-type column.
This patch is for Todo item named Add dumping of comments on index
columns and composite type columns.
As Tom Lane said, this patch is not for dumping comments on index columns,
but only for comment on composite-type column.
Guillaume Smet wrote:
On Wed, Mar 25, 2009 at 5:48 PM, hubert depesz lubaczewski
dep...@depesz.com wrote:
I would love to get it, but when I suggested it some time in the past
Tom shot it down as bad idea.
http://archives.postgresql.org/message-id/20071016132131.ga4...@depesz.com
I agree
Bruce Momjian wrote:
I thought the logical solution to this was to place the socket in a
secure directory and not bother with SSL at all.
How would a client algorithmically determine whether the server socket
was in a secure directory?
--
Sent via pgsql-hackers mailing list
Hi,
Just to warn people that I'm making a comprehensive proof reading of
the release notes.
Here are the first comments:
- This was available previously via a configure
--enable-integer-datetimes (Neil Conway) - I don't think we need
Neil's name in the details
- New semi- and ansi-joins (Tom) -
Tatsuhito Kasahara kasahara.tatsuh...@oss.ntt.co.jp wrote:
So, main purpose of displaying the last query string is ..
- check whether idle in transaction (running long time) process
after SOME SQL is exists or not.
- check the content of SOME SQL.
The feature could be achieved by an
Hi,
Guillaume Smet wrote:
On Thu, Mar 26, 2009 at 2:51 AM, Fujii Masao masao.fu...@gmail.com wrote:
What does the default mean? You mean that new trigger should use
the existing trigger option character (-t)?
Yes, that's my point.
I understand it seems weird to switch the options but I'm
On Thu, 2009-03-26 at 08:32 +0100, Guillaume Smet wrote:
On Thu, Mar 26, 2009 at 2:51 AM, Fujii Masao masao.fu...@gmail.com wrote:
What does the default mean? You mean that new trigger should use
the existing trigger option character (-t)?
Yes, that's my point.
I understand it seems
ITAGAKI Takahiro wrote:
The feature could be achieved by an extension module using new executor
hooks in 8.4. It is just like contrib/pg_stat_statements;
Well, it is a good idea.
Displaying last-query-string may be useful, but it is not a feature for
general purpose. So, it may be an external
On Wednesday 25 March 2009 23:17:41 Robert Haas wrote:
With respect to this item:
Disable appending of the epoch date/time when '%' escapes are missing
in log_filename (Robert Haas)
I might suggest explaining it this way:
This change makes it easier to use PostgreSQL in conjunction with an
Bruce,
Here is the second set of comments:
- pg_hba.conf: it seems to me the format has changed which may break
existing pg_hba.conf (it broke the default one of the RPM packaging).
We should make it very visible as the format hasn't changed for a
while. I suppose we'll put it at the top but I
Hi Simon.
On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs si...@2ndquadrant.com wrote:
Earlier, we discussed having a single trigger file that contains an
option rather than two distinct trigger files. That design is better
because it allows the user to choose at failover time, rather than
Would someone please review this?
Since we are about to go to beta, it may be that no one is up for
reviewing it right now. But I've added it to the CommitFest page for
the next CommitFest.
http://wiki.postgresql.org/wiki/CommitFest_2009-First
...Robert
--
Sent via pgsql-hackers mailing
Hi.
Since we are about to go to beta, it may be that no one is up for
reviewing it right now. But I've added it to the CommitFest page for
the next CommitFest.
Thank you.
I wait until the next CommitFest.
-
Taro Minowa(Higepon)
http://www.monaos.org/
A user on IRC reported a crash (backend segfault) in GiST insertion
(in 8.3.5 but I can reproduce this in today's HEAD) that turns out
to be due to misbehaviour of gist_box_picksplit.
The nature of the problem is this: if gist_box_picksplit doesn't find
a good disposition on the first try, then
On Thu, Mar 26, 2009 at 2:16 PM, Srinath K srinat...@persistent.co.in wrote:
I'm implementing global index - an index that indexes all tables in an
inheritance hierarchy. For complete feature description, please refer
README.user.
...
This e-mail may contain privileged and confidential
Srinath K srinat...@persistent.co.in writes:
DISCLAIMER
==
This e-mail may contain privileged and confidential information which
is the property of Persistent Systems Ltd.
If you want to submit patches, you're really going to have to get your
corporate lawyers to let you submit them
On Thu, Mar 26, 2009 at 5:39 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
A user on IRC reported a crash (backend segfault) in GiST insertion
(in 8.3.5 but I can reproduce this in today's HEAD) that turns out
to be due to misbehaviour of gist_box_picksplit.
Andrew, thank you for the
By chance I discovered that this query in the regression tests
SELECT ntile(NULL) OVER (ORDER BY ten, four), ten, four FROM tenk1 LIMIT 2;
stops working if work_mem is small enough: it either dumps core or
delivers wrong answers depending on platform.
After some tracing I found out the reason.
Lawrence, Ramon ramon.lawre...@ubc.ca writes:
Attached is a patch that will disable the physical-tlist optimization
for hash join if the number of batches is greater than 1. The patch and
performance results were created by Michael Henderson (graduate
student).
I've applied the attached
On Thu, 2009-03-26 at 12:57 -0400, Tom Lane wrote:
If work_mem is small enough, that means the tuplestore is
forced into dump-to-disk mode, which means it releases all its
in-memory tuples. And guess what: the ScanTupleSlot is pointing at
one of those, it doesn't have its own copy of the
On Wed, 2009-03-25 at 18:08 +0900, Tatsuhito Kasahara wrote:
If we can also check previous query_string of idle-in-transaction,
it is useful for analysis of long transaction problem.
I'm more interested in the problem itself. Why do you think there is a
problem and why does knowing this help
Why do we have separate parameters for autovacuum and vacuum, except for
maintenance_work_mem?
Should we also have autovacuum_work_mem?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list
On Thu, Mar 26, 2009 at 7:34 PM, Simon Riggs si...@2ndquadrant.com wrote:
Why do we have separate parameters for autovacuum and vacuum, except for
maintenance_work_mem?
Should we also have autovacuum_work_mem?
We already discussed it here:
Since Bruce seems not to be in a hurry to update his open-items mailbox,
I've taken the liberty of adding entries for all the items that I think
are relevant for 8.4 to the wiki page:
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
Anybody who wants to start cleaning these things up,
Simon Riggs si...@2ndquadrant.com writes:
Sounds very similar to the solution that you just removed from the hash
join code for performance reasons. Flushing memory when we overflow
sounds like an artifact from the time when tuplestore split from
tuplesort. Can't we keep the appropriate rows
Tom Lane wrote:
Since Bruce seems not to be in a hurry to update his open-items mailbox,
I've taken the liberty of adding entries for all the items that I think
are relevant for 8.4 to the wiki page:
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
Anybody who wants to start
Magnus Hagander mag...@hagander.net writes:
Tom Lane wrote:
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
Anybody who wants to start cleaning these things up, have at it.
We were in agreement to move the Win32 namespace issue to the TODO list,
right? Unless anybody objects, I'll
On Thu, 2009-03-26 at 19:46 +0100, Guillaume Smet wrote:
On Thu, Mar 26, 2009 at 7:34 PM, Simon Riggs si...@2ndquadrant.com wrote:
Why do we have separate parameters for autovacuum and vacuum, except for
maintenance_work_mem?
Should we also have autovacuum_work_mem?
We already
Gregory Stark st...@enterprisedb.com writes:
Another thought now though. What if someone updates the pg_index entry --
since we never reset indcheckxmin then the new tuple will have a new xmin and
will suddenly become invisible again for no reason.
Fixing this for REINDEX is fairly
On Thu, Mar 26, 2009 at 7:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Gregory Stark st...@enterprisedb.com writes:
Another thought now though. What if someone updates the pg_index entry --
since we never reset indcheckxmin then the new tuple will have a new xmin
and
will suddenly become
Greg Stark st...@enterprisedb.com writes:
On Thu, Mar 26, 2009 at 7:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I realized what was bothering me about that patch: it could reset
indcheckxmin too soon, ie, while there are still transactions that
shouldn't use the index.
That doesn't sound like
I agree with Magnus' original reasoning: we can have more than one
autovacuum process, so we may have autovacuum_max_workers active and so
the work mem they use must be smaller. For maintenance_work_mem we would
typically only have one session using it at any time, so we either have
to start
On Wed, 2009-03-25 at 13:25 -0400, Tom Lane wrote:
I am not sure whether the statement in 52.5 is still accurate, though.
We have an API definition by which extractQuery can distinguish all
match from no match. If we just legislate that some match isn't
a valid behavior for zero-key queries,
On Thu, 2009-03-26 at 13:43 -0700, Josh Berkus wrote:
I agree with Magnus' original reasoning: we can have more than one
autovacuum process, so we may have autovacuum_max_workers active and so
the work mem they use must be smaller. For maintenance_work_mem we would
typically only have one
Simon,
Hmmm, perhaps the right way to do this is to have a user called
autovacuum that is used to perform autovacuums.
This makes sense, depending on which autovac params actually get picked
up from the session.
Seems like a nice small change for 8.4?
Hmmm. Maybe not small enough.
--On Donnerstag, März 26, 2009 13:43:45 -0700 Josh Berkus
j...@agliodbs.com wrote:
I actually have a client who does both automated and manual vacuums.
Having two settings would definitely be convenient for them.
I often found people doing this running within a) their own superuser with
Hi Kedar,
First of all, congratulations for the excellent work.
I have some comments and questions.
In get_relevent_partition (btw, relevant is spelled with an a) you are
maintaining 2 lists. I guess this is only useful for multi-column
partitions, right?
If you have a single column partition
On Saturday 21 March 2009 01:01:57 Sergey Burladyan wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Care to submit a patch?
this is it, i divide it into two, first is change source and second is
change ru.po file for psql.
I have now committed a more extensive pluralization, but
On Wed, 2009-03-25 at 19:31 -0400, Tom Lane wrote:
* I'd also like to come to some agreement about getting rid of the
fail-on-NULL-scankey problem in newScanKey(). As I noted in the
comment there, we could make that work cleanly if we are willing to
assume that all GIN-indexable operators are
Fujii Masao masao.fu...@gmail.com writes:
Set the maximum number of times to retry the copy or link command
maxretries option of pg_standby is documented as above, but actually
indicates the maximum number of times to *try* the copy or link command.
So, if -r 0 is specified, pg_standby always
Jeff Davis pg...@j-davis.com writes:
Also, if extractQuery is non-strict, shouldn't we call it and see if it
returns some useful keys?
Perhaps. One risk factor for approaching it that way is that there are
probably a lot of opclasses out there that haven't bothered to mark
these functions
Simon Riggs si...@2ndquadrant.com writes:
On Thu, 2009-03-26 at 13:43 -0700, Josh Berkus wrote:
That said, it would be unnecessary if I could use ROLES to set
parameters more reliably
Hmmm, perhaps the right way to do this is to have a user called
autovacuum that is used to perform
On 3/26/09 4:10 PM, Tom Lane wrote:
Simon Riggssi...@2ndquadrant.com writes:
On Thu, 2009-03-26 at 13:43 -0700, Josh Berkus wrote:
That said, it would be unnecessary if I could use ROLES to set
parameters more reliably
Hmmm, perhaps the right way to do this is to have a user called
map_sql_value_to_xml_value() currently errors out with a more or less vague
error message, when a date or timestamp datatype with an infinite value is
converted to XML. This is likely to create some confusion, especially when
you have to debug some complex procedures and involved XML
Robert Haas wrote:
OK, I am all wet. I now understand why the editing is the
time-consuming part of this job. On the plus side it is probably
possible to parallelize it to some degree by splitting the list into N
pieces after the remove insignificant items step.
With respect to this item:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
OK, I am all wet. I now understand why the editing is the
time-consuming part of this job. On the plus side it is probably
possible to parallelize it to some degree by splitting the list into N
pieces after the remove
Josh Berkus wrote:
All,
In any case, the release notes aren't normally a bottleneck. I still
think that Bruce had his priorities out of whack in not cleaning up
his open-items list before doing this. If he had done so, nobody
would have noticed how long the notes took.
Yes,
Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Yes, although Bruce *has* asked for help in cleaning up the open-items list.
I spent several hours on that on Saturday, and more or less got the bird
in response... the way Bruce has that page set up, only he can do any
actual item
Peter Eisentraut wrote:
Bruce Momjian wrote:
I thought the logical solution to this was to place the socket in a
secure directory and not bother with SSL at all.
How would a client algorithmically determine whether the server socket
was in a secure directory?
You have to configure your
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
In any case, the release notes aren't normally a bottleneck.
...
Could I respectfully request people make an effort to change the
subject lines when the thread radically moves away from its
original purpose? Modern mail systems don't thread
On Thu, Mar 26, 2009 at 8:31 PM, Bruce Momjian br...@momjian.us wrote:
Josh Berkus wrote:
All,
In any case, the release notes aren't normally a bottleneck. I still
think that Bruce had his priorities out of whack in not cleaning up
his open-items list before doing this. If he had done
Robert Haas wrote:
On Thu, Mar 26, 2009 at 8:31 PM, Bruce Momjian br...@momjian.us wrote:
Josh Berkus wrote:
All,
In any case, the release notes aren't normally a bottleneck. ?I still
think that Bruce had his priorities out of whack in not cleaning up
his open-items list before
Quick patch to fix the fact that the EXPLAIN ANALYZE VERBOSE is clobbering
tab-completion for ANALYZE VERBOSE.
--
Greg Sabino Mullane g...@endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
Index: tab-complete.c
===
RCS file:
Robert Haas wrote:
On Thu, Mar 26, 2009 at 8:31 PM, Bruce Momjian br...@momjian.us wrote:
Josh Berkus wrote:
All,
In any case, the release notes aren't normally a bottleneck. ?I still
think that Bruce had his priorities out of whack in not cleaning up
his open-items list before
Robert Haas wrote:
On Thu, Mar 26, 2009 at 9:28 PM, Bruce Momjian br...@momjian.us wrote:
At this point I think we are just trying to get a list of items that
need to be done before we can release beta. ?Very little, if anything,
should be getting added to that list at this point.
You
On Thu, Mar 26, 2009 at 9:35 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Thu, Mar 26, 2009 at 8:31 PM, Bruce Momjian br...@momjian.us wrote:
Josh Berkus wrote:
All,
In any case, the release notes aren't normally a bottleneck. ?I still
think that Bruce had his
Robert Haas wrote:
On Thu, Mar 26, 2009 at 8:30 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
OK, I am all wet. ?I now understand why the editing is the
time-consuming part of this job. ?On the plus side it is probably
possible to
Guillaume Smet wrote:
Hi,
Just to warn people that I'm making a comprehensive proof reading of
the release notes.
Here are the first comments:
- This was available previously via a configure
--enable-integer-datetimes (Neil Conway) - I don't think we need
Neil's name in the details
-
On Thu, Mar 26, 2009 at 9:28 PM, Bruce Momjian br...@momjian.us wrote:
At this point I think we are just trying to get a list of items that
need to be done before we can release beta. Very little, if anything,
should be getting added to that list at this point.
You can say that, but things
Guillaume Smet wrote:
Bruce,
Here is the second set of comments:
- pg_hba.conf: it seems to me the format has changed which may break
existing pg_hba.conf (it broke the default one of the RPM packaging).
We should make it very visible as the format hasn't changed for a
while. I suppose
On Thu, Mar 26, 2009 at 8:30 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
OK, I am all wet. I now understand why the editing is the
time-consuming part of this job. On the plus side it is probably
possible to parallelize it to some
On Thu, Mar 26, 2009 at 9:36 PM, Bruce Momjian br...@momjian.us wrote:
I'm sure they will. But the current problem is getting beta released
in the first place, and AFAICS we're all waiting for you.
As Tom said, it is more the open items that we are waiting on, not the
release notes, but if
Robert Haas wrote:
On Thu, Mar 26, 2009 at 9:36 PM, Bruce Momjian br...@momjian.us wrote:
I'm sure they will. ?But the current problem is getting beta released
in the first place, and AFAICS we're all waiting for you.
As Tom said, it is more the open items that we are waiting on, not the
On Fri, Mar 27, 2009 at 1:44 AM, Bruce Momjian br...@momjian.us wrote:
- Previously EXPLAIN VERBOSE output an internal representation of the
query plan - s/output/outputs/ ?
The existing wording seems correct.
I think Bruce's phrasing was in the past tense. It's a bit weird
because the verb
Andrew Dunstan wrote:
This URL http://www.pgbuildfarm.org/cgi-bin/typedefs.pl gives a
typedef list that is (currently) the combined result from three fairly
different buildfarm members:
dungbeetle | 2009-03-22 06:44:01
brown_bat | 2009-03-21 13:00:58
dawn_bat | 2009-03-21 14:23:40
Greg Stark wrote:
On Fri, Mar 27, 2009 at 1:44 AM, Bruce Momjian br...@momjian.us wrote:
- Previously EXPLAIN VERBOSE output an internal representation of the
query plan - s/output/outputs/ ?
The existing wording seems correct.
I think Bruce's phrasing was in the past tense. It's a
laser wrote:
hi all,
I read the code that it seems easy for the cursor in plpgsql to return
ROW_COUNT after
MOVE LAST etc. The SPI_processed variable already there, but didn't put
it into estate
structure, any reason for that?
thanks and best regards
Sorry, we have decided
bruce wrote:
Andrew Dunstan wrote:
This URL http://www.pgbuildfarm.org/cgi-bin/typedefs.pl gives a
typedef list that is (currently) the combined result from three fairly
different buildfarm members:
dungbeetle | 2009-03-22 06:44:01
brown_bat | 2009-03-21 13:00:58
dawn_bat |
Hi,
On Thu, Mar 26, 2009 at 8:54 PM, Guillaume Smet
guillaume.s...@gmail.com wrote:
Hi Simon.
On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs si...@2ndquadrant.com wrote:
Earlier, we discussed having a single trigger file that contains an
option rather than two distinct trigger files. That
Bruce Momjian wrote:
bruce wrote:
Andrew Dunstan wrote:
This URL http://www.pgbuildfarm.org/cgi-bin/typedefs.pl gives a
typedef list that is (currently) the combined result from three fairly
different buildfarm members:
dungbeetle | 2009-03-22 06:44:01
brown_bat | 2009-03-21
2009/3/27 Tom Lane t...@sss.pgh.pa.us:
By chance I discovered that this query in the regression tests
SELECT ntile(NULL) OVER (ORDER BY ten, four), ten, four FROM tenk1 LIMIT 2;
stops working if work_mem is small enough: it either dumps core or
delivers wrong answers depending on platform.
Andrew Dunstan wrote:
Andrew, this is disappointing news. When you talked about generating an
typedef list from the buildfarm, you were saying how great it would be
--- now a year later you post:
It'd be nice to get that dealt with before we run pg_indent, but it's
not like we'd
Robert Haas robertmh...@gmail.com writes:
On Thu, Mar 26, 2009 at 10:11 PM, Bruce Momjian br...@momjian.us wrote:
I think pushing pre-existing bugs to 8.5 is a mistake,
What is the threshold for has to be fixed before we can go to beta
versus has to be fixed before release?
I did not by any
On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas robertmh...@gmail.com wrote:
That includes a whole slough of patches that weren't submitted until
after November 1st and which I think should probably be bumped en
masse to 8.5:
postgresql.conf: patch to have ParseConfigFile report all parsing
On Fri, Mar 27, 2009 at 2:44 AM, Bruce Momjian br...@momjian.us wrote:
Guillaume Smet wrote:
- Add -M (query mode) to /contrib/pgbench (ITAGAKI Takahiro)
-Itagaki san's name inconsistent with other mentions of his name
Above all fixed, thanks.
I think you fixed this one the wrong way.
It
Bruce Momjian br...@momjian.us writes:
Frankly, I don't remember anyone complaining we didn't find any typedefs
in pgindent,
There are lots and lots of places where it's obvious that pgindent
was misinformed on the subject, because it puts in a space where there
should not be one, eg typename *
79 matches
Mail list logo
