Re: [HACKERS] pg_reorg in core?

Hi, I'm sakamoto, maintainer of reorg. >> What could be also great is to move the project directly into github to >> facilitate its maintenance and development. >No argument from me there, especially as I have my own fork in github, >but that's up to the current maintainers. Yup, I am thinking dev

Re: [HACKERS] proposal - assign result of query to psql variable

Hi Pavel, (2012/09/21 2:01), Pavel Stehule wrote: >> - Is it intentional that \gset can set special variables such as >> AUTOCOMMIT and HOST? I don't see any downside for this behavior, >> because \set also can do that, but it is not documented nor tested at all. >> > > I use a same "SetVariable

Re: [HACKERS] proposal - assign result of query to psql variable

Hello 2012/9/19 Shigeru HANADA : > On Fri, Aug 10, 2012 at 3:21 AM, Pavel Stehule > wrote: >> there is new version of this patch >> >> * cleaned var list parser >> * new regress tests >> * support FETCH_COUNT > 0 > > Here are my review comments. > > Submission > == > The patch is formatte

Re: [HACKERS] 9.2 Cascading replication after slave promotion

On Tue, 14 Aug 2012 10:50:07 -0700 Josh Berkus wrote: > > > Yeah, I think there's more people that agree with this use-case > > than you seem to think.. That said, I appreciate that it's not a > > trivial thing to support cleanly. > > Not trivial, no, but not major either. Really what needs t

Re: [HACKERS] PLV8JS

On Fri, Sep 21, 2012 at 3:14 PM, Milton Labanda <1000ton@gmail.com> wrote: > Hi friends, wich context is the apropiate to install this plugin? > I have > > Ubuntu 11 > x64 architecture > postgresql 9,2 > libv8-3.1 (system package) > > but not get install it. Some ideas? Well, I'm not sure if

Re: [HACKERS] CREATE SCHEMA IF NOT EXISTS

2012/9/21 David E. Wheeler > On Sep 21, 2012, at 10:59 AM, Tom Lane wrote: > > > I don't believe this has been thought through nearly carefully enough. > > If CREATE SCHEMA created a schema and nothing more, then the proposed > > implementation would probably be fine. But per spec, CREATE SCHEM

Re: [v9.3] Extra Daemons (Re: [HACKERS] elegant and effective way for running jobs inside a database)

On Friday, September 21, 2012 6:50 PM Alvaro Herrera wrote: Excerpts from Amit Kapila's message of vie sep 21 02:26:49 -0300 2012: > On Thursday, September 20, 2012 7:13 PM Alvaro Herrera wrote: > > > Well, there is a difficulty here which is that the number of processes > >> connected to database

