Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Bruce Momjian writes: > On Mon, Mar 25, 2013 at 10:14:15AM -0700, Josh Berkus wrote: >>> No, it *isn't* a good idea. GUCs that change application-visible >>> semantics are dangerous. We should have learned this lesson by now. >> Really? I thought that standard_conforming_strings was a great ex

Re: [HACKERS] pg_upgrade segfaults when given an invalid PGSERVICE value

Bruce Momjian writes: > On Mon, Mar 25, 2013 at 07:07:42PM -0400, Tom Lane wrote: >> Well, plan B would be to invent a replacement function that does have >> the ability to return an error message, but that seems like a lot of >> work for a problem that's so marginal that it wasn't noticed till no

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On Mon, Mar 25, 2013 at 10:14:15AM -0700, Josh Berkus wrote: > Tom, > > > No, it *isn't* a good idea. GUCs that change application-visible > > semantics are dangerous. We should have learned this lesson by now. > > Really? I thought that standard_conforming_strings was a great example > of how

Re: [HACKERS] pg_upgrade segfaults when given an invalid PGSERVICE value

On Mon, Mar 25, 2013 at 07:07:42PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > We are taking this approach because PQconndefaults() doesn't have an API > > to return the error cause, while other API calls do. Returning true so > > we can later report the right error from a later API call j

Re: [HACKERS] plpgsql_check_function - rebase for 9.3

Josh Berkus writes: > Where are we with this patch? I'm a bit unclear from the discussion on > whether it passes muster or not. Things seem to have petered out. I took another look at this patch tonight. I think the thing that is bothering everybody (including Pavel) is that as submitted, pl_c

Re: [HACKERS] Limiting setting of hint bits by read-only queries; vacuum_delay

On Mon, 2013-03-25 at 12:21 +, Greg Stark wrote: > On Mon, Mar 25, 2013 at 2:50 AM, Greg Smith wrote: > > The idea I was thinking about is refactoring the background writer's role in > > hint bit maintenance > > A good first step might be to separate the "dirty" bit into two bits. > "mandator

Re: [HACKERS] Limiting setting of hint bits by read-only queries; vacuum_delay

On Tue, Mar 26, 2013 at 12:00 AM, Simon Riggs wrote: > I'll bet you all a beer at PgCon 2014 that this remains unresolved at > that point. Are you saying you're only interested in working on it now? That after 9.3 is release you won't be interested in working on it any more? As you said we've be

Re: [HACKERS] Enabling Checksums

On Mon, Mar 25, 2013 at 3:51 PM, Bruce Momjian wrote: > Great analysis. Is there any logic to using a lighter-weight checksum > calculation for cases where the corruption is rare? For example, we > know that network transmission can easily be corrupted, while buffer > corruption is rare, and if

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 2013.03.25 6:03 PM, Darren Duncan wrote: On 2013.03.25 5:55 PM, Craig Ringer wrote: On 03/25/2013 10:28 PM, Tom Lane wrote: Yeah, they are, because things break when they're set wrong. They also make debugging and support harder; you need to get an ever-growing list of GUC values from the u

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 2013.03.25 5:55 PM, Craig Ringer wrote: On 03/25/2013 10:28 PM, Tom Lane wrote: Yeah, they are, because things break when they're set wrong. They also make debugging and support harder; you need to get an ever-growing list of GUC values from the user to figure out what their query does. byte

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 03/25/2013 10:28 PM, Tom Lane wrote: > Yeah, they are, because things break when they're set wrong. They also make debugging and support harder; you need to get an ever-growing list of GUC values from the user to figure out what their query does. bytea_output, standard_conforming_strings, etc. Y

Re: [HACKERS] [COMMITTERS] pgsql: Add PF_PRINTF_ATTRIBUTE to on_exit_msg_fmt.

