2010/6/17 Greg Stark gsst...@mit.edu:
On Thu, Jun 17, 2010 at 4:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I actually wonder if we shouldn't automatically tag plpgsql functions
with the search_path in effect at the time of their creation (as if
the user had done ALTER FUNCTION ... SET
On Fri, 2010-06-18 at 10:20 +0900, Fujii Masao wrote:
On Fri, Jun 18, 2010 at 2:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
We should make trace_recovery_messages available only when
the WAL_DEBUG macro was defined?
No, because it's used in a lot
On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera wrote:
Excerpts from Mark Wong's message of mié jun 16 23:54:52 -0400 2010:
==Usability review==
Read what the patch is supposed to do, and consider:
Does the patch actually implement that?
How does it play with ON_ERROR_STOP/ROLLBACK?
On Fri, Jun 18, 2010 at 04:33, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Hi,
We don't have any statistic views for walsenders in SR's master server
in 9.0, but such views would be useful to monitor and manage standby
servers from the master server. I have two ideas for the
On Thu, 2010-06-17 at 16:13 +0900, Fujii Masao wrote:
Hi,
In the following debug message in RemoveOldXlogFiles(), the variables
log and seg don't indicate LSN, so we should use %u instead of %X?
elog(DEBUG2, removing WAL segments older than %X/%X, log, seg);
I attached the patch to
On Thu, 2010-06-17 at 13:33 -0400, Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com writes:
On Wed, Jun 16, 2010 at 12:24 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
This is because pg_archivecleanup puts the line break \n in the head of
debug message. Why should we do so?
On 18 June 2010 09:31, Jean-Baptiste Quenot j...@caraldi.com wrote:
2010/6/17 Greg Stark gsst...@mit.edu:
On Thu, Jun 17, 2010 at 4:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I actually wonder if we shouldn't automatically tag plpgsql functions
with the search_path in effect at the time of
On Fri, 2010-06-18 at 11:33 +0900, Takahiro Itagaki wrote:
1. Add another system view for walsenders, ex. pg_stat_replication.
It would show pid, remote host, and sent location for each walsender.
I prefer this option. I consider it an omission that we should correct.
Not sure I understand
On 18/06/10 13:41, Simon Riggs wrote:
On Fri, 2010-06-18 at 11:33 +0900, Takahiro Itagaki wrote:
1. Add another system view for walsenders, ex. pg_stat_replication.
It would show pid, remote host, and sent location for each walsender.
I prefer this option. I consider it an omission that
Simon Riggs si...@2ndquadrant.com writes:
I think it would be more helpful if it showed a filename. Shall we
change that?
The point of the committed change was to make that message look like
every other one in xlog.c that shows a log/seg pair.
If we were going to start redesigning the printout
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Let's discuss what the best possible user interface for the information
would be first, and then decide if we need/want to force an initdb for
that. We have pg_upgrade now, that makes initdb less painful, and if
it's just a new
A recent discussion with a developer convinced me that enums would be
much more useful if new values could be added to the label list easily
without changing the stored values. Given the current representation of
enums as a globally unique oid, I think this is just about impossible if
the
On Fri, Jun 18, 2010 at 11:50 AM, Andrew Dunstan and...@dunslane.net wrote:
Then set the
first value at 8 * p, then next at 9* p and so on. This is designed to
allow more space to add labels at the beginning and end of the list, where
this is more likely. Adding a label would be a matter of
Robert Haas wrote:
On Fri, Jun 18, 2010 at 11:50 AM, Andrew Dunstan and...@dunslane.net wrote:
Then set the
first value at 8 * p, then next at 9* p and so on. This is designed to
allow more space to add labels at the beginning and end of the list, where
this is more likely. Adding a label
On Jun 18, 2010, at 9:07 AM, Robert Haas wrote:
Then set the
first value at 8 * p, then next at 9* p and so on. This is designed to
allow more space to add labels at the beginning and end of the list, where
this is more likely. Adding a label would be a matter of finding the labels
adjacent
On Jun 18, 2010, at 9:34 AM, Andrew Dunstan wrote:
I'd be perfectly happy to hear a reasonable alternative. Assuming we use some
integer representation, given two labels represented by n and n+1, we can't
add a label between them without rewriting the tables that use the type,
whether it's
On Fri, 2010-06-18 at 12:34 -0400, Andrew Dunstan wrote:
Robert Haas wrote:
On Fri, Jun 18, 2010 at 11:50 AM, Andrew Dunstan and...@dunslane.net
wrote:
Then set the
first value at 8 * p, then next at 9* p and so on. This is designed to
allow more space to add labels at the
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
I like the idea of being able to modify enums on the fly, but I'm
skeptical of an implementation that won't always work. Maybe it's
still better than what we have now, but it seems grotty.
I'd be perfectly happy to hear a
David E. Wheeler wrote:
What's the likelihood of a failure?
Constructing a failure case would be simple. In practice, I suspect it
would be very low.
And would the position of the new label (represented by its internal number) be
predictive? IOW, would updating the same varenumtype in
David E. Wheeler wrote:
On Jun 18, 2010, at 9:34 AM, Andrew Dunstan wrote:
I'd be perfectly happy to hear a reasonable alternative. Assuming we use some
integer representation, given two labels represented by n and n+1, we can't add
a label between them without rewriting the tables that
I vote for % .
I'd vote for %, out of those. Reason: the operator isn't commutative,
in fact left and right inputs aren't even the same datatype, so a glyph
that looks asymmetric seems more natural.
+1 on %
(Frankly, as long as it isn't or | I can live with it ... )
--
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
I like the idea of being able to modify enums on the fly, but I'm
skeptical of an implementation that won't always work. Maybe it's
still better than what we have now, but it seems grotty.
I'd
On Fri, Jun 18, 2010 at 12:59 PM, Andrew Dunstan and...@dunslane.net wrote:
You are just bumping up the storage cost. Part of the attraction of enums is
their efficiency.
What's efficient about them? Aren't we using 4 bytes to store a value
that will nearly always fit in 2, if not 1?
--
On Jun 18, 2010, at 10:03 AM, Josh Berkus wrote:
I'd vote for %, out of those. Reason: the operator isn't commutative,
in fact left and right inputs aren't even the same datatype, so a glyph
that looks asymmetric seems more natural.
+1 on %
+1 from me, too.
Best,
David
--
Sent via
Robert Haas wrote:
On Fri, Jun 18, 2010 at 12:59 PM, Andrew Dunstan and...@dunslane.net wrote:
You are just bumping up the storage cost. Part of the attraction of enums is
their efficiency.
What's efficient about them? Aren't we using 4 bytes to store a value
that will nearly
On Fri, Jun 18, 2010 at 1:59 PM, Andrew Dunstan and...@dunslane.net wrote:
This was debated when we implemented enums. As between 1,2 and 4 there is
often not much to choose, as alignment padding makes it pretty much the
same. But any of them are more efficient than storing a numeric value or
On Fri, Jun 18, 2010 at 6:26 PM, David E. Wheeler da...@kineticode.com wrote:
+1 from me, too.
1 isn't a valid character in a postgres operator
:P
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Jun 18, 2010, at 11:20 AM, Greg Stark wrote:
+1 from me, too.
1 isn't a valid character in a postgres operator
Dammit!
This reminds me, I wanted to ask one more thing:
We don't have a slice operator for arrays; would we be happy with % being such
an operator in a future version? And,
On Fri, Jun 18, 2010 at 6:17 PM, Andrew Dunstan and...@dunslane.net wrote:
Tom Lane wrote:
Insert a sort order column into pg_enum, and rearrange the values in
that whenever the user wants to add a new value in a particular place.
+1 I was going to say exactly the same thing.
You give up
Hi to all.
Please take a look at the initial comment contained into the logtape.c file:
http://doxygen.postgresql.org/logtape_8c-source.html
Almost at the beginning of that file, it is affirmed that implementing
tapes on disk (quote: /by creating a separate file for each tape/)
will require
On Fri, Jun 18, 2010 at 2:36 PM, mac_man2...@hotmail.it
mac_man2...@hotmail.it wrote:
Please take a look at the initial comment contained into the logtape.c file:
http://doxygen.postgresql.org/logtape_8c-source.html
Almost at the beginning of that file, it is affirmed that implementing tapes
Il 18/06/2010 21:00, Robert Haas ha scritto:
On Fri, Jun 18
Did you read the rest of the comment? It explains how the code avoids this...
Robert, thanks for your reply.
I read the rest of the document, but please take in account that my
question wasn't about avoiding.
My question is in
On Fri, Jun 18, 2010 at 3:11 PM, mac_man2...@hotmail.it
mac_man2...@hotmail.it wrote:
Il 18/06/2010 21:00, Robert Haas ha scritto:
On Fri, Jun 18
Did you read the rest of the comment? It explains how the code avoids
this...
Robert, thanks for your reply.
I read the rest of the document,
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
Insert a sort order column into pg_enum, and rearrange the values in
that whenever the user wants to add a new value in a particular place.
You give up cheap comparisons in exchange for flexibility. I think lots
of people would
Robert Haas robertmh...@gmail.com writes:
On Fri, Jun 18, 2010 at 3:11 PM, mac_man2...@hotmail.it
mac_man2...@hotmail.it wrote:
I repeat my question. Tuplesort.c and logtape.c DO implement tapes on disk
and currently they do not request 2x or 4x of the input space: so, again, in
which case
Ok, so let's try asking the question in another way.
Which is the difference between having more than one tape into a file
and having one tape per file?
I mean, we are peaking runs belonging to different tapes and merge those
runs.
Moreover, why space is reduced taking in account that we can
On Fri, Jun 18, 2010 at 3:46 PM, mac_man2...@hotmail.it
mac_man2...@hotmail.it wrote:
Which is the difference between having more than one tape into a file and
having one tape per file?
It makes it easier to recycle space a little at a time. Suppose
you're merging two runs of 100 blocks each.
On Fri, Jun 18, 2010 at 7:27 PM, David E. Wheeler da...@kineticode.com wrote:
We don't have a slice operator for arrays; would we be happy with % being
such an operator in a future version? And, does the spec say anything about
array operators?
Personally, I don't find any of these
On Fri, Jun 18, 2010 at 1:59 PM, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
On Fri, Jun 18, 2010 at 12:59 PM, Andrew Dunstan and...@dunslane.net
wrote:
You are just bumping up the storage cost. Part of the attraction of enums
is
their efficiency.
What's efficient
Joseph Adams wrote:
Also, I can't seem to find the original debates from when enums were
implemented. Does anyone have a link to that thread in the archives?
Thanks.
Start here
http://archives.postgresql.org/pgsql-hackers/2006-08/msg00979.php
cheers
andrew
--
Sent via pgsql-hackers
Excerpts from Joseph Adams's message of vie jun 18 18:17:50 -0400 2010:
Couldn't enum_eq just use get_fn_expr_argtype to determine the type of
enum input rather than rely on it being stored in the value (either
implicitly via OID or explicitly as a word half)?
Also, I can't seem to find the
Joseph Adams joeyadams3.14...@gmail.com writes:
Couldn't enum_eq just use get_fn_expr_argtype to determine the type of
enum input rather than rely on it being stored in the value
No. Support functions have to work in many contexts where there is no
side channel such as get_fn_expr_argtype.
Tom Lane wrote:
And how would it be per data-type?
Well, there'd be two kinds of enums, just as you were saying before.
I'm not sure how we'd expose that to users exactly, or whether there
could be provisions for switching a type's behavior after creation.
43 matches
Mail list logo
