Re: GIN pending list pages not recycled promptly (was Re: [HACKERS] GIN improvements part 1: additional information)

On Wed, Jan 22, 2014 at 9:12 PM, Heikki Linnakangas wrote: > On 01/22/2014 03:39 AM, Tomas Vondra wrote: >> >> What annoys me a bit is the huge size difference between the index >> updated incrementally (by a sequence of INSERT commands), and the index >> rebuilt from scratch using VACUUM FULL. It

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/18/2014 12:14 PM, Joe Conway wrote: > 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

Re: [HACKERS] delta relations in AFTER triggers

David Fetter wrote: > On Wed, Jun 18, 2014 at 03:30:34PM -0700, Kevin Grittner wrote: >> the more I think about it (and discuss it) the more I'm >> inclined to suffer the additional complexity of the standard >> syntax for specifying transition relations in order to avoid >> unnecessary overhead

Re: [HACKERS] Possible index issue on 9.5 slave

On 19/06/14 12:35, Tom Lane wrote: Peter Geoghegan writes: On Wed, Jun 18, 2014 at 8:09 PM, Ian Barwick wrote: Interesting, I'll take a look later. I'm pretty suspicious of incompatibilities that may exist between the two sets of OS collations involved here. We aren't very clear on the e

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/18/2014 08:45 PM, Tom Lane wrote: > Joe Conway writes: >> On 06/18/2014 07:29 PM, Tom Lane wrote: >>> With the attached patch on top of yours, I see no leak >>> anymore. > >> I can confirm that -- rock solid with 1 million iterations. I >> assu

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

Joe Conway writes: > On 06/18/2014 07:29 PM, Tom Lane wrote: >> With the attached patch on top of yours, I see no leak anymore. > I can confirm that -- rock solid with 1 million iterations. I assume > that should not be back-patched though? Well, we usually think memory leaks are back-patchable

Re: [HACKERS] Possible index issue on 9.5 slave

On Wed, Jun 18, 2014 at 8:35 PM, Tom Lane wrote: >> Still, it should be possible to >> determine if that's the problem using btreecheck. > > Does btreecheck attempt to verify that the sort ordering of the index > matches the comparison behavior of the datatype? That would (in general) > require c

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

Joe Conway writes: > On 06/18/2014 08:19 PM, Tom Lane wrote: >> Actually, I was wondering whether we couldn't remove that >> CreateTupleDescCopy call entirely. > Apparently not, at least without some additional surgery. > ExecMakeTableFunctionResult() tries to free the tupledesc and segfaults.

Re: [HACKERS] Possible index issue on 9.5 slave

Peter Geoghegan writes: > On Wed, Jun 18, 2014 at 8:09 PM, Ian Barwick wrote: >> Interesting, I'll take a look later. > I'm pretty suspicious of incompatibilities that may exist between the > two sets of OS collations involved here. We aren't very clear on the > extent to which what you're doing

Re: [HACKERS] Possible index issue on 9.5 slave

On 19/06/14 12:30, Peter Geoghegan wrote: On Wed, Jun 18, 2014 at 8:09 PM, Ian Barwick wrote: Interesting, I'll take a look later. I'm pretty suspicious of incompatibilities that may exist between the two sets of OS collations involved here. We aren't very clear on the extent to which what yo

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/18/2014 08:19 PM, Tom Lane wrote: > Actually, I was wondering whether we couldn't remove that > CreateTupleDescCopy call entirely. Apparently not, at least without some additional surgery. ExecMakeTableFunctionResult() tries to free the tuplede

Re: [HACKERS] Possible index issue on 9.5 slave

On Wed, Jun 18, 2014 at 8:09 PM, Ian Barwick wrote: > Interesting, I'll take a look later. I'm pretty suspicious of incompatibilities that may exist between the two sets of OS collations involved here. We aren't very clear on the extent to which what you're doing is supported, but it's certainly

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

Joe Conway writes: > On a side note, while perusing this section of code: > 8<-- at dblink.c:1176 -- > /* make sure we have a persistent copy of the tupdesc */ > tupdesc = CreateTupleDescCopy(tupdesc); > Shouldn't that CreateTupleDescCopy() happe

Re: [HACKERS] Possible index issue on 9.5 slave

On 19/06/14 11:58, Peter Geoghegan wrote: On Wed, Jun 18, 2014 at 6:54 PM, Ian Barwick wrote: I've just run into an index issue on 9.5 HEAD on a slave (master and slave both compiled from 66802246e22d51858cd543877fcfddf24e6812f2); details below (I have only found one index on the slave where th

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/18/2014 07:29 PM, Tom Lane wrote: > I wrote: >> I do see growth in the per-query context as well. I'm not sure >> where that's coming from, but we probably should try to find >> out. A couple hundred bytes per iteration is going to add up, >> e

Re: [HACKERS] Possible index issue on 9.5 slave

On Wed, Jun 18, 2014 at 6:54 PM, Ian Barwick wrote: > I've just run into an index issue on 9.5 HEAD on a slave (master and slave > both compiled from 66802246e22d51858cd543877fcfddf24e6812f2); details > below (I have only found one index on the slave where the issue occurs so > far). Would you m

Re: [HACKERS] delta relations in AFTER triggers

On Wed, Jun 18, 2014 at 03:30:34PM -0700, Kevin Grittner wrote: > David Fetter wrote: > > Robert Haas wrote: > >> Kevin Grittner wrote: > > > The good: > > - Generating the tuplestores.  Yay! > > Thanks for that.  ;-) Sorry, I just can't resist references to Spaghetti Westerns. https://en.

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

