[HACKERS] bad examples in pg_dump README

The ./src/bin/pg_dump README contains several inoperable examples. First, this suggestion: | or to list tables: | | pg_restore --table | less seems bogus, i.e. the --table option requires an argument specifing which table to restore, and does not "list tables". Next, this suggested comma

[HACKERS] PGCon 2013 - CFP & unconference day

Folks, The PGCon Call for Papers went out last month. But you have about two weeks left to respond. If you are doing something interesting with PostgreSQL, please submit a proposal. You might be one of the backend hackers or work on a PostgreSQL related project and want to share your know-how

Re: [HACKERS] pg_upgrade test script creates port conflicts in parallel testing

Andrew Dunstan writes: > On 01/03/2013 12:58 PM, Tom Lane wrote: >> Does anyone have an objection to fixing the pg_upgrade test script >> to suppress the TCP socket? > Should be OK. We can't do that on Windows, though, so please make it > conditional so we don't break Mingw buildfarm members. Th

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

On 01/03/2013 02:30 PM, Kevin Grittner wrote: Andrew Dunstan wrote: I don't especially have a horse in the race, but ISTM that if you want the information you want it to be able to persist across dump/restore, at least optionally. If you can happily lose it when you're forced to recover using

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

Andrew Dunstan wrote: > I don't especially have a horse in the race, but ISTM that if you want > the information you want it to be able to persist across dump/restore, > at least optionally. If you can happily lose it when you're forced to > recover using a logical dump then it's not that impor

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

On 01/03/2013 04:51 PM, Kevin Grittner wrote: Robert Haas wrote: Christopher Browne wrote: these timestamps Should Not be captured or carried forward by pg_dump. If we put a creation time into pg_database or pg_class, then streaming replication will, as a "physical" replication mechanism, car

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

Robert Haas wrote: > Christopher Browne wrote: >> these timestamps Should Not be captured or carried forward by >> pg_dump. >> If we put a creation time into pg_database or pg_class, then >> streaming replication will, as a "physical" replication >> mechanism, carry the timestamp forward into re

Re: [HACKERS] Reminder: CFP for pgCon closes January 19th

On 1/3/13 1:02 PM, Josh Berkus wrote: > Hackers, > > As a reminder, we are going to close the call for presentations for > pgCon on January 15th this year, in an effort to get speakers notified > sooner. Please submit your talks as soon as you can. Correction, the 19th. Also, a URL would help:

[HACKERS] Reminder: CFP for pgCon closes January 15th

Hackers, As a reminder, we are going to close the call for presentations for pgCon on January 15th this year, in an effort to get speakers notified sooner. Please submit your talks as soon as you can. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers maili

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

On Thu, Jan 3, 2013 at 12:54 PM, Christopher Browne wrote: > Yep, and I think that the behaviour of tar pretty nicely characterizes > what's troublesome here. It is quite likely that a tar run will *capture* > the creation time of a file, but if you pull data from a tar archive, it is > by no mea

Re: [HACKERS] Review of Row Level Security

KaiGai, * Kohei KaiGai (kai...@kaigai.gr.jp) wrote: > IMO, only "parser" should accept command types except for ALL but > raise an error something like "it is not supported yet" to protect from > syntax conflicts. Right, I agree with this. > Right now, I plan to submit a revised patch with the s

Re: [HACKERS] Feature Request: pg_replication_master()

On 3 January 2013 18:35, Josh Berkus wrote: > Robert, > >> In my view, the biggest problem with recovery.conf is that the >> parameters in there are not GUCs, which means that all of the >> infrastructure that we've built for managing GUCs does not work with >> them. As an example, when we conver

Re: PATCH: Split stats file per database WAS: [HACKERS] autovacuum stress-testing our system

On Thu, Jan 3, 2013 at 8:31 PM, Tomas Vondra wrote: > On 3.1.2013 18:47, Heikki Linnakangas wrote: >> On 03.01.2013 01:15, Tomas Vondra wrote: >>> 2) a new global/stat directory >>> -- >>> >>> The pgstat.stat file was originally saved into the "global" directory, >>> bu

Re: PATCH: Split stats file per database WAS: [HACKERS] autovacuum stress-testing our system

On 3.1.2013 18:47, Heikki Linnakangas wrote: > On 03.01.2013 01:15, Tomas Vondra wrote: >> 2) a new global/stat directory >> -- >> >> The pgstat.stat file was originally saved into the "global" directory, >> but with so many files that would get rather messy so I've crea

Re: [HACKERS] pg_upgrade test script creates port conflicts in parallel testing

