Re: [HACKERS] Triggers on foreign tables

Le mardi 18 mars 2014 03:54:19 Kouhei Kaigai a écrit : > > I hacked on this for awhile, but there remain two matters on which I'm > > uncertain about the right way forward. > > > > (1) To acquire the old tuple for UPDATE/DELETE operations, the patch > > closely parallels our handling for INSTEAD

Re: [HACKERS] gaussian distribution pgbench

(2014/03/17 22:37), Tom Lane wrote: > KONDO Mitsumasa writes: >> (2014/03/17 18:02), Heikki Linnakangas wrote: >>> On 03/17/2014 10:40 AM, KONDO Mitsumasa wrote: >>> There is an infinite number of variants of the TPC-B test that we could >>> include >>> in pgbench. If we start adding every one of

Re: [HACKERS] gaussian distribution pgbench

(2014/03/17 23:29), Robert Haas wrote: On Sat, Mar 15, 2014 at 4:50 AM, Mitsumasa KONDO wrote: There are explanations and computations as comments in the code. If it is about the documentation, I'm not sure that a very precise mathematical definition will help a lot of people, and might rather

Re: [HACKERS] inherit support for foreign tables

Hello, > By the way, Can I have a simple script to build an environment to > run this on? I built test environment and ran the simple test using postgres_fdw and got parameterized path from v3 patch on the following operation as shown there, and v6 also gives one, but I haven't seen the reparamet

Re: [HACKERS] gaussian distribution pgbench

And I find new useful point of this feature. Under following results are '--gaussian=20' case and '--gaussian=2' case, and postgresql setting is same. > [mitsu-ko@pg-rex31 pgbench]$ ./pgbench -c8 -j4 --gaussian=20 -T30 -P 5 > starting vacuum...end. > progress: 5.0 s, 4285.8 tps, lat 1.860 ms stdde

Re: [HACKERS] gaussian distribution pgbench

On 03/18/2014 11:57 AM, KONDO Mitsumasa wrote: I think that this feature will be also useful for survey new buffer-replace algorithm and checkpoint strategy, so on. Sure. No doubt about that. If we remove this option, it is really dissapointed.. As long as we get the \setrandom changes in,

Re: [HACKERS] pg_dump without explicit table locking

On 18.03.14 00:15, Tom Lane wrote: > Jim Nasby writes: >> On 3/17/14, 8:47 AM, Tom Lane wrote: >>> (Note that this is only one of assorted O(N^2) behaviors in older versions >>> of pg_dump; we've gradually stamped them out over time.) > >> On that note, it's recommended that when you are taking a

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe Reply-To:

On 8 March 2014 11:14, Simon Riggs wrote: > On 7 March 2014 09:04, Simon Riggs wrote: > >> The right thing to do here is to not push to the extremes. If we mess >> too much with the ruleutil stuff it will just be buggy. A more >> considered analysis in a later release is required for a full and >

[HACKERS] GSoC question

Hi, PostgreSQL community! My name is Artur Gadelshin, I'm from Saint-Petersburg, Russia. I'm 4th year student in Computer Scince. I haven't enough experience in C/C++, but I really in love with PostgreSQL (but, yes, haven't experience to develop this). My dream is to be computer scientist or data

Re: [HACKERS] GSoC question

Artur, * Artur Gadelshin (ar.gadels...@gmail.com) wrote: > Is there any chance to participate in your community and get some help in > envolving, may be simple tasks, advices about books which I should read or > smth else. There are a number of GSoC project ideas here: https://wiki.postgresql.or

[HACKERS] B-tree descend for insertion locking

When inserting into a B-tree index, all the pages are read-locked when descending the tree. When we reach the leaf page, the read-lock is exchanged for a write-lock. There's nothing wrong with that, but why don't we just directly grab a write-lock on the leaf page? When descending, we know the

Re: [HACKERS] Triggers on foreign tables

On Mon, Mar 17, 2014 at 11:54 PM, Kouhei Kaigai wrote: >> I hacked on this for awhile, but there remain two matters on which I'm >> uncertain about the right way forward. >> >> (1) To acquire the old tuple for UPDATE/DELETE operations, the patch closely >> parallels our handling for INSTEAD OF tri

Re: [HACKERS] Replication slots and footguns

On Thu, Mar 13, 2014 at 9:07 PM, Josh Berkus wrote: > On 03/13/2014 05:28 PM, Robert Haas wrote: >> Well we may have kind of hosed ourselves, because the in-memory data >> structures that represent the data structure have an in_use flag that >> indicates whether the structure is allocated at all,

