Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

On Wed, May 28, 2014 at 8:22 AM, ash wrote: >> None of that involves answering hypothetical questions; but what you >> want to do does, and that I think is the problem in a nutshell. > > In a nutshell I'd like PostgreSQL to just re-parse the *current* view > definition. Should that throw an error

Re: [HACKERS] replication protocol documentation inconsistencies

On Wed, May 28, 2014 at 6:51 PM, Andres Freund wrote: > On 2014-05-21 07:29:53 -0400, Peter Eisentraut wrote: >> Looking at >> http://www.postgresql.org/docs/devel/static/protocol-replication.html >> under START_REPLICATION it goes >> >> """ >> The payload of each CopyData message from server to t

Re: [HACKERS] Documenting the Frontend/Backend Protocol update criteria

Jan Urbański made a presentation titled 'Postgres on the wire', subtitle 'A look at the PostgreSQL wire protocol'. I hope this covers some of your interest. Presentation slide deck is available at http://www.pgcon.org/2014/schedule/attachments/330_postgres-for-the-wire.pdf Hope it helps; --- K

Re: [HACKERS] Spreading full-page writes

On Wed, May 28, 2014 at 1:10 PM, Amit Kapila wrote: > On Tue, May 27, 2014 at 1:19 PM, Fujii Masao wrote: >> On Tue, May 27, 2014 at 3:57 PM, Simon Riggs >> wrote: >> > The requirements we were discussing were around >> > >> > A) reducing WAL volume >> > B) reducing foreground overhead of writin

Re: [HACKERS] Compression of full-page-writes

On Thu, May 29, 2014 at 7:21 PM, Simon Riggs wrote: > On 29 May 2014 01:07, Bruce Momjian wrote: >> On Wed, May 28, 2014 at 04:04:13PM +0100, Simon Riggs wrote: >>> On 28 May 2014 15:34, Fujii Masao wrote: >>> >>> >> Also, compress_backup_block GUC needs to be merged with full_page_writes. >>> >

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

Robert Haas writes: > On Wed, May 28, 2014 at 8:22 AM, ash wrote: >>> None of that involves answering hypothetical questions; but what you >>> want to do does, and that I think is the problem in a nutshell. >> >> In a nutshell I'd like PostgreSQL to just re-parse the *current* view >> definitio

Re: [HACKERS] WAL replay bugs

On Wed, Apr 23, 2014 at 9:43 PM, Heikki Linnakangas wrote: > And here is the tool itself. It consists of two parts: > > 1. Modifications to the backend to write the page images > 2. A post-processing tool to compare the logged images between master and > standby. Having that into Postgres at the d

Re: [HACKERS] backup_label revisited

On Thu, May 29, 2014 at 9:12 PM, Greg Stark wrote: > So I ran into the case again where a system crashed while a hot backup > was being taken. Postgres couldn't start up automatically because the > backup_label was present. This has come up before e.g. > http://www.postgresql.org/message-id/caazku

Re: [HACKERS] replication protocol documentation inconsistencies

Robert Haas wrote: > On Wed, May 28, 2014 at 6:51 PM, Andres Freund wrote: > > On 2014-05-21 07:29:53 -0400, Peter Eisentraut wrote: > >> More generally, it is weird that the message formats are described > >> there, even though the rest of the protocol documentation only mentions > >> the messag

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

Robert Haas writes: > What exactly do you mean by "re-parse the current view definition"? > The only form of the view definition we actually have is already > parsed into an internal form (see pg_rewrite) which, for the reasons > I've attempted to explain, is not easy to adapt to new column types.

Re: [HACKERS] pg_stat directory and pg_stat_statements

On Thu, May 29, 2014 at 3:02 PM, Peter Geoghegan wrote: > On Wed, May 28, 2014 at 10:49 PM, Fujii Masao wrote: >> You're concerned about the scenario using pg_upgrade? I'm not sure the detail >> of pg_upgrade. But if it doesn't work properly, we should have gotten >> the trouble > > I'm not worri

Re: [HACKERS] Jsonb: jbvBinary usage in the convertJsonbValue?

On Thu, May 29, 2014 at 7:34 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote: > I'm little confused by the convertJsonbValue functon at jsonb_utils.c > Maybe I misunderstood something, so I need help =) > if (IsAJsonbScalar(val) || val->type == jbvBinary) convertJsonbScalar(buffer, he

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

