Re: [HACKERS] Built-in support for a memory consumption ulimit?

On Wed, Jun 18, 2014 at 10:00 AM, Tom Lane wrote: > Amit Kapila writes: > > Won't it be possible if we convert malloc calls in backend code to > > go through wrapper, we already have some precedents of same like > > guc_malloc, pg_malloc? > > We do not have control over mallocs done by third-part

[HACKERS] include_dir catch-22

There is, IMO, a significant oversight with the include_dir feature. If a distributor wants to enable it by default at initdb time, they can't just turn it on in postgresql.conf.sample, because initdb will die when the postgres backend refuses to start because the configdir is missing. Yet the co

[HACKERS] Re: [REVIEW] Re: Re: BUG #9578: Undocumented behaviour for temp tables created inside query language (SQL) functions

On Tue, Jun 17, 2014 at 12:30 AM, Abhijit Menon-Sen wrote: > (Cc: to pgsql-bugs dropped.) > > At 2014-03-17 18:24:55 +1100, kommi.harib...@gmail.com wrote: >> >> *** a/doc/src/sgml/xfunc.sgml >> --- b/doc/src/sgml/xfunc.sgml >> *** >> *** 153,159 SELECT clean_emp(); >> --- 153,18

Re: [HACKERS] include_dir catch-22

On 06/18/2014 03:30 PM, Craig Ringer wrote: > There is, IMO, a significant oversight with the include_dir feature. > > If a distributor wants to enable it by default at initdb time, they > can't just turn it on in postgresql.conf.sample, because initdb will die > when the postgres backend refuses

Re: [HACKERS] Selectivity estimation for inet operators

I wanted to check the patch last time and found a bug effecting MVC vs MVC part of the join selectivity. Fixed version attached. Emre Hasegeli : > Comparing the lists with each other slows down the function when > statistics set to higher values. To avoid this problem I only use > log(n) values of

Re: [HACKERS] Minmax indexes

On 06/17/2014 09:16 PM, Andres Freund wrote: On 2014-06-17 12:14:00 -0400, Robert Haas wrote: On Tue, Jun 17, 2014 at 12:04 PM, Andres Freund wrote: Well, I'm not the guy who does things with geometric data, but I don't want to ignore the significant percentage of our users who are. As you mu

Re: [HACKERS] Re: [REVIEW] Re: Re: BUG #9578: Undocumented behaviour for temp tables created inside query language (SQL) functions

Thanks, I've marked this ready for committer. -- Abhijit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] RHEL6 packaging issue for 9.4 beta - libevent conflict