Re: [HACKERS] on_exit_reset fails to clear DSM-related exit actions

On Mon, Mar 17, 2014 at 1:41 PM, Tom Lane wrote: > Robert Haas writes: >> After mulling over a few possible approaches, I came up with the >> attached, which seems short and to the point. > > Looks reasonable in principle. I didn't run through all the existing > PGSharedMemoryDetach calls to see

Re: [HACKERS] plpgsql.warn_shadow

On 14/03/14 13:12, Simon Riggs wrote: On 14 March 2014 11:10, Pavel Stehule wrote: 2014-03-14 12:02 GMT+01:00 Marko Tiikkaja : On 3/14/14 10:56 AM, Simon Riggs wrote: The patch looks fine, apart from some non-guideline code formatting issues. I'm not sure what you're referring to. I th

Re: [HACKERS] pg_dump without explicit table locking

On 18.03.14 02:32, Joe Conway wrote: > On 03/17/2014 05:55 PM, Jeff Janes wrote: >> On Mon, Mar 17, 2014 at 5:48 PM, Craig Ringer >> >> LOCK TABLE table1, table2, table3, ... > >> would help, instead of doing individual statements? > >> If I recall correctly, someone did submit a patch to do th

Re: [HACKERS] HEAD seems to generate larger WAL regarding GIN index

On Mon, Mar 17, 2014 at 10:44 PM, Alvaro Herrera wrote: > Fujii Masao escribió: >> On Sun, Mar 16, 2014 at 7:15 AM, Alexander Korotkov >> wrote: > >> >> That could be optimized, but I figured we can live with it, thanks to the >> >> fastupdate feature. Fastupdate allows amortizing that cost over

Re: [HACKERS] [COMMITTERS] pgsql: Make it easy to detach completely from shared memory.

On 18 March 2014 11:59, Robert Haas wrote: > Make it easy to detach completely from shared memory. > > The new function dsm_detach_all() can be used either by postmaster > children that don't wish to take any risk of accidentally corrupting > shared memory; or by forked children of regular backend

Re: [HACKERS] plpgsql.warn_shadow

2014-03-18 13:23 GMT+01:00 Petr Jelinek : > > On 14/03/14 13:12, Simon Riggs wrote: > >> On 14 March 2014 11:10, Pavel Stehule wrote: >> >>> >>> >>> 2014-03-14 12:02 GMT+01:00 Marko Tiikkaja : >>> >>> On 3/14/14 10:56 AM, Simon Riggs wrote: > The patch looks fine, apart from some non-gu

Re: [HACKERS] plpgsql.warn_shadow

On 18 March 2014 12:23, Petr Jelinek wrote: > Agree that compile_errors dos not make sense, additional_errors and > additional_warnings seems better, maybe plpgsql.extra_warnings and > plpgsql.extra_errors? That sems better to me also. -- Simon Riggs http://www.2ndQuadrant.c

Re: [HACKERS] [COMMITTERS] pgsql: Make it easy to detach completely from shared memory.

On Tue, Mar 18, 2014 at 8:41 AM, Simon Riggs wrote: > On 18 March 2014 11:59, Robert Haas wrote: >> Make it easy to detach completely from shared memory. >> >> The new function dsm_detach_all() can be used either by postmaster >> children that don't wish to take any risk of accidentally corruptin

Re: [HACKERS] Is this a bug?

On Mon, Mar 17, 2014 at 10:27 PM, Michael Paquier wrote: > On Tue, Mar 18, 2014 at 10:24 AM, Fabrízio de Royes Mello > wrote: >> >> On Thu, Mar 13, 2014 at 10:22 AM, Robert Haas wrote: >>> Well, it's fairly harmless, but it might not be a bad idea to tighten that >>> up. >> The attached patch ti

[HACKERS] GSoC proposal. Index-only scans for GIST

Hello! Here is the text of my proposal which I've applied to GSoC. (and link http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/lubennikovaav/5629499534213120) Any suggestions and comments are welcome. *Project name* Support for index-only scans for GIST index *Brief review* C

Re: [HACKERS] pg_archivecleanup bug

On Tue, Mar 18, 2014 at 11:25:46AM +0530, Amit Kapila wrote: > On Thu, Mar 13, 2014 at 11:18 AM, Bruce Momjian wrote: > > > > I have developed the attached patch which fixes all cases where > > readdir() wasn't checking for errno, and cleaned up the syntax in other > > cases to be consistent. > >

