Re: [HACKERS] How to determine failed connection attempt due to invalid authorization (libpq)?

On Mon, Oct 18, 2010 at 07:26:32AM -0700, David Fetter wrote: > On Mon, Oct 18, 2010 at 10:18:25AM -0400, Robert Haas wrote: > > On Mon, Oct 18, 2010 at 10:05 AM, David Fetter wrote: > > > On Mon, Oct 18, 2010 at 10:03:55AM -0400, Robert Haas wrote: > > >> On Sun, Oct 17, 2010 at 2:03 AM, Dmitriy

Re: [HACKERS] Timeout and wait-forever in sync rep

On Mon, Oct 18, 2010 at 10:24 PM, Fujii Masao wrote: > I mean, for example, that the server cannot detect the disconnection for > more than 60 seconds even if the user configures the keepalive as follows. > >    tcp_keepalives_idle      = 10 >    tcp_keepalives_interval  = 5 >    tcp_keepalives_co

[HACKERS] comments on type attributes broken in 9.1devel

The comment code refactoring c10575ff005c330d0475345621b7d381eb510c48 broke comments on composite type attributes: COMMENT ON COLUMN foo.a is 'test'; ERROR: 42809: "foo" is a composite type LOCATION: heap_openrv, heapam.c:1110 This is because as the code was moved from CommentAttribute() to get

Re: [HACKERS] Timeout and wait-forever in sync rep

On Tue, Oct 19, 2010 at 1:06 AM, Greg Stark wrote: > On Mon, Oct 18, 2010 at 12:03 AM, Fujii Masao wrote: >> The keepalives don't work at least on linux when the connection is terminated >> after sending a packet and before receiving TCP-level ACK. You can confirm >> this by unplugging the LAN ca

Re: [HACKERS] security hook on table creation

(2010/10/18 23:14), Robert Haas wrote: >> If MVCC visibility always would match with existing permission checks, >> we don't need to pay special attention for these things, do we? > > It seems to me that you're worrying about the wrong set of problems. > The original purpose of what I proposed was

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Tom Lane wrote: > Bruce Momjian writes: > > Looking at the pg_upgrade code some more, I found that it was not > > removing the PG_VERSION file when deleting <= 8.4 tablespace files. > > This might confuse administrators so the attached patch adds the removal > > of PG_VERSION. I would like to ap

Re: [HACKERS] Simplifying replication

On 19 October 2010 11:16, Josh Berkus wrote: > 4. I can start a new replica off the master by running a single command-line > utility on the standby and giving it connection information to the master. >  Using this connection, it should be able to start a backup snapshot, copy > the entire databas

Re: [HACKERS] Serializable snapshot isolation patch

> Jeff Davis wrote: > On Mon, 2010-10-18 at 13:26 -0500, Kevin Grittner wrote: > I assume here that you mean that you _did_ see the failure > (serialization error) and therefore did not see the problem? Yeah. > Also, are you sure it was using the GiST index for the searches and > didn't just

Re: [HACKERS] external pid file

Euler Taveira de Oliveira wrote: > Hi, > > Is there any reason the postmaster.pid and external_pid_file contents to be > different? No, the external_pid_file option is only to create an additional pid file in a new location. -- Bruce Momjian http://momjian.us EnterpriseDB

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Bruce Momjian writes: > Looking at the pg_upgrade code some more, I found that it was not > removing the PG_VERSION file when deleting <= 8.4 tablespace files. > This might confuse administrators so the attached patch adds the removal > of PG_VERSION. I would like to apply this to master and 9.0

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

bruce wrote: > Tom Lane wrote: > > Dave Cramer writes: > > > as seen below create tablespace does not throw an error or appear to > > > do anything other than register the tablespace. > > > > I suspect this behavior is partially intentional, because tablespace > > creation now involves an extra l

Re: [HACKERS] PL/JS

On Tue, Oct 19, 2010 at 9:04 AM, Terri Laurenzo wrote: > Is there a pl/js yet?  I've not been able to find anything > but was thinking about putting something together based on v8 or spidermonkey. I'm working on PL/v8, that is one of PL/JS (PL/JavaScript) implementation based on v8. http://code.g

Re: [HACKERS] PL/JS

Excerpts from Terri Laurenzo's message of lun oct 18 21:04:36 -0300 2010: > Is there a pl/js yet? I've not been able to find anything but was thinking > about putting something together based on v8 or spidermonkey. http://code.google.com/p/plv8js/ -- Álvaro Herrera The PostgreSQL Company - Co