Heikki Linnakangas writes: > On 25.03.2013 15:36, Tom Lane wrote: >> Heikki Linnakangas writes: >>> Add PF_PRINTF_ATTRIBUTE to on_exit_msg_fmt. >>> Per warning from -Wmissing-format-attribute. >> Hm, this is exactly what I removed yesterday, because it makes the build >> fail outright on old gcc

Re: [HACKERS] Limiting setting of hint bits by read-only queries; vacuum_delay

Simon Riggs writes: > On 25 March 2013 23:18, Tom Lane wrote: >> This is clearly worth thinking about and trying to find better solutions >> for. I'm only against trying to solve it in the 9.3 timeframe. It will >> take a lot longer than that to get something that works tolerably well. > I'll

Re: [HACKERS] Request for vote to move forward with recovery.conf overhaul

On Mon, Mar 25, 2013 at 1:14 PM, Simon Riggs wrote: > On 25 March 2013 04:08, Michael Paquier wrote: > > > Feedback is warmly welcome. > > I'll look at this in the coming week. > Thanks. -- Michael

Re: [HACKERS] Limiting setting of hint bits by read-only queries; vacuum_delay

On 25 March 2013 23:18, Tom Lane wrote: > Greg Stark writes: >> On Mon, Mar 25, 2013 at 9:53 PM, Kevin Grittner wrote: >>> That would make it harder to construct a degenerate case > >> I don't think it's hard at all. It's the same as the case Simon wants >> to solve except that the cost is incur

Re: [HACKERS] Limiting setting of hint bits by read-only queries; vacuum_delay

Greg Stark writes: > On Mon, Mar 25, 2013 at 9:53 PM, Kevin Grittner wrote: >> That would make it harder to construct a degenerate case > I don't think it's hard at all. It's the same as the case Simon wants > to solve except that the cost is incurred in a different way. Imagine > a system where

Re: [HACKERS] Limiting setting of hint bits by read-only queries; vacuum_delay

On Mon, Mar 25, 2013 at 5:57 PM, Greg Stark wrote: > On Mon, Mar 25, 2013 at 9:53 PM, Kevin Grittner wrote: >> That would make it harder to construct a degenerate case > > I don't think it's hard at all. It's the same as the case Simon wants > to solve except that the cost is incurred in a differ

Re: [HACKERS] pg_upgrade segfaults when given an invalid PGSERVICE value

Bruce Momjian writes: > We are taking this approach because PQconndefaults() doesn't have an API > to return the error cause, while other API calls do. Returning true so > we can later report the right error from a later API call just feels > wrong. Well, plan B would be to invent a replacement

Re: [HACKERS] Limiting setting of hint bits by read-only queries; vacuum_delay

On Mon, Mar 25, 2013 at 9:53 PM, Kevin Grittner wrote: > That would make it harder to construct a degenerate case I don't think it's hard at all. It's the same as the case Simon wants to solve except that the cost is incurred in a different way. Imagine a system where there's a huge data load to

Re: [HACKERS] adding support for zero-attribute unique/etc keys

Brendan Jurd writes: > On 26 March 2013 05:04, Darren Duncan wrote: >> On 2013.03.25 1:17 AM, Albe Laurenz wrote: >>> The desired effect can be had today with a unique index: >>> CREATE TABLE singleton (id integer); >>> CREATE UNIQUE INDEX singleton_idx ON singleton((1)); >> Okay, that is helpfu

Re: [HACKERS] Limiting setting of hint bits by read-only queries; vacuum_delay

Simon Riggs wrote: > On 25 March 2013 20:44, Kevin Grittner wrote: >> This is absolutely a real-world problem, but I disagree that the >> solution you propose is risk-free.  It would be trivial to >> construct a test which would show massive performance degradation. > > It is trivial to show mas

Re: [HACKERS] adding support for zero-attribute unique/etc keys

On 26 March 2013 05:04, Darren Duncan wrote: > On 2013.03.25 1:17 AM, Albe Laurenz wrote: >> The desired effect can be had today with a unique index: >> >> CREATE TABLE singleton (id integer); >> CREATE UNIQUE INDEX singleton_idx ON singleton((1)); > > Okay, that is helpful, and less of a kludge t