On Mon, Jun 2, 2014 at 8:52 AM, ash wrote: >> On Wed, May 28, 2014 at 8:22 AM, ash wrote: None of that involves answering hypothetical questions; but what you want to do does, and that I think is the problem in a nutshell. >>> >>> In a nutshell I'd like PostgreSQL to just re-parse the *

Re: [HACKERS] pg_stat directory and pg_stat_statements

On 2014-06-02 22:59:55 +0900, Fujii Masao wrote: > On Thu, May 29, 2014 at 3:02 PM, Peter Geoghegan wrote: > > On Wed, May 28, 2014 at 10:49 PM, Fujii Masao wrote: > >> You're concerned about the scenario using pg_upgrade? I'm not sure the > >> detail > >> of pg_upgrade. But if it doesn't work p

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

Robert Haas writes: > On Mon, Jun 2, 2014 at 8:52 AM, ash wrote: >> Should this fail, the user will have to work around it, but most of the >> time it could just work. > You're either missing or choosing to ignore the point that I'm making, > which is that we *don't have* the text form of the vi

Re: [HACKERS] Jsonb: jbvBinary usage in the convertJsonbValue?

On 06/02/2014 10:02 AM, Robert Haas wrote: On Thu, May 29, 2014 at 7:34 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote: I'm little confused by the convertJsonbValue functon at jsonb_utils.c Maybe I misunderstood something, so I need help =) if (IsAJsonbScalar(val) || val->type == jbvBinary)

Re: [HACKERS] Allowing join removals for more join types

David Rowley writes: > I'm not quite there with inner joins yet. I'm still getting my head around > just where the join quals are actually stored. TBH I think that trying to do anything at all for inner joins is probably a bad idea. The cases where the optimization could succeed are so narrow th

Re: [HACKERS] Allowing join removals for more join types

* Tom Lane (t...@sss.pgh.pa.us) wrote: > David Rowley writes: > > I'm not quite there with inner joins yet. I'm still getting my head around > > just where the join quals are actually stored. > > TBH I think that trying to do anything at all for inner joins is probably > a bad idea. The cases wh

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

Tom Lane writes: > Robert Haas writes: >> On Mon, Jun 2, 2014 at 8:52 AM, ash wrote: >>> Should this fail, the user will have to work around it, but most of the >>> time it could just work. > >> You're either missing or choosing to ignore the point that I'm making, >> which is that we *don't h

Re: [HACKERS] Jsonb: jbvBinary usage in the convertJsonbValue?

On 06/02/2014 10:22 AM, Andrew Dunstan wrote: On 06/02/2014 10:02 AM, Robert Haas wrote: On Thu, May 29, 2014 at 7:34 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote: I'm little confused by the convertJsonbValue functon at jsonb_utils.c Maybe I misunderstood something, so I need help =) if

Re: [HACKERS] Allowing join removals for more join types

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> TBH I think that trying to do anything at all for inner joins is probably >> a bad idea. The cases where the optimization could succeed are so narrow >> that it's unlikely to be worth adding cycles to every query to check. > I agr

Re: plpython_unicode test (was Re: [HACKERS] buildfarm / handling (undefined) locales)

Andrew Dunstan writes: > On 06/01/2014 05:35 PM, Tom Lane wrote: >> I did a little bit of experimentation and determined that none of the >> LATIN1 characters are significantly more portable than what we've got: >> for instance a-acute fails to convert into 16 of the 33 supported >> server-side en

Re: [HACKERS] recovery testing for beta

On Fri, May 30, 2014 at 8:09 PM, Amit Kapila wrote: > On Sat, May 31, 2014 at 3:51 AM, Jeff Janes wrote: > > On Thu, May 29, 2014 at 8:15 PM, Amit Kapila > wrote: > >> On Thu, May 29, 2014 at 10:09 PM, Jeff Janes > wrote: > >> > > >> > What features in 9.4 need more beta testing for recovery?

Re: [HACKERS] recovery testing for beta

Hi, On 2014-06-02 09:03:25 -0700, Jeff Janes wrote: > On Fri, May 30, 2014 at 8:09 PM, Amit Kapila > wrote: > > > On Sat, May 31, 2014 at 3:51 AM, Jeff Janes wrote: > > > On Thu, May 29, 2014 at 8:15 PM, Amit Kapila > > wrote: > > >> On Thu, May 29, 2014 at 10:09 PM, Jeff Janes > > wrote: > >