Re: [HACKERS] PL/JS

Is there a pl/js yet? I've not been able to find anything but was thinking about putting something together based on v8 or spidermonkey. Terry Sent from my iPhone On Oct 18, 2010, at 4:27 PM, Greg wrote: > Hi everyone! Did anyone had a chance to use PL/JS for sp development? Im > working on

[HACKERS] max_wal_senders must die

Hackers, What purpose is served, exactly, by max_wal_senders? In order for a standby to connect, it must have a superuser login, and replication connections must be enabled in pg_hba.conf. How is having one more setting in one more file you have to enable on the master benefitting anyone?

[HACKERS] Simplifying replication

Robert asked me to write this up, so here it is. It is critical that we make replication easier to set up, administrate and monitor than it currently is. In my conversations with people, this is more important to our users and the adoption of PostgreSQL than synchronous replication is. Firs

[HACKERS] PL/JS

Hi everyone! Did anyone had a chance to use PL/JS for sp development? Im working on app that uses JS to work with data and was wandering whether PL/JS can offer full data management functionality like PL/PgSLQ? Thanks. Greg.

Re: [HACKERS] Creation of temporary tables on read-only standby servers

On Mon, Oct 18, 2010 at 1:27 PM, Robert Haas wrote: >> It'd be kinda cool if we had it, but the work required to get there >> seems far out of proportion to the benefits ... > > I agree.  I think that's backing into the problem from the wrong end. > The limiting factor here is that we require the

Re: [HACKERS] Creation of temporary tables on read-only standby servers

On Mon, Oct 18, 2010 at 3:55 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Oct 18, 2010 at 3:26 PM, Tom Lane wrote: >>> Andres Freund writes: Hm. Wouldnt it be possible to use virtual xids for that purpose? They are never seen outside of that session anyway... >>> >>> Well, may

Re: [HACKERS] Serializable snapshot isolation patch

On Mon, 2010-10-18 at 13:26 -0500, Kevin Grittner wrote: > > 2. I think there's a GiST bug (illustrating with PERIOD type): > > My assumptions for GiST were that: > > (1) A search for a matching value could bail out at any level in the > tree; there is no requirement for the search to proceed

Re: [HACKERS] knngist - 0.8

Robert Haas writes: > On Mon, Oct 18, 2010 at 3:40 PM, Peter Eisentraut wrote: >> Frankly, I have no idea what knngist has to do with any of this, as I >> haven't followed that topic at all. > Me neither, except for the fact that the PostGIS guys are interested > in both things. I think this th

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Tom Lane wrote: > Yeah. We have gotten complaints in the past from people who tried to > specify a mount point as a tablespace, and it failed because of > lost+found or the mount dir being root-owned. We've told them to make a > subdirectory, but that always seemed like a workaround. With the ne

Re: [HACKERS] Creation of temporary tables on read-only standby servers

Robert Haas writes: > On Mon, Oct 18, 2010 at 3:26 PM, Tom Lane wrote: >> Andres Freund writes: >>> Hm. Wouldnt it be possible to use virtual xids for that purpose? They are >>> never seen outside of that session anyway... >> >> Well, maybe, but then you need infrastructure to track whether VXI

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Robert Haas writes: > On Mon, Oct 18, 2010 at 3:21 PM, Tom Lane wrote: >> Given the use of the version-numbered subdirectory, I see no real merit >> in insisting that the parent directory be empty anyway.  It'd be >> precisely analogous to "initdb -D /foo/bar/data" insisting that /foo/bar >> be e

Re: [HACKERS] knngist - 0.8

On Mon, Oct 18, 2010 at 3:40 PM, Peter Eisentraut wrote: > On mån, 2010-10-18 at 15:36 -0400, Robert Haas wrote: >> On Mon, Oct 18, 2010 at 3:33 PM, Peter Eisentraut wrote: >> > On mån, 2010-10-18 at 11:41 +0100, Mark Cave-Ayland wrote: >> >> Paul Ramsey wrote: >> >> >> >> >> So what kind of data

Re: [HACKERS] knngist - 0.8