Re: [HACKERS] [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed

On Fri, Sep 21, 2012 at 05:16:46PM +0800, Rural Hunter wrote: > >>I am thinking this query needs to be split apart into a UNION where the > >>second part handles TOAST tables and looks at the schema of the _owner_ > >>of the TOAST table. Needs to be backpatched too. > >OK, I am at a conference now

[HACKERS] Re: [WIP] Patch : Change pg_ident.conf parsing to be the same as pg_hba.conf

On Friday, September 21, 2012 8:28 PM Heikki Linnakangas wrote: On 02.07.2012 15:08, Amit Kapila wrote: >> Attached is a Patch to change the parsing of pg_ident.conf to make it >> similar to pg_hba.conf. >> This is based on Todo Item: >> http://archives.postgresql.org/pgsql-hackers/2011-06/msg02204

Re: [HACKERS] pg_reorg in core?

(2012/09/22 10:02), Christopher Browne wrote: If the present project is having a tough time doing enhancements, I should think it mighty questionable to try to draw it into core, that presses it towards a group of already very busy developers. On the other hand, if the present development ef

Re: [HACKERS] pg_reorg in core?

If the present project is having a tough time doing enhancements, I should think it mighty questionable to try to draw it into core, that presses it towards a group of already very busy developers. On the other hand, if the present development efforts can be made more public, by having them take p

Re: [HACKERS] 64-bit API for large object

> Tom, Kaigai, > >> Kohei KaiGai writes: >>> Tom, could you give us a suggestion which manner is better approach; whether >>> the PQfn should have responsibility for endian translation of >>> 64bit-integer, or >>> callers (lo_tell64 or lo_seek64)? >> >> Adding anything inside pqFunctionCall is

Re: [HACKERS] pg_reorg in core?

On Sat, Sep 22, 2012 at 9:08 AM, sakamoto wrote: > (2012/09/21 22:32), Michael Paquier wrote: > >> On Fri, Sep 21, 2012 at 9:33 PM, Daniele Varrazzo < >> daniele.varra...@gmail.com >> > >> wrote: >> >> On Fri, Sep 21, 2012 at 5:17 AM, Josh Kupershmidt >>

Re: [HACKERS] pg_reorg in core?

(2012/09/21 22:32), Michael Paquier wrote: On Fri, Sep 21, 2012 at 9:33 PM, Daniele Varrazzo mailto:daniele.varra...@gmail.com>> wrote: On Fri, Sep 21, 2012 at 5:17 AM, Josh Kupershmidt mailto:schmi...@gmail.com>> wrote: I haven't submitted it to PGXN as I prefer the original autho

Re: [HACKERS] CREATE SCHEMA IF NOT EXISTS

On Sat, Sep 22, 2012 at 3:06 AM, David E. Wheeler wrote: > On Sep 21, 2012, at 10:59 AM, Tom Lane wrote: > > > I don't believe this has been thought through nearly carefully enough. > > If CREATE SCHEMA created a schema and nothing more, then the proposed > > implementation would probably be fine

Re: [HACKERS] 64-bit API for large object

Tom, Kaigai, > Kohei KaiGai writes: >> Tom, could you give us a suggestion which manner is better approach; whether >> the PQfn should have responsibility for endian translation of 64bit-integer, >> or >> callers (lo_tell64 or lo_seek64)? > > Adding anything inside pqFunctionCall is useless, un

Re: [HACKERS] External Replication

Hi, On Friday, September 21, 2012 11:06:46 PM m...@rpzdesign.com wrote: > Thanks for the link on the GIT patch code. > > I did a big major domo search and found some stuff related to command > triggers: > > http://archives.postgresql.org/pgsql-hackers/2012-03/msg00169.php > > "Look into the new

Re: [HACKERS] External Replication

Andres: Thanks for the link on the GIT patch code. I did a big major domo search and found some stuff related to command triggers: http://archives.postgresql.org/pgsql-hackers/2012-03/msg00169.php "Look into the new event triggers started recently." - Are these command triggers currently in

Re: [HACKERS] External Replication

On Friday, September 21, 2012 08:12:26 PM m...@rpzdesign.com wrote: > Heikki: > > Thanks for the response. I am writing an external replication engine > and putting hooks into postgres to send "signals" via a unix socket to > the outside world. > > All of the logic and implementation will occur

[HACKERS] External Replication

Heikki: Thanks for the response. I am writing an external replication engine and putting hooks into postgres to send "signals" via a unix socket to the outside world. All of the logic and implementation will occur OUTSIDE the postgres codebase and will not interfere with any WAL based repli

Re: [HACKERS] CREATE SCHEMA IF NOT EXISTS

"Dickson S. Guedes" writes: > I reviewed this v5 of patch: > - https://commitfest.postgresql.org/action/patch_view?id=907 > The patch is small and implements a new syntax to CREATE SCHEMA > that allow the creation of a schema be skipped when IF NOT EXISTS is > used. I don't believe this has bee

Re: [HACKERS] CREATE SCHEMA IF NOT EXISTS

On Sep 21, 2012, at 10:59 AM, Tom Lane wrote: > I don't believe this has been thought through nearly carefully enough. > If CREATE SCHEMA created a schema and nothing more, then the proposed > implementation would probably be fine. But per spec, CREATE SCHEMA > can specify not only creating the

Re: [HACKERS] 64-bit API for large object

Kohei KaiGai writes: > Tom, could you give us a suggestion which manner is better approach; whether > the PQfn should have responsibility for endian translation of 64bit-integer, > or > callers (lo_tell64 or lo_seek64)? Adding anything inside pqFunctionCall is useless, unless we were to add an i

Re: [HACKERS] DB & Schema

On 21.09.2012 17:58, m...@rpzdesign.com wrote: During the execution of ProcessUtility() function in /src/backend/xxx/utility.c, the CreateStmt node type is processed to create a table. Is there a global function in the context of the backend process that will deliver what the current database a

Re: [HACKERS] Suggestion for --truncate-tables to pg_restore

On 09/20/2012 12:24:49 PM, Karl O. Pinc wrote: > I've had problems using pg_restore --data-only when > restoring individual schemas (which contain data which > has had bad things done to it). --clean does not work > well because of dependent objects in other schemas. Before doing any more work I

Re: [HACKERS] 64-bit API for large object

2012/9/21 Tatsuo Ishii : >> Kohei KaiGai writes: >>> My preference is nothing are changed both pg_getmsgint64() of the backend >>> and routines under PQfn() of the libpq. Isn't it unavailable to deliver >>> int64- >>> value "after" the endian translation on the caller side? >> >> Right. If we ha

Re: [HACKERS] 64-bit API for large object

> Kohei KaiGai writes: >> My preference is nothing are changed both pg_getmsgint64() of the backend >> and routines under PQfn() of the libpq. Isn't it unavailable to deliver >> int64- >> value "after" the endian translation on the caller side? > > Right. If we had to change anything on the bac

[HACKERS] Re: [WIP] Patch : Change pg_ident.conf parsing to be the same as pg_hba.conf

On 02.07.2012 15:08, Amit Kapila wrote: Attached is a Patch to change the parsing of pg_ident.conf to make it similar to pg_hba.conf. This is based on Todo Item: http://archives.postgresql.org/pgsql-hackers/2011-06/msg02204.php Purpose - This will allow to catch syntax errors in pg_ident at the

[HACKERS] DB & Schema

During the execution of ProcessUtility() function in /src/backend/xxx/utility.c, the CreateStmt node type is processed to create a table. Is there a global function in the context of the backend process that will deliver what the current database and schema names? The querystring cannot be r

Re: [HACKERS] [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.

On Friday, September 21, 2012 03:30:31 PM Marko Tiikkaja wrote: > On 9/20/12 11:55 PM, Andres Freund wrote: > > On Monday, September 17, 2012 03:58:37 PM Tom Lane wrote: > >> OK, that explains why we've not seen a blizzard of trouble reports. > >> Still seems like a good idea to fix it ASAP, though

Re: [HACKERS] 64-bit API for large object

Kohei KaiGai writes: > My preference is nothing are changed both pg_getmsgint64() of the backend > and routines under PQfn() of the libpq. Isn't it unavailable to deliver int64- > value "after" the endian translation on the caller side? Right. If we had to change anything on the backend side, it

Re: [HACKERS] pg_reorg in core?

On Fri, Sep 21, 2012 at 1:00 PM, Hitoshi Harada wrote: > I'm not familiar with pg_reorg, but I wonder why we need a separate > program for this task. I know pg_reorg is ok as an external program > per se, but if we could optimize CLUSTER (or VACUUM which I'm a little > pessimistic about) in the s

Re: [HACKERS] pg_reorg in core?

On Fri, Sep 21, 2012 at 9:33 PM, Daniele Varrazzo < daniele.varra...@gmail.com> wrote: > On Fri, Sep 21, 2012 at 5:17 AM, Josh Kupershmidt > wrote: > > > If the argument for moving pg_reorg into core is "faster and easier" > > development, well I don't really buy that. > > I don't see any problem

Re: [HACKERS] [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.

On 9/20/12 11:55 PM, Andres Freund wrote: On Monday, September 17, 2012 03:58:37 PM Tom Lane wrote: OK, that explains why we've not seen a blizzard of trouble reports. Still seems like a good idea to fix it ASAP, though. Btw, I think RhodiumToad/Andrew Gierth and I some time ago helped a user i

Re: [v9.3] Extra Daemons (Re: [HACKERS] elegant and effective way for running jobs inside a database)

Excerpts from Amit Kapila's message of vie sep 21 02:26:49 -0300 2012: > On Thursday, September 20, 2012 7:13 PM Alvaro Herrera wrote: > > Well, there is a difficulty here which is that the number of processes > > connected to databases must be configured during postmaster start > > (because it de

Re: [HACKERS] pg_reorg in core?

On Fri, Sep 21, 2012 at 5:17 AM, Josh Kupershmidt wrote: > If the argument for moving pg_reorg into core is "faster and easier" > development, well I don't really buy that. I don't see any problem in having pg_reorg in PGXN instead. I've tried adding a META.json to the project and it seems work

[HACKERS] Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown

On Tuesday, September 18, 2012 6:02 PM Fujii Masao wrote: On Mon, Sep 17, 2012 at 4:03 PM, Amit Kapila wrote: >> Approach-2 : >> Provide a variable wal_send_status_interval, such that if this is 0, then >> the current behavior would prevail and if its non-zero then KeepAlive >> message would be s

Re: [HACKERS] 64-bit API for large object

> 2012/9/21 Tatsuo Ishii : >> I thought pgPutInt64() takes care of endianness. No? >> > It works inside of the PGfn(), when isint = 1 towards pointer data type. > In my sense, it is a bit problem specific solution. > > So, I'd like to see other person's opinion here. >>

Re: [HACKERS] 64-bit API for large object

2012/9/21 Tatsuo Ishii : > I thought pgPutInt64() takes care of endianness. No? > It works inside of the PGfn(), when isint = 1 towards pointer data type. In my sense, it is a bit problem specific solution. So, I'd like to see other person's opinion here. >>> >>> I think

Re: [HACKERS] 64-bit API for large object

I thought pgPutInt64() takes care of endianness. No? >>> It works inside of the PGfn(), when isint = 1 towards pointer data type. >>> In my sense, it is a bit problem specific solution. >>> >>> So, I'd like to see other person's opinion here. >> >> I think we cannot change this because we

Re: [HACKERS] 64-bit API for large object

2012/9/21 Tatsuo Ishii : Hmm, I see. Please deliver the 64bit integer argument as reference, and don't forget endian translations here. >>> >>> I thought pgPutInt64() takes care of endianness. No? >>> >> It works inside of the PGfn(), when isint = 1 towards pointer data type. >> In my sen

Re: [HACKERS] 64-bit API for large object

>>> Hmm, I see. Please deliver the 64bit integer argument as reference, >>> and don't forget endian translations here. >> >> I thought pgPutInt64() takes care of endianness. No? >> > It works inside of the PGfn(), when isint = 1 towards pointer data type. > In my sense, it is a bit problem specific

Re: [HACKERS] ToDo: allow to get a number of processed rows by COPY statement [Review of Patch]

On Friday, September 21, 2012 1:23 AM Pavel Stehule wrote: >> Basic stuff: >> >> - Patch applies OK. but offset difference in line numbers. >> - Compiles with errors in contrib [pg_stat_statements, sepgsql] modules >> - Regression failed; one test-case in COPY due to incomplete te

Re: [HACKERS] 64-bit API for large object

2012/9/21 Tatsuo Ishii : >>> I think Tom's point is, there are tons of applications which define >>> their own "int64_t" (at least in 2005). >>> Also pg_config.h has: >>> >>> #define HAVE_STDINT_H 1 >>> >>> and this suggests that PostgreSQL adopts to platforms which does not >>> have stdint.h. If

Re: [HACKERS] 64-bit API for large object

>> I think Tom's point is, there are tons of applications which define >> their own "int64_t" (at least in 2005). >> Also pg_config.h has: >> >> #define HAVE_STDINT_H 1 >> >> and this suggests that PostgreSQL adopts to platforms which does not >> have stdint.h. If so, we need to take care of such

Re: [HACKERS] [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed

于 2012/9/19 7:22, Bruce Momjian 写道: On Mon, Sep 17, 2012 at 05:07:23PM -0400, Bruce Momjian wrote: # select * from pg_tables where tablename='sql_features'; schemaname | tablename | tableowner | tablespace | hasindexes | hasrules | hastriggers +--+

Re: [HACKERS] 64-bit API for large object

> > Currently lo_initialize() throws an error if one of oids are not > > available. I doubt we do the same way for 64-bit functions since this > > will make 9.3 libpq unable to access large objects stored in pre-9.2 > > PostgreSQL servers. > > > It seems to me the situation to split the case of pr

Re: [HACKERS] 64-bit API for large object

> I think Tom's point is, there are tons of applications which define > their own "int64_t" (at least in 2005). > Also pg_config.h has: > > #define HAVE_STDINT_H 1 > > and this suggests that PostgreSQL adopts to platforms which does not > have stdint.h. If so, we need to take care of such platfor

Re: [HACKERS] xlog filename formatting functions in recovery

On 03.07.2012 15:13, Robert Haas wrote: On the substance of the patch, I believe the reason why this is currently disallowed is because the TLI is implicitly taken from the running system, and on the standby that might be the wrong value. Yeah, I believe that's the reason. So the question is, w