On 01/03/2013 12:58 PM, Tom Lane wrote: I've been getting complaints lately about failures of parallel builds of the Fedora Postgres RPMs on the same machine. I just figured out what's going on: the pg_upgrade regression test script starts test postmasters using the default value of listen_addr

Re: [HACKERS] Feature Request: pg_replication_master()

Robert, > In my view, the biggest problem with recovery.conf is that the > parameters in there are not GUCs, which means that all of the > infrastructure that we've built for managing GUCs does not work with > them. As an example, when we converted recovery.conf to use the same > lexer that the G

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

On Thu, Jan 3, 2013 at 12:27 PM, Robert Haas wrote: > On Thu, Jan 3, 2013 at 11:15 AM, Hannu Krosing wrote: >> This is what I did with my sample pl/python function ;) > > Yeah, except that the "c" in "ctime" does not stand for create, and > therefore the function isn't necessarily reliable. The

[HACKERS] pg_upgrade test script creates port conflicts in parallel testing

I've been getting complaints lately about failures of parallel builds of the Fedora Postgres RPMs on the same machine. I just figured out what's going on: the pg_upgrade regression test script starts test postmasters using the default value of listen_addresses, which means that they try to bind to

Re: PATCH: Split stats file per database WAS: [HACKERS] autovacuum stress-testing our system

On 03.01.2013 01:15, Tomas Vondra wrote: 2) a new global/stat directory -- The pgstat.stat file was originally saved into the "global" directory, but with so many files that would get rather messy so I've created a new global/stat directory and all the files are store

Re: [HACKERS] pg_retainxlog for inclusion in 9.3?

On Thu, Jan 3, 2013 at 11:32 AM, Magnus Hagander wrote: > Any particular reason? It goes pretty tightly together with > pg_receivexlog, which is why I'd prefer putting it alongside that one. > But if you have a good argument against it, I can change my mind :) Mostly that it seems like a hack, an

Re: [HACKERS] Writing Trigger Functions in C

> Date: Sat, 29 Dec 2012 23:45:06 -0500 > Subject: Re: [HACKERS] Writing Trigger Functions in C > From: robertmh...@gmail.com > To: charle...@outlook.com > CC: cbbro...@gmail.com; pgsql-hackers@postgresql.org > > On Mon, Dec 24, 2012 at 10:43 AM, Charles Gom

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

On Thu, Jan 3, 2013 at 11:15 AM, Hannu Krosing wrote: > This is what I did with my sample pl/python function ;) Yeah, except that the "c" in "ctime" does not stand for create, and therefore the function isn't necessarily reliable. The problem is even worse for tables, where a rewrite may remove

[HACKERS] Print b-tree tuples

Hello, I'm trying to print out the tuples in the b-tree nodes for analysis, but when iterate over more than the first entry of the tuples (scanKey++), I strangely get the error below on query execution: ERROR: relation "simpletest" does not exist LINE 1: SELECT * FROM simpletest WHERE id = 50

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

On Thu, Jan 3, 2013 at 2:06 AM, Stephen Frost wrote: > I'd be alright with this also, tbh. Not preserving such information > across pg_dump's wouldn't really be all *that* much of a loss. I think it would be mandatory for pg_dump not to restore this info actually. A fair amount of work has gone

Re: [HACKERS] pg_retainxlog for inclusion in 9.3?

On Thu, Jan 3, 2013 at 3:13 PM, Robert Haas wrote: > On Tue, Jan 1, 2013 at 10:10 AM, Magnus Hagander wrote: >> So, it turns out the reason I got no feedback on this tool, was that I >> forgot both to email about and to actually push the code to github :O >> So this is actually code that's almost

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

Fabrízio de Royes Mello escribió: > As Peter said we can start add it for a few commands in one release (maybe > first for shared objects) and then for a few more commands in a next > release, and next... until we cover all commands... No, he was describing a pessimistic scenario that he doesn't

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

On 01/03/2013 03:09 PM, Robert Haas wrote: On Thu, Jan 3, 2013 at 8:46 AM, Hannu Krosing wrote: How is "what does database creation date mean?" a different question ? It is same question as : what is the creation date of db when I create a replica of my database from backup? does it depend o

Re: [HACKERS] dynamic SQL - possible performance regression in 9.2

Peter Eisentraut writes: > On 1/1/13 6:48 PM, Tom Lane wrote: >> Here's a draft patch for that. > This didn't make a difference in my test case. I might have to do some > bisecting to find where the problem was introduced. Could we see the test case? Or at least oprofile results for it?

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

On Thu, Jan 3, 2013 at 12:30 PM, Alvaro Herrera wrote: > > Peter Eisentraut escribió: > > > If we're going to store object creation time, I think we should do it > > for all objects, stored in a separate catalog, like pg_depend or > > pg_description, keyed off classid, objectid. And have a simple

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