On mån, 2010-10-18 at 15:36 -0400, Robert Haas wrote: > On Mon, Oct 18, 2010 at 3:33 PM, Peter Eisentraut wrote: > > On mån, 2010-10-18 at 11:41 +0100, Mark Cave-Ayland wrote: > >> Paul Ramsey wrote: > >> > >> >> So what kind of data structure would you like for a typmod? > >> > > >> > I'm a primi

Re: [HACKERS] knngist - 0.8

On Mon, Oct 18, 2010 at 3:33 PM, Peter Eisentraut wrote: > On mån, 2010-10-18 at 11:41 +0100, Mark Cave-Ayland wrote: >> Paul Ramsey wrote: >> >> >> So what kind of data structure would you like for a typmod? >> > >> > I'm a primitive enough beast that just having 64-bits would make me >> > happy.

Re: [HACKERS] knngist - 0.8

On mån, 2010-10-18 at 11:41 +0100, Mark Cave-Ayland wrote: > Paul Ramsey wrote: > > >> So what kind of data structure would you like for a typmod? > > > > I'm a primitive enough beast that just having 64-bits would make me > > happy. As a general matter though, a bytea? > > > > P > > For my vot

Re: [HACKERS] Creation of temporary tables on read-only standby servers

On Mon, Oct 18, 2010 at 3:26 PM, Tom Lane wrote: > Andres Freund writes: >> On Monday 18 October 2010 20:06:01 Tom Lane wrote: >>> Not unless you have some credible concept for how it might ever be >>> implemented.  You can't create temp tables because you can't modify >>> system catalogs, and if

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

On Mon, Oct 18, 2010 at 3:21 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Oct 18, 2010 at 3:05 PM, Bruce Momjian wrote: >>> Robert Haas wrote: I haven't yet been convinced we need or want to relax the rule about the directory being empty. >>> >>> Uh, how would pg_upgrade work t

Re: [HACKERS] Floating-point timestamps versus Range Types

On Mon, 2010-10-18 at 14:49 -0400, Tom Lane wrote: > whereas an int-timestamp build sees these inputs as all the same. > Thus, to get into trouble you'd need to have a unique index on data that > conflicts at the microsecond scale but not at the tenth-of-a-microsecond > scale. This seems implausib

Re: [HACKERS] Creation of temporary tables on read-only standby servers

Andres Freund writes: > On Monday 18 October 2010 20:06:01 Tom Lane wrote: >> Not unless you have some credible concept for how it might ever be >> implemented. You can't create temp tables because you can't modify >> system catalogs, and if you did somehow create them you couldn't put >> anythin

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Robert Haas writes: > On Mon, Oct 18, 2010 at 3:05 PM, Bruce Momjian wrote: >> Robert Haas wrote: >>> I haven't yet been convinced we need or want to relax the rule about >>> the directory being empty. >> >> Uh, how would pg_upgrade work then?  It would require renaming the >> top-level tablespa

Re: [HACKERS] Creation of temporary tables on read-only standby servers

On Monday 18 October 2010 20:06:01 Tom Lane wrote: > Bruce Momjian writes: > > Currently it isn't possible to create temporary tables on read-only > > standby servers, and I don't see it listed on the TODO list. Can I add > > it? > > Not unless you have some credible concept for how it might eve

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Robert Haas wrote: > On Mon, Oct 18, 2010 at 3:05 PM, Bruce Momjian wrote: > > Robert Haas wrote: > >> On Mon, Oct 18, 2010 at 3:02 PM, Tom Lane wrote: > >> > Bruce Momjian writes: > >> >> Robert Haas wrote: > >> >>> Perhaps we should fix the behavior rather than the documentation. > >> > > >> >

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

On Mon, Oct 18, 2010 at 3:05 PM, Bruce Momjian wrote: > Robert Haas wrote: >> On Mon, Oct 18, 2010 at 3:02 PM, Tom Lane wrote: >> > Bruce Momjian writes: >> >> Robert Haas wrote: >> >>> Perhaps we should fix the behavior rather than the documentation. >> > >> >> We can't fix the behavior because

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Robert Haas wrote: > On Mon, Oct 18, 2010 at 3:02 PM, Tom Lane wrote: > > Bruce Momjian writes: > >> Robert Haas wrote: > >>> Perhaps we should fix the behavior rather than the documentation. > > > >> We can't fix the behavior because we have to allow an old cluster to > >> keep its tablespace fi

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Tom Lane wrote: > Bruce Momjian writes: > > Robert Haas wrote: > >> Perhaps we should fix the behavior rather than the documentation. > > > We can't fix the behavior because we have to allow an old cluster to > > keep its tablespace files during a pg_upgrade. They are given a script > > to delet

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> I suspect this behavior is partially intentional, because tablespace > >> creation now involves an extra level of subdirectory. However, it's > >> not clear to me why CREATE TABLESPACE is still changing the permissions > >> on the p

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

