[HACKERS] preproc.c compilation error

Hello all: This is my first time mail to all, yesterday I tried to compile postgresin my linux, but an error keep bother me. env: Ubuntu 13.10 Linux rugal-TM8473 3.11.0-15-generic #23-Ubuntu SMP Mon Dec 9 18:17:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-1

Re: [HACKERS] preproc.c compilation error

and even successfully compiled PG, I got warning preproc.y: In function ‘vmmerror’: preproc.y:76:2: warning: enumeration value ‘ET_FATAL’ not handled in switch [-Wswitch] switch(type) ^ 2014/1/9 Rugal Bernstein > Hello all: >This is my first time mail to all, yesterday I tried to comp

Re: [HACKERS] [bug fix] multibyte messages are displayed incorrectly on the client

On Tue, Jan 7, 2014 at 8:56 AM, MauMau wrote: > I suppose we know (or at least believe) those encodings during backend > startup: > > * client encoding - the client_encoding parameter passed in the startup > packet, or if that's not present, client_encoding GUC value. > > * server encoding - the e

Re: [HACKERS] Standalone synchronous master

From: "Andres Freund" On 2014-01-08 14:42:37 -0800, Joshua D. Drake wrote: If we have the following: db0->db1:down Using the model (as I understand it) that is being discussed we have increased our failure rate because the moment db1:down we also lose db0. The node db0 may be up but if it i

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

On Tue, Jan 7, 2014 at 1:15 PM, Tom Lane wrote: > Emre Hasegeli writes: >> I get assertion failure on initsplan.c line 1325 while executing following >> query >> on HEAD (edc43458d797a5956f4bf39af18cf62abb0077db). It works fine >> without --enable-cassert. > >> update subscriber set properties =

Re: [HACKERS] [bug fix] multibyte messages are displayed incorrectly on the client

From: "Robert Haas" Suppose the startup packet itself is malformed. How will you report the error? I think we have no choice but to report the error in English, because we don't know what the client wants. Regards MauMau -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o

Re: [HACKERS] [bug fix] multibyte messages are displayed incorrectly on the client

From: "Robert Haas" Suppose the startup packet itself is malformed. How will you report the error? I think we have no choice but to report the error in English, because we don't know what the client wants. Regards MauMau -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o

Re: [HACKERS] preproc.c compilation error

You have to rebuild the auto-generated pgc.c, preproc.c and preproc.y or simply remove them to force a rebuild. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meske

Re: [HACKERS] Recovery to backup point

On 12/09/2013 03:05 PM, MauMau wrote: From: "Heikki Linnakangas" Thanks. Looks sane, although I don't much like the proposed interface to trigger this, setting recovery_target_time='backup_point'. What the code actually does is to stop recovery as soon as you reach consistency, which might not

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

Andreas, Robert, * Andreas Karlsson (andr...@proxel.se) wrote: > A patch with updated documentation is attached. Thanks for working on this! > On 01/02/2014 04:08 AM, Robert Haas wrote: > >I'm wondering whether the time should be stored inside the PlannedStmt > >node instead of passing it around

Re: [HACKERS] array_length(anyarray)

On 19 December 2013 08:05, Pavel Stehule wrote: > > > > 2013/12/19 David Fetter >> >> On Wed, Dec 18, 2013 at 09:27:54PM +0100, Marko Tiikkaja wrote: >> > Hi, >> > >> > Attached is a patch to add support for array_length(anyarray), which >> > only works for one-dimensional arrays, returns 0 for e

Re: [HACKERS] nested hstore patch

On 01/08/2014 04:29 PM, Oleg Bartunov wrote: Attached is a new version of patch, which addresses most issues raised by Andres. It's long holidays in Russia now and it happened that Teodor is traveling with family, so Teodor asked me to reply. Comments in code will be added asap. Oleg, Ple

Re: [HACKERS] preproc.c compilation error

Thanks, seems it is because the first time pgc.c and others are generated, but [make distclean] did not clean them, which lead to this problem! after [rm pgc.c preproc.h preproc.c preproc.y] it is now successfully compiled without any warning! thank you! Java Developer; Mysql/Oracle DBA; C/Java/Py

Re: [HACKERS] preproc.c compilation error

On 2014-01-09 22:12:53 +0800, Rugal Bernstein wrote: > Thanks, seems it is because the first time pgc.c and others are generated, > but [make distclean] did not clean them, which lead to this problem! > after [rm pgc.c preproc.h preproc.c preproc.y] > it is now successfully compiled without any war

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On Fri, Dec 6, 2013 at 6:41 PM, Amit Kapila wrote: >Agreed, summarization of data for LZ/Chunkwise encoding especially for >non-compressible (hundred tiny fields, all changed/half changed) or less >compressible data (hundred tiny fields, half nulled) w.r.t CPU > usage is as below: > >

Re: [HACKERS] Standalone synchronous master

On 01/09/2014 05:09 AM, Robert Treat wrote: > On Wed, Jan 8, 2014 at 6:15 PM, Josh Berkus wrote: >> Stephen, >> >> >>> I'm aware, my point was simply that we should state, up-front in >>> 25.2.7.3 *and* where we document synchronous_standby_names, that it >>> requires at least three servers to be

Re: [HACKERS] Standalone synchronous master

On 01/09/2014 12:05 AM, Stephen Frost wrote: > * Andres Freund (and...@2ndquadrant.com) wrote: >> On 2014-01-08 17:56:37 -0500, Stephen Frost wrote: >>> * Andres Freund (and...@2ndquadrant.com) wrote: That's why you should configure a second standby as another (candidate) synchronous repl

Re: [HACKERS] Standalone synchronous master

On 01/08/2014 11:49 PM, Tom Lane wrote: > "Joshua D. Drake" writes: >> On 01/08/2014 01:55 PM, Tom Lane wrote: >>> Sync mode is about providing a guarantee that the data exists on more than >>> one server *before* we tell the client it's committed. If you don't need >>> that guarantee, you should

Re: [HACKERS] Standalone synchronous master

On 01/09/2014 01:57 PM, MauMau wrote: > From: "Andres Freund" >> On 2014-01-08 14:42:37 -0800, Joshua D. Drake wrote: >>> If we have the following: >>> >>> db0->db1:down >>> >>> Using the model (as I understand it) that is being discussed we have >>> increased our failure rate because the moment d

Re: [HACKERS] Standalone synchronous master

On 01/09/2014 02:01 AM, Jim Nasby wrote: > On 1/8/14, 6:05 PM, Tom Lane wrote: >> Josh Berkus writes: >>> >On 01/08/2014 03:27 PM, Tom Lane wrote: >>What we lack, and should work on, is a way for sync mode to have M larger >>than one. AFAICS, right now we'll report commit as soon a

Re: [HACKERS] Recovery to backup point

From: "Heikki Linnakangas" After some refactoring and fixing bugs in the existing code, I came up with the attached patch. I called the option simply "recovery_target", with the only allowed value of "immediate". IOW, if you want to stop recovery as early as possible, you add recovery_target='im

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

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

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

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

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

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

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

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

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 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: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 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 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] [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] [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] [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+.

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

[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+.

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

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

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

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

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

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

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

  1   2   >