Re: [HACKERS] Limiting setting of hint bits by read-only queries; vacuum_delay

On 25 March 2013 20:44, Kevin Grittner wrote: > Simon Riggs wrote: >> Merlin Moncure wrote: > >>> we need testing against real world workloads, or at least a much >>> better synthetic one than pgbench, which per recent discussions >>> is probably the top objective of the project (a performance >

Re: [HACKERS] Limiting setting of hint bits by read-only queries; vacuum_delay

On Mon, Mar 25, 2013 at 1:05 PM, Simon Riggs wrote: > On 25 March 2013 14:26, Merlin Moncure wrote: > >> This is pretty similar to the proposal Atri and I just recently made. >> I am 100% in agreement that something must be done here...SELECT has >> none of the i/o mitigation features that vacuum

Re: [HACKERS] Limiting setting of hint bits by read-only queries; vacuum_delay

Simon Riggs wrote: > Merlin Moncure wrote: >> we need testing against real world workloads, or at least a much >> better synthetic one than pgbench, which per recent discussions >> is probably the top objective of the project (a performance >> farm, etc.). > > Self-tuning the background workload

Re: [HACKERS] Let's invent a function to report lock-wait-blocking PIDs

On Thu, Mar 21, 2013 at 12:03:21AM +0100, Dimitri Fontaine wrote: > Tom Lane writes: > >> pg_is_lock_exclusive(lock, lock) returns boolean > >> pg_is_lock_exclusive(lock[], lock[]) returns boolean > > > >> I suppose that the lock type would be text ('ExclusiveLock'), but we > >> could also exp

[HACKERS] Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)

On 26 March 2013 05:26, Greg Stark wrote: > I'm not as sanguine as Tom is about how likely these corner cases will > be met actually. As far as I can tell checking IS NULL on > array_length() was the supported way to check for 0-length arrays > previously Correct. There was no other way to check

Re: [HACKERS] Assertion failure when promoting node by deleting recovery.conf and restart node

On 15.03.2013 04:25, Michael Paquier wrote: Hi, When trying to *promote* a slave as master by removing recovery.conf and restarting node, I found an assertion failure on master branch: LOG: database system was shut down in recovery at 2013-03-15 10:22:27 JST TRAP: FailedAssertion("!(ControlFile

Re: [HACKERS] backward incompatible pg_basebackup and pg_receivexlog

On 25.03.2013 11:23, Heikki Linnakangas wrote: On 19.03.2013 13:49, Magnus Hagander wrote: On Tue, Mar 19, 2013 at 11:39 AM, Heikki Linnakangas wrote: On 19.03.2013 04:42, Peter Eisentraut wrote: Also, using the old tools against new server versions either behaves funny or silently appears t

Re: [HACKERS] Interesting post-mortem on a near disaster with git

On Mon, Mar 25, 2013 at 11:07 AM, Stefan Kaltenbrunner wrote: >> Back when we used CVS for quite a few years I kept 7 day rolling >> snapshots of the CVS repo, against just such a difficulty as this. But >> we seem to be much better organized with infrastructure these days so I >> haven't done tha

Re: [HACKERS] Interesting post-mortem on a near disaster with git

On Mon, Mar 25, 2013 at 7:07 PM, Stefan Kaltenbrunner wrote: > On 03/24/2013 11:22 PM, Andrew Dunstan wrote: >> >> On 03/24/2013 06:06 PM, Michael Paquier wrote: >>> On Mon, Mar 25, 2013 at 12:52 AM, Tom Lane >> > wrote: >>> >>> Over the weekend, KDE came within a gn

[HACKERS] Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)

On Mon, Mar 25, 2013 at 5:14 PM, Josh Berkus wrote: > Tom, > >> No, it *isn't* a good idea. GUCs that change application-visible >> semantics are dangerous. We should have learned this lesson by now. > > Really? I thought that standard_conforming_strings was a great example > of how to ease our