[HACKERS] pg_basebackup --slot=SLOTNAME -X stream

Hi, Is there the explicit reason why --slot option that pg_receivexlog already has has not been added into pg_basebackup? If not, I'd like to support that option to eliminate the need to increase wal_keep_segments for pg_basebackup. Thought? Regards, -- Fujii Masao -- Sent via pgsql-hackers

Re: [HACKERS] pg_basebackup --slot=SLOTNAME -X stream

Hi, On 2014-03-18 22:25:05 +0900, Fujii Masao wrote: > Is there the explicit reason why --slot option that pg_receivexlog > already has has not been added into pg_basebackup? If not, > I'd like to support that option to eliminate the need to increase > wal_keep_segments for pg_basebackup. Thought?

Re: [HACKERS] pg_basebackup --slot=SLOTNAME -X stream

On 03/18/2014 03:25 PM, Fujii Masao wrote: Hi, Is there the explicit reason why --slot option that pg_receivexlog already has has not been added into pg_basebackup? If not, I'd like to support that option to eliminate the need to increase wal_keep_segments for pg_basebackup. Thought? That seem

Re: [HACKERS] pg_basebackup --slot=SLOTNAME -X stream

On Tue, Mar 18, 2014 at 2:32 PM, Heikki Linnakangas wrote: > On 03/18/2014 03:25 PM, Fujii Masao wrote: > >> Hi, >> >> Is there the explicit reason why --slot option that pg_receivexlog >> already has has not been added into pg_basebackup? If not, >> I'd like to support that option to eliminate t

Re: [HACKERS] pg_archivecleanup bug

Bruce Momjian writes: > Very good point. I have modified the patch to add this block in all > cases where it was missing. I started to wonder about the comment and > if the Mingw fix was released. Based on some research, I see this as > fixed in mingw-runtime-3.2, released 2003-10-10. That's p

Re: [HACKERS] [COMMITTERS] pgsql: Make it easy to detach completely from shared memory.

Robert Haas writes: > On Tue, Mar 18, 2014 at 8:41 AM, Simon Riggs wrote: >> Perhaps we should consider a parameter for PGSharedMemoryDetach() ? > Yeah, maybe. It seems like a possible modularity violation, because > the PGSharedMemory... stuff has heretofore not needed to know anything > about

Re: [HACKERS] pg_archivecleanup bug

On Tue, Mar 18, 2014 at 9:56 AM, Tom Lane wrote: > Bruce Momjian writes: >> Very good point. I have modified the patch to add this block in all >> cases where it was missing. I started to wonder about the comment and >> if the Mingw fix was released. Based on some research, I see this as >> fi

Re: [HACKERS] pg_archivecleanup bug

On Tue, Mar 18, 2014 at 10:03:46AM -0400, Robert Haas wrote: > On Tue, Mar 18, 2014 at 9:56 AM, Tom Lane wrote: > > Bruce Momjian writes: > >> Very good point. I have modified the patch to add this block in all > >> cases where it was missing. I started to wonder about the comment and > >> if t

Re: [HACKERS] [COMMITTERS] pgsql: Make it easy to detach completely from shared memory.

On 18 March 2014 13:51, Tom Lane wrote: > Robert Haas writes: >> On Tue, Mar 18, 2014 at 8:41 AM, Simon Riggs wrote: >>> Perhaps we should consider a parameter for PGSharedMemoryDetach() ? > >> Yeah, maybe. It seems like a possible modularity violation, because >> the PGSharedMemory... stuff ha

Re: [HACKERS] pg_basebackup --slot=SLOTNAME -X stream

On Tue, Mar 18, 2014 at 9:46 AM, Magnus Hagander wrote: > I started working on that at some point long ago, but never got far enough. > > Right now, it seems the right way to do that is to somehow reimplement it on > top of a "lightweight slot" that gets automatically destroyed when > pg_basebacku

Re: [HACKERS] pg_archivecleanup bug

Bruce Momjian escribió: > On Tue, Mar 18, 2014 at 10:03:46AM -0400, Robert Haas wrote: > > On Tue, Mar 18, 2014 at 9:56 AM, Tom Lane wrote: > > > Bruce Momjian writes: > > >> Very good point. I have modified the patch to add this block in all > > >> cases where it was missing. I started to wond

