Re: [HACKERS] WIP patch (v2) for updatable security barrier views

On 9 January 2014 15:19, Tom Lane wrote: > Dean Rasheed writes: >> My first thought was that it should just preprocess any security >> barrier quals in subquery_planner() in the same way as other quals are >> preprocessed. But thinking about it further, those quals are destined >> to become the q

Re: [HACKERS] Standalone synchronous master

On Fri, Jan 10, 2014 at 3:23 AM, Simon Riggs wrote: > On 8 January 2014 21:40, Tom Lane wrote: >> Kevin Grittner writes: >>> I'm torn on whether we should cave to popular demand on this; but >>> if we do, we sure need to be very clear in the documentation about >>> what a successful return from

Re: [HACKERS] Recovery to backup point

On Fri, Jan 10, 2014 at 12:08 AM, MauMau wrote: > C2. "recovery_target = 'immediate'" sounds less intuitive than my suggestion > "recovery_target_time = 'backup_point'", at least for those who want to > recover to the backup point. > Although I don't have a good naming sense in English, the value

[HACKERS] [review] libpq: Support TLSv1.1+ (was: fe-secure.c and SSL/TLS)

I applied both libpq.tls11plus.diff and the related psql.conninfo.tlsver.diff patch to postgresql git head. Source review: The source changes are pretty tiny. Although I think the change from TLSv1_method to SSLv23_method is correct, the comment is not quite correct: > * SSLv23_method() is only

Re: [HACKERS] Standalone synchronous master

On Thu, Jan 9, 2014 at 10:45 PM, Bruce Momjian wrote: > > I think RAID-1 is a very good comparison because it is successful > technology and has similar issues. > > RAID-1 is like Postgres synchronous_standby_names mode in the sense that > the RAID-1 controller will not return success until writes

Re: [HACKERS] Disallow arrays with non-standard lower bounds

Jim Nasby writes: > ISTM that allowing users to pick arbitrary lower array bounds was a huge > mistake. I've never seen anyone make use of it, can't think of any legitimate > use cases for it, and hate the stupendous amount of extra code needed to deal > with it. You lack imagination, sir.

Re: [HACKERS] Planning time in explain/explain analyze

Greg Stark writes: > On Thu, Jan 9, 2014 at 9:14 PM, Tom Lane wrote: >> In short then, I think we should just add this to EXPLAIN and be done. >> -1 for sticking the info into PlannedStmt or anything like that. > I'm confused. I thought I was arguing to support your suggestion that > the initial

Re: [HACKERS] Bogus error handling in pg_upgrade