On Mon, Oct 18, 2010 at 3:02 PM, Tom Lane wrote: > Bruce Momjian writes: >> Robert Haas wrote: >>> Perhaps we should fix the behavior rather than the documentation. > >> We can't fix the behavior because we have to allow an old cluster to >> keep its tablespace files during a pg_upgrade.  They ar

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Bruce Momjian writes: > Robert Haas wrote: >> Perhaps we should fix the behavior rather than the documentation. > We can't fix the behavior because we have to allow an old cluster to > keep its tablespace files during a pg_upgrade. They are given a script > to delete those files later, if they w

Re: [HACKERS] Floating-point timestamps versus Range Types

On Mon, Oct 18, 2010 at 2:29 PM, Jeff Davis wrote: > A reasonable conversion path might be to offer integer timestamps using > a different type name (e.g. inttimestamp) that always means integer > timestamps. Then, they could convert using ALTER TABLE, then do an > in-place upgrade. We could even

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Bruce Momjian writes: > Tom Lane wrote: >> I suspect this behavior is partially intentional, because tablespace >> creation now involves an extra level of subdirectory. However, it's >> not clear to me why CREATE TABLESPACE is still changing the permissions >> on the parent directory. Bruce, exa

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Dave Cramer wrote: > >> >> IIRC the reason this works is that the tablespace code now creates a > >> >> version-specific subdirectory inside the specified directory. ?This was > >> >> done to help binary upgrades. > >> > > >> > Right, the directory is catalog-version named, which was done to allow

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Dave Cramer wrote: > >> >> > postgres=# select version(); > >> >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? version > >> >> > --- > >> >> > ?PostgreSQL 9.0.1 on x86_64-unkno

Re: [HACKERS] Floating-point timestamps versus Range Types

Robert Haas writes: > A more interesting question is whether and how we can ease the > migration path from float timestamps to integer timestamps. Even > without range types, if someone does have a UNIQUE index on a > timestamp column, could they get an error if they dump from a > float-timestamp

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

On Mon, Oct 18, 2010 at 2:39 PM, Bruce Momjian wrote: > Dave Cramer wrote: >> On Mon, Oct 18, 2010 at 2:20 PM, Bruce Momjian wrote: >> > Alvaro Herrera wrote: >> >> Hi Dave, >> >> >> >> Excerpts from Dave Cramer's message of lun oct 18 12:23:40 -0300 2010: >> >> > as seen below create tablespace

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Dave Cramer wrote: > On Mon, Oct 18, 2010 at 2:20 PM, Bruce Momjian wrote: > > Alvaro Herrera wrote: > >> Hi Dave, > >> > >> Excerpts from Dave Cramer's message of lun oct 18 12:23:40 -0300 2010: > >> > as seen below create tablespace does not throw an error or appear to > >> > do anything other t

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

On Mon, Oct 18, 2010 at 2:20 PM, Bruce Momjian wrote: > Alvaro Herrera wrote: >> Hi Dave, >> >> Excerpts from Dave Cramer's message of lun oct 18 12:23:40 -0300 2010: >> > as seen below create tablespace does not throw an error or appear to >> > do anything other than register the tablespace. >> >

Re: [HACKERS] Floating-point timestamps versus Range Types

On Mon, 2010-10-18 at 14:06 -0400, Robert Haas wrote: > Right. I think your argument that we should "do nothing" upthread is > exactly right. OK. > A more interesting question is whether and how we can ease the > migration path from float timestamps to integer timestamps. Even > without range

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Robert Haas wrote: > On Mon, Oct 18, 2010 at 2:17 PM, Bruce Momjian wrote: > > Dave Cramer wrote: > >> On Mon, Oct 18, 2010 at 11:37 AM, Tom Lane wrote: > >> > Dave Cramer writes: > >> >> as seen below create tablespace does not throw an error or appear to > >> >> do anything other than register

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Tom Lane wrote: > Dave Cramer writes: > > as seen below create tablespace does not throw an error or appear to > > do anything other than register the tablespace. > > I suspect this behavior is partially intentional, because tablespace > creation now involves an extra level of subdirectory. Howe