On Thu, Jan 3, 2013 at 11:41 AM, Stephen Frost wrote: > * Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote: > > On Thu, Jan 3, 2013 at 11:13 AM, Stephen Frost > wrote: > > > Please use hard-tabs (not spaces) and the column should come before the > > > variable length records (see the comm

Re: [HACKERS] dynamic SQL - possible performance regression in 9.2

On 1/1/13 6:48 PM, Tom Lane wrote: > I wrote: >> > I'm inclined to think that Heikki's patch doesn't go far enough, if we >> > want to optimize behavior in this case. What we really want to happen >> > is that parsing, planning, and execution all happen in the caller's >> > memory context, with no

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

Peter Eisentraut escribió: > If we're going to store object creation time, I think we should do it > for all objects, stored in a separate catalog, like pg_depend or > pg_description, keyed off classid, objectid. And have a simple C > function to call to update the information stored there. +1

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

On Thu, Jan 3, 2013 at 9:18 AM, Pavel Stehule wrote: > 2013/1/3 Peter Eisentraut : >> On 1/2/13 11:08 PM, Fabrízio de Royes Mello wrote: >>> The attached patch add a new column into 'pg_database' called >>> 'datcreated' to store the timestamp of database creation. >>> >>> If this feature is approv

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

2013/1/3 Peter Eisentraut : > On 1/2/13 11:08 PM, Fabrízio de Royes Mello wrote: >> The attached patch add a new column into 'pg_database' called >> 'datcreated' to store the timestamp of database creation. >> >> If this feature is approved I could extend it to add a column into >> 'pg_class' to st

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

On 1/3/13 6:34 AM, Hannu Krosing wrote: >>> If what you want is something close to current unix file time semantics >>> (ctime, mtime, atime) then why not just create a function to look up >>> these >>> attributes on database directory and/or database files ? >> Because too many things change those

Re: [HACKERS] pg_retainxlog for inclusion in 9.3?

On Tue, Jan 1, 2013 at 10:10 AM, Magnus Hagander wrote: > So, it turns out the reason I got no feedback on this tool, was that I > forgot both to email about and to actually push the code to github :O > So this is actually code that's almost half a year old and that I was > supposed to submit for

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

On 1/2/13 11:08 PM, Fabrízio de Royes Mello wrote: > The attached patch add a new column into 'pg_database' called > 'datcreated' to store the timestamp of database creation. > > If this feature is approved I could extend it to add a column into > 'pg_class' to store creation timestamp too. While

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

On Thu, Jan 3, 2013 at 8:46 AM, Hannu Krosing wrote: > How is "what does database creation date mean?" a different question ? > > It is same question as : > > what is the creation date of db when I create a replica of my database from > backup? > > does it depend on how I restore my replica ? > >

Re: [HACKERS] missing rename support

On Sat, Dec 3, 2011 at 4:46 PM, Peter Eisentraut wrote: > I noticed the following object types don't have support for an ALTER ... > RENAME command: > > DOMAIN (but ALTER TYPE works) > FOREIGN DATA WRAPPER > OPERATOR > RULE > SERVER > > Are there any restrictions why these couldn't be added? > I

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

On 01/03/2013 02:42 PM, Stephen Frost wrote: * Hannu Krosing (ha...@krosing.net) wrote: But then some customer comes and wants it to mean "when was this replica database created" ? That's an entirely different question, imv, than what we're talking about. I'm not saying that it won't be asked,

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

* Hannu Krosing (ha...@krosing.net) wrote: > But then some customer comes and wants it to mean "when was this > replica database created" ? That's an entirely different question, imv, than what we're talking about. I'm not saying that it won't be asked, but as it's a different question, we can lo

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

* Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote: > On Thu, Jan 3, 2013 at 11:13 AM, Stephen Frost wrote: > > Please use hard-tabs (not spaces) and the column should come before the > > variable length records (see the comment in pg_database.h). > > You all right... I fixed it in attache

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

On 01/03/2013 02:17 PM, Stephen Frost wrote: * Hannu Krosing (ha...@krosing.net) wrote: Can't we actually fix these to preserve file creation date like tar does and still keep unix file semantics ? I'm not sure that I really see the advantage to trying to use the filesystem to keep this informa

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

On Thu, Jan 3, 2013 at 11:33 AM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > > On Thu, Jan 3, 2013 at 11:13 AM, Stephen Frost wrote: > > > > * Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote: > > > The attached patch add a new column into 'pg_database' called 'datcreated'

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

On Thu, Jan 3, 2013 at 11:13 AM, Stephen Frost wrote: > > * Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote: > > The attached patch add a new column into 'pg_database' called 'datcreated' > > to store the timestamp of database creation. > > Please use hard-tabs (not spaces) and the column

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

* Hannu Krosing (ha...@krosing.net) wrote: > Can't we actually fix these to preserve file creation date like tar > does and still keep > unix file semantics ? I'm not sure that I really see the advantage to trying to use the filesystem to keep this information for us..? > So it is as about agreei

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

* Hannu Krosing (ha...@krosing.net) wrote: > If what you want is something close to current unix file time > semantics (ctime, mtime, atime) then why not just create a function > to look up these attributes on database directory and/or database > files ? Because, as noted before, those aren't alwa

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

* Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote: > The attached patch add a new column into 'pg_database' called 'datcreated' > to store the timestamp of database creation. Please use hard-tabs (not spaces) and the column should come before the variable length records (see the comment in

Re: [HACKERS] [PATCH] Make pg_basebackup configure and start standby [Review]

2013-01-02 11:54 keltezéssel, Boszormenyi Zoltan írta: 2013-01-02 10:37 keltezéssel, Boszormenyi Zoltan írta: 2013-01-02 10:12 keltezéssel, Magnus Hagander írta: On Wed, Jan 2, 2013 at 9:59 AM, Boszormenyi Zoltan > wrote: 2013-01-02 01:24 keltezéssel, Tom Lane írta

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

On 01/03/2013 11:18 AM, Andres Freund wrote: On 2013-01-03 11:03:17 +0100, Hannu Krosing wrote: On 12/28/2012 03:14 AM, Stephen Frost wrote: ... I agree that what I was suggesting would be possible to implement with event triggers, but I see that as a rather advanced feature that most users are

Re: [HACKERS] Can't setval() a sequence to return the first value

Hello postgres=# select setval('xx', 1, false); setval 1 (1 row) postgres=# select nextval('xx'); nextval - 1 (1 row) Regards Pavel 2013/1/3 Hannu Krosing : > Hi hackers. > > Is it by design that you can't setval(seq, value) a sequence to a value > which return

[HACKERS] Can't setval() a sequence to return the first value

Hi hackers. Is it by design that you can't setval(seq, value) a sequence to a value which returns the first value: See the sample below for better explanation: hannu=# create sequence s; CREATE SEQUENCE hannu=# select nextval('s'); nextval - 1 (1 row) hannu=# select setval('s'

Re: [HACKERS] Behaviour of bgworker with SIGHUP

On Mon, 2012-12-31 at 17:44 -0300, Alvaro Herrera wrote: > Alvaro Herrera wrote: > > Guillaume Lelarge wrote: > > > On Mon, 2012-12-31 at 11:03 -0300, Alvaro Herrera wrote: > > > > > > I think this (have a config option, and have SIGHUP work as expected) > > > > would be useful to demo in worker_s

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

On 01/03/2013 05:04 AM, Robert Haas wrote: O Yeah, I don't think this is really a problem. I would expect the psql support for this feature to be not a whole lot more complicated than that. Sure, it might be more than 5 lines of raw code if it requires an additional version of some query for wh

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

--On 2. Januar 2013 23:04:43 -0500 Robert Haas wrote: TBH, I don't think anyone has any business changing the creation timestamp. Ever. For me, the fact that pg_dump wouldn't preserve this information would be a feature, not a bug. I mostly meant to point out that someone could bypass it

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

2013/1/3 Hannu Krosing : > On 12/28/2012 03:14 AM, Stephen Frost wrote: > ... >> >> I agree that what I was suggesting would be possible to implement with >> event triggers, but I see that as a rather advanced feature that most users >> aren't going to understand or implement. At the same time, tho

[HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

On 2013-01-03 11:03:17 +0100, Hannu Krosing wrote: > On 12/28/2012 03:14 AM, Stephen Frost wrote: > ... > >I agree that what I was suggesting would be possible to implement with > >event triggers, but I see that as a rather advanced feature that most > >users aren't going to understand or implement

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

On 12/28/2012 03:14 AM, Stephen Frost wrote: ... I agree that what I was suggesting would be possible to implement with event triggers, but I see that as a rather advanced feature that most users aren't going to understand or implement. At the same time, those more novice users are likely to be

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

2013/1/3 Stephen Frost : > * Robert Haas (robertmh...@gmail.com) wrote: >> Well, IMHO, there is no need for any syntax change at all. CREATE >> TABLE and CREATE DATABASE should just record the creation time >> somewhere, and that's all. If you dump-and-reload, the creation time >> changes. Deal