I wrote: > I do see growth in the per-query context as well. I'm not sure > where that's coming from, but we probably should try to find out. > A couple hundred bytes per iteration is going to add up, even if it's > not as fast as 8K per iteration. I'm not sure it's dblink's fault, > because I do

[HACKERS] Possible index issue on 9.5 slave

Hi I've just run into an index issue on 9.5 HEAD on a slave (master and slave both compiled from 66802246e22d51858cd543877fcfddf24e6812f2); details below (I have only found one index on the slave where the issue occurs so far). The setup is admittedly slightly unusual; master is OS X 10.7.5, slave

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

I was going to answer each message, but Fabrízio summarized everything so far really nicely. Thanks Fabrízio. On Wed, Jun 18, 2014 at 5:25 PM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > Then, to summarize Matheus must do: > * use an option instead of change the syntax and catalog

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

On 06/19/2014 01:50 AM, Shreesha wrote: > However in my case, I don't know why there wasn't a default database > with name 'root' got created or why the server rejects the client when > it tries to connect to the default database. Take a look at the initdb manual, the tutorial, and the installat

Re: [HACKERS] idle_in_transaction_timeout

On Wed, Jun 18, 2014 at 8:01 PM, Josh Berkus [via PostgreSQL] < ml-node+s1045698n5807868...@n5.nabble.com> wrote: > On 06/18/2014 04:54 PM, Marko Tiikkaja wrote: > > On 2014-06-19 1:46 AM, Josh Berkus wrote: > >> Robert's right, not killing the "BEGIN;" only transactions is liable to > >> result i

Re: [HACKERS] idle_in_transaction_timeout

Josh Berkus writes: > Counter-argument: most app frameworks which do an automatic BEGIN; also > do other stuff like SET TIMEZONE each time as well. Is this really a > case worth worrying about? SET TIMEZONE doesn't result in taking a snapshot either. regards, tom lane

Re: [HACKERS] /proc/self/oom_adj is deprecated in newer Linux kernels

Gurjeet Singh writes: > On Tue, Jun 10, 2014 at 12:05 PM, Tom Lane wrote: >> If we're going to do this, I would say that we should also take the >> opportunity to get out from under the question of which kernel API >> we're dealing with. So perhaps a design like this: >> >> 1. If the environmen

Re: [HACKERS] idle_in_transaction_timeout

On 06/18/2014 04:54 PM, Marko Tiikkaja wrote: > On 2014-06-19 1:46 AM, Josh Berkus wrote: >> Robert's right, not killing the "BEGIN;" only transactions is liable to >> result in user confusion unless we label those sessions differently in >> pg_stat_activity. > > Wouldn't they be labeled different

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-19 1:46 AM, Josh Berkus wrote: Robert's right, not killing the "BEGIN;" only transactions is liable to result in user confusion unless we label those sessions differently in pg_stat_activity. Wouldn't they be labeled differently already? i.e. the last query would be "BEGIN". Unles

Re: [HACKERS] idle_in_transaction_timeout

On 06/18/2014 02:52 PM, Bruce Momjian wrote: > On Wed, Jun 18, 2014 at 04:41:30PM -0400, Robert Haas wrote: >> The only problem I see is that it makes the semantics kind of weird >> and confusing. "Kill connections that are idle in transaction for too >> long" is a pretty clear spec; "kill connect

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

On 06/02/2014 11:38 AM, Andrew Dunstan wrote: 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

Re: [HACKERS] delta relations in AFTER triggers

David Fetter wrote: > Robert Haas wrote: >> Kevin Grittner wrote: > The good: > - Generating the tuplestores.  Yay! Thanks for that.  ;-) > The bad: > - Generating them exactly and only for AFTER triggers The standard only allows them for AFTER triggers, and I'm not sure what the sema

Re: [HACKERS] btreecheck extension

On Wed, Jun 18, 2014 at 4:48 AM, Stephen Frost wrote: > I'm fine with having these start out as external tools which are doing > checks, but I've been specifically asked about (and have desired myself > from time-to-time...) an in-core capability to check index/heap/etc > validity. Folks coming f

Re: [HACKERS] delta relations in AFTER triggers

Robert Haas wrote: > Kevin Grittner wrote: > Can you describe what the standard syntax for the row variables > is, as opposed to our syntax?  Also, what's the standard syntax > for the the transition relations? If you want either (or both), the standard has you using a REFERENCING clause right

Re: [HACKERS] idle_in_transaction_timeout

On Wed, Jun 18, 2014 at 04:41:30PM -0400, Robert Haas wrote: > 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;" im

Re: [HACKERS] delta relations in AFTER triggers

Alvaro Herrera wrote: > Kevin Grittner wrote: > TRUNCATE triggers shouldn't have delta relations, that's for > sure, or it'd completely negate the point of TRUNCATE triggers. > I don't think we have any other event, do we?  People who get > delta relations for deleting all rows should be using DE

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

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] 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] [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] 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] [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

[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] 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

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] [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] 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] 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] 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

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

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

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] [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] [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] 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

-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] 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] 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] 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] 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] 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] 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 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] 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] 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] 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] 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] 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] 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

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 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

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 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] 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 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?

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 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] 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] 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] 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?

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] 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] 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] 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] 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] 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] 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

[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] 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] 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] 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

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] 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] 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 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] 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] 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] 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] 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

* 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] 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] 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] 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

  1   2   >