* Tom Lane:
I just noticed that we are now advertising the ability to insert UTF16
surrogate pairs in strings and identifiers (see section 4.1.2.2 in
current docs, in particular). Is this really wise? I thought that
surrogate pairs were specifically prohibited in UTF8 strings, because
of
On Sat, Aug 21, 2010 at 08:15, Michael Haggerty mhag...@alum.mit.edu wrote:
Max Bowsher wrote:
On 20/08/10 19:07, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 19:56, Max Bowsher m...@f2s.com wrote:
On 20/08/10 18:43, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 19:41, Max Bowsher
On Sun, Aug 22, 2010 at 18:17, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Sun, Aug 22, 2010 at 17:29, Tom Lane t...@sss.pgh.pa.us wrote:
So I'd like to see a positive argument why this is important for users
to know, rather than merely we should expose
On 8/22/10, Peter Eisentraut pete...@gmx.net wrote:
On sön, 2010-08-22 at 14:29 -0400, Tom Lane wrote:
I just noticed that we are now advertising the ability to insert UTF16
surrogate pairs in strings and identifiers (see section 4.1.2.2 in
current docs, in particular). Is this really
On Sat, Aug 7, 2010 at 8:39 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I made a discussion page in wiki for the compatibility issue.
http://wiki.postgresql.org/wiki/String_Functions_and_Operators_Compatibility
nice, thank you
I filled cells for SQL Server and DB2.
* concat() is not
2010/8/23 Itagaki Takahiro itagaki.takah...@gmail.com:
On Sat, Aug 7, 2010 at 8:39 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I made a discussion page in wiki for the compatibility issue.
http://wiki.postgresql.org/wiki/String_Functions_and_Operators_Compatibility
nice, thank you
I
[moving to -hackers]
On Thu, Aug 19, 2010 at 9:43 PM, Robert Haas robertmh...@gmail.com wrote:
I suspect this is the same problem as bug #4897, and probably also the
same problem as this:
http://archives.postgresql.org/pgsql-bugs/2009-08/msg00114.php
and maybe also this and this:
Magnus Hagander mag...@hagander.net writes:
On Sun, Aug 22, 2010 at 18:17, Tom Lane t...@sss.pgh.pa.us wrote:
With the current AV launch algorithm, unless you have very serious
system-wide issues there will be a worker launched into each database
approximately every autovacuum_naptime seconds.
Pavel Stehule pavel.steh...@gmail.com writes:
... The formating
enhancing should be shared with RAISE NOTICE command.
I remain of the opinion that RAISE's approach to formatting is
completely broken and inextensible, and that any attempt to be somehow
compatible with it is going to lead to an
Tom Lane wrote:
So I'd like to see a positive argument why this is important for users
to know, rather than merely we should expose every conceivable detail
by default. Why wouldn't a user care more about last AV time for a
specific table, which we already do expose?
What I actually want
On Mon, Aug 23, 2010 at 16:28, Greg Smith g...@2ndquadrant.com wrote:
Tom Lane wrote:
So I'd like to see a positive argument why this is important for users
to know, rather than merely we should expose every conceivable detail
by default. Why wouldn't a user care more about last AV time for
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 23, 2010 at 16:28, Greg Smith g...@2ndquadrant.com wrote:
What I actually want here is for the time that the last table autovacuum
started, adding to the finish time currently exposed by pg_stat_user_tables.
Now, that would be quite
On Mon, Aug 23, 2010 at 16:38, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 23, 2010 at 16:28, Greg Smith g...@2ndquadrant.com wrote:
What I actually want here is for the time that the last table autovacuum
started, adding to the finish time
2010/8/23 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
... The formating
enhancing should be shared with RAISE NOTICE command.
I remain of the opinion that RAISE's approach to formatting is
completely broken and inextensible, and that any attempt to be somehow
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 23, 2010 at 16:38, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
We could also store last_autovacuum_vacuum_duration - is that better
or worse than start and end time?
No, I think you want to know the
Robert Haas robertmh...@gmail.com writes:
After some discussion with Magnus, I think what is going on here is
that the postmaster kicks off a new child process, which terminates
before it actually starts running our code, either in OS-supplied code
or some sort of filter like anti-spam or
On Mon, Aug 23, 2010 at 17:09, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
After some discussion with Magnus, I think what is going on here is
that the postmaster kicks off a new child process, which terminates
before it actually starts running our code, either
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 23, 2010 at 17:09, Tom Lane t...@sss.pgh.pa.us wrote:
I would be inclined to write this off as Windows randomness that's
unfixable on our end. We could recommend that people take a closer
look at what AV software they have installed and
Excerpts from Andrew Dunstan's message of lun ago 23 05:35:09 -0400 2010:
To add a label at the end of the list, do:
ALTER TYPE myenum ADD 'newlabel';
To add a label somewhere else, do:
ALTER TYPE myenum ADD 'newlabel' BEFORE 'existinglabel';
or
ALTER TYPE myenum ADD
Excerpts from Bruce Momjian's message of dom ago 22 12:51:47 -0400 2010:
Well, the reason that value is 200 million is for pg_clog cleanup, not
for xid wraparound protection. The next sentence does relate to xid
wraparound, but it seems to fit because the previous sentence ends with
xid
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Bruce Momjian's message of dom ago 22 12:51:47 -0400 2010:
Do you have a suggestion? Reorder the items?
I'd add another para before that one saying that this value also
affects pg_clog truncation. I agree that putting pg_clog
Excerpts from Tom Lane's message of lun ago 23 12:40:32 -0400 2010:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Bruce Momjian's message of dom ago 22 12:51:47 -0400 2010:
Do you have a suggestion? Reorder the items?
I'd add another para before that one saying that
On Aug 23, 2010, at 2:35 AM, Andrew Dunstan wrote:
I'm not wedded to the syntax. Let the bikeshedding begin.
Seems pretty good to me as-is.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
All,
FYI, the system which sparked this original discussion turned out, on
extensive analysis, to have ZFS-level filesystem corruption. The
polling issues were related to that rather than to Postgres.
--
-- Josh Berkus
On Mon, August 23, 2010 11:49 am, Alvaro Herrera wrote:
Excerpts from Andrew Dunstan's message of lun ago 23 05:35:09 -0400 2010:
To add a label at the end of the list, do:
ALTER TYPE myenum ADD 'newlabel';
To add a label somewhere else, do:
ALTER TYPE myenum ADD 'newlabel' BEFORE
On Mon, August 23, 2010 11:49 am, Alvaro Herrera wrote:
Excerpts from Andrew Dunstan's message of lun ago 23 05:35:09 -0400 2010:
To add a label at the end of the list, do:
ALTER TYPE myenum ADD 'newlabel';
To add a label somewhere else, do:
ALTER TYPE myenum ADD 'newlabel' BEFORE
Andrew Dunstan and...@dunslane.net writes:
On Mon, August 23, 2010 11:49 am, Alvaro Herrera wrote:
What do you need AFTER for? Seems to me that BEFORE should be enough.
(You already have the unadorned syntax for adding an item after the last
one, which is the corner case that BEFORE alone
You're right. Strictly speaking we don't need it. But it doesn't hurt much
to provide it for a degree of symmetry.
Swami Josh predicts that if we don't add AFTER now, we'll be adding it
in 2 years when enough people complain about it.
--
-- Josh Berkus
On 23 August 2010 10:35, Andrew Dunstan and...@dunslane.net wrote:
Attached is a WIP patch that allows enums to be extended with additional
labels arbitrarily. As previously discussed, it works by adding an explicit
sort order column to pg_enum. It keeps track of whether the labels are
On Mon, Aug 23, 2010 at 11:49:41AM -0400, Alvaro Herrera wrote:
Excerpts from Andrew Dunstan's message of lun ago 23 05:35:09 -0400 2010:
To add a label at the end of the list, do:
ALTER TYPE myenum ADD 'newlabel';
To add a label somewhere else, do:
ALTER TYPE myenum ADD
On Mon, Aug 23, 2010 at 01:54:40PM -0400, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On Mon, August 23, 2010 11:49 am, Alvaro Herrera wrote:
What do you need AFTER for? Seems to me that BEFORE should be
enough. (You already have the unadorned syntax for adding an
item
Josh Berkus j...@agliodbs.com writes:
Swami Josh predicts that if we don't add AFTER now, we'll be adding it
in 2 years when enough people complain about it.
If it's not there, no one will ever miss it. You might as well argue
that there should be a way of creating a foreign key reference by
On Mon, Aug 23, 2010 at 1:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On Mon, August 23, 2010 11:49 am, Alvaro Herrera wrote:
What do you need AFTER for? Seems to me that BEFORE should be enough.
(You already have the unadorned syntax for adding an
On 23 August 2010 19:25, Joseph Adams joeyadams3.14...@gmail.com wrote:
On Mon, Aug 23, 2010 at 1:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On Mon, August 23, 2010 11:49 am, Alvaro Herrera wrote:
What do you need AFTER for? Seems to me that BEFORE
On Mon, Aug 23, 2010 at 11:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 23, 2010 at 17:09, Tom Lane t...@sss.pgh.pa.us wrote:
I would be inclined to write this off as Windows randomness that's
unfixable on our end. We could recommend that
Alvaro Herrera wrote:
Excerpts from Tom Lane's message of lun ago 23 12:40:32 -0400 2010:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Bruce Momjian's message of dom ago 22 12:51:47 -0400 2010:
Do you have a suggestion? Reorder the items?
I'd add another para
If it's not there, no one will ever miss it. You might as well argue
that there should be a way of creating a foreign key reference by
ALTER'ing the referenced table instead of the referencing table.
Sure, if the SQL committee was into symmetry, they might have provided
such a thing. But
Thom Brown t...@linux.com writes:
On 23 August 2010 19:25, Joseph Adams joeyadams3.14...@gmail.com wrote:
But what if you want to insert an OID at the end?
ALTER TYPE colors ADD 'orange';
Alternatively, if people are dead set on symmetry, what we should do
to simplify is drop *this* syntax,
Bruce Momjian br...@momjian.us writes:
OK, I have attached a proposed patch to improve this. I moved the
pg_clog mention to a new paragraph and linked it to the reason the
default is relatively low.
The references to vacuum freeze are incorrect; autovacuum does NOT
do the equivalent of VACUUM
On tor, 2010-05-27 at 22:32 +0300, Peter Eisentraut wrote:
I suggest that we add the functions pg_stat_get_backend_server_addr
and pg_stat_get_backend_server_port, but don't expose them in
pg_stat_activity. (_server_port is really mostly for symmetry,
because you can't currently bind to
On 23/08/10 22:06, Tom Lane wrote:
Thom Brownt...@linux.com writes:
On 23 August 2010 19:25, Joseph Adamsjoeyadams3.14...@gmail.com wrote:
But what if you want to insert an OID at the end?
ALTER TYPE colors ADD 'orange';
Alternatively, if people are dead set on symmetry, what we should
Excerpts from Bruce Momjian's message of lun ago 23 14:55:55 -0400 2010:
OK, I have attached a proposed patch to improve this. I moved the
pg_clog mention to a new paragraph and linked it to the reason the
default is relatively low.
Comments?
I think the new para doesn't make much sense,
Josh Berkus j...@agliodbs.com writes:
I really don't see the value in making a command substantially less
intuitive in order to avoid a single keyword, unless it affects areas of
Postgres outside of this particular command.
It's the three variants to do two things that I find unintuitive.
As
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
OK, I have attached a proposed patch to improve this. I moved the
pg_clog mention to a new paragraph and linked it to the reason the
default is relatively low.
The references to vacuum freeze are incorrect; autovacuum does NOT
do
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of lun ago 23 14:55:55 -0400 2010:
OK, I have attached a proposed patch to improve this. I moved the
pg_clog mention to a new paragraph and linked it to the reason the
default is relatively low.
Comments?
I think the new
On Mon, Aug 23, 2010 at 3:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown t...@linux.com writes:
On 23 August 2010 19:25, Joseph Adams joeyadams3.14...@gmail.com wrote:
But what if you want to insert an OID at the end?
ALTER TYPE colors ADD 'orange';
Alternatively, if people are dead
From the users point of view, this could be a Windows or AV issue, but just
stops Postgres service, does not affect or interfire on Windows stability or
AV stability, instead it affect your product. So if you can improve the
stability of the service (and data integrity at the most) it could be a
On Mon, August 23, 2010 3:20 pm, Heikki Linnakangas wrote:
On 23/08/10 22:06, Tom Lane wrote:
Thom Brownt...@linux.com writes:
On 23 August 2010 19:25, Joseph Adamsjoeyadams3.14...@gmail.com
wrote:
But what if you want to insert an OID at the end?
ALTER TYPE colors ADD 'orange';
On 20/08/10 17:28, Tom Lane wrote:
[ It's way past time to change the thread title ]
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
On 20/08/10 16:24, Tom Lane wrote:
You keep on proposing solutions that only work for walsender :-(.
Well yes, the other places where we use
On Aug 23, 2010, at 12:20 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
I really don't see the value in making a command substantially less
intuitive in order to avoid a single keyword, unless it affects areas of
Postgres outside of this particular command.
It's the three
Hi,
I am using Perl (DBD::Pg) with Postgres. DBD::Pg already fully supports
asynchronous queries, and the canceling of those queries, but I need to
cancel a synchronous query. So to do that, I am trying to write
$sth-cancel() support for DBD::Pg. Here's my example in Perl:
my $aborted
On 8/23/10 12:20 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
I really don't see the value in making a command substantially less
intuitive in order to avoid a single keyword, unless it affects areas of
Postgres outside of this particular command.
It's the three variants to do
Kevin,
In the for what it's worth department, I tried out the current
Serializable Snapshot Isolation (SSI) patch with this test case at
the SERIALIZABLE transaction isolation level. Rather than defining
a foreign key, I ran the queries which an SSI implementation in a
SERIALIZABLE-only
Josh Berkus wrote:
On 8/23/10 12:20 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
I really don't see the value in making a command substantially less
intuitive in order to avoid a single keyword, unless it affects areas of
Postgres outside of this particular command.
It's
Andrew Dunstan wrote:
Attached is a WIP patch that allows enums to be extended with additional
labels arbitrarily. As previously discussed, it works by adding an
explicit sort order column to pg_enum. It keeps track of whether the
labels are correctly sorted by oid value, and if so uses
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 20/08/10 17:28, Tom Lane wrote:
Well, yes they are. They cause unnecessary process wakeups and thereby
consume cycles even when the database is idle. See for example a
longstanding complaint here:
David E. Wheeler da...@kineticode.com writes:
On Aug 23, 2010, at 12:20 PM, Tom Lane wrote:
It's the three variants to do two things that I find unintuitive.
I strongly suspect that you are in the minority on this one.
Yeah, seems like I'm losing the argument. Oh well.
Eric Simon esi...@theiqgroup.com writes:
Now that I've established some context, here's where I'm at: I've written
$sth-cancel() for DBD::Pg using PQcancel(), and it works (it returns the
status 57014: QUERY CANCELED). The problem is that the $sth-execute call
(which resides between the two
Bruce Momjian br...@momjian.us writes:
I also noticed you grab an oid for the new type using the oid counter
without trying to make it in sorted order. Seems that would be possible
for adding enums to the end of the list, and might not be worth it. A
quick hack might be to just try of an
Excerpts from Tom Lane's message of lun ago 23 19:44:02 -0400 2010:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
[ latch proposal ]
This seems reasonably clean as far as signal conditions generated
internally to Postgres go, but I remain unclear on how it helps for
Hackers,
I've been trying to come up with a simpler way to iterate over a series of
values in pgTAP tests than by creating a table, inserting rows, and then
selecting from the table. The best I've come up with so far is:
CREATE TYPE vcmp AS ( lv semver, op text, rv semver);
SELECT
(2010/08/22 21:38), KaiGai Kohei wrote:
(2010/08/22 0:20), Robert Haas wrote:
On Aug 20, 2010, at 8:27 PM, KaiGai Koheikai...@kaigai.gr.jp wrote:
(2010/08/20 23:34), Robert Haas wrote:
2010/8/19 KaiGai Koheikai...@ak.jp.nec.com:
I think our standard criteria for the inclusion of hooks is that
Marko et al,
This is my first ever attempt of a patch review just for learning the
procedure. I'm not a postgres developer, so the review is partial and mostly
from the usability prospective.
The original message id of the patch is
63 matches
Mail list logo