Re: [HACKERS] Portability issues in shm_mq

On Mon, Mar 17, 2014 at 11:09 PM, Tom Lane wrote: > Robert Haas writes: >> OK, I tried this out. The major complication that cropped up was >> that, if we make the length word always a Size but align the buffer to >> MAXIMUM_ALIGNOF, then the length word might get split if sizeof(Size) >> > MAXI

Re: [HACKERS] Portability issues in shm_mq

Robert Haas writes: > On Mon, Mar 17, 2014 at 11:09 PM, Tom Lane wrote: >> Would it get noticeably simpler or faster if you omitted support for >> the sizeof(Size) > MAXIMUM_ALIGNOF case? It looks like perhaps not, >> but if we were paying anything much I'd be tempted to just put in >> a static

Re: [HACKERS] GSoC proposal. Index-only scans for GIST

On Tue, Mar 18, 2014 at 9:12 AM, Anastasia Lubennikova wrote: > Support for index-only scans for GIST index This is a cool idea, if it can be made to work. > If the fetch() is specified by the developer, then using it, algorithm can > retrieve the data directly to output areas at this stage, wit

Re: [HACKERS] GSoC proposal. Index-only scans for GIST

Robert Haas writes: > Tom Lane previously proposed extending SP-GiST to support index-only > scans. You might find that discussing worth reading, or perhaps > consider it as an alternative if GiST doesn't work out: > http://www.postgresql.org/message-id/10839.1323885...@sss.pgh.pa.us That wasn't

Re: [HACKERS] Minimum supported version of Python?

On 03/17/2014 10:31 PM, Peter Eisentraut wrote: On Sun, 2014-03-16 at 22:34 -0400, Tom Lane wrote: As for 2.4 vs 2.5, I don't have a lot of faith that we're really supporting anything that's not represented in the buildfarm... There are many other features that the build farm doesn't test and

Re: [HACKERS] Portability issues in shm_mq

On Tue, Mar 18, 2014 at 10:44 AM, Tom Lane wrote: >> The thing I kind of like about this approach is that it makes the code >> fully independent of the relationship between MAXIMUM_ALIGNOF and >> sizeof(Size). > > Yeah. If it's not costing us much to support both cases, let's do so. OK, committe

Re: [HACKERS] pg_archivecleanup bug

On 18 March 2014 14:15, Alvaro Herrera wrote: > Bruce Momjian escribió: >> On Tue, Mar 18, 2014 at 10:03:46AM -0400, Robert Haas wrote: >> > On Tue, Mar 18, 2014 at 9:56 AM, Tom Lane wrote: >> > > Bruce Momjian writes: >> > >> Very good point. I have modified the patch to add this block in all

Re: [HACKERS] Minimum supported version of Python?

On 3/17/14, 10:55 PM, Tom Lane wrote: > It doesn't pass the regression tests. Do you need more of a bug report > than that? It does pass the tests for me and others. If you are seeing something different, then we need to see some details, like what platform, what version, what Python version, ho

Re: [HACKERS] pg_archivecleanup bug

On Tue, Mar 18, 2014 at 11:36 AM, Simon Riggs wrote: > Given the above, this means we've run for about 7 years without a > reported issue on this. If we are going to "make this better" by > actually having it throw errors in places that didn't throw errors > before, are we sure that is going to ma

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

On Tue, Mar 18, 2014 at 3:42 AM, Amit Kapila wrote: > The message for exclusive lock on tuple print the database information. It is true that it is possible to have a deadlock or lock chains that involves locks on other databases. In this example the table "test" is not in the database that just

Re: [HACKERS] Minimum supported version of Python?

On 3/17/14, 10:47 PM, Joshua D. Drake wrote: > We shouldn't be supporting anything the community doesn't support. > Python 2.3 is dead. We shouldn't actively support it nor suggest that we > could or should via the docs. The information that is available to me about this issue is lacking details,

Re: [HACKERS] pg_archivecleanup bug

On 18 March 2014 15:50, Robert Haas wrote: > On Tue, Mar 18, 2014 at 11:36 AM, Simon Riggs wrote: >> Given the above, this means we've run for about 7 years without a >> reported issue on this. If we are going to "make this better" by >> actually having it throw errors in places that didn't throw

Re: [HACKERS] Minimum supported version of Python?

On 3/18/14, 11:22 AM, Andrew Dunstan wrote: > Actually, if you run a buildfarm animal you have considerable control > over what it tests. I appreciate that. My problem here isn't time or ideas or coding, but lack of hardware resources. If I had hardware, I could set up tests for every build depe