On Sun, Dec 29, 2013 at 12:25:04AM -0500, Tom Lane wrote: > A credulous person might suppose that this chunk of code is designed > to abort if pg_resetxlog fails: > > prep_status("Setting next transaction ID for new cluster"); > exec_prog(UTILITY_LOG_FILE, NULL, true, > "\"%s

Re: [HACKERS] ALTER SYSTEM SET command to change postgresql.conf parameters

On Thu, Jan 9, 2014 at 12:26 AM, Robert Haas wrote: > On Mon, Jan 6, 2014 at 11:37 PM, Amit Kapila wrote: >> On Tue, Jan 7, 2014 at 12:52 AM, Robert Haas wrote: >>> On Mon, Jan 6, 2014 at 9:48 AM, Amit Kapila wrote: > Couldn't we also handle this by postponing FreeConfigVariables until

Re: [HACKERS] Show lossy heap block info in EXPLAIN ANALYZE for bitmap heap scan

I wrote: > Robert Haas wrote: > > Hmm, fair point. But I'm still not convinced that we really need to > > add extra accounting for this. What's wrong with just reporting the > > number of exact and lossy pages? > No. I intended to show the desired memory space for a TIDBitmap rather > than the

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On Tue, Jan 7, 2014 at 8:46 PM, Peter Geoghegan wrote: > I've worked on a simple set of tests, written quickly in bash, that I > think exercise interesting cases: > > https://github.com/petergeoghegan/upsert > > Perhaps most notably, these tests make comparisons between the > performance of ordina

Re: [HACKERS] [PATCH] pg_basebackup: progress report max once per second

On Thu, Jan 9, 2014, at 20:05, Magnus Hagander wrote: > On Thu, Nov 14, 2013 at 10:27 AM, Mika Eloranta wrote: >> On 13 Nov 2013, at 20:51, Mika Eloranta wrote: >> >> >> > Prevent excessive progress reporting that can grow to gigabytes >> > of output with large databases. >> >> >> Same patc

Re: [HACKERS] Turning off HOT/Cleanup sometimes

* Robert Haas (robertmh...@gmail.com) wrote: > So when somebody says "relying on vacuum instead of doing > HOT pruning" what I hear is "flush performance down the toilet"... but > of course the real way to resolve this is to test whatever patch Simon > or someone else eventually posts, not to specu

Re: [HACKERS] Disallow arrays with non-standard lower bounds

On 10/01/14 12:55, Peter Geoghegan wrote: On Thu, Jan 9, 2014 at 3:41 PM, David Fetter wrote: We have dropped support, as you put it, for bigger and harder-hitting mistakes than this. Anybody whose code has this kind of silliness in it will be in other kinds of trouble, too. While the decisio

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On Thu, Jan 9, 2014 at 4:43 PM, Tom Lane wrote: > Robert Haas writes: >> The problem with saying that we should let VACUUM do this work is the >> same as the problem with saying that if you're late for your Concorde >> flight, you should go running across the tarmac and try to catch it. >> The co

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

Sorry for the lateness of this... On 11/14/13, 8:40 PM, Michael Paquier wrote: + /* +* Phase 4 of REINDEX CONCURRENTLY +* +* Now that the concurrent indexes have been validated could be used, +* we need to swap each concurrent index with its corresponding ol

Re: [HACKERS] array_length(anyarray)

On 1/10/14, 1:20 AM, Merlin Moncure wrote: I'm piling on: it's not clear at all to me why you've special cased this to lower_bound=1. First of all, there are other reasons to check length than iteration. Can you point me to some examples? the server API function should implement as many reas

Re: [HACKERS] array_length(anyarray)

On Thu, Jan 9, 2014 at 11:08 AM, Marko Tiikkaja wrote: > On 1/9/14 5:44 PM, Florian Pflug wrote: >> >> On Jan9, 2014, at 14:57 , Dean Rasheed wrote: >>> >>> On 19 December 2013 08:05, Pavel Stehule wrote: length should be irrelevant to fact so array starts from 1, 0 or anything >>

Re: [HACKERS] Disallow arrays with non-standard lower bounds

On Thu, Jan 9, 2014 at 3:41 PM, David Fetter wrote: > We have dropped support, as you put it, for bigger and harder-hitting > mistakes than this. Anybody whose code has this kind of silliness in > it will be in other kinds of trouble, too. While the decision to make it possible to set the lower

Re: [HACKERS] Disallow arrays with non-standard lower bounds

On 10/01/14 12:41, David Fetter wrote: [..] David (who is among that tiny minority who believe that arrays should be indexed from 0.5 as a compromise ;) Clearly we should use 1/e as the starting index, where 'e' is Euler's constant 2.718... :-) (Much more mathematically profound!) Cheers, G

Re: [HACKERS] Disallow arrays with non-standard lower bounds

On Thu, Jan 09, 2014 at 04:30:25PM -0600, Jim Nasby wrote: > ISTM that allowing users to pick arbitrary lower array bounds was a > huge mistake. I've never seen anyone make use of it, can't think of > any legitimate use cases for it, and hate the stupendous amount of > extra code needed to deal wit

Re: [HACKERS] array_length(anyarray)

On Jan9, 2014, at 23:26 , Jim Nasby wrote: > On 1/9/14, 11:08 AM, Marko Tiikkaja wrote: >> On 1/9/14 5:44 PM, Florian Pflug wrote: >>> On Jan9, 2014, at 14:57 , Dean Rasheed wrote: On 19 December 2013 08:05, Pavel Stehule wrote: > length should be irrelevant to fact so array starts from

Re: [HACKERS] Disallow arrays with non-standard lower bounds

On Thu, Jan 9, 2014 at 2:30 PM, Jim Nasby wrote: > ISTM that allowing users to pick arbitrary lower array bounds was a huge > mistake. I've never seen anyone make use of it, can't think of any > legitimate use cases for it, and hate the stupendous amount of extra code > needed to deal with it. I

[HACKERS] proposal, patch: allow multiple plpgsql plugins

Hello We talked about enhancing a plpgsql plugin API to support more active plugins. I wrote a prototype based on function plpgsql_register_plugin instead rendezvous variable. There are two basic questions: a) will we support rendezvous variable still? b) will we support same API still - a ref

Re: [HACKERS] nested hstore patch

I moved patch to the January commitfest (https://commitfest.postgresql.org/action/patch_view?id=1289) . Oleg PS. Kudos to Teodor and his mobile phone, which he used to synchronize branches on github. On Fri, Jan 10, 2014 at 2:08 AM, Andrew Dunstan wrote: > > On 01/09/2014 02:11 PM, Josh Berku

[HACKERS] Disallow arrays with non-standard lower bounds

ISTM that allowing users to pick arbitrary lower array bounds was a huge mistake. I've never seen anyone make use of it, can't think of any legitimate use cases for it, and hate the stupendous amount of extra code needed to deal with it. Obviously we can't just drop support, but what about an

Re: [HACKERS] array_length(anyarray)

On 1/9/14, 11:08 AM, Marko Tiikkaja wrote: On 1/9/14 5:44 PM, Florian Pflug wrote: On Jan9, 2014, at 14:57 , Dean Rasheed wrote: On 19 December 2013 08:05, Pavel Stehule wrote: length should be irrelevant to fact so array starts from 1, 0 or anything else Yes, this should just return the n

Re: [HACKERS] Add CREATE support to event triggers

On 1/9/14, 11:58 AM, Alvaro Herrera wrote: Robert Haas escribió: On Wed, Jan 8, 2014 at 10:27 PM, Alvaro Herrera wrote: Hmm. This seems like a reasonable thing to do, except that I would like the "output" to always be the constant, and have some other way to enable the clause or disable it.

Re: [HACKERS] Planning time in explain/explain analyze

On Thu, Jan 9, 2014 at 9:14 PM, Tom Lane wrote: > In short then, I think we should just add this to EXPLAIN and be done. > -1 for sticking the info into PlannedStmt or anything like that. I'm confused. I thought I was arguing to support your suggestion that the initial planning store the time in

Re: [HACKERS] Turning off HOT/Cleanup sometimes

Robert Haas writes: > The problem with saying that we should let VACUUM do this work is the > same as the problem with saying that if you're late for your Concorde > flight, you should go running across the tarmac and try to catch it. > The cost of dead tuples is related in a linear fashion to the

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

On Thu, Jan 9, 2014 at 10:29 PM, Gabriele Bartolini < gabriele.bartol...@2ndquadrant.it> wrote: > Hi Steeve, > > Il 09/01/14 22:10, Steeve Lennmark ha scritto: > > > > That's a much better solution, I attached a patch with the updated code. > > > > # SELECT oid, pg_tablespace_location(oid) FROM pg

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On 2014-01-09 16:27:23 -0500, Robert Haas wrote: > People *think* they don't like that, because that's the way it works > right now. If it worked some other way, there's a good chance people > would be complaining about that behavior, too. I think on of the primary reason why it's causing huge sl

Re: [HACKERS] Standalone synchronous master

On 1/9/14, 9:01 AM, Hannu Krosing wrote: Yeah, and I think that the logging command that was suggested allows >for that*if configured correctly*. *But* for relying on this, we would also need to make logging *synchronous*, which would probably not go down well with many people, as it makes thin

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

Hi Steeve, > Il 09/01/14 22:10, Steeve Lennmark ha scritto: > > That's a much better solution, I attached a patch with the updated code. > > # SELECT oid, pg_tablespace_location(oid) FROM pg_tablespace; > [...] > 16388 | /tmp/tblspc1 > 16389 | /tmp/tblspc2 I'd suggest, a similar solution to the

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On Thu, Jan 9, 2014 at 1:54 PM, Tom Lane wrote: > Stephen Frost writes: >> That said, I'm not entirely convinced that traversing these dead tuples >> is all *that* painful during SELECT. If there's that many levels then >> hopefully it's not long til an UPDATE comes along and cleans them up. > >

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On 1/9/14, 12:54 PM, Tom Lane wrote: Stephen Frost writes: That said, I'm not entirely convinced that traversing these dead tuples is all *that* painful during SELECT. If there's that many levels then hopefully it's not long til an UPDATE comes along and cleans them up. There's always VACUUM

Re: [HACKERS] Planning time in explain/explain analyze

Greg Stark writes: > However I don't see the issue here. Two gettimeofday calls per query > plan is not really going to hurt even on systems where it's slow. I tend to agree with this, especially if the calls only occur when the user asks for the information (ie, does an EXPLAIN rather than just

Re: [HACKERS] [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL

On 1/9/14, 1:18 PM, knizhnik wrote: So it is clear why do we need shared memory for parallel query execution. But why it has to be dynamic? Why it can not be preallocated at start time as most of other resources used by PostgreSQL? That would limit us to doing something like allocating a fixe

Re: [HACKERS] Planning time in explain/explain analyze

On Thu, Jan 9, 2014 at 1:50 PM, Stephen Frost wrote: >> I do not think we want to always measure the time it took to >> generate a plan due to slow clocks on some architectures. Also I >> feel that such a patch would be more invasive. > > The slow-clock argument is really quite frustrating for tho

Re: [HACKERS] [BUG] Archive recovery failure on 9.3+.

On 01/09/2014 12:05 PM, Heikki Linnakangas wrote: > Actually, why is the partially-filled 00010002 file > archived in the first place? Looking at the code, it's been like that > forever, but it seems like a bad idea. If the original server is still > up and running, and writing mor

Re: [HACKERS] [BUG] Archive recovery failure on 9.3+.

On 01/09/2014 10:36 PM, Tom Lane wrote: Heikki Linnakangas writes: On 01/09/2014 10:16 PM, Tom Lane wrote: Don't we want to archive both? If you want to recover to the end of the old timeline, you're going to need that file too, no? Hmm. It should be the responsibility of the original serv

Re: [HACKERS] [BUG] Archive recovery failure on 9.3+.

Heikki Linnakangas writes: > On 01/09/2014 10:16 PM, Tom Lane wrote: >> Don't we want to archive both? If you want to recover to the end of the >> old timeline, you're going to need that file too, no? > Hmm. It should be the responsibility of the original server to archive > the segment on the

[HACKERS] [PATCH] pgcrypto: implement gen_random_uuid

The only useful feature of the uuid-ossp module in my opinion is the uuid_generate_v4 function and as uuid-ossp is more or less abandonware people have had trouble building and installing it. This patch implements an alternative uuid v4 generation function in pgcrypto which could be moved to c

Re: [HACKERS] [BUG] Archive recovery failure on 9.3+.

On 01/09/2014 10:16 PM, Tom Lane wrote: Heikki Linnakangas writes: Actually, why is the partially-filled 00010002 file archived in the first place? ... So, the rationale is that otherwise it would take a long time until that segment is archived. To be precise, I don't think t

Re: [HACKERS] [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL

On 01/09/2014 11:48 PM, Claudio Freire wrote: On Thu, Jan 9, 2014 at 4:39 PM, knizhnik wrote: At fork time I only wrote about reserving the address space. After reserving it, all you have to do is implement an allocator that works in shared memory (protected by a lwlock of course). In essence,

Re: [HACKERS] [BUG] Archive recovery failure on 9.3+.

Heikki Linnakangas writes: > Actually, why is the partially-filled 00010002 file > archived in the first place? ... > So, the rationale is that otherwise it would take a long time until that > segment is archived. To be precise, I don't think the segment with the > old TLI woul

Re: [HACKERS] [BUG] Archive recovery failure on 9.3+.

On 01/09/2014 08:18 PM, Heikki Linnakangas wrote: On 12/12/2013 04:00 AM, Kyotaro HORIGUCHI wrote: Hello, we happened to see server crash on archive recovery under some condition. After TLI was incremented, there should be the case that the WAL file for older timeline is archived but not for th

Re: [HACKERS] [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL

On Thu, Jan 9, 2014 at 4:48 PM, Claudio Freire wrote: > On Thu, Jan 9, 2014 at 4:39 PM, knizhnik wrote: >>> At fork time I only wrote about reserving the address space. After >>> reserving it, all you have to do is implement an allocator that works >>> in shared memory (protected by a lwlock of c

Re: [HACKERS] [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL

On Thu, Jan 9, 2014 at 4:39 PM, knizhnik wrote: >> At fork time I only wrote about reserving the address space. After >> reserving it, all you have to do is implement an allocator that works >> in shared memory (protected by a lwlock of course). >> >> In essence, a hypothetical pg_dsm_alloc(region

Re: [HACKERS] [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL

On 01/09/2014 11:30 PM, Claudio Freire wrote: On Thu, Jan 9, 2014 at 4:24 PM, knizhnik wrote: On 01/09/2014 09:46 PM, Claudio Freire wrote: On Thu, Jan 9, 2014 at 2:22 PM, Robert Haas wrote: It would be nice to have better operating system support for this. For example, IIUC, 64-bit Linux ha

Re: [HACKERS] [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL

On Fri, Jan 10, 2014 at 1:00 AM, knizhnik wrote: > On 01/09/2014 11:09 PM, Amit Kapila wrote: >> >> >> Using DuplicateHandle(), we can make segment stick for Postmaster >> lifetime. I have used below test (used dsm_demo module) to verify: > > As far as I understand DuplicateHandle() should really

Re: [HACKERS] [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL

On 01/09/2014 11:09 PM, Amit Kapila wrote: On Thu, Jan 9, 2014 at 12:21 AM, Robert Haas wrote: On Tue, Jan 7, 2014 at 10:20 PM, Amit Kapila wrote: On Tue, Jan 7, 2014 at 2:46 AM, Robert Haas wrote: Well, right now we just reopen the same object from all of the processes, which seems to work

Re: [HACKERS] [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL

On Thu, Jan 9, 2014 at 4:24 PM, knizhnik wrote: > On 01/09/2014 09:46 PM, Claudio Freire wrote: >> >> On Thu, Jan 9, 2014 at 2:22 PM, Robert Haas wrote: >>> >>> It would be nice to have better operating system support for this. >>> For example, IIUC, 64-bit Linux has 128TB of address space availa

[HACKERS] [PATCH] Filter error log statements by sqlstate

Allow the default log_min_error_statement to be overridden per sqlstate to make it possible to filter out some error types while maintaining a low log_min_error_statement or enable logging for some error types when the default is to not log anything. I've tried to do something like this using

Re: [HACKERS] [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL

On 01/09/2014 09:46 PM, Claudio Freire wrote: On Thu, Jan 9, 2014 at 2:22 PM, Robert Haas wrote: It would be nice to have better operating system support for this. For example, IIUC, 64-bit Linux has 128TB of address space available for user processes. When you clone(), it can either share the

Re: [HACKERS] [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL

On 01/09/2014 09:22 PM, Robert Haas wrote: On Wed, Jan 8, 2014 at 2:39 PM, knizhnik wrote: I wonder what is the intended use case of dynamic shared memory? Is is primarly oriented on PostgreSQL extensions or it will be used also in PosatgreSQL core? My main motivation is that I want to use it

Re: [HACKERS] [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL

On Thu, Jan 9, 2014 at 12:21 AM, Robert Haas wrote: > On Tue, Jan 7, 2014 at 10:20 PM, Amit Kapila wrote: >> On Tue, Jan 7, 2014 at 2:46 AM, Robert Haas wrote: >>> >>> Well, right now we just reopen the same object from all of the >>> processes, which seems to work fine and doesn't require any o

Re: [HACKERS] nested hstore patch

On 01/09/2014 06:12 AM, Andrew Dunstan wrote: > Oleg, > > Please merge in the jsonb work and resubmit. See > I note that > this repo does not apparently contain any of your latest changes. I'll go further and say that if the Hstore2 pa

Re: [HACKERS] Turning off HOT/Cleanup sometimes

Stephen Frost writes: > That said, I'm not entirely convinced that traversing these dead tuples > is all *that* painful during SELECT. If there's that many levels then > hopefully it's not long til an UPDATE comes along and cleans them up. There's always VACUUM ;-) If you take about ten steps b

Re: [HACKERS] [PATCH] pg_basebackup: progress report max once per second

On Thu, Nov 14, 2013 at 10:27 AM, Mika Eloranta wrote: > On 13 Nov 2013, at 20:51, Mika Eloranta wrote: > > > Prevent excessive progress reporting that can grow to gigabytes > > of output with large databases. > > Same patch as an attachment. > Would it not make more sense to instead store the

Re: [HACKERS] Turning off HOT/Cleanup sometimes

* Simon Riggs (si...@2ndquadrant.com) wrote: > > I'm -1 for a parameter as well, but I think that just stopping SELECTs > > from doing pruning at all might well be a win. It's at least worthy > > of some investigation. > > Turning HOT off completely would be an absolute disaster for OLTP on > hig

Re: [HACKERS] Turning off HOT/Cleanup sometimes

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > But in a > SELECT, the effect is only that you will have to skip less dead tuples, > which is not as exciting. Agreed. There's also the option to have it be done based on some expectation of future work- that is, if we have to traverse X number

Re: [HACKERS] Standalone synchronous master

On 8 January 2014 21:40, Tom Lane wrote: > Kevin Grittner writes: >> I'm torn on whether we should cave to popular demand on this; but >> if we do, we sure need to be very clear in the documentation about >> what a successful return from a commit request means. Sooner or >> later, Murphy's Law b

Re: [HACKERS] Turning off HOT/Cleanup sometimes

Alvaro Herrera writes: > Robert Haas escribió: >> But the argument that we don't need a parameter because one >> behavior is best for everyone is not going to fly. > In the above, there's the underlying assumption that it doesn't matter > *what* we do with the page after doing or not doing prunin

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On 9 January 2014 17:21, Tom Lane wrote: > Robert Haas writes: >> On Wed, Jan 8, 2014 at 3:33 AM, Simon Riggs wrote: >>> We also make SELECT clean up blocks as it goes. That is useful in OLTP >>> workloads, but it means that large SQL queries and pg_dump effectively >>> do much the same work as

Re: [HACKERS] [BUG] Archive recovery failure on 9.3+.

On 12/12/2013 04:00 AM, Kyotaro HORIGUCHI wrote: Hello, we happened to see server crash on archive recovery under some condition. After TLI was incremented, there should be the case that the WAL file for older timeline is archived but not for that of the same segment id but for newer timeline. A

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

On Thu, Jan 9, 2014 at 6:58 PM, Steeve Lennmark wrote: > Currently pg_basebackup is pretty invasive when using tablespaces, at > least using the plain format. This since it requires the tablespace to > be written to the same location as on the server beeing backed up. This > both breaks backing up

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

On 01/09/2014 06:58 PM, Steeve Lennmark wrote: > This patch adds the ability to relocate tablespaces by adding the command line argument --tablespace (-T) which takes a required argument in the format "oid:tablespacedir". After all tablespaces are fetched this code updates the symlink to point t

Re: [HACKERS] Standalone synchronous master

Robert, > I think the problem here is that we tend to have a limited view of > "the right way to use synch rep". If I have 5 nodes, and I set 1 > synchronous and the other 3 asynchronous, I've set up a "known > successor" in the event that the leader fails. In this scenario > though, if the "succe

Re: [HACKERS] Turning off HOT/Cleanup sometimes

Robert Haas escribió: > Unfortunately, there's no categorical answer. You can come up with > workloads where HOT pruning on selects is a win; just create a bunch > of junk and then read the same pages lots of times in a row. And you > can also come up with workloads where it's a loss; create a b

Re: [HACKERS] integrate pg_upgrade analyze_new_cluster.sh into vacuumdb

Robert Haas writes: > I was referring to the analyze-in-stages logic, which is not specific > to 8.4. I don't see a reason not to put that into vacuumdb. Right, that's Peter's core proposal, which I agreed with. The issue was what to do with some other steps that pg_upgrade sometimes sticks int

Re: [HACKERS] Add CREATE support to event triggers

Robert Haas escribió: > On Wed, Jan 8, 2014 at 10:27 PM, Alvaro Herrera > wrote: > > Hmm. This seems like a reasonable thing to do, except that I would like > > the "output" to always be the constant, and have some other way to > > enable the clause or disable it. With your "present" boolean: >

Re: [HACKERS] integrate pg_upgrade analyze_new_cluster.sh into vacuumdb

On Thu, Jan 9, 2014 at 12:44 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Jan 8, 2014 at 10:32 PM, Tom Lane wrote: >>> I don't think this vacuumdb feature should deal with any >>> version-conversion issues. So it sounds like the thing to do is keep the >>> wrapper script, which will giv

Re: [HACKERS] [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL

On Thu, Jan 9, 2014 at 2:22 PM, Robert Haas wrote: > It would be nice to have better operating system support for this. > For example, IIUC, 64-bit Linux has 128TB of address space available > for user processes. When you clone(), it can either share the entire > address space (i.e. it's a thread

Re: [HACKERS] Standalone synchronous master

On Thu, Jan 9, 2014 at 09:36:47AM -0800, Jeff Janes wrote: > Oh, right. Because the main reason for a sync replica degrading is that > it's down. In which case it isn't going to record anything. This would > still be useful for sync rep candidates, though, and I'll document why >

Re: [HACKERS] integrate pg_upgrade analyze_new_cluster.sh into vacuumdb

Robert Haas writes: > On Wed, Jan 8, 2014 at 10:32 PM, Tom Lane wrote: >> I don't think this vacuumdb feature should deal with any >> version-conversion issues. So it sounds like the thing to do is keep the >> wrapper script, which will give us a place to put any such special actions >> without

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On Jan9, 2014, at 18:09 , Tom Lane wrote: > Florian Pflug writes: >> For float 4 and float8, wasn't the consensus that the potential >> lossy-ness of addition makes this impossible anyway, even without the >> NaN issue? But... > > Well, that was my opinion, I'm not sure if it was consensus ;-).

Re: [HACKERS] integrate pg_upgrade analyze_new_cluster.sh into vacuumdb

On Wed, Jan 8, 2014 at 10:32 PM, Tom Lane wrote: > Peter Eisentraut writes: >> pg_upgrade creates a script analyze_new_cluster.{sh|bat} that runs >> vacuumdb --analyze-only in three stages with different statistics target >> settings to get a fresh cluster analyzed faster. I think this behavior

Re: [HACKERS] Standalone synchronous master

On Wed, Jan 8, 2014 at 3:00 PM, Josh Berkus wrote: > On 01/08/2014 01:49 PM, Tom Lane wrote: > > Josh Berkus writes: > >> If we really want auto-degrading sync rep, then we'd (at a minimum) need > >> a way to determine *from the replica* whether or not it was in degraded > >> mode when the maste

Re: [HACKERS] Add CREATE support to event triggers

On Wed, Jan 8, 2014 at 10:27 PM, Alvaro Herrera wrote: > Craig Ringer escribió: >> Instead, can't we use your already proposed subclause structure? >> >> {"authorization":{"authorization_role":"some guy", >> "output":"AUTHORIZATION %i{authorization_role}"}, >> "if_not_exists": {

Re: [HACKERS] newlines at end of generated SQL

On Wed, Jan 8, 2014 at 10:17 PM, Peter Eisentraut wrote: > Is there a reason why the programs in src/bin/scripts all put newlines > at the end of the SQL commands they generate? This produces useless > empty lines in the server log (and client output, if selected). If you're asking whether you c

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On Thu, Jan 9, 2014 at 12:21 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Jan 8, 2014 at 3:33 AM, Simon Riggs wrote: >>> We also make SELECT clean up blocks as it goes. That is useful in OLTP >>> workloads, but it means that large SQL queries and pg_dump effectively >>> do much the same

Re: [HACKERS] Turning off HOT/Cleanup sometimes

Robert Haas writes: > On Wed, Jan 8, 2014 at 3:33 AM, Simon Riggs wrote: >> We also make SELECT clean up blocks as it goes. That is useful in OLTP >> workloads, but it means that large SQL queries and pg_dump effectively >> do much the same work as VACUUM, generating huge amounts of I/O and >> WA

Re: [HACKERS] [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL

On Wed, Jan 8, 2014 at 2:39 PM, knizhnik wrote: > I wonder what is the intended use case of dynamic shared memory? > Is is primarly oriented on PostgreSQL extensions or it will be used also in > PosatgreSQL core? My main motivation is that I want to use it to support parallel query. There is unf

Re: [HACKERS] Standalone synchronous master

On Thu, Jan 9, 2014 at 04:55:22PM +0100, Hannu Krosing wrote: > On 01/09/2014 04:15 PM, MauMau wrote: > > From: "Hannu Krosing" > >> On 01/09/2014 01:57 PM, MauMau wrote: > >>> Let me ask a (probably) stupid question. How is the sync rep > >>> different from RAID-1? > >>> > >>> When I first saw

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

Florian Pflug writes: > For float 4 and float8, wasn't the consensus that the potential > lossy-ness of addition makes this impossible anyway, even without the > NaN issue? But... Well, that was my opinion, I'm not sure if it was consensus ;-). But NaN is an orthogonal problem I think. I'm not s

Re: [HACKERS] array_length(anyarray)

On 1/9/14 5:44 PM, Florian Pflug wrote: On Jan9, 2014, at 14:57 , Dean Rasheed wrote: On 19 December 2013 08:05, Pavel Stehule wrote: length should be irrelevant to fact so array starts from 1, 0 or anything else Yes, this should just return the number of elements, and 0 for an empty array.

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On Wed, Jan 8, 2014 at 3:33 AM, Simon Riggs wrote: > VACUUM cleans up blocks, which is nice because it happens offline in a > lazy manner. > > We also make SELECT clean up blocks as it goes. That is useful in OLTP > workloads, but it means that large SQL queries and pg_dump effectively > do much t

Re: [HACKERS]

On Tue, Jan 7, 2014 at 10:55 PM, Dilip kumar wrote: > Below attached patch is implementing following todo item.. > > machine-readable pg_controldata? > > http://www.postgresql.org/message-id/4b901d73.8030...@agliodbs.com > > Possible approaches: > > 1. Implement as backend function and provi

Re: [HACKERS] array_length(anyarray)

On Jan9, 2014, at 14:57 , Dean Rasheed wrote: > On 19 December 2013 08:05, Pavel Stehule wrote: >> length should be irrelevant to fact so array starts from 1, 0 or anything >> else > > Yes, this should just return the number of elements, and 0 for an empty array. +1. Anything that complains abo

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On Jan9, 2014, at 17:15 , Tom Lane wrote: > Dean Rasheed writes: >> Reading over this, I realised that there is a problem with NaN >> handling --- once the state becomes NaN, it can never recover. So the >> results using the inverse transition function don't match HEAD in >> cases like this: > >

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

Dean Rasheed writes: > Reading over this, I realised that there is a problem with NaN > handling --- once the state becomes NaN, it can never recover. So the > results using the inverse transition function don't match HEAD in > cases like this: Ouch! That takes out numeric, float4, and float8 in

Re: [HACKERS] Standalone synchronous master

On 01/09/2014 04:15 PM, MauMau wrote: > From: "Hannu Krosing" >> On 01/09/2014 01:57 PM, MauMau wrote: >>> Let me ask a (probably) stupid question. How is the sync rep >>> different from RAID-1? >>> >>> When I first saw sync rep, I expected that it would provide the same >>> guarantees as RAID-1

Re: [HACKERS] Failed assertion root->hasLateralRTEs on initsplan.c

Robert Haas writes: > On Tue, Jan 7, 2014 at 1:15 PM, Tom Lane wrote: >> The next question is if we should allow it with LATERAL. That would >> essentially be treating "subscriber" as having implicitly appeared at the >> start of the FROM list, which I guess is all right ... but does anyone >> w

Re: [HACKERS] [BUG] Archive recovery failure on 9.3+.

On Thu, Dec 12, 2013 at 11:00 AM, Kyotaro HORIGUCHI wrote: > Hello, we happened to see server crash on archive recovery under > some condition. > > After TLI was incremented, there should be the case that the WAL > file for older timeline is archived but not for that of the same > segment id but f

Re: [HACKERS] WIP patch (v2) for updatable security barrier views

Dean Rasheed writes: > My first thought was that it should just preprocess any security > barrier quals in subquery_planner() in the same way as other quals are > preprocessed. But thinking about it further, those quals are destined > to become the quals of subqueries in the range table, so we don

Re: [HACKERS] [BUG] Archive recovery failure on 9.3+.

Hi, Somebody is reading this thread? This problem seems still remaining on REL9_3_STABLE. Many users would face this problem, so we should resolve this in next release. I think his patch is reasonable to fix this problem. Please check this again. regards, -- Tomonari Ka

Re: [HACKERS] Standalone synchronous master

From: "Hannu Krosing" On 01/09/2014 01:57 PM, MauMau wrote: Let me ask a (probably) stupid question. How is the sync rep different from RAID-1? When I first saw sync rep, I expected that it would provide the same guarantees as RAID-1 in terms of durability (data is always mirrored on two serv

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On 15 December 2013 01:57, Tom Lane wrote: > Josh Berkus writes: >> I think even the FLOAT case deserves some consideration. What's the >> worst-case drift? > > Complete loss of all significant digits. > > The case I was considering earlier of single-row windows could be made > safe (I think) if

Re: [HACKERS] [bug fix] ECPG app crashes due to SIGBUS on SPARC Solaris

On Sun, Jan 05, 2014 at 03:42:42PM +0900, MauMau wrote: > I ran the ECPG regression test with the unpatched 64-bit PostgreSQL > 9.2.4 on SPARC Solaris, and it succeeded (all 54 tests passed). For > ... Thanks a lot. Patch applied to HEAD and all the backbranches. Will push shortly. Michael -- M

  1   2   >