Re: [HACKERS] Serializable snapshot isolation patch

First off, thanks for the review! I know that it's a lot of work, and I do appreciate it. Jeff Davis wrote: > * Trivial stuff: > > I get a compiler warning: > > indexfsm.c: In function *RecordFreeIndexPage*: > indexfsm.c:55: warning: implicit declaration of function > *PageIsPredica

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Alvaro Herrera wrote: > Hi Dave, > > Excerpts from Dave Cramer's message of lun oct 18 12:23:40 -0300 2010: > > as seen below create tablespace does not throw an error or appear to > > do anything other than register the tablespace. > > > > postg...@db01:~> less /opt/pg/data/jnj_indexes/PG_VERSIO

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

On Mon, Oct 18, 2010 at 2:17 PM, Bruce Momjian wrote: > Dave Cramer wrote: >> On Mon, Oct 18, 2010 at 11:37 AM, Tom Lane wrote: >> > Dave Cramer writes: >> >> as seen below create tablespace does not throw an error or appear to >> >> do anything other than register the tablespace. >> > >> > I su

Re: [HACKERS] ISN patch that applies cleanly with git apply

On Mon, Oct 18, 2010 at 1:57 PM, Tom Lane wrote: > Robert Haas writes: >> I may be in the minority here, but I'm inclined to just apply this and >> move on. > > FWIW, I agree with applying the code patch as-is, but I think we need to > consider the documentation.  Specifically: > > 1. The first p

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Dave Cramer wrote: > On Mon, Oct 18, 2010 at 11:37 AM, Tom Lane wrote: > > Dave Cramer writes: > >> as seen below create tablespace does not throw an error or appear to > >> do anything other than register the tablespace. > > > > I suspect this behavior is partially intentional, because tablespac

Re: [HACKERS] WIP: extensible enums

Andrew Dunstan writes: > If you have want to work on it and prove it's going to be better, please > do. I'm not convinced it will do a whole lot better than a binary search > that in most cases will do no more than a handful of probes. Yeah, that's a good point. There's a range of table sizes

Re: [HACKERS] Floating-point timestamps versus Range Types

On Mon, Oct 18, 2010 at 1:12 PM, Tom Lane wrote: > IOW I don't think the range argument holds much water for keeping float > timestamps alive.  The on-disk-compatibility argument does, though. Right. I think your argument that we should "do nothing" upthread is exactly right. Deprecating float

Re: [HACKERS] Creation of temporary tables on read-only standby servers

Bruce Momjian writes: > Currently it isn't possible to create temporary tables on read-only > standby servers, and I don't see it listed on the TODO list. Can I add > it? Not unless you have some credible concept for how it might ever be implemented. You can't create temp tables because you can

Re: [HACKERS] Creation of temporary tables on read-only standby servers

2010/10/18 Bruce Momjian : > Currently it isn't possible to create temporary tables on read-only > standby servers, and I don't see it listed on the TODO list.  Can I add > it? Yes, still probably something we partially visit with global temp table thread from Robert Haas... Having non-WALed glob

Re: [HACKERS] Timeline in the light of Synchronous replication

I believe we should come up with a universal solution that will solve potential future problems as well (for example, if in sync replication, we decide to send writes to standbys in parallel to writing on local disk). The ideal thing would be to have an id that is incremented on every failure, and

Re: [HACKERS] ISN patch that applies cleanly with git apply

Robert Haas writes: > I may be in the minority here, but I'm inclined to just apply this and > move on. FWIW, I agree with applying the code patch as-is, but I think we need to consider the documentation. Specifically: 1. The first para of http://developer.postgresql.org/pgdocs/postgres/isn.htm

Re: [HACKERS] WIP: extensible enums

On 10/18/2010 01:40 PM, Dean Rasheed wrote: On 18 October 2010 15:52, Tom Lane wrote: So I'm thinking the comparison procedure goes like this: 1. Both OIDs even? If so, just compare them numerically, and we're done. 2. Lookup cache entry for enum type. 3. Both OIDs in list of known

[HACKERS] Creation of temporary tables on read-only standby servers

Currently it isn't possible to create temporary tables on read-only standby servers, and I don't see it listed on the TODO list. Can I add it? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to b