Re: [HACKERS] Portability issues in shm_mq

All right. On Fri, Mar 14, 2014 at 4:43 PM, Tom Lane wrote: > Whilst setting up a buildfarm member on an old, now-spare Mac, I was > somewhat astonished to discover that contrib/test_shm_mq crashes thus: > TRAP: FailedAssertion("!(rb >= sizeof(uint64))", File: "shm_mq.c", Line: 429) > but only in

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

On Tue, Mar 18, 2014 at 11:59 AM, Greg Stark wrote: > On Tue, Mar 18, 2014 at 3:42 AM, Amit Kapila wrote: >> The message for exclusive lock on tuple print the database information. > > It is true that it is possible to have a deadlock or lock chains that > involves locks on other databases. > In

Re: [HACKERS] Portability issues in shm_mq

Robert Haas writes: > First, can you retest this with the latest code? Yeah, on it now. > If we want to inject some randomness into the test, which parameters > do we want to randomize and over what ranges? I think the message length is the only particularly interesting parameter. It'd be nice

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

On Tue, Mar 18, 2014 at 12:00 AM, Amit Kapila wrote: >> Therefore I think the only case worth considering here is when >> database/relation/TID are all defined. The other cases where there is >> partial information are dead code; and the case where there is nothing >> defined (such as the one in

Re: [HACKERS] pg_archivecleanup bug

On 13 March 2014 05:48, Bruce Momjian wrote: > On Mon, Dec 9, 2013 at 11:27:28AM -0500, Robert Haas wrote: >> On Thu, Dec 5, 2013 at 6:15 PM, Tom Lane wrote: >> > But the other usages seem to be in assorted utilities, which >> > will need to do it right for themselves. initdb.c's walkdir() seem

Re: [HACKERS] Minimum supported version of Python?

Peter Eisentraut-2 wrote > On 3/18/14, 11:22 AM, Andrew Dunstan wrote: >> Actually, if you run a buildfarm animal you have considerable control >> over what it tests. > > I appreciate that. My problem here isn't time or ideas or coding, but > lack of hardware resources. If I had hardware, I coul

Re: [HACKERS] Portability issues in shm_mq

I wrote: > Robert Haas writes: >> First, can you retest this with the latest code? > Yeah, on it now. Early returns not good: *** /Users/buildfarm/bf-data/HEAD/pgsql.93630/contrib/test_shm_mq/expected/test_shm_mq.out Tue Mar 18 12:00:18 2014 --- /Users/buildfarm/bf-data/HEAD/pgsql.93630

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

Robert Haas escribió: > On Tue, Mar 18, 2014 at 12:00 AM, Amit Kapila wrote: > >> Therefore I think the only case worth considering here is when > >> database/relation/TID are all defined. The other cases where there is > >> partial information are dead code; and the case where there is nothing >

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

Robert Haas writes: > Well, if we're back to one version of the message, and I'm glad we > are, can we go back to saying: > CONTEXT: while updating tuple (0,2) in relation "public"."foo" of > database "postgres" If I end up being the one who commits this, it's going to say while updating tuple

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

Tom Lane escribió: > Robert Haas writes: > > Well, if we're back to one version of the message, and I'm glad we > > are, can we go back to saying: > > > CONTEXT: while updating tuple (0,2) in relation "public"."foo" of > > database "postgres" > > If I end up being the one who commits this, it's

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

Alvaro Herrera writes: > Please see my reply to Robert. My proposal (in form of a patch) is > while operating on tuple (0,2) in table "foo": updating tuple > Would this work for you? It's pretty lousy from a readability standpoint, even in English; I shudder to think what it might come out as

Re: [HACKERS] Planner hints in Postgresql

On Mon, Mar 17, 2014 at 8:47 PM, Tom Lane wrote: > Claudio Freire writes: > > On Mon, Mar 17, 2014 at 7:01 PM, Jim Nasby wrote: > >> Even better would be if the planner could estimate how bad a plan will > >> become if we made assumptions that turn out to be wrong. > > > That's precisely what r

[HACKERS] json/jsonb/hstore operator precedence

Fwiw I'm finding myself repeatedly caught up by the operator precedence rules when experimenting with jsonb: stark=***# select segment->'id' as id from flight_segments where segment->>'marketing_airline_code' <> segment->>'operating_airline_code' ; ERROR: 42883: operator does not exist: text <>

Re: [HACKERS] GSoC proposal. Index-only scans for GIST

Alexander, Can you comment on the below proposal? I'd like your opinion on how difficult it will be. On 03/18/2014 06:12 AM, Anastasia Lubennikova wrote: > Hello! > Here is the text of my proposal which I've applied to GSoC. > (and link > http://www.google-melange.com/gsoc/proposal/public/google

Re: [HACKERS] Portability issues in shm_mq

I wrote: > Early returns not good: Also, these compiler messages are probably relevant: ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g

Re: [HACKERS] Portability issues in shm_mq

On Tue, Mar 18, 2014 at 1:16 PM, Tom Lane wrote: > I wrote: >> Early returns not good: > > Also, these compiler messages are probably relevant: > > ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute > -Wformat-secur

Re: [HACKERS] Portability issues in shm_mq

On 2014-03-18 13:31:47 -0400, Robert Haas wrote: > Well, I definitely forgot that. I'll count myself lucky if that's the > only problem. One minor thing missing, patch attached. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development,

Re: [HACKERS] pg_archivecleanup bug

On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote: > > While I am not a fan of backpatching, the fact we are ignoring errors in > > some critical cases seems the non-cosmetic parts should be backpatched. > > pg_resetxlog was not an offender here; its coding was sound. > > We shouldn't b

Re: [HACKERS] pg_archivecleanup bug

On 18 March 2014 18:01, Bruce Momjian wrote: > On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote: >> > While I am not a fan of backpatching, the fact we are ignoring errors in >> > some critical cases seems the non-cosmetic parts should be backpatched. >> >> pg_resetxlog was not an offen

Re: [HACKERS] Risk Estimation WAS: Planner hints in Postgresql

> On Mon, Mar 17, 2014 at 8:47 PM, Tom Lane wrote: >> Yeah. I would like to see the planner's cost estimates extended to >> include some sort of uncertainty estimate, whereupon risk-averse people >> could ask it to prefer low-uncertainty plans over high-uncertainty ones >> (the plans we typicall

Re: [HACKERS] pg_archivecleanup bug

On Tue, Mar 18, 2014 at 06:11:30PM +, Simon Riggs wrote: > On 18 March 2014 18:01, Bruce Momjian wrote: > > On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote: > >> > While I am not a fan of backpatching, the fact we are ignoring errors in > >> > some critical cases seems the non-cosm

Re: [HACKERS] Portability issues in shm_mq

and...@anarazel.de (Andres Freund) writes: > On 2014-03-18 13:31:47 -0400, Robert Haas wrote: >> Well, I definitely forgot that. I'll count myself lucky if that's the >> only problem. > One minor thing missing, patch attached. setup_dynamic_shared_memory needed some more hacking too. Committed.

Re: [HACKERS] Risk Estimation WAS: Planner hints in Postgresql

On Tue, Mar 18, 2014 at 11:43 PM, Josh Berkus wrote: > > > On Mon, Mar 17, 2014 at 8:47 PM, Tom Lane wrote: > >> Yeah. I would like to see the planner's cost estimates extended to > >> include some sort of uncertainty estimate, whereupon risk-averse people > >> could ask it to prefer low-uncert

Re: [HACKERS] Risk Estimation WAS: Planner hints in Postgresql

Atri Sharma writes: > One of the factors that leads to bad estimates is that the histogram of the > values of a column maintained by the planner gets old by time and the data > in the column changes. So, the histogram is no longer a quite accurate view > of the data and it leads to bad selectivity

Re: [HACKERS] Wiki Page Draft for upcoming release

On 03/17/2014 05:49 PM, Josh Berkus wrote: > All, > > https://wiki.postgresql.org/wiki/20140320UpdateIssues > > I'm sure my explanation of the data corruption issue is not correct, so > please fix it. Thanks! > Anyone? We're going public with this in 36 hours, so I'd love for it to actually b

Re: [HACKERS] pg_archivecleanup bug

Bruce Momjian escribió: > On Tue, Mar 18, 2014 at 06:11:30PM +, Simon Riggs wrote: > > On 18 March 2014 18:01, Bruce Momjian wrote: > > > On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote: > > >> > While I am not a fan of backpatching, the fact we are ignoring errors > > >> > in > >

Re: [HACKERS] pg_archivecleanup bug

On 18 March 2014 18:18, Bruce Momjian wrote: > On Tue, Mar 18, 2014 at 06:11:30PM +, Simon Riggs wrote: >> On 18 March 2014 18:01, Bruce Momjian wrote: >> > On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote: >> >> > While I am not a fan of backpatching, the fact we are ignoring erro

Re: [HACKERS] pg_archivecleanup bug

Simon Riggs escribió: > On 18 March 2014 18:18, Bruce Momjian wrote: > > On Tue, Mar 18, 2014 at 06:11:30PM +, Simon Riggs wrote: > >> Why make style changes at all? A patch with no style changes would > >> mean backpatch and HEAD versions would be the same. > > > > The old style had errno se

Re: [HACKERS] plpgsql.warn_shadow

On 18/03/14 13:43, Pavel Stehule wrote: 2014-03-18 13:23 GMT+01:00 Petr Jelinek > Agree that compile_errors dos not make sense, additional_errors and additional_warnings seems better, maybe plpgsql.extra_warnings and plpgsql.extra_errors? extra* sound

Re: [HACKERS] Portability issues in shm_mq

After the last round of changes, I can confirm that my original test with UTF8 locale works, and my HPPA box is happy too. We could still stand to improve the regression test though. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] Failure while inserting parent tuple to B-tree is not fun

On 02/06/2014 06:42 AM, Peter Geoghegan wrote: I'm not sure about this: *** _bt_findinsertloc(Relation rel, *** 675,680 --- 701,707 static void _bt_insertonpg(Relation rel, Buffer buf, + Buffer cbuf,

Re: [HACKERS] pg_archivecleanup bug

On 18 March 2014 18:55, Alvaro Herrera wrote: > That said, I don't find comma expression to be particularly "not > simple". Maybe, but we've not used it before anywhere in Postgres, so I don't see a reason to start now. Especially since C is not the native language of many people these days and

Re: [HACKERS] plpgsql.warn_shadow

2014-03-18 19:56 GMT+01:00 Petr Jelinek : > > On 18/03/14 13:43, Pavel Stehule wrote: > > 2014-03-18 13:23 GMT+01:00 Petr Jelinek > >> >> Agree that compile_errors dos not make sense, additional_errors and >> additional_warnings seems better, maybe plpgsql.extra_warnings and >> plpgsql.extra_err

Re: [HACKERS] Wiki Page Draft for upcoming release

On Tue, Mar 18, 2014 at 6:41 PM, Josh Berkus wrote: > > Anyone? We're going public with this in 36 hours, so I'd love for it to > actually be correct. I'll do a first pass now. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscriptio

Re: [HACKERS] GSoC proposal. Index-only scans for GIST

On Tue, Mar 18, 2014 at 5:12 PM, Anastasia Lubennikova < lubennikov...@gmail.com> wrote: > 2. gistget algorithm (several parts omitted): > > Check the key > gistindex_keytest() - does this index tuple satisfy the scan key(s)? > > Scan all items on the GiST index page and insert them into the queue

Re: [HACKERS] Portability issues in shm_mq

On Tue, Mar 18, 2014 at 12:15 PM, Tom Lane wrote: >> It's tempting to instead add one or more tests that we specifically >> choose to have values we think are likely to exercise >> platform-specific differences or otherwise find bugs - e.g. just add a >> second test where the queue size and messa

Re: [HACKERS] GSoC proposal. Index-only scans for GIST

Josh, Anastasia has already consulted to me in person. It is not big proposal. But for newbie who is not familiar with PostgreSQL code base and especially GiST it seems fair enough. With best regards, Alexander Korotkov. On Tue, Mar 18, 2014 at 9:16 PM, Josh Berkus wrote: > Alexander, > >

Re: [HACKERS] GSoC proposal. Index-only scans for GIST

On 03/18/2014 12:11 PM, Alexander Korotkov wrote: > Josh, > > Anastasia has already consulted to me in person. It is not big proposal. > But for newbie who is not familiar with PostgreSQL code base and especially > GiST it seems fair enough. > Thanks, that's what I wanted to know. -- Josh Berk

Re: [HACKERS] B-tree descend for insertion locking

On Tue, Mar 18, 2014 at 4:12 AM, Heikki Linnakangas wrote: > See attached patch. The new contract of _bt_getroot is a bit weird: it locks > the returned page in the requested lock-mode, shared or exclusive, if the > root page was also the leaf page. Otherwise it's locked in shared mode > regardles

Re: [HACKERS] pg_archivecleanup bug

On 03/18/2014 09:04 PM, Simon Riggs wrote: On 18 March 2014 18:55, Alvaro Herrera wrote: That said, I don't find comma expression to be particularly "not simple". Maybe, but we've not used it before anywhere in Postgres, so I don't see a reason to start now. Especially since C is not the nat

Re: [HACKERS] plpgsql.warn_shadow

On 18 March 2014 19:04, Pavel Stehule wrote: > I don't think so only "shadow" is good name for some check. Maybe > "shadow-variables-check" "shadowed-variables" would be a better name. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training

Re: [HACKERS] plpgsql.warn_shadow

2014-03-18 20:14 GMT+01:00 Simon Riggs : > On 18 March 2014 19:04, Pavel Stehule wrote: > > > I don't think so only "shadow" is good name for some check. Maybe > > "shadow-variables-check" > > "shadowed-variables" would be a better name. > +1 > > -- > Simon Riggs http://www.

Re: [HACKERS] plpgsql.warn_shadow

On 18/03/14 20:15, Pavel Stehule wrote: 2014-03-18 20:14 GMT+01:00 Simon Riggs >: On 18 March 2014 19:04, Pavel Stehule mailto:pavel.steh...@gmail.com>> wrote: > I don't think so only "shadow" is good name for some check. Maybe > "shadow-variables-ch

Re: [HACKERS] Wiki Page Draft for upcoming release

On Tue, Mar 18, 2014 at 7:05 PM, Greg Stark wrote: > I'll do a first pass now. I fixed the "Causes" section. I haven't touched the other sections which are pretty reasonable. It would be nice to have more suggestions for what people should do other than dump/restore. It would be nice to be able

Re: [HACKERS] Wiki Page Draft for upcoming release

On 2014-03-18 19:28:53 +, Greg Stark wrote: > It would be nice to be able to tell people that if they vacuum, then > reindex and check all their foreign key constraints then they should > be ok. I don't think so: http://archives.postgresql.org/message-id/20140317233919.GS16438%40awork2.anaraze

Re: [HACKERS] plpgsql.warn_shadow

Hello Tomorrow I'll do a review fast check +To aid the user in finding instances of simple but common problems before +they cause harm, PL/PgSQL provides a number of additional +checks. When enabled, depending on the configuration, they +can be used to emit either a WARNIN

Re: [HACKERS] plpgsql.warn_shadow

On 3/18/14, 7:56 PM, Petr Jelinek wrote: Ok, so I took the liberty of rewriting the patch so that it uses plpgsql.extra_warnings and plpgsql.extra_errors configuration variables with possible values "none", "all" and "shadow" ("none" being the default). Updated doc and regression tests to reflect

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

On Tue, Mar 18, 2014 at 12:53 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Please see my reply to Robert. My proposal (in form of a patch) is >> while operating on tuple (0,2) in table "foo": updating tuple >> Would this work for you? > > It's pretty lousy from a readability standpoint, eve

Re: [HACKERS] plpgsql.warn_shadow

On 18/03/14 20:36, Pavel Stehule wrote: +To aid the user in finding instances of simple but common problems before +they cause harm, PL/PgSQL provides a number of additional +checks. When enabled, depending on the configuration, they +can be used to emit either a WARNING

Re: [HACKERS] plpgsql.warn_shadow

2014-03-18 20:44 GMT+01:00 Petr Jelinek : > > On 18/03/14 20:36, Pavel Stehule wrote: > >> >> >> +To aid the user in finding instances of simple but common problems >> before >> +they cause harm, PL/PgSQL provides a number of >> additional >> +checks. When enabled, depending on the

Re: [HACKERS] Planner hints in Postgresql

On Tue, Mar 18, 2014 at 11:53 AM, Claudio Freire wrote: > > On Mon, Mar 17, 2014 at 8:47 PM, Tom Lane wrote: >> >> Claudio Freire writes: >> > On Mon, Mar 17, 2014 at 7:01 PM, Jim Nasby wrote: >> >> Even better would be if the planner could estimate how bad a plan will >> >> become if we made a

Re: [HACKERS] plpgsql.warn_shadow

On 18/03/14 20:45, Pavel Stehule wrote: 2014-03-18 20:44 GMT+01:00 Petr Jelinek >: On 18/03/14 20:36, Pavel Stehule wrote: +To aid the user in finding instances of simple but common problems before +they cause ha

  1   2   >