Re: [HACKERS] recovery testing for beta

On Mon, Jun 2, 2014 at 9:14 AM, Andres Freund wrote: > Hi, > > On 2014-06-02 09:03:25 -0700, Jeff Janes wrote: > > > > GNU make does not realize that pg_xlogdump depends > > on src/backend/access/rmgrdesc/heapdesc.c. (I don't know how or why it > has > > that dependency, but changes did not take

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

On Mon, Jun 2, 2014 at 10:21 AM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jun 2, 2014 at 8:52 AM, ash wrote: >>> Should this fail, the user will have to work around it, but most of the >>> time it could just work. > >> You're either missing or choosing to ignore the point that I'm making

Re: [HACKERS] recovery testing for beta

Hi, On 2014-06-02 10:15:19 -0700, Jeff Janes wrote: > > > Also, pg_xlogdump -p insists on being given a start position. I > > would > > > be nice if it could just find the first file in the given directory. Any > > > reason it can't do that, other than just that no one implemented it yet? >

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

Robert Haas writes: > On Mon, Jun 2, 2014 at 10:21 AM, Tom Lane wrote: >> The real problem in my mind is one of user expectations. If the database >> silently does something behind your back, people expect that that action >> will be *right* and they don't have to worry about it. I don't think

Re: [HACKERS] Jsonb: jbvBinary usage in the convertJsonbValue?

On Mon, Jun 2, 2014 at 7:22 AM, Andrew Dunstan wrote: > Yes, I've just been looking at that. I think this is probably a hangover > from when these routines were recast to some extent. Given that we're not > seeing any errors from it, I'd be inclined to remove the the "|| val->type > == jbvBinary"

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

* Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Jun 2, 2014 at 10:21 AM, Tom Lane wrote: > > The real problem in my mind is one of user expectations. If the database > > silently does something behind your back, people expect that that action > > will be *right* and they don't have to worr

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas writes: > > I agree, but I think it's important to note that Alex's complaint is > > not unique - the way things work now is a real source of frustration > > for users. > > Oh, I quite agree with that. My concern here has to do with automatica

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

On 06/02/2014 10:40 AM, Stephen Frost wrote: > Tom's point goes back to what I was trying to drive at originally- > people should have to ask for this. Perhaps we can provide a way for > them to ask which is explicit enough that they understand "this might > not do exactly what you think it does",

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

On 2014-06-02 10:48:02 -0700, Josh Berkus wrote: > On 06/02/2014 10:40 AM, Stephen Frost wrote: > > Tom's point goes back to what I was trying to drive at originally- > > people should have to ask for this. Perhaps we can provide a way for > > them to ask which is explicit enough that they underst

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

On 2014-06-02 13:40:32 -0400, Stephen Frost wrote: > Of course, there is a question about if it's worth it to keep around the > exact text of each CREATE VIEW and build all this infrastructure for > something which will only work properly in a specific subset of cases > and in many others could bre

Re: [HACKERS] recovery testing for beta

Jeff Janes wrote: > GNU make does not realize that pg_xlogdump depends > on src/backend/access/rmgrdesc/heapdesc.c. (I don't know how or why it has > that dependency, but changes did not take effect with a simple "make > install") Is that a known issue? Is there someway to fix it? Uh, you're ri

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

Tom Lane wrote: > Oh, I quite agree with that. My concern here has to do with automatically > and silently making changes that we can't be very sure will meet the > user's expectations. Perhaps what we need is some kind of UI/API design > whereby the user can inspect/modify/approve the semantic

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

On Mon, Jun 2, 2014 at 1:40 PM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Mon, Jun 2, 2014 at 10:21 AM, Tom Lane wrote: >> > The real problem in my mind is one of user expectations. If the database >> > silently does something behind your back, people expect that

Re: [HACKERS] [GSoC] Clustering in MADlib - status update

Hi! 2014-06-02 19:16 GMT+02:00 Hai Qian : > I like the second option for refactoring the code. I think it is doable. > > And where is your code on Github? > It's not on Github, but on my own Gitlab (a self-hosted open-source alternative to github). You can find it here [0]. I'm using two repos:

Re: [HACKERS] [PATCH] Replacement for OSSP-UUID for Linux and BSD

On Thu, May 29, 2014 at 1:56 PM, Tom Lane wrote: > Bruce Momjian writes: >> One thing that concerns me is that we already had the problem that users >> creating the uuid-ossp extension had to double-quote the name because of >> the dash, and we have regularly questioned the viability of the >> uu

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

Alvaro Herrera writes: > Tom Lane wrote: >> Oh, I quite agree with that. My concern here has to do with automatically >> and silently making changes that we can't be very sure will meet the >> user's expectations. Perhaps what we need is some kind of UI/API design >> whereby the user can inspect

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

Robert Haas writes: > FWIW, I don't think reparsing the original view-text is even remotely > plausible. The fact that views stay glued to the same objects even of > those objects are renamed is a pretty handy property of the current > system, and any sort of reparse-from-scratch technique would

Re: [HACKERS] [GSoC] Clustering in MADlib - status update

I like the second option for refactoring the code. I think it is doable. And where is your code on Github? Hai -- *Pivotal * A new platform for a new era On Sun, Jun 1, 2014 at 1:06 PM, Maxence Ahlouche wrote: > Hi all! > > I've pushed my report for this week on my

Re: [HACKERS] Proposing pg_hibernate

On Fri, May 30, 2014 at 5:33 PM, Josh Kupershmidt wrote: > On Tue, May 27, 2014 at 10:01 PM, Gurjeet Singh wrote: > >> When the Postgres server is being stopped/shut down, the `Buffer >> Saver` scans the >> shared-buffers of Postgres, and stores the unique block identifiers of >> each cached >> b

Re: [HACKERS] pg_stat directory and pg_stat_statements

On Mon, Jun 2, 2014 at 11:07 PM, Andres Freund wrote: > On 2014-06-02 22:59:55 +0900, Fujii Masao wrote: >> On Thu, May 29, 2014 at 3:02 PM, Peter Geoghegan wrote: >> > On Wed, May 28, 2014 at 10:49 PM, Fujii Masao >> > wrote: >> >> You're concerned about the scenario using pg_upgrade? I'm not

Re: plpython_unicode test (was Re: [HACKERS] buildfarm / handling (undefined) locales)

I wrote: > Andrew Dunstan writes: >> Let's just stick to ASCII. > The more I think about it, the more I think that using a plain-ASCII > character would defeat most of the purpose of the test. Non-breaking > space seems like the best bet here, not least because it has several > different represe

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

On Mon, Jun 2, 2014 at 2:47 PM, Tom Lane wrote: >> Deparse-and-reparse might be better, but I'll bet that has too >> many problems to be viable, too (even if I haven't yet thought of what >> they are). For better or for worse, I think the best we're likely to >> be able to do is somehow manipulat

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

Robert Haas writes: > On Mon, Jun 2, 2014 at 2:47 PM, Tom Lane wrote: >> I think deparse-and-reparse is exactly what we have to do, mainly because, >> if you subscribe to the idea that the user should see and approve semantic >> changes, what else are we going to show her except SQL? If she want

Re: [HACKERS] [BUGS] BUG #9652: inet types don't support min/max

On Thu, May 29, 2014 at 3:28 AM, Keith Fiske wrote: > On Sun, Mar 23, 2014 at 10:42 PM, Haribabu Kommi > wrote: >> >> On Fri, Mar 21, 2014 at 5:17 PM, wrote: >> > The following bug has been logged on the website: >> > reclog=> select * from foo; >> >bar >> > - >> > 1.2.3.4 >> > (1

Re: [HACKERS] Spreading full-page writes

On Mon, Jun 2, 2014 at 6:04 PM, Fujii Masao wrote: > On Wed, May 28, 2014 at 1:10 PM, Amit Kapila wrote: > > > IIUC in DBW mechanism, we need to have a temporary sequential > > log file of fixed size which will be used to write data before the data > > gets written to its actual location in table

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

On Mon, Jun 02, 2014 at 01:29:25PM -0400, Robert Haas wrote: > I agree, but I think it's important to note that Alex's complaint is > not unique - the way things work now is a real source of frustration > for users. In a previous job, I wrote a schema-upgrade script that > dropped all of the views