Re: [HACKERS] patch (for 9.1) string functions

2010/8/24 Itagaki Takahiro : > I applied the attached patch to HEAD. concat(), concat_ws(), left(), > right(), and reverse() are in it, but format() and sprintf() are not. > It's my understanding that we don't have consensus about the best syntax > for the formatting function. We can forget about R

Re: [HACKERS] patch (for 9.1) string functions

I applied the attached patch to HEAD. concat(), concat_ws(), left(), right(), and reverse() are in it, but format() and sprintf() are not. It's my understanding that we don't have consensus about the best syntax for the formatting function. We can forget about RAISE. C-like printf syntax is the nex

Re: [HACKERS] Typing Records

On 08/23/2010 08:33 PM, David E. Wheeler wrote: > 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: > Aside from that, might the

[HACKERS] INSERT and parentheses

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 4bd58db3.4070...@cs.helsinki.fi

Re: [HACKERS] security hook on authorization

(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 Kohei wrote: >>> (2010/08/20 23:34), Robert Haas wrote: 2010/8/19 KaiGai Kohei: I think our standard criteria for the inclusion of hooks is that you must demonstrate

[HACKERS] Typing Records

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 cmp_

Re: Interruptible sleeps (was Re: [HACKERS] CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)

Excerpts from Tom Lane's message of lun ago 23 19:44:02 -0400 2010: > Heikki Linnakangas 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 > response to actual signals. Thi

Re: [HACKERS] WIP: extensible enums

Bruce Momjian 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 oid+1 from the l

Re: [HACKERS] Problem Using PQcancel in a Synchronous Query

"Eric Simon" 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 alarm() calls a

Re: [HACKERS] WIP: extensible enums

"David E. Wheeler" 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. regards, tom

Re: Interruptible sleeps (was Re: [HACKERS] CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)

Heikki Linnakangas 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: >> https://bugzilla.redhat.com/show_bug.cgi?id=252129 >>

Re: [HACKERS] WIP: extensible enums

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 us

Re: [HACKERS] WIP: extensible enums

Josh Berkus wrote: > On 8/23/10 12:20 PM, Tom Lane wrote: > > Josh Berkus 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 t

Re: [Glue] [HACKERS] Deadlock bug

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-on

Re: [HACKERS] WIP: extensible enums

On 8/23/10 12:20 PM, Tom Lane wrote: > Josh Berkus 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 thing

[HACKERS] Problem Using PQcancel in a Synchronous Query

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

Re: [HACKERS] WIP: extensible enums

On Aug 23, 2010, at 12:20 PM, Tom Lane wrote: > Josh Berkus 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

Re: Interruptible sleeps (was Re: [HACKERS] CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)

On 20/08/10 17:28, Tom Lane wrote: [ It's way past time to change the thread title ] Heikki Linnakangas 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 pg_usleep() are not really a problem

Re: [HACKERS] WIP: extensible enums

On Mon, August 23, 2010 3:20 pm, Heikki Linnakangas wrote: > On 23/08/10 22:06, Tom Lane wrote: >> Thom Brown writes: >>> On 23 August 2010 19:25, Joseph Adams >>> wrote: But what if you want to insert an OID at the end? >> >>> ALTER TYPE colors ADD 'orange'; >> >> Alternatively, if people ar

Re: [HACKERS] [BUGS] BUG #5305: Postgres service stops when closing Windows session

>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 b

Re: [HACKERS] WIP: extensible enums

On Mon, Aug 23, 2010 at 3:06 PM, Tom Lane wrote: > Thom Brown writes: >> On 23 August 2010 19:25, Joseph Adams 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

Re: [HACKERS] Return of the Solaris vacuum polling problem -- anyone remember this?

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

Re: [HACKERS] Return of the Solaris vacuum polling problem -- anyone remember this?

Tom Lane wrote: > Bruce Momjian 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 eq

Re: [HACKERS] WIP: extensible enums

Josh Berkus 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 I mentioned a m

Re: [HACKERS] Return of the Solaris vacuum polling problem -- anyone remember this?

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 sen

Re: [HACKERS] WIP: extensible enums

On 23/08/10 22:06, Tom Lane wrote: Thom Brown writes: On 23 August 2010 19:25, Joseph Adams 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, and

Re: [HACKERS] [9.1] pg_stat_get_backend_server_addr

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 mu

Re: [HACKERS] Return of the Solaris vacuum polling problem -- anyone remember this?

Bruce Momjian 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 FREEZE. Pl

Re: [HACKERS] WIP: extensible enums

Thom Brown writes: > On 23 August 2010 19:25, Joseph Adams 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, and just have the BEFORE and AFTER var

Re: [HACKERS] WIP: extensible enums

> 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. B

Re: [HACKERS] Return of the Solaris vacuum polling problem -- anyone remember this?

Alvaro Herrera wrote: > Excerpts from Tom Lane's message of lun ago 23 12:40:32 -0400 2010: > > Alvaro Herrera 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

Re: [HACKERS] [BUGS] BUG #5305: Postgres service stops when closing Windows session

On Mon, Aug 23, 2010 at 11:37 AM, Tom Lane wrote: > Magnus Hagander writes: >> On Mon, Aug 23, 2010 at 17:09, Tom Lane 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 softwar

Re: [HACKERS] WIP: extensible enums

On 23 August 2010 19:25, Joseph Adams wrote: > On Mon, Aug 23, 2010 at 1:54 PM, Tom Lane wrote: >> "Andrew Dunstan" 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

Re: [HACKERS] WIP: extensible enums

On Mon, Aug 23, 2010 at 1:54 PM, Tom Lane wrote: > "Andrew Dunstan" 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, w

Re: [HACKERS] WIP: extensible enums

Josh Berkus 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 ALTER'ing the ref

Re: [HACKERS] WIP: extensible enums

On Mon, Aug 23, 2010 at 01:54:40PM -0400, Tom Lane wrote: > "Andrew Dunstan" 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 th

Re: [HACKERS] WIP: extensible enums

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 TYP

Re: [HACKERS] WIP: extensible enums

On 23 August 2010 10:35, 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 o

Re: [HACKERS] WIP: extensible enums

> 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

Re: [HACKERS] WIP: extensible enums

"Andrew Dunstan" 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 doesn't cover)

Re: [HACKERS] WIP: extensible enums

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 'newla

Re: [HACKERS] WIP: extensible enums

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 'newla

Re: [HACKERS] Return of the Solaris vacuum polling problem -- anyone remember this?

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 Postg

Re: [HACKERS] WIP: extensible enums

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: http://www.postgresql.org/mailpref/pgs

Re: [HACKERS] Return of the Solaris vacuum polling problem -- anyone remember this?

Excerpts from Tom Lane's message of lun ago 23 12:40:32 -0400 2010: > Alvaro Herrera 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" > >

Re: [HACKERS] Return of the Solaris vacuum polling problem -- anyone remember this?

Alvaro Herrera 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 truncation as > the f

Re: [HACKERS] Return of the Solaris vacuum polling problem -- anyone remember this?

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 w

Re: [HACKERS] WIP: extensible enums

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 A

Re: [HACKERS] [BUGS] BUG #5305: Postgres service stops when closing Windows session

Magnus Hagander writes: > On Mon, Aug 23, 2010 at 17:09, Tom Lane 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 maybe try some other >> one. >

Re: [HACKERS] [BUGS] BUG #5305: Postgres service stops when closing Windows session

On Mon, Aug 23, 2010 at 17:09, Tom Lane wrote: > Robert Haas 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 s

Re: [HACKERS] [BUGS] BUG #5305: Postgres service stops when closing Windows session

Robert Haas 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 anti-virus software.

Re: [HACKERS] More vacuum stats

Magnus Hagander writes: > On Mon, Aug 23, 2010 at 16:38, Tom Lane wrote: >> Magnus Hagander 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 actual time not only the duration. > Well, y

Re: [HACKERS] patch (for 9.1) string functions

2010/8/23 Tom Lane : > Pavel Stehule 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 le

Re: [HACKERS] More vacuum stats

On Mon, Aug 23, 2010 at 16:38, Tom Lane wrote: > Magnus Hagander writes: >> On Mon, Aug 23, 2010 at 16:28, Greg Smith 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, tha

Re: [HACKERS] More vacuum stats

Magnus Hagander writes: > On Mon, Aug 23, 2010 at 16:28, Greg Smith 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 useful. That'd require another stats m

Re: [HACKERS] More vacuum stats

On Mon, Aug 23, 2010 at 16:28, Greg Smith 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 a >> speci

Re: [HACKERS] More vacuum stats

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

Re: [HACKERS] patch (for 9.1) string functions

Pavel Stehule 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 unusably broken design.

Re: [HACKERS] More vacuum stats

Magnus Hagander writes: > On Sun, Aug 22, 2010 at 18:17, Tom Lane 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.  AFAICS this does not >> tell

Re: [HACKERS] [BUGS] BUG #5305: Postgres service stops when closing Windows session

[moving to -hackers] On Thu, Aug 19, 2010 at 9:43 PM, Robert Haas 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: > http://archives.postgresql

Re: [HACKERS] patch (for 9.1) string functions

2010/8/23 Itagaki Takahiro : > On Sat, Aug 7, 2010 at 8:39 PM, Pavel Stehule 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. > >>>

Re: [HACKERS] patch (for 9.1) string functions

On Sat, Aug 7, 2010 at 8:39 PM, Pavel Stehule 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 compatible between

Re: [HACKERS] UTF16 surrogate pairs in UTF8 encoding

On 8/22/10, Peter Eisentraut 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 wise? I t

Re: [HACKERS] More vacuum stats

On Sun, Aug 22, 2010 at 18:17, Tom Lane wrote: > Magnus Hagander writes: >> On Sun, Aug 22, 2010 at 17:29, 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 w

Re: [HACKERS] git: uh-oh

On Sat, Aug 21, 2010 at 08:15, Michael Haggerty wrote: > Max Bowsher wrote: >> On 20/08/10 19:07, Magnus Hagander wrote: >>> On Fri, Aug 20, 2010 at 19:56, Max Bowsher wrote: On 20/08/10 18:43, Magnus Hagander wrote: > On Fri, Aug 20, 2010 at 19:41, Max Bowsher wrote: >> On 20/08/10