Re: [HACKERS] WIP: extensible enums

Dean Rasheed writes: > I think the hash map lookups could be made pretty quick, if we're > prepared to write a bit of dedicated code there rather than relying on > the more general-purpose caching code. It's still going to be very significantly slower than what I'm suggesting --- I'm *already* as

Re: [HACKERS] string function - "format" function proposal

On Mon, Oct 18, 2010 at 1:07 PM, Pavel Stehule wrote: > 2010/10/18, Robert Haas : >> On Mon, Oct 18, 2010 at 7:37 AM, Itagaki Takahiro >> wrote: >>> On Sat, Oct 16, 2010 at 7:29 AM, Robert Haas >>> wrote: No doubt.  The problem is that we're going to end up with those bells and whistle

Re: [HACKERS] WIP: extensible enums

On 18 October 2010 15:52, Tom Lane wrote: > So I'm thinking the comparison procedure goes like this: > > 1. Both OIDs even? >        If so, just compare them numerically, and we're done. > > 2. Lookup cache entry for enum type. > > 3. Both OIDs in list of known-sorted OIDs? >        If so, just co

Re: [HACKERS] WIP: extensible enums

Andrew Dunstan writes: > On 10/18/2010 10:52 AM, Tom Lane wrote: >> We could possibly deal with enum types that follow the existing >> convention if we made the cache entry hold a list of all the original, >> known-to-be-sorted OIDs. (This could be reasonably compact and cheap to >> probe if it w

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

On Mon, Oct 18, 2010 at 11:37 AM, Tom Lane wrote: > Dave Cramer writes: >> as seen below create tablespace does not throw an error or appear to >> do anything other than register the tablespace. > > I suspect this behavior is partially intentional, because tablespace > creation now involves an ex

Re: [HACKERS] WIP: extensible enums

On 10/18/2010 10:52 AM, Tom Lane wrote: We could possibly deal with enum types that follow the existing convention if we made the cache entry hold a list of all the original, known-to-be-sorted OIDs. (This could be reasonably compact and cheap to probe if it were represented as a starting OID

Re: [HACKERS] Floating-point timestamps versus Range Types

Andrew Dunstan writes: > On 10/17/2010 04:40 PM, Tom Lane wrote: >> ... That's assuming that we think there are >> no users who are depending on float timestamps for functionality (they >> have a wider range than int timestamps don't they?). > Yes, they do. > Maybe we need to look at providing a

Re: [HACKERS] ISN patch that applies cleanly with git apply

On 18 October 2010 16:17, Tom Lane wrote: > Personally I was hoping for some independent validation that the > proposed changes match current reality in ISN-land.  But apparently > no one actually wants to repeat the research, so we might as well just > take the changes on faith. I'm not at all s

Re: [HACKERS] string function - "format" function proposal

2010/10/18, Robert Haas : > On Mon, Oct 18, 2010 at 7:37 AM, Itagaki Takahiro > wrote: >> On Sat, Oct 16, 2010 at 7:29 AM, Robert Haas >> wrote: >>> No doubt. The problem is that we're going to end up with those bells >>> and whistles in two places: in to_char or other type-specific >>> formatti

Re: [HACKERS] patch: Add JSON datatype to PostgreSQL (GSoC, WIP)

> > I like as simple design as we can accept. ISTM format, I/O interface, > > simple get/set, mapping tuple from/to object, and indexing are minimum > > requirement. > > +1 to small start, but simple get/set are already debatable... > For example, text/json conversion: > A. SELECT ''::json; > B.

Re: [HACKERS] Timeout and wait-forever in sync rep

On Mon, Oct 18, 2010 at 12:03 AM, Fujii Masao wrote: > The keepalives don't work at least on linux when the connection is terminated > after sending a packet and before receiving TCP-level ACK. You can confirm > this by unplugging the LAN cable from a client server while running pgbench > on a cli

Re: [HACKERS] ISN patch that applies cleanly with git apply

On Mon, Oct 18, 2010 at 11:17 AM, Tom Lane wrote: > Peter Geoghegan writes: >>> I may be in the minority here, but I'm inclined to just apply this and >>> move on.  I agree with your concerns that this whole module is badly >>> designed and that the approach of hard-coding the list of ISBN ranges

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Dave Cramer writes: > as seen below create tablespace does not throw an error or appear to > do anything other than register the tablespace. I suspect this behavior is partially intentional, because tablespace creation now involves an extra level of subdirectory. However, it's not clear to me wh

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Hi Dave, Excerpts from Dave Cramer's message of lun oct 18 12:23:40 -0300 2010: > as seen below create tablespace does not throw an error or appear to > do anything other than register the tablespace. > > postg...@db01:~> less /opt/pg/data/jnj_indexes/PG_VERSION > 8.4 > postg...@db01:~> /opt/pg91

[HACKERS] create tablespace fails silently, or succeeds improperly

as seen below create tablespace does not throw an error or appear to do anything other than register the tablespace. postg...@db01:~> less /opt/pg/data/jnj_indexes/PG_VERSION 8.4 postg...@db01:~> /opt/pg91/bin/psql -p 5433 psql (9.0.1) Type "help" for help. postgres=# select version();

Re: [HACKERS] ISN patch that applies cleanly with git apply

Peter Geoghegan writes: >> I may be in the minority here, but I'm inclined to just apply this and >> move on.  I agree with your concerns that this whole module is badly >> designed and that the approach of hard-coding the list of ISBN ranges >> is fundamentally unscalable, but unless we're going

Re: [HACKERS] knngist - 0.8

David Fetter wrote: For my vote, I'd prefer either the Oid of a custom type or an array of Oid, Datum pairs - i.e. something we can extend in the future if required. This sounds a lot like a foreign key to another table. Are you not proposing doing that because of performance considerations?

Re: [HACKERS] ISN patch that applies cleanly with git apply

> I may be in the minority here, but I'm inclined to just apply this and > move on.  I agree with your concerns that this whole module is badly > designed and that the approach of hard-coding the list of ISBN ranges > is fundamentally unscalable, but unless we're going to rip it out or > rearchitec

Re: [HACKERS] WIP: extensible enums

Andrew Dunstan writes: > On 10/17/2010 03:56 PM, Tom Lane wrote: >> [clever scheme to treat even numbered enum Oids as sorted] >> The one problem I can see with this is that it's only partially >> on-disk-compatible with existing enum types: it'll almost certainly >> think that they require slow c

Re: [HACKERS] [GENERAL] column-level update privs + lock table

On Mon, Oct 18, 2010 at 10:27 AM, Robert Haas wrote: > Please add this to > https://commitfest.postgresql.org/action/commitfest_view/open > > I want to look at this at some point, but we still have over a dozen > patches from the current CF to deal with. Added at

Re: [HACKERS] string function - "format" function proposal

On Mon, Oct 18, 2010 at 7:37 AM, Itagaki Takahiro wrote: > On Sat, Oct 16, 2010 at 7:29 AM, Robert Haas wrote: >> No doubt.  The problem is that we're going to end up with those bells >> and whistles in two places: in to_char or other type-specific >> formatting functions, and again in format. >

Re: [HACKERS] [GENERAL] column-level update privs + lock table

On Fri, Oct 15, 2010 at 3:49 PM, Josh Kupershmidt wrote: > [Moving to -hackers] > > On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs wrote: >> On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote: >>> On Thu, Oct 7, 2010 at 7:43 PM, Josh Kupershmidt wrote: >>> >>> > I noticed that granting a us

Re: [HACKERS] How to determine failed connection attempt due to invalid authorization (libpq)?

On Mon, Oct 18, 2010 at 10:18:25AM -0400, Robert Haas wrote: > On Mon, Oct 18, 2010 at 10:05 AM, David Fetter wrote: > > On Mon, Oct 18, 2010 at 10:03:55AM -0400, Robert Haas wrote: > >> On Sun, Oct 17, 2010 at 2:03 AM, Dmitriy Igrishin > >> wrote: > >> > I've asked pgsql-general. > >> > Unfortu

Re: [HACKERS] How to determine failed connection attempt due to invalid authorization (libpq)?

On Mon, Oct 18, 2010 at 10:05 AM, David Fetter wrote: > On Mon, Oct 18, 2010 at 10:03:55AM -0400, Robert Haas wrote: >> On Sun, Oct 17, 2010 at 2:03 AM, Dmitriy Igrishin wrote: >> > I've asked pgsql-general. >> > Unfortunately it seems that there is no better way to do it except >> > parsing PQer

Re: [HACKERS] ask for review of MERGE

On Mon, Oct 18, 2010 at 10:09 AM, Boxuan Zhai wrote: > > > On Mon, Oct 18, 2010 at 9:54 PM, Robert Haas wrote: >> >> I think that MERGE is supposed to trigger one rule for each row in the >> source data.  So: >> >> On Sun, Oct 17, 2010 at 8:20 PM, Greg Smith wrote: >> > MERGE INTO Stock t >> >  

Re: [HACKERS] security hook on table creation

2010/10/17 KaiGai Kohei : > (2010/10/15 22:04), Stephen Frost wrote: >> KaiGai, >> >> * KaiGai Kohei (kai...@kaigai.gr.jp) wrote: >>> However, it requires the plugin modules need to know everything; >>> such as what is visible/invisible. It seems to me too closely- >>> coupled interface. >> >> I ag

Re: [HACKERS] WIP: extensible enums

On 10/17/2010 03:56 PM, Tom Lane wrote: [clever scheme to treat even numbered enum Oids as sorted] The one problem I can see with this is that it's only partially on-disk-compatible with existing enum types: it'll almost certainly think that they require slow comparison, even when they don't

Re: [HACKERS] ask for review of MERGE

On Mon, Oct 18, 2010 at 9:54 PM, Robert Haas wrote: > I think that MERGE is supposed to trigger one rule for each row in the > source data. So: > > On Sun, Oct 17, 2010 at 8:20 PM, Greg Smith wrote: > > MERGE INTO Stock t > > USING (SELECT * FROM Stock WHERE item_id=10) AS s > > ON s.item_id=

Re: [HACKERS] How to determine failed connection attempt due to invalid authorization (libpq)?

On Mon, Oct 18, 2010 at 10:03:55AM -0400, Robert Haas wrote: > On Sun, Oct 17, 2010 at 2:03 AM, Dmitriy Igrishin wrote: > > I've asked pgsql-general. > > Unfortunately it seems that there is no better way to do it except > > parsing PQerrorMessage(). Sadly. > > Yeah, doesn't look like it. A quic

Re: [HACKERS] How to determine failed connection attempt due to invalid authorization (libpq)?

On Sun, Oct 17, 2010 at 2:03 AM, Dmitriy Igrishin wrote: > I've asked pgsql-general. > Unfortunately it seems that there is no better way to do it except > parsing PQerrorMessage(). Sadly. Yeah, doesn't look like it. A quick glance at the code reveals that a PGresult can store individual error f

Re: [HACKERS] ask for review of MERGE

I think that MERGE is supposed to trigger one rule for each row in the source data. So: On Sun, Oct 17, 2010 at 8:20 PM, Greg Smith wrote: > MERGE INTO Stock t >  USING (SELECT * FROM Stock WHERE item_id=10) AS s >  ON s.item_id=t.item_id >  WHEN MATCHED THEN UPDATE SET balance=s.balance + 1 >  

Re: [HACKERS] ISN patch that applies cleanly with git apply

On Sun, Oct 3, 2010 at 9:53 AM, Peter Geoghegan wrote: > Whoops...seems there was some minor mangling when I applied the > original patch by: > > pe...@linux-peter-home:~/postgresql> patch --version > GNU patch 2.6.1.81-5b68 > snip*** > pe...@linux-peter-home:~/postgresql> patch -c < contrib_i

Re: [HACKERS] knngist - 0.8

On Mon, Oct 18, 2010 at 11:41:06AM +0100, Mark Cave-Ayland wrote: > Paul Ramsey wrote: > > >>So what kind of data structure would you like for a typmod? > > > >I'm a primitive enough beast that just having 64-bits would make me > >happy. As a general matter though, a bytea? > > > >P > > For my vo

Re: [HACKERS] leaky views, yet again

On Mon, Oct 18, 2010 at 5:02 AM, KaiGai Kohei wrote: >> Just to give one example of what this patch misses (probably; as I said >> I haven't read it lately), what about selectivity estimation?  One of >> the things we like to do when we have an otherwise-unknown function is >> to try it on all the

Re: [HACKERS] string function - "format" function proposal

2010/10/18 Itagaki Takahiro : > On Sat, Oct 16, 2010 at 7:29 AM, Robert Haas wrote: >> No doubt.  The problem is that we're going to end up with those bells >> and whistles in two places: in to_char or other type-specific >> formatting functions, and again in format. > > If we decide to use C-like

  1   2   >