Hi all I posted about a possible packaging issue with RHEL 6 PGDG packages for 9.4beta on pgsql-yum-pkg, but things are pretty quiet over there (a prior mail asking about what happened with moving to git hasn't had a response). Given that time is a concern with 9.4, I thought I'd raise it here.

Re: [HACKERS] datistemplate of pg_database does not behave as per description in documentation

From: "Rajeev rastogi" Please find the attached patch with only documentation change. I marked this as ready for committer. The patch is good because it matches the description in the following page: http://www.postgresql.org/docs/devel/static/manage-ag-templatedbs.html Regards MauMau

Re: [HACKERS] Minmax indexes

On 2014-06-18 12:18:26 +0300, Heikki Linnakangas wrote: > On 06/17/2014 09:16 PM, Andres Freund wrote: > >Well, it might be doable to correlate them along one axis, but along > >both? That's more complicated... And even alongside one axis you > >already get into problems if your geometries are irr

Re: [HACKERS] Minmax indexes

On 2014-06-17 16:48:07 -0700, Greg Stark wrote: > On Tue, Jun 17, 2014 at 11:16 AM, Andres Freund > wrote: > > Well, it might be doable to correlate them along one axis, but along > > both? That's more complicated... And even alongside one axis you > > already get into problems if your geometrie

Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows

From: "Michael Paquier" When doing some work on Windows, I noticed that the mkvc specs in src/tools/msvc use wsock32.lib, which is as far as I understand an old, obsolete version of the Windows socket library. Wouldn't it make sense to update the specs to build only with ws2_32.lib like in the p

Re: [HACKERS] btreecheck extension

* Peter Geoghegan (p...@heroku.com) wrote: > On Tue, Jun 17, 2014 at 5:11 PM, Robert Haas wrote: > > Now, we could. We could come up with an extensible syntax, like this: > > > > CHECK relation [ USING { checktype [ '(' arg [, ...] '}' [, ...] ]; > > That's what I had in mind. Using the same tri

Re: [HACKERS] Minmax indexes

On 06/18/2014 01:46 PM, Andres Freund wrote: On 2014-06-18 12:18:26 +0300, Heikki Linnakangas wrote: The main problem with using it for geometric types is that you can't easily CLUSTER the table to make the minmax index effective again. But there are ways around that. Which are? Sure you can t

Re: [HACKERS] How about a proper TEMPORARY TABLESPACE?

* Matheus de Oliveira (matioli.math...@gmail.com) wrote: > Hi Hackers, Having read only the subject- +1 from me on the idea. Maybe +1000. > I was facing a situation were we wanted to set temp_tablespaces to a > tablespace on a ephemeral disk (yes, it is AWS ephemeral disk), and I know > many use

Re: [HACKERS] comparison operators

* Andrew Dunstan (and...@dunslane.net) wrote: > I think I'd rather just say "for many data types" or something along > those lines, rather than imply that there is some obvious rule that > users should be able to intuit. Perhaps with a link to where the informaiton about which exist is available..

Re: [HACKERS] Minmax indexes

On Tue, Jun 17, 2014 at 2:16 PM, Andres Freund wrote: >> But I'm not trying to say that we absolutely have to support that kind >> of thing; what I am trying to say is that there should be a README or >> a mailing list post or some such that says: "We thought about how >> generic to make this. We

Re: [HACKERS] datistemplate of pg_database does not behave as per description in documentation

On Wed, Jun 18, 2014 at 7:47 PM, MauMau wrote: > From: "Rajeev rastogi" > >> Please find the attached patch with only documentation change. > > > I marked this as ready for committer. The patch is good because it matches > the description in the following page: > > http://www.postgresql.org/docs

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

Hello , >I have a few preliminary comments about your patch Thank you for review comments. >the patch creates src/common/lz4/.travis.yml, which it shouldn't. Agree. I will remove it. >Shouldn't this use palloc? palloc() is disallowed in critical sections and we are already in CS while executing

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

On 2014-06-18 18:10:34 +0530, Rahila Syed wrote: > Hello , > > >I have a few preliminary comments about your patch > Thank you for review comments. > > >the patch creates src/common/lz4/.travis.yml, which it shouldn't. > Agree. I will remove it. > > >Shouldn't this use palloc? > palloc() is disa

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

At 2014-06-18 18:10:34 +0530, rahilasye...@gmail.com wrote: > > palloc() is disallowed in critical sections and we are already in CS > while executing this code. So we use malloc(). Are these allocations actually inside a critical section? It seems to me that the critical section starts further do

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

At 2014-06-18 18:25:34 +0530, a...@2ndquadrant.com wrote: > > Are these allocations actually inside a critical section? It seems to me > that the critical section starts further down, but perhaps I am missing > something. OK, I was missing that XLogInsert() itself can be called from inside a criti

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

On Wed, Jun 18, 2014 at 6:25 PM, Abhijit Menon-Sen wrote: > At 2014-06-18 18:10:34 +0530, rahilasye...@gmail.com wrote: > > > > palloc() is disallowed in critical sections and we are already in CS > > while executing this code. So we use malloc(). > > Are these allocations actually inside a criti

Re: [HACKERS] Proposal for CSN based snapshots

On Tue, Jun 17, 2014 at 9:00 PM, Craig Ringer wrote: > On 06/18/2014 12:41 AM, Robert Haas wrote: >> On Mon, Jun 16, 2014 at 12:58 AM, Craig Ringer wrote: >>> > On 05/30/2014 11:14 PM, Heikki Linnakangas wrote: >> Yeah. To recap, the failure mode is that if the master crashes and >> res

Re: [HACKERS] WAL replay bugs

On Tue, Jun 17, 2014 at 5:40 PM, Michael Paquier wrote: > On Wed, Jun 18, 2014 at 1:40 AM, Robert Haas wrote: >> On Mon, Jun 2, 2014 at 8:55 AM, Michael Paquier >> wrote: >> I'm not sure if this is reasonably possible, but one thing that would >> make this tool a whole lot easier to use would be

Re: [HACKERS] comparison operators

Stephen Frost writes: > * Andrew Dunstan (and...@dunslane.net) wrote: >> I think I'd rather just say "for many data types" or something along >> those lines, rather than imply that there is some obvious rule that >> users should be able to intuit. > Perhaps with a link to where the informaiton ab

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

On Tue, Jun 17, 2014 at 9:45 PM, Brightwell, Adam wrote: > I absolutely appreciate all of the feedback that has been provided. It has > been educational. To your point above, I started putting together a wiki > page, as Stephen has spoken to, that is meant to capture these concerns and > conside

Re: [HACKERS] Proposal for CSN based snapshots

On 06/18/2014 09:12 PM, Robert Haas wrote: > No. Otherwise, one of those bits could get changed after a backend > takes a snapshot and before it finishes using it - so that the > transaction snapshot is in effect changing underneath it. You could > avoid that by memorizing the contents of CLOG wh

[HACKERS] Cube distance patch?

Hi, In September 2013, there was patch sent by Stas Kelvich ( http://www.postgresql.org/message-id/9e07e159-e405-41e2-9889-a04f534fc...@gmail.com) that adds indexable kNN searches to cube contrib module. What is needed so that it could get committed? Regards, depesz

Re: [HACKERS] RHEL6 packaging issue for 9.4 beta - libevent conflict

Craig Ringer writes: > I posted about a possible packaging issue with RHEL 6 PGDG packages for > 9.4beta on pgsql-yum-pkg, but things are pretty quiet over there (a > prior mail asking about what happened with moving to git hasn't had a > response). > http://www.postgresql.org/message-id/53a10ef9.

Re: [HACKERS] datistemplate of pg_database does not behave as per description in documentation

From: "Fujii Masao" On Wed, Jun 18, 2014 at 7:47 PM, MauMau wrote: I marked this as ready for committer. The patch is good because it matches the description in the following page: http://www.postgresql.org/docs/devel/static/manage-ag-templatedbs.html ISTM that this patch has already been

Re: [HACKERS] RHEL6 packaging issue for 9.4 beta - libevent conflict

On 06/18/2014 09:34 AM, Tom Lane wrote: Craig Ringer writes: I posted about a possible packaging issue with RHEL 6 PGDG packages for 9.4beta on pgsql-yum-pkg, but things are pretty quiet over there (a prior mail asking about what happened with moving to git hasn't had a response). http://www.p

Re: [HACKERS] Cube distance patch?

At 2014-06-18 15:33:37 +0200, dep...@gmail.com wrote: > > Hi, > > In September 2013, there was patch sent by Stas Kelvich ( > http://www.postgresql.org/message-id/9e07e159-e405-41e2-9889-a04f534fc...@gmail.com) > that adds indexable kNN searches to cube contrib module. > > What is needed so that

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

On Tue, Jun 17, 2014 at 10:06 PM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Fri, Jun 13, 2014 at 3:11 AM, Dean Rasheed >> wrote: >> > Yeah, I was thinking something like this could work, but I would go >> > further. Suppose you had separate GRANTable privileges fo

Re: [HACKERS] Clarification of FDW API Documentation

--On 13. Juni 2014 13:46:38 -0400 Tom Lane wrote: Imagine if `BeginForeignScan` set up a remote cursor and `IterateForeignScan` just fetched _one tuple at a time_ (unlike the current behavior where they are fetched in batches). The tuple would be passed to `ExecForeignDelete` (as is required)

Re: [HACKERS] How about a proper TEMPORARY TABLESPACE?

On Wed, Jun 18, 2014 at 9:00 AM, Stephen Frost wrote: > > > I have took some small time to make a PoC just to see if that is doable. > > And so I did a new syntax like: > > > > CREATE TABLESPACE spcname [TEMP | TEMPORARY] LOCATION ... > > > > So, if TEMP or TEMPORARY is present, I mark a new c

Re: [HACKERS] comparison operators

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Andrew Dunstan (and...@dunslane.net) wrote: > >> I think I'd rather just say "for many data types" or something along > >> those lines, rather than imply that there is some obvious rule that > >> users should be able to intuit. >

Re: [HACKERS] comparison operators

Andrew Dunstan wrote > On 06/17/2014 07:25 PM, Andres Freund wrote: >> On 2014-06-17 19:22:07 -0400, Tom Lane wrote: >>> Andrew Dunstan < > andrew@ > > writes: I went to have a look at documenting the jsonb comparison operators, and found that the docs on comparison operators conta

Re: [HACKERS] comparison operators

David G Johnston writes: > Andrew Dunstan wrote >> I think I'd rather just say "for many data types" or something along >> those lines, rather than imply that there is some obvious rule that >> users should be able to intuit. > Ideal world for me: we'd list the data types that do not provide co

Re: [HACKERS] RHEL6 packaging issue for 9.4 beta - libevent conflict

Hi, On Wed, 2014-06-18 at 09:41 -0400, Andrew Dunstan wrote: > The only thing I can think of offhand that would require it is > pgbouncer. Yeah. Recent pgbouncer versions require libevent 2.0+, and RHEL 6 has 1.4. Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

* Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Jun 17, 2014 at 10:06 PM, Stephen Frost wrote: > > I had taken it to be a single privilege, but you're right, it could be > > done for each of those.. I really don't think we have the bits for more > > than one case here though (if that) with

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

On Tue, Jun 17, 2014 at 10:25 PM, Stephen Frost wrote: >> Yeah, if we have to ask an external security module a question for >> each row, there's little hope of any real optimization. However, I >> think there will be a significant number of cases where people will >> want filtering clauses that

Re: [HACKERS] RHEL6 packaging issue for 9.4 beta - libevent conflict

On 06/18/2014 06:34 AM, Tom Lane wrote: Craig Ringer writes: I posted about a possible packaging issue with RHEL 6 PGDG packages for 9.4beta on pgsql-yum-pkg, but things are pretty quiet over there (a prior mail asking about what happened with moving to git hasn't had a response). http://www.p

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

On Wed, Jun 18, 2014 at 10:40 AM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Tue, Jun 17, 2014 at 10:06 PM, Stephen Frost wrote: >> > I had taken it to be a single privilege, but you're right, it could be >> > done for each of those.. I really don't think we have t

Re: [HACKERS] Atomics hardware support table & supported architectures

On Tue, Jun 17, 2014 at 1:55 PM, Andres Freund wrote: > But the concern is more whether 1 byte can actually be written > without also writing neighbouring values. I.e. there's hardware out > there that'll implement a 1byte store as reading 4 bytes, changing one > of the bytes in a register, and th

Re: [HACKERS] Quantify small changes to predicate evaluation

On Tue, Jun 17, 2014 at 10:23 AM, Dennis Butterstein wrote: > Hi Marti, thank you for your quick reply. I tried the proposed tweaks and > see some differences regarding the measurements. It seems as if the overall > query performance dropped a little what I think the disabled turbo boost > mode is

[HACKERS] buildfarm client release 4.13

I have released version 4.13 of the PostgreSQL Buildfarm client. This can be downloaded from Changes in this release (from the git log): fcc182b Don't run TestCollateLinuxUTF8 on unsupported branches. 273af50 Don't run

Re: [HACKERS] 9.5 CF1

On Tue, Jun 17, 2014 at 6:54 PM, Tom Lane wrote: > Alvaro Herrera writes: > > Robert Haas wrote: > >> On Mon, Jun 16, 2014 at 2:36 AM, Abhijit Menon-Sen > wrote: > >>> P.S. If you tag your reviews with [REVIEW] in the Subject, it'll be > >>> easier to keep track of them. > > >> I and, I believe

[HACKERS] Is analyze_new_cluster.sh still useful?

Hi, now that we have vacuumdb --all --analyze-in-stages in 9.4, wouldn't it make sense to get rid of the analyze_new_cluster.sh file which pg_upgrade writes? The net content is a single line which could as well be printed by pg_upgrade itself. Instead of an lengthy explanation how to invoke that m

Re: [HACKERS] BUG #10680 - ldapbindpasswd leaks to postgresql log

On Wed, Jun 18, 2014 at 4:50 AM, Tom Lane wrote: > Steven Siebert writes: > > Attached is a proposed patch for BUG #10680. > > > It's a simple fix to the problem of the ldapbindpasswd leaking in > > clear text to the postgresql log. The patch simply removes the raw > > pg_hba.conf line from the

Re: [HACKERS] Atomics hardware support table & supported architectures

On 2014-06-18 11:15:15 -0400, Robert Haas wrote: > On Tue, Jun 17, 2014 at 1:55 PM, Andres Freund wrote: > > What happens is that gcc will do a syscall triggering the kernel to turn > > of scheduling; perform the math and store the result; turn scheduling on > > again. That way there cannot be a o

Re: [HACKERS] How about a proper TEMPORARY TABLESPACE?

* Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote: > On Wed, Jun 18, 2014 at 9:00 AM, Stephen Frost wrote: > > Not sure about that specific syntax (don't we have SET options now?) but > > I do like the general idea. > > Maybe something like that: > > CREATE TABLESPACE spcname LOCATION '/

Re: [HACKERS] Set new system identifier using pg_resetxlog

On Tue, Jun 17, 2014 at 12:50 PM, Andres Freund wrote: >> >> I can clearly understand the utility of being able to reset the system >> >> ID to a new, randomly-generated system ID - but giving the user the >> >> ability to set a particular value of their own choosing seems like a >> >> pretty shar

Re: [HACKERS] delta relations in AFTER triggers

On Tue, Jun 17, 2014 at 04:07:55PM -0400, Robert Haas wrote: > On Sat, Jun 14, 2014 at 7:56 PM, Kevin Grittner wrote: > > I looked at the standard, and initially tried to implement the > > standard syntax for this; however, it appeared that the reasons > > given for not using standard syntax for t

Re: [HACKERS] replication identifier format

On 2014-06-18 12:36:13 -0400, Robert Haas wrote: > > I actually don't think any of the discussions I was involved in had the > > externally visible version of replication identifiers limited to 16bits? > > If you are referring to my patch, 16bits was just the width of the > > *internal* name that s

Re: [HACKERS] Is analyze_new_cluster.sh still useful?

Christoph Berg writes: > now that we have vacuumdb --all --analyze-in-stages in 9.4, wouldn't > it make sense to get rid of the analyze_new_cluster.sh file which > pg_upgrade writes? The net content is a single line which could as > well be printed by pg_upgrade itself. Instead of an lengthy > exp

Re: [HACKERS] Set new system identifier using pg_resetxlog

On 2014-06-18 12:36:13 -0400, Robert Haas wrote: > On Tue, Jun 17, 2014 at 12:50 PM, Andres Freund > wrote: > >> >> I can clearly understand the utility of being able to reset the system > >> >> ID to a new, randomly-generated system ID - but giving the user the > >> >> ability to set a particula

Re: [HACKERS] Is analyze_new_cluster.sh still useful?

On 2014-06-18 12:51:43 -0400, Tom Lane wrote: > Another angle is that some folks might have tried to automate things > even more, with a wrapper script that starts up the new postmaster > and runs analyze_new_cluster.sh all by itself. I guess they could > make the wrapper do "vacuumdb --all --anal

Re: [HACKERS] How about a proper TEMPORARY TABLESPACE?

Stephen Frost writes: > Yes. I'd definitely like to see an ALTER TABLESPACE option, with an > ERROR that lists out all of the non-temporary objects which are found > (and lists any other databases which have objects in those > tablespaces..). That would allow administrators who have existing > n

Re: [HACKERS] Set new system identifier using pg_resetxlog

On 2014-06-18 18:54:05 +0200, Andres Freund wrote: > On 2014-06-18 12:36:13 -0400, Robert Haas wrote: > > Sure, but that only requires being able to reset the ID randomly, not > > to a particular value. > > I can definitely see a point in a version of the option that generates > the id randomly.

Re: [HACKERS] Is analyze_new_cluster.sh still useful?

Andres Freund writes: > On 2014-06-18 12:51:43 -0400, Tom Lane wrote: >> Another angle is that some folks might have tried to automate things >> even more, with a wrapper script that starts up the new postmaster >> and runs analyze_new_cluster.sh all by itself. I guess they could >> make the wrap

Re: [HACKERS] Set new system identifier using pg_resetxlog

On Wed, Jun 18, 2014 at 12:54 PM, Andres Freund wrote: >> Well, I think it *does* make pg_resetxlog more dangerous; see previous >> discussion of pg_computemaxlsn. > > Wasn't the thing around pg_computemaxlsn that there's actually no case > where it could be used safely? And that experienced peopl

Re: [HACKERS] Is analyze_new_cluster.sh still useful?

On 2014-06-18 13:24:14 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-06-18 12:51:43 -0400, Tom Lane wrote: > >> Another angle is that some folks might have tried to automate things > >> even more, with a wrapper script that starts up the new postmaster > >> and runs analyze_new_cluste

Re: [HACKERS] Set new system identifier using pg_resetxlog

On 18/06/14 19:26, Robert Haas wrote: On Wed, Jun 18, 2014 at 12:54 PM, Andres Freund wrote: I don't see how the proposed ability makes it more dangerous. It *already* has the ability to reset the timelineid. That's the case where users are much more likely to think about resetting it because t

Re: [HACKERS] Set new system identifier using pg_resetxlog

On 2014-06-18 13:26:37 -0400, Robert Haas wrote: > My vote is to hold off on this until we've talked about replication > identifiers and other related topics in more depth. I really don't understand this. We're *NOT* proposing this patch as an underhanded way of preempting the discussion of whethe

Re: [HACKERS] Set new system identifier using pg_resetxlog

On 06/13/2014 05:31 PM, Petr Jelinek wrote: > Hello, > > attached is a simple patch which makes it possible to change the system > identifier of the cluster in pg_control. This is useful for > individualization of the instance that is started on top of data > directory produced by pg_basebackup -

Re: [HACKERS] Set new system identifier using pg_resetxlog

Josh Berkus wrote: > On 06/13/2014 05:31 PM, Petr Jelinek wrote: > > Hello, > > > > attached is a simple patch which makes it possible to change the system > > identifier of the cluster in pg_control. This is useful for > > individualization of the instance that is started on top of data > > direc

Re: [HACKERS] Set new system identifier using pg_resetxlog

On 2014-06-18 10:44:56 -0700, Josh Berkus wrote: > On 06/13/2014 05:31 PM, Petr Jelinek wrote: > > Hello, > > > > attached is a simple patch which makes it possible to change the system > > identifier of the cluster in pg_control. This is useful for > > individualization of the instance that is st

Re: [HACKERS] Set new system identifier using pg_resetxlog

At 2014-06-18 10:44:56 -0700, j...@agliodbs.com wrote: > > I'm unclear on why we would overload pg_resetxlog for this. Because pg_resetxlog already does something very similar, so the patch is small. If it were independent, it would have to copy quite some code from pg_resetxlog. > Wouldn't it b

Re: [HACKERS] How to change the pgsql source code and build it??

Well, the initdb issue looks to be resolved. Actually, after making the changes as suggested by Kyotaro Horiguchi, I copied only initdb binary to my platform and didn't copy all of them. Hence, the dependencies were still not resolved and was getting the error. However, now the database server is

Re: [HACKERS] Is analyze_new_cluster.sh still useful?

Andres Freund writes: > On 2014-06-18 13:24:14 -0400, Tom Lane wrote: >> Andres Freund writes: >>> On 2014-06-18 12:51:43 -0400, Tom Lane wrote: Another angle is that some folks might have tried to automate things even more, with a wrapper script that starts up the new postmaster a

Re: [HACKERS] Is analyze_new_cluster.sh still useful?

On 2014-06-18 13:54:16 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-06-18 13:24:14 -0400, Tom Lane wrote: > >> Andres Freund writes: > >>> On 2014-06-18 12:51:43 -0400, Tom Lane wrote: > Another angle is that some folks might have tried to automate things > even more, with

Re: [HACKERS] Set new system identifier using pg_resetxlog

On 06/18/2014 10:48 AM, Abhijit Menon-Sen wrote: > At 2014-06-18 10:44:56 -0700, j...@agliodbs.com wrote: >> >> I'm unclear on why we would overload pg_resetxlog for this. > > Because pg_resetxlog already does something very similar, so the patch > is small. If it were independent, it would have

Re: [HACKERS] Set new system identifier using pg_resetxlog

On 2014-06-18 10:59:59 -0700, Josh Berkus wrote: > On 06/18/2014 10:48 AM, Abhijit Menon-Sen wrote: > > At 2014-06-18 10:44:56 -0700, j...@agliodbs.com wrote: > >> > >> I'm unclear on why we would overload pg_resetxlog for this. > > > > Because pg_resetxlog already does something very similar, so

Re: [HACKERS] How about a proper TEMPORARY TABLESPACE?

On Wed, Jun 18, 2014 at 1:59 PM, Tom Lane wrote: > > Stephen Frost writes: > > Yes. I'd definitely like to see an ALTER TABLESPACE option, with an > > ERROR that lists out all of the non-temporary objects which are found > > (and lists any other databases which have objects in those > > tablespa

Re: [HACKERS] Set new system identifier using pg_resetxlog

On 06/18/2014 11:03 AM, Andres Freund wrote: > Well, all those actually do write to the xlog (to write a new > checkpoint, containing the updated control file). Since pg_resetxlog has > done all this pretty much since forever renaming it now seems to be a > big hassle for users for pretty much no b

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

* Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Jun 17, 2014 at 10:25 PM, Stephen Frost wrote: > > I agree that we want to support that, if we can do so reasonably. What > > I was trying to get at is simply this- don't we provide that already > > with the leakproof attribute and functions?

Re: [HACKERS] How about a proper TEMPORARY TABLESPACE?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Yes. I'd definitely like to see an ALTER TABLESPACE option, with an > > ERROR that lists out all of the non-temporary objects which are found > > (and lists any other databases which have objects in those > > tablespaces..). That

Re: [HACKERS] pg_control is missing a field for LOBLKSIZE

On Tue, Jun 17, 2014 at 8:46 PM, Bruce Momjian wrote: > On Tue, Jun 17, 2014 at 07:12:16PM -0400, Tom Lane wrote: >> Bruce Momjian writes: >> > On Tue, Jun 17, 2014 at 03:55:02PM -0400, Alvaro Herrera wrote: >> >> Can't you compare it to the historic default value? I mean, add an >> >> assumptio

Re: [HACKERS] idle_in_transaction_timeout

Robert Haas wrote: > Tom Lane wrote: >> Robert Haas writes: >>> I thought the reason why this hasn't been implemented before >>> now is that sending an ErrorResponse to the client will result >>> in a loss of protocol sync. >> >> Hmm ... you are right that this isn't as simple as an >> ereport(

Re: [HACKERS] [bug fix] Memory leak in dblink

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/10/2014 02:57 AM, MauMau wrote: > From: "Amit Kapila" >> Is there a need to free memory context in PG_CATCH()? In error >> path the memory due to this temporary context will get freed as >> it will delete the transaction context and this tempora

Re: [HACKERS] pg_control is missing a field for LOBLKSIZE

Robert Haas writes: > On Tue, Jun 17, 2014 at 8:46 PM, Bruce Momjian wrote: >> On Tue, Jun 17, 2014 at 07:12:16PM -0400, Tom Lane wrote: >>> What about comparing to the symbolic value LOBLKSIZE? This would make >>> pg_upgrade assume that the old installation had been tweaked the same >>> as in i

Re: [HACKERS] [bug fix] Memory leak in dblink

Joe Conway writes: > I think the context deletion was missed in the first place because > storeRow() is the wrong place to create the context. Rather than > creating the context in storeRow() and deleting it two levels up in > materializeQueryResult(), I think it should be created and deleted in >

Re: [HACKERS] [bug fix] Memory leak in dblink

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/18/2014 12:09 PM, Tom Lane wrote: > Joe Conway writes: >> I think the context deletion was missed in the first place >> because storeRow() is the wrong place to create the context. >> Rather than creating the context in storeRow() and deleting i

Re: [HACKERS] pg_control is missing a field for LOBLKSIZE

On Wed, Jun 18, 2014 at 2:55 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jun 17, 2014 at 8:46 PM, Bruce Momjian wrote: >>> On Tue, Jun 17, 2014 at 07:12:16PM -0400, Tom Lane wrote: What about comparing to the symbolic value LOBLKSIZE? This would make pg_upgrade assume that th

Re: [HACKERS] idle_in_transaction_timeout

On 06/18/2014 11:50 AM, Kevin Grittner wrote: > The first thing is that I don't think a delay between the BEGIN and > the SELECT should cause a timeout to trigger, but more importantly > there should not be two ERROR responses to one SELECT statement. I do think a delay between BEGIN and SELECT sh

Re: [HACKERS] pg_control is missing a field for LOBLKSIZE

Robert Haas writes: > On Wed, Jun 18, 2014 at 2:55 PM, Tom Lane wrote: >> The net behavior would be the same, but I thought it might be easier to >> code by thinking of it this way. Or maybe it wouldn't --- it's just a >> suggestion. > Well, the difference is that if we just don't check it, the

Re: [HACKERS] idle_in_transaction_timeout

Josh Berkus writes: > There are plenty of badly-written applications which "auto-begin", that > is, they issue a "BEGIN;" immediately after every "COMMIT;" whether or > not there's any additional work to do. This is a major source of IIT > and the timeout should not ignore it. Nonsense. We exp

Re: [HACKERS] pg_control is missing a field for LOBLKSIZE

On Wed, Jun 18, 2014 at 3:28 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Jun 18, 2014 at 2:55 PM, Tom Lane wrote: >>> The net behavior would be the same, but I thought it might be easier to >>> code by thinking of it this way. Or maybe it wouldn't --- it's just a >>> suggestion. > >> W

Re: [HACKERS] Is analyze_new_cluster.sh still useful?

On Wed, Jun 18, 2014 at 10:58 AM, Andres Freund wrote: > On 2014-06-18 13:54:16 -0400, Tom Lane wrote: >> I think we're not on the same page. My point is that someone might want >> to automate the whole sequence: stop old postmaster, run pg_upgrade, start >> the updated postmaster normally (henc

Re: [HACKERS] [COMMITTERS] pgsql: Reduce the number of semaphores used under --disable-spinlocks.

On Wed, Jun 18, 2014 at 3:32 PM, Andres Freund wrote: > Hi, > > On 2014-01-08 23:58:16 +, Robert Haas wrote: >> Reduce the number of semaphores used under --disable-spinlocks. >> >> Instead of allocating a semaphore from the operating system for every >> spinlock, allocate a fixed number of se

Re: [HACKERS] How about a proper TEMPORARY TABLESPACE?

Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Stephen Frost writes: > > > Yes. I'd definitely like to see an ALTER TABLESPACE option, with an > > > ERROR that lists out all of the non-temporary objects which are found > > > (and lists any other databases which have objects in

Re: [HACKERS] idle_in_transaction_timeout

On 06/18/2014 12:32 PM, Tom Lane wrote: > Josh Berkus writes: >> There are plenty of badly-written applications which "auto-begin", that >> is, they issue a "BEGIN;" immediately after every "COMMIT;" whether or >> not there's any additional work to do. This is a major source of IIT >> and the ti

[HACKERS] Re: [COMMITTERS] pgsql: Reduce the number of semaphores used under --disable-spinlocks.

On 2014-06-18 15:52:49 -0400, Robert Haas wrote: > On Wed, Jun 18, 2014 at 3:32 PM, Andres Freund wrote: > > Hi, > > > > On 2014-01-08 23:58:16 +, Robert Haas wrote: > >> Reduce the number of semaphores used under --disable-spinlocks. > >> > >> Instead of allocating a semaphore from the operat

Re: [HACKERS] [bug fix] Memory leak in dblink

Joe Conway writes: > On 06/18/2014 12:09 PM, Tom Lane wrote: >> I find myself a bit suspicious of this whole thing though. If >> it's necessary to explicitly clean up the tmpcontext, why not also >> the sinfo->cstrs allocation? And what about the tupdesc, >> attinmeta, etc created further up in

Re: [HACKERS] How about a proper TEMPORARY TABLESPACE?

On Wed, Jun 18, 2014 at 4:53 PM, Alvaro Herrera wrote: > > Stephen Frost wrote: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > > Stephen Frost writes: > > > > Yes. I'd definitely like to see an ALTER TABLESPACE option, with an > > > > ERROR that lists out all of the non-temporary objects which a

Re: [HACKERS] [COMMITTERS] pgsql: Reduce the number of semaphores used under --disable-spinlocks.

On Wed, Jun 18, 2014 at 3:56 PM, Andres Freund wrote: >> > I'm looking at the way you did this in the context of the atomics >> > patch. Won't: >> > s_init_lock_sema(volatile slock_t *lock) >> > { >> > static int counter = 0; >> > >> > *lock = (++counter) % NUM_SPINLOCK_SEMAPH

Re: [HACKERS] idle_in_transaction_timeout

On Wed, Jun 18, 2014 at 3:53 PM, Josh Berkus wrote: > On 06/18/2014 12:32 PM, Tom Lane wrote: >> Josh Berkus writes: >>> There are plenty of badly-written applications which "auto-begin", that >>> is, they issue a "BEGIN;" immediately after every "COMMIT;" whether or >>> not there's any addition

Re: [HACKERS] Atomics hardware support table & supported architectures

On Wed, Jun 18, 2014 at 12:13 PM, Andres Freund wrote: > There might be cases where that's true, but in the majority of cases > where the variable isn't highly contended it's just about the same. In > many cases the microcode will implement atomic ops using ll/sc > operations internally anyway. B

Re: [HACKERS] Atomics hardware support table & supported architectures

On 2014-06-18 17:04:49 -0400, Robert Haas wrote: > On Wed, Jun 18, 2014 at 12:13 PM, Andres Freund > wrote: > > There might be cases where that's true, but in the majority of cases > > where the variable isn't highly contended it's just about the same. In > > many cases the microcode will impleme

  1   2   >