Re: [HACKERS] pg_upgrade segfaults when given an invalid PGSERVICE value

On Mon, Mar 25, 2013 at 10:59:21AM -0400, Steve Singer wrote: > On 13-03-20 05:54 PM, Tom Lane wrote: > >Steve Singer writes: > > > > >> From a end-user expectations point of view I am okay with somehow > >>marking the structure returned by PQconndefaults in a way that the > >>connect calls will

Re: [HACKERS] Interesting post-mortem on a near disaster with git

On 03/24/2013 11:22 PM, Andrew Dunstan wrote: > > On 03/24/2013 06:06 PM, Michael Paquier wrote: >> On Mon, Mar 25, 2013 at 12:52 AM, Tom Lane > > wrote: >> >> Over the weekend, KDE came within a gnat's eyelash of losing *all* >> their authoritative git repos, de

Re: [HACKERS] Limiting setting of hint bits by read-only queries; vacuum_delay

On 25 March 2013 14:26, Merlin Moncure wrote: > This is pretty similar to the proposal Atri and I just recently made. > I am 100% in agreement that something must be done here...SELECT has > none of the i/o mitigation features that vacuum has. Is your idea > better? probably (although you have t

Re: [HACKERS] adding support for zero-attribute unique/etc keys

On 2013.03.25 1:17 AM, Albe Laurenz wrote: Darren Duncan wrote: From my usage and http://www.postgresql.org/docs/9.2/interactive/sql-createtable.html I see that Postgres requires constraints like unique (and primary) keys, and foreign keys, to range over at least 1 attribute/column. I propose

[HACKERS] regression test failed when enabling checksum

Hi, I found that the regression test failed when I created the database cluster with the checksum and set wal_level to archive. I think that there are some bugs around checksum feature. Attached is the regression.diff. Regards, -- Fujii Masao regression.diffs Description: Binary data -- Sen

Re: [HACKERS] odd behavior in materialized view

On Fri, Mar 8, 2013 at 1:52 AM, Kevin Grittner wrote: > Fujii Masao wrote: > >> Thanks! I confirmed that the problem that I reported has >> disappeared in HEAD. >> >> Unfortunately I found another odd behavior. When I accessed the >> MV after VACUUM ANALYZE, I got the following error. >> >> E

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Tom, > No, it *isn't* a good idea. GUCs that change application-visible > semantics are dangerous. We should have learned this lesson by now. Really? I thought that standard_conforming_strings was a great example of how to ease our users into a backwards-compatibility break. My thought was t

Re: [HACKERS] Limiting setting of hint bits by read-only queries; vacuum_delay

> This is pretty similar to the proposal Atri and I just recently made. > I am 100% in agreement that something must be done here...SELECT has > none of the i/o mitigation features that vacuum has. Is your idea > better? probably (although you have to give a small penalty for a user > facing tunab

[HACKERS] Re: DROP OWNED BY fails to drop privileges granted by non-owners (was Re: [GENERAL] Bug, Feature, or what else?)

Tom Lane escribió: > It looks to me like DropOwnedObjects doesn't actually insist on > superuserness to do DROP OWNED, only ability to become the role, > which means that DROP OWNED BY is completely broken for privileges > if executed by a non-superuser; the only privileges it would remove > would

Re: [HACKERS] pg_dump selectively ignores extension configuration tables

On Mar 25, 2013, at 10:48 AM, Joe Conway wrote: > On 03/25/2013 08:12 AM, Vibhor Kumar wrote: >> Since, nobody has picked this one. >> >> If there is no objection,then I can test this patch against 9.1 & 9.2. > > Here are diffs for 9.1 and 9.2. The previous email was against 9.3 dev. Thanks J

Re: [HACKERS] pg_dump selectively ignores extension configuration tables

On Mar 25, 2013, at 10:17 AM, Alvaro Herrera wrote: > Vibhor Kumar escribió: >> On Mar 25, 2013, at 9:56 AM, Joe Conway wrote: >> >>> On 03/14/2013 05:23 PM, Joe Conway wrote: On 03/13/2013 04:16 PM, Dimitri Fontaine wrote: > Joe Conway writes: >> I think it should dump the user

Re: [HACKERS] pg_dump selectively ignores extension configuration tables

On 03/25/2013 08:12 AM, Vibhor Kumar wrote: > Since, nobody has picked this one. > > If there is no objection,then I can test this patch against 9.1 & 9.2. Here are diffs for 9.1 and 9.2. The previous email was against 9.3 dev. Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, Pos

Re: [HACKERS] Let's invent a function to report lock-wait-blocking PIDs

Greg Smith wrote: > Note that an EXPLAIN based approach doesn't solve all the problems > in this area, because the trickiest ones I run into are ALTER TABLE > changes--which you can't EXPLAIN. Some API that dumps the locks an > arbitrary statement acquired just before it exits would be ideal. > W

Re: [HACKERS] pg_dump selectively ignores extension configuration tables

Vibhor Kumar escribió: > On Mar 25, 2013, at 9:56 AM, Joe Conway wrote: > > > On 03/14/2013 05:23 PM, Joe Conway wrote: > >> On 03/13/2013 04:16 PM, Dimitri Fontaine wrote: > >>> Joe Conway writes: > I think it should dump the user data portion, especially since that > matches what pg_

Re: [HACKERS] pg_dump selectively ignores extension configuration tables

On Mar 25, 2013, at 9:56 AM, Joe Conway wrote: > On 03/14/2013 05:23 PM, Joe Conway wrote: >> On 03/13/2013 04:16 PM, Dimitri Fontaine wrote: >>> Joe Conway writes: I think it should dump the user data portion, especially since that matches what pg_dump would do if you did not specify

Re: [HACKERS] [COMMITTERS] pgsql: Add PF_PRINTF_ATTRIBUTE to on_exit_msg_fmt.

On 25.03.2013 15:36, Tom Lane wrote: Heikki Linnakangas writes: Add PF_PRINTF_ATTRIBUTE to on_exit_msg_fmt. Per warning from -Wmissing-format-attribute. Hm, this is exactly what I removed yesterday, because it makes the build fail outright on old gcc: gcc -O1 -Wall -Wmissing-prototypes -Wpoi

Re: [HACKERS] pg_upgrade segfaults when given an invalid PGSERVICE value

On 13-03-20 05:54 PM, Tom Lane wrote: Steve Singer writes: From a end-user expectations point of view I am okay with somehow marking the structure returned by PQconndefaults in a way that the connect calls will later fail. Unless the program changes the value of PGSERVICE, surely all su

Re: [HACKERS] pg_dump selectively ignores extension configuration tables

On 03/14/2013 05:23 PM, Joe Conway wrote: > On 03/13/2013 04:16 PM, Dimitri Fontaine wrote: >> Joe Conway writes: >>> I think it should dump the user data portion, especially since that >>> matches what pg_dump would do if you did not specify the table or schema. >> >> +1 >> >> If you don't have t

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 21 March 2013 10:45, Brendan Jurd wrote: > src/test/isolation/expected/timeouts.out| 16 +- > src/test/isolation/specs/timeouts.spec | 8 +- Oops, looks like some unrelated changes made their way into the original patch. Apologies. Here's a -v2 patch, sans stowaways. Che

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Brendan Jurd writes: > On 26 March 2013 00:30, Tom Lane wrote: >> No, it *isn't* a good idea. GUCs that change application-visible >> semantics are dangerous. We should have learned this lesson by now. > They are? Yeah, they are, because things break when they're set wrong. Sometimes we have

Re: [HACKERS] Limiting setting of hint bits by read-only queries; vacuum_delay

On Sun, Mar 24, 2013 at 6:14 AM, Simon Riggs wrote: > vacuum_delay is designed to slow down VACUUMs from writing too many > blocks. However, SELECTs also dirty data blocks but are NOT slowed > down by vacuum_delay. > > So the current situation is that a large SELECT operates similarly to > a VACUU

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 26 March 2013 00:30, Tom Lane wrote: > Brendan Jurd writes: >> On 25 March 2013 13:02, Josh Berkus wrote: >>> Brendan, how hard would it be to create a GUC for backwards-compatible >>> behavior? > >> Good idea. > > No, it *isn't* a good idea. GUCs that change application-visible > semantics

Re: [HACKERS] Enabling Checksums

On Fri, Mar 22, 2013 at 05:09:53PM +0200, Ants Aasma wrote: > To see real world performance numbers I dumped the algorithms on top > of the checksums patch. I set up postgres with 32MB shared buffers, > and ran with concurrency 4 select only pgbench and a worst case > workload, results are median o

Re: [HACKERS] [COMMITTERS] pgsql: Add PF_PRINTF_ATTRIBUTE to on_exit_msg_fmt.

Heikki Linnakangas writes: > Add PF_PRINTF_ATTRIBUTE to on_exit_msg_fmt. > Per warning from -Wmissing-format-attribute. Hm, this is exactly what I removed yesterday, because it makes the build fail outright on old gcc: gcc -O1 -Wall -Wmissing-prototypes -Wpointer-arith -Wformat-security -fno-st

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Brendan Jurd writes: > On 25 March 2013 13:02, Josh Berkus wrote: >> Brendan, how hard would it be to create a GUC for backwards-compatible >> behavior? > Good idea. No, it *isn't* a good idea. GUCs that change application-visible semantics are dangerous. We should have learned this lesson by

Re: [HACKERS] adding support for zero-attribute unique/etc keys

Albe Laurenz writes: > Darren Duncan wrote: >> I propose that this be generalized so that constraints may instead be >> nullary, >> that is, range over zero or more attributes/columns instead. > Since an imagined zero-column query would have an empty set of > result columns, you could with equal

Re: [HACKERS] Enabling Checksums

On Fri, Mar 22, 2013 at 11:35:35PM -0500, Jim Nasby wrote: > On 3/20/13 8:41 AM, Bruce Momjian wrote: > >Also, if a users uses checksums in 9.3, could they initdb without > >checksums in 9.4 and use pg_upgrade? As coded, the pg_controldata > >checksum settings would not match and pg_upgrade would

Re: [HACKERS] Limiting setting of hint bits by read-only queries; vacuum_delay

On Mon, Mar 25, 2013 at 2:50 AM, Greg Smith wrote: > The idea I was thinking about is refactoring the background writer's role in > hint bit maintenance A good first step might be to separate the "dirty" bit into two bits. "mandatory dirty" and "optional dirty". (Or maybe "hard dirty" and "soft d

Re: [HACKERS] backward incompatible pg_basebackup and pg_receivexlog

On 19.03.2013 13:49, Magnus Hagander wrote: On Tue, Mar 19, 2013 at 11:39 AM, Heikki Linnakangas wrote: On 19.03.2013 04:42, Peter Eisentraut wrote: Also, using the old tools against new server versions either behaves funny or silently appears to work, both of which might be a problem. Hmm

Re: [HACKERS] Default connection parameters for postgres_fdw and dblink

Tom Lane wrote: > It struck me while looking at the regression test arrangements for > postgres_fdw that as things are set up, the default username for > outgoing connections is going to be that of the operating system > user running the postmaster. dblink is the same way. > > Now, this might not

Re: [HACKERS] adding support for zero-attribute unique/etc keys

Darren Duncan wrote: > From my usage and > http://www.postgresql.org/docs/9.2/interactive/sql-createtable.html I see that > Postgres requires constraints like unique (and primary) keys, and foreign > keys, > to range over at least 1 attribute/column. > > I propose that this be generalized so tha