Re: [HACKERS] New option for pg_basebackup, to specify a different directory for pg_xlog

on 15 November 2013 17:26 Magnus Hagander wrote: >On Fri, Nov 15, 2013 at 12:10 PM, Haribabu kommi >mailto:haribabu.ko...@huawei.com>> wrote: >On 14 November 2013 23:59 Fujii Masao wrote: >> On Thu, Nov 14, 2013 at 9:08 PM, Haribabu kommi >> mailto:haribabu.ko...@huawei.com>> wrote: >> > Please fi

Re: [HACKERS] New option for pg_basebackup, to specify a different directory for pg_xlog

On 15 November 2013 17:26 Magnus Hagander wrote: On Fri, Nov 15, 2013 at 12:10 PM, Haribabu kommi mailto:haribabu.ko...@huawei.com>> wrote: On 14 November 2013 23:59 Fujii Masao wrote: > On Thu, Nov 14, 2013 at 9:08 PM, Haribabu kommi > mailto:haribabu.ko...@huawei.com>> wrote: > > Please find att

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Fri, Nov 15, 2013 at 10:18 PM, Peter Eisentraut wrote: > On 11/14/13, 2:50 AM, Amit Kapila wrote: >> Find the rebased version attached with this mail. > > Doesn't build: > > openjade -wall -wno-unused-param -wno-empty -wfully-tagged -D . -D . -c > /usr/share/sgml/docbook/stylesheet/dsssl/modu

Re: [HACKERS] pre-commit triggers

On 11/15/2013 09:07 PM, Peter Eisentraut wrote: On Fri, 2013-11-15 at 13:01 -0500, Andrew Dunstan wrote: Attached is a patch to provide a new event trigger that will fire on transaction commit. xact.c: In function ‘CommitTransaction’: xact.c:1835:3: warning: implicit declaration of function ‘

Re: [HACKERS] pre-commit triggers

On Fri, 2013-11-15 at 13:01 -0500, Andrew Dunstan wrote: > Attached is a patch to provide a new event trigger that will fire on > transaction commit. xact.c: In function ‘CommitTransaction’: xact.c:1835:3: warning: implicit declaration of function ‘PreCommitTriggersFire’ [-Wimplicit-function-dec

Re: [HACKERS] -d option for pg_isready is broken

On Wed, Nov 13, 2013 at 9:37 PM, Josh Berkus wrote: > > handyrep@john:~/handyrep$ pg_isready --version > pg_isready (PostgreSQL) 9.3.1 > > handyrep@john:~/handyrep$ pg_isready -h john -p 5432 -U postgres -d > postgres -q > pg_isready: missing "=" after "postgres" in connection info string > > han

Re: [HACKERS] review: autovacuum_work_mem

On Sun, Oct 20, 2013 at 7:21 AM, Magnus Hagander wrote: > On Sun, Oct 20, 2013 at 2:22 AM, Peter Geoghegan wrote: >> It seemed neater to me to create a new flag, so that in principle any >> vacuum() code path can request autovacuum_work_mem, rather than having >> lazyvacuum.c code call IsAutoVac

Re: [HACKERS] The number of character limitation of custom script on pgbench

Sawada Masahiko writes: > I attached the patch which solves this problem, and have submitted to CF3. > I changed how to get the SQL from custom script file. This needed a bit of work: - Use of strncat didn't seem particularly safe, or efficient. I changed it to explicitly account for space cons

Re: [HACKERS] additional json functionality

On 11/15/2013 07:32 PM, Josh Berkus wrote: On 11/15/2013 04:00 PM, David Johnston wrote: Looking at this a different way: could we just implement BSON and leave json alone? http://bsonspec.org/ In short? No. For one thing, our storage format is different from theirs (better, frankly), and a

Re: [HACKERS] additional json functionality

On 11/15/2013 04:00 PM, David Johnston wrote: > Looking at this a different way: could we just implement BSON and leave json > alone? > > http://bsonspec.org/ In short? No. For one thing, our storage format is different from theirs (better, frankly), and as a result is not compliant with their

Re: [HACKERS] additional json functionality

Looking at this a different way: could we just implement BSON and leave json alone? http://bsonspec.org/ David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/additional-json-functionality-tp5777975p5778656.html Sent from the PostgreSQL - hackers mailing list arc

Re: [HACKERS] additional json functionality

Josh Berkus wrote > On 11/15/2013 02:59 PM, Merlin Moncure wrote: >> On Fri, Nov 15, 2013 at 4:31 PM, Hannu Krosing < > hannu@ > > wrote: >> I think you may be on to something here. This might also be a way >> opt-in to fast(er) serialization (upthread it was noted this is >> unimportant; I'm s

Re: [HACKERS] strncpy is not a safe version of strcpy

On Sat, Nov 16, 2013 at 4:09 AM, Alvaro Herrera wrote: > David Rowley escribió: > > On Fri, Nov 15, 2013 at 12:33 PM, Tomas Vondra wrote: > > > > Be careful with 'Name' data type - it's not just a simple string > buffer. > > > AFAIK it needs to work with hashing etc. so the zeroing is actually >

Re: [HACKERS] Improve code in tidbitmap.c

"Etsuro Fujita" writes: > I'd like to do the complementary explanation of this. > In tbm_union_page() and tbm_intersect_page() in tidbitmap.c, WORDS_PER_PAGE > is used in the scan of a lossy chunk, instead of WORDS_PER_CHUNK, where > these macros are defined as: > /* number of active words for an

Re: [HACKERS] Extra functionality to createuser

On Fri, Nov 15, 2013 at 3:14 PM, Peter Eisentraut wrote: > On 11/14/13, 4:35 PM, Christopher Browne wrote:> On Thu, Nov 14, 2013 at > 5:41 AM, Sameer Thakur wrote: >>> So i think -g option is failing >> >> Right you are. >> >> I was missing a "g:" in the getopt_long() call. >> >> Attached is a re

Re: [HACKERS] autovacuum_work_mem

On Mon, Oct 21, 2013 at 6:44 AM, Magnus Hagander wrote: > +1. If changing at all, then maybe just "autovacuum_mem"? I would like to stick with autovacuum_work_mem - it reflects the fact that it's a setting shadowed by maintenance_work_mem, without being too verbose. -- Peter Geoghegan -- Sen

Re: [HACKERS] additional json functionality

On 11/15/2013 02:59 PM, Merlin Moncure wrote: > On Fri, Nov 15, 2013 at 4:31 PM, Hannu Krosing wrote: > I think you may be on to something here. This might also be a way > opt-in to fast(er) serialization (upthread it was noted this is > unimportant; I'm skeptical). I deeply feel that two types

Re: [HACKERS] pg_dump insert with column names speedup

David Rowley writes: > The tailing white space is fixed in the attached patch. Applied with minor cosmetic adjustments. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.o

Re: [HACKERS] additional json functionality

On Fri, Nov 15, 2013 at 4:31 PM, Hannu Krosing wrote: I think we need to take a *very* hard look at #3 before exploring #1 or #2: Haven't through it through yet but it may be possible to handle this in such a way that will be mostly transparent to the end user and may have oth

Re: [HACKERS] additional json functionality

On 11/15/2013 09:25 PM, Merlin Moncure wrote: > On Fri, Nov 15, 2013 at 1:51 PM, David E. Wheeler > wrote: >> On Nov 15, 2013, at 6:35 AM, Merlin Moncure wrote: >> >>> Here are the options on the table: >>> 1) convert existing json type to binary flavor (notwithstanding objections) >>> 2) mainta

Re: [HACKERS] Review:Patch: SSL: prefer server cipher order

On 11/15/2013 11:49 AM, Marko Kreen wrote: On Fri, Nov 15, 2013 at 11:16:25AM -0800, Adrian Klaver wrote: The description of the GUCs show up in the documentation but I am not seeing the GUCs themselves in postgresql.conf, so I could test no further. It is entirely possible I am missing a step a

Re: [HACKERS] additional json functionality

On Nov 15, 2013, at 2:02 PM, Andrew Dunstan wrote: > Yeah, it would be a total foot gun here I think. > > I've come to the conclusion that the only possible solution is to have a > separate type. That's a bit sad, but there it is. The upside is that this > will make the work Teodor has mention

Re: [HACKERS] additional json functionality

On 11/15/2013 04:53 PM, Tom Lane wrote: "k...@rice.edu" writes: On Fri, Nov 15, 2013 at 01:18:22PM -0800, Josh Berkus wrote: I believe this was a danger we recognized when we added the JSON type, including the possibility that a future binary type might need to be a separate type due to compa

Re: [HACKERS] additional json functionality

"k...@rice.edu" writes: > On Fri, Nov 15, 2013 at 01:18:22PM -0800, Josh Berkus wrote: >> I believe this was a danger we recognized when we added the JSON type, >> including the possibility that a future binary type might need to be a >> separate type due to compatibility issues. The only sad thi

Re: [HACKERS] additional json functionality

On Fri, Nov 15, 2013 at 01:18:22PM -0800, Josh Berkus wrote: > > I believe this was a danger we recognized when we added the JSON type, > including the possibility that a future binary type might need to be a > separate type due to compatibility issues. The only sad thing is the > naming; it woul

Re: [HACKERS] additional json functionality

Merlin Moncure-2 wrote >> I don't want to have two types, but I think I'd probably rather have two >> clean types than this. I can't imagine it being remotely acceptable to >> have >> behaviour depend in whether or not something was ever stored, which is >> what >> this looks like. > > Well, maybe

Re: [HACKERS] additional json functionality

On 11/15/2013 01:12 PM, David E. Wheeler wrote: > On Nov 15, 2013, at 12:37 PM, Andrew Dunstan wrote: > >> It's making my head hurt, to be honest, and it sounds like a recipe for >> years and years of inconsistencies and bugs. >> >> I don't want to have two types, but I think I'd probably rather

Re: [HACKERS] additional json functionality

On Nov 15, 2013, at 12:37 PM, Andrew Dunstan wrote: > It's making my head hurt, to be honest, and it sounds like a recipe for years > and years of inconsistencies and bugs. > > I don't want to have two types, but I think I'd probably rather have two > clean types than this. I can't imagine it

Re: [HACKERS] Turning recovery.conf into GUCs

On 11/15/2013 06:38 AM, Jaime Casanova wrote: >> > Please check for compiler warnings in pg_basebackup: >> > >> > pg_basebackup.c:1109:1: warning: ‘escapeConnectionParameter’ defined but >> > not used [-Wunused-function] >> > pg_basebackup.c:1168:1: warning: ‘escape_quotes’ defined but not used >

Re: [HACKERS] postgres_fdw, remote triggers and schemas

On 15 November 2013 21:03, Tom Lane wrote: > Thom Brown writes: >> Is this unintended, or is it something users should fix themselves by >> being explicit about relation schemas in trigger functions? Should >> the schema search path instead pick up whatever the default would be >> for the user b

Re: [HACKERS] pg_dump insert with column names speedup

On Sat, Nov 16, 2013 at 9:04 AM, Peter Eisentraut wrote: > src/bin/pg_dump/pg_dump.c:1604: trailing whitespace. > + staticStmt = createPQExpBuffer(); > src/bin/pg_dump/pg_dump.c:1612: trailing whitespace. > + else > src/bin/pg_dump/pg_du

Re: [HACKERS] postgres_fdw, remote triggers and schemas

Thom Brown writes: > I've observed an issue whereby a parent table with a trigger that > redirects inserts to a child table fails to run the trigger > successfully if written to using a foreign table: That trigger is making unsafe assumptions about what search_path it's run under. If you don't w

Re: [HACKERS] Errors on missing pg_subtrans/ files with 9.3

On Fri, Nov 15, 2013 at 3:21 PM, Robert Haas wrote: > > I think what would help the most is if you could arrange to obtain a > stack backtrace at the point when the error is thrown. Maybe put a > long sleep call in just before the error happens, and when it gets > stuck there, attach gdb and run

Re: [HACKERS] additional json functionality

On 2013-11-15 12:54:53 -0800, Josh Berkus wrote: > On 11/15/2013 12:25 PM, Merlin Moncure wrote: > > Kinda yes, kinda no. Here's a rough sketch of what I'm thinking: > > > > *) 'json' type internally has a binary as well a text representation. > > The text representation is basically the current

Re: [HACKERS] additional json functionality

On Fri, Nov 15, 2013 at 2:54 PM, Josh Berkus wrote: > On 11/15/2013 12:25 PM, Merlin Moncure wrote: >> Kinda yes, kinda no. Here's a rough sketch of what I'm thinking: >> >> *) 'json' type internally has a binary as well a text representation. >> The text representation is basically the current t

Re: [HACKERS] additional json functionality

On 11/15/2013 12:25 PM, Merlin Moncure wrote: > Kinda yes, kinda no. Here's a rough sketch of what I'm thinking: > > *) 'json' type internally has a binary as well a text representation. > The text representation is basically the current type behavior That's not at all workable. Users would b

Re: [HACKERS] additional json functionality

On Fri, Nov 15, 2013 at 2:37 PM, Andrew Dunstan wrote: > > On 11/15/2013 03:25 PM, Merlin Moncure wrote: >> >> On Fri, Nov 15, 2013 at 1:51 PM, David E. Wheeler >> wrote: >>> >>> On Nov 15, 2013, at 6:35 AM, Merlin Moncure wrote: >>> Here are the options on the table: 1) convert existi

[HACKERS] postgres_fdw, remote triggers and schemas

Hi, I've observed an issue whereby a parent table with a trigger that redirects inserts to a child table fails to run the trigger successfully if written to using a foreign table: Example: Database 1: CREATE TABLE parent (id int, content text); CREATE TABLE child () INHERITS (parent); CREATE

Re: [HACKERS] additional json functionality

On 11/15/2013 03:25 PM, Merlin Moncure wrote: On Fri, Nov 15, 2013 at 1:51 PM, David E. Wheeler wrote: On Nov 15, 2013, at 6:35 AM, Merlin Moncure wrote: Here are the options on the table: 1) convert existing json type to binary flavor (notwithstanding objections) 2) maintain side by side t

Re: [HACKERS] additional json functionality

On Fri, Nov 15, 2013 at 1:51 PM, David E. Wheeler wrote: > On Nov 15, 2013, at 6:35 AM, Merlin Moncure wrote: > >> Here are the options on the table: >> 1) convert existing json type to binary flavor (notwithstanding objections) >> 2) maintain side by side types, one representing binary, one text

Re: [HACKERS] Errors on missing pg_subtrans/ files with 9.3

On Wed, Nov 13, 2013 at 12:29 PM, J Smith wrote: > Looks like we got another set of errors overnight. Here's the log file > from the errors. (Log file scrubbed slightly to remove private data, > but still representative of the problem I believe.) > > Nov 13 05:34:34 dev postgres[6084]: [4-1] user=

Re: [HACKERS] Extra functionality to createuser

On 11/14/13, 4:35 PM, Christopher Browne wrote:> On Thu, Nov 14, 2013 at 5:41 AM, Sameer Thakur wrote: >> So i think -g option is failing > > Right you are. > > I was missing a "g:" in the getopt_long() call. > > Attached is a revised patch that handles that. > src/bin/scripts/createuser.c:117: i

Re: [HACKERS] GIN improvements part2: fast scan

On Sat, Nov 16, 2013 at 12:10 AM, Peter Eisentraut wrote: > On 11/14/13, 12:26 PM, Alexander Korotkov wrote: > > Revised version of patch is attached. > > This doesn't build: > > ginget.c: In function ‘scanPage’: > ginget.c:1108:2: warning: implicit declaration of function > ‘GinDataLeafPageGetPo

Re: [HACKERS] GIN improvements part2: fast scan

On 11/14/13, 12:26 PM, Alexander Korotkov wrote: > Revised version of patch is attached. This doesn't build: ginget.c: In function ‘scanPage’: ginget.c:1108:2: warning: implicit declaration of function ‘GinDataLeafPageGetPostingListEnd’ [-Wimplicit-function-declaration] ginget.c:1108:9: warning:

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

Hi, On 2013-11-15 11:40:17 +0900, Michael Paquier wrote: > - 20131114_3_reindex_concurrently.patch, providing the core feature. > Patch 3 needs to have patch 2 applied first. Regression tests, > isolation tests and documentation are included with the patch. Have you addressed my concurrency conce

Re: [HACKERS] Wait free LW_SHARED acquisition - v0.2

On 2013-11-15 20:47:26 +0100, Andres Freund wrote: > Hi, > > On 2013-09-27 00:55:45 +0200, Andres Freund wrote: > > So what's todo? The file header tells us: > > * - revive pure-spinlock implementation > > * - abstract away atomic ops, we really only need a few. > > * - CAS > > * - LOCK XA

Re: [HACKERS] Minmax indexes

On Fri, Nov 8, 2013 at 12:11 PM, Alvaro Herrera wrote: > Erik Rijkers wrote: > > On Thu, September 26, 2013 00:34, Erik Rijkers wrote: > > > On Wed, September 25, 2013 22:34, Alvaro Herrera wrote: > > > > > >> [minmax-5.patch] > > > > > > I have the impression it's not quite working correctly. > >

Re: [HACKERS] pg_dump insert with column names speedup

src/bin/pg_dump/pg_dump.c:1604: trailing whitespace. + staticStmt = createPQExpBuffer(); src/bin/pg_dump/pg_dump.c:1612: trailing whitespace. + else src/bin/pg_dump/pg_dump.c:1614: trailing whitespace. +

Re: [HACKERS] additional json functionality

On Nov 15, 2013, at 6:35 AM, Merlin Moncure wrote: > Here are the options on the table: > 1) convert existing json type to binary flavor (notwithstanding objections) > 2) maintain side by side types, one representing binary, one text. > unfortunately, i think the text one must get the name 'json'

Re: [HACKERS] Review:Patch: SSL: prefer server cipher order

On Fri, Nov 15, 2013 at 11:16:25AM -0800, Adrian Klaver wrote: > The description of the GUCs show up in the documentation but I am > not seeing the GUCs themselves in postgresql.conf, so I could test > no further. It is entirely possible I am missing a step and would > appreciate enlightenment. So

Re: [HACKERS] GIN improvements part2: fast scan

On Fri, Nov 15, 2013 at 11:39 PM, Rod Taylor wrote: > > > > On Fri, Nov 15, 2013 at 2:26 PM, Alexander Korotkov > wrote: > >> On Fri, Nov 15, 2013 at 11:18 PM, Rod Taylor wrote: >> >>> 2%. >>> >>> It's essentially sentence fragments from 1 to 5 words in length. I >>> wasn't expecting it to be mu

Re: [HACKERS] GIN improvements part2: fast scan

On Fri, Nov 15, 2013 at 2:26 PM, Alexander Korotkov wrote: > On Fri, Nov 15, 2013 at 11:18 PM, Rod Taylor wrote: > >> 2%. >> >> It's essentially sentence fragments from 1 to 5 words in length. I wasn't >> expecting it to be much smaller. >> >> 10 recent value selections: >> >> white vinegar redu

Re: [HACKERS] GIN improvements part2: fast scan

On Fri, Nov 15, 2013 at 11:18 PM, Rod Taylor wrote: > 2%. > > It's essentially sentence fragments from 1 to 5 words in length. I wasn't > expecting it to be much smaller. > > 10 recent value selections: > > white vinegar reduce color running > vinegar cure uti > cane vinegar acidity depends pa

Re: [HACKERS] Cannot allocate memory

"Heng Zhi Feng (zh...@hsr.ch)" wrote: > Virtual Machine – Ubuntu 13.10 > 1.92GB Memory > 2 Parallel Processors > work_mem = 11MB > shared_buffers = 448MB > max_connections = 80 > 2013-11-15 11:02:35 CET LOG:  could not fork autovacuum worker process: > Cannot allocate memory > 2013-11-15 11:0

Re: [HACKERS] GIN improvements part2: fast scan

2%. It's essentially sentence fragments from 1 to 5 words in length. I wasn't expecting it to be much smaller. 10 recent value selections: white vinegar reduce color running vinegar cure uti cane vinegar acidity depends parameter how remedy fir clogged shower use vinegar sensitive skin hom

[HACKERS] Review:Patch: SSL: prefer server cipher order

First review of the above patch as listed in current CommitFest as well as subsequent ECDH patch in the thread below: http://www.postgresql.org/message-id/1383782378-7342-1-git-send-email-mark...@gmail.com Platform OpenSuse 12.2 Both patches applied cleanly. Configured: ./configure --with-py

Re: [HACKERS] Sequence Access Method WIP

On 15 November 2013 15:48, Peter Eisentraut wrote: > On 11/14/13, 3:10 PM, Simon Riggs wrote: >> On 16 January 2013 00:40, Simon Riggs wrote: >> >>> SeqAm allows you to specify a plugin that alters the behaviour for >>> sequence allocation and resetting, aimed specifically at clustering >>> syste

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 11/14/13, 9:40 PM, Michael Paquier wrote: > Hi all, > > Please find attached updated patches for the support of REINDEX > CONCURRENTLY, renamed 2.0 for the occasion: > - 20131114_1_index_drop_comments.patch, patch that updates some > comments in index_drop. This updates only a couple of comment

Re: [HACKERS] Sequence Access Method WIP

On 11/14/13, 3:10 PM, Simon Riggs wrote: > On 16 January 2013 00:40, Simon Riggs wrote: > >> SeqAm allows you to specify a plugin that alters the behaviour for >> sequence allocation and resetting, aimed specifically at clustering >> systems. >> >> New command options on end of statement allow sy

Re: [HACKERS] Sequence Access Method WIP

On 15 November 2013 15:08, Heikki Linnakangas wrote: > I wonder if the level of abstraction is right. That is the big question and not something to shy away from. What is presented is not the first thought, by a long way. Andres' contribution to the patch is mainly around this point, so the seq

Re: [HACKERS] GIN improvements part 1: additional information

On Fri, Nov 15, 2013 at 9:56 PM, Peter Eisentraut wrote: > On 11/15/13, 12:24 PM, Alexander Korotkov wrote: > > On Fri, Nov 15, 2013 at 8:58 PM, Peter Eisentraut > > wrote: > > > > On 11/14/13, 6:00 AM, Alexander Korotkov wrote: > > > Sorry, I posted buggy version

Re: [HACKERS] Sequence Access Method WIP

On 2013-11-15 20:08:30 +0200, Heikki Linnakangas wrote: > It's pretty hard to review the this without seeing the "other" > implementation you're envisioning to use this API. But I'll try: We've written a distributed sequence implementation against it, so it works at least for that use case. While

Re: [HACKERS] trivial one-off memory leak in guc-file.l ParseConfigFile

On 22.09.2013 22:40, didier wrote: Hi fix a small memory leak in guc-file.l ParseConfigFile AbsoluteConfigLocation() return a strdup string but it's never free or referenced outside ParseConfigFile Courtesy Valgrind and Noah Misch MEMPOOL work. I spotted and fixed this some time ago while fi

Re: [HACKERS] Sequence Access Method WIP

On 14.11.2013 22:10, Simon Riggs wrote: On 16 January 2013 00:40, Simon Riggs wrote: SeqAm allows you to specify a plugin that alters the behaviour for sequence allocation and resetting, aimed specifically at clustering systems. New command options on end of statement allow syntax CREATE S

[HACKERS] pre-commit triggers

Attached is a patch to provide a new event trigger that will fire on transaction commit. I have tried to make certain that it fires at a sufficiently early stage in the commit process that some of the evils mentioned in previous discussions on this topic aren't relevant. The triggers don't f

Re: [HACKERS] GIN improvements part 1: additional information

On 11/15/13, 12:24 PM, Alexander Korotkov wrote: > On Fri, Nov 15, 2013 at 8:58 PM, Peter Eisentraut > wrote: > > On 11/14/13, 6:00 AM, Alexander Korotkov wrote: > > Sorry, I posted buggy version of patch. Attached version is correct. > > This patch crashes th

Re: [HACKERS] GIN improvements part2: fast scan

On Fri, Nov 15, 2013 at 6:57 PM, Rod Taylor wrote: > I tried again this morning using gin-packed-postinglists-16.patch and > gin-fast-scan.6.patch. No crashes. > > It is about a 0.1% random sample of production data (10,000,000 records) > with the below structure. Pg was compiled with debug enabl

Re: [HACKERS] writable FDWs / update targets confusion

Albe Laurenz writes: > Tom, could you show us a rope if there is one? What is it you actually need to fetch? IIRC, the idea was that most FDWs would do the equivalent of fetching the primary-key columns to use in an update. If that's what you need, then AddForeignUpdateTargets should identify t

Re: [HACKERS] Transaction-lifespan memory leak with plpgsql DO blocks

On 2013-11-14 22:23, Tom Lane wrote: So after some experimentation I came up with version 2, attached. Thanks for looking into this! I currently do not have access to a setup to try the patch. A colleague of mine will look into this next week. Thanks again, Yeb Havinga -- Sent via pgsql-h

Re: [HACKERS] GIN improvements part 1: additional information

On Fri, Nov 15, 2013 at 8:58 PM, Peter Eisentraut wrote: > On 11/14/13, 6:00 AM, Alexander Korotkov wrote: > > Sorry, I posted buggy version of patch. Attached version is correct. > > This patch crashes the hstore the pg_trgm regression tests. > What exact version did you try 14 or 16? If it was

Re: [HACKERS] Optimize kernel readahead using buffer access strategy

On 11/14/13, 7:09 AM, KONDO Mitsumasa wrote: > I create a patch that is improvement of disk-read and OS file caches. It can > optimize kernel readahead parameter using buffer access strategy and > posix_fadvice() in various disk-read situations. Various compiler warnings: tablecmds.c: In function

Re: [HACKERS] GIN improvements part 1: additional information

On 11/14/13, 6:00 AM, Alexander Korotkov wrote: > Sorry, I posted buggy version of patch. Attached version is correct. This patch crashes the hstore the pg_trgm regression tests. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://

Re: [HACKERS] Storing pg_stat_statements query texts externally, pg_stat_statements in core

On 11/14/13, 3:17 AM, Peter Geoghegan wrote: > Attached patch allows pg_stat_statements to store arbitrarily long > query texts, using an external, transparently managed lookaside file. Compiler warnings with fortify settings: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-afte

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On 11/14/13, 2:50 AM, Amit Kapila wrote: > Find the rebased version attached with this mail. Doesn't build: openjade -wall -wno-unused-param -wno-empty -wfully-tagged -D . -D . -c /usr/share/sgml/docbook/stylesheet/dsssl/modular/catalog -d stylesheet.dsl -t sgml -i output-html -V html-index po

Re: [HACKERS] Minmax indexes (timings)

Erik Rijkers wrote: > Perhaps someone finds these timings useful. > '--enable-cassert' Assertions can really distort the timings, and not always equally for all code paths.  Any chance of re-running those tests without that? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise Pos

Re: [HACKERS] Minmax indexes (timings)

On 2013-11-15 17:11:46 +0100, Erik Rijkers wrote: > I've been messing with minmax indexes some more so here are some results of > that. > > Perhaps someone finds these timings useful. > > > Centos 5.7, 32 GB memory, 2 quadcores. > > '--prefix=/var/data1/pg_stuff/pg_installations/pgsql.minmax'

Re: [HACKERS] writable FDWs / update targets confusion

Tomas Vondra wrote: > I'm working on adding write support to one of my FDWs. Adding INSERT went > pretty fine, but when adding DELETE/UPDATE I got really confused about how > the update targets are supposed to work. > > My understanding of how it's supposed to work is this: > > (1) AddForeignUpd

Re: [HACKERS] SSL renegotiation

On 2013-11-15 10:58:19 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2013-11-15 10:43:23 -0500, Tom Lane wrote: > >> Another reason I'm not in a hurry is that the problem we're trying > >> to solve doesn't seem to be causing real-world trouble. So by > >> "awhile", I'm thinking "let's let

Re: [HACKERS] [PATCH] Add transforms feature

Hi, Peter Eisentraut writes: > Rebased patch. No changes except that merge conflicts were resolved, > and I had to add some Data::Dumper tweaks to the regression tests so > that the results came out in consistent order on different versions of > Perl. I just spent some time reading that patch,

Re: [HACKERS] SSL renegotiation

Andres Freund writes: > On 2013-11-15 10:43:23 -0500, Tom Lane wrote: >> Another reason I'm not in a hurry is that the problem we're trying >> to solve doesn't seem to be causing real-world trouble. So by >> "awhile", I'm thinking "let's let it get through 9.4 beta testing". > Well, there have b

Re: [HACKERS] strncpy is not a safe version of strcpy

Alvaro Herrera wrote: > Kevin Grittner escribió: >> That argument would be more persuasive if I could find any current >> usage of the namecpy() function anywhere in the source code. > > Well, its cousin namestrcpy is used in a lot of places.  That one uses a > regular C string as source; namecpy

Re: [HACKERS] SSL renegotiation

Alvaro Herrera writes: > So I committed this patch without backpatching anything. ... > ... should we wait longer for the new renegotiation code to > be more battle-tested? +1 to waiting awhile. I think if we don't see any problems in HEAD, then back-patching as-is would be the best solution. Th

Re: [HACKERS] SSL renegotiation

On 2013-11-15 10:43:23 -0500, Tom Lane wrote: > +1 to waiting awhile. I think if we don't see any problems in > HEAD, then back-patching as-is would be the best solution. > The other alternatives are essentially acknowledging that you're > back-patching something you're afraid isn't production rea

Re: [HACKERS] strncpy is not a safe version of strcpy

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Andres Freund writes: > > I didn't argue against s/strncpy/strlcpy/. That's clearly a sensible > > fix. > > I am arguing about introducing additional code and error messages about > > it, that need to be translated. And starting doing so in isolationtester

Re: [HACKERS] strncpy is not a safe version of strcpy

Kevin Grittner escribió: > Alvaro Herrera wrote: > > > This code should probably be using namecpy().  Note namecpy() > > doesn't memset() after strncpy() and has survived the test of > > time, which strongly suggests that the memset is indeed > > superfluous. > > That argument would be more pers

Re: [HACKERS] strncpy is not a safe version of strcpy

Alvaro Herrera wrote: > This code should probably be using namecpy().  Note namecpy() > doesn't memset() after strncpy() and has survived the test of > time, which strongly suggests that the memset is indeed > superfluous. That argument would be more persuasive if I could find any current usage

Re: [HACKERS] GIN improvements part2: fast scan

I tried again this morning using gin-packed-postinglists-16.patch and gin-fast-scan.6.patch. No crashes during index building. Pg was compiled with debug enabled in both cases. The data is a ~0.1% random sample of production data (10,000,000 records for the test) with the below structure. T

Re: [HACKERS] strncpy is not a safe version of strcpy

Andres Freund writes: > I didn't argue against s/strncpy/strlcpy/. That's clearly a sensible > fix. > I am arguing about introducing additional code and error messages about > it, that need to be translated. And starting doing so in isolationtester > of all places. I agree with Andres on this. C

Re: [HACKERS] Database disconnection and switch inside a single bgworker

Michael Paquier writes: > Currently, bgworkers offer the possibility to connect to a given > database using BackgroundWorkerInitializeConnection in bgworker.h, but > there is actually no way to disconnect from a given database inside > the same bgworker process. That's isomorphic to having a back

Re: [HACKERS] strncpy is not a safe version of strcpy

David Rowley escribió: > On Fri, Nov 15, 2013 at 12:33 PM, Tomas Vondra wrote: > > Be careful with 'Name' data type - it's not just a simple string buffer. > > AFAIK it needs to work with hashing etc. so the zeroing is actually needed > > here to make sure two values produce the same result. At l

Re: [HACKERS] Turning recovery.conf into GUCs

On Fri, Nov 15, 2013 at 11:38 PM, Jaime Casanova wrote: > those are functions that are no longer used but Josh considered they > could become useful before release. > i can put them inside #ifdef _NOT_USED_ decorations or just remove > them now and if/when we find some use for them re add them Why

Re: [HACKERS] strncpy is not a safe version of strcpy

On 2013-11-15 10:04:12 -0500, Stephen Frost wrote: > * Andres Freund (and...@2ndquadrant.com) wrote: > > Sure, there can be longer paths, but postgres don't support them. In a > > *myriad* of places. It's just not worth spending code on it. > > > > Just about any of the places that use MAXPGPATH ar

Re: [HACKERS] strncpy is not a safe version of strcpy

* Andres Freund (and...@2ndquadrant.com) wrote: > Sure, there can be longer paths, but postgres don't support them. In a > *myriad* of places. It's just not worth spending code on it. > > Just about any of the places that use MAXPGPATH are "vulnerable" or > produce confusing error messages if it's

Re: [HACKERS] strncpy is not a safe version of strcpy

On 2013-11-15 09:53:24 -0500, Stephen Frost wrote: > * Andres Freund (and...@2ndquadrant.com) wrote: > > FWIW, argv0 is pretty much guaranteed to be shorter than MAXPGPATH since > > MAXPGPATH is the longest a path can be, and argv[0] is either the > > executable's > > name (if executed via PATH) o

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

On Fri, Nov 15, 2013 at 6:06 AM, Dimitri Fontaine wrote: >> But: I very, very much agree with the other concerns around this. This >> should be a patch to fix single user mode, not one to make postgres into >> a single process database. It's not, and trying to make it by using >> single user mode

Re: [HACKERS] ERROR during end-of-xact/FATAL

On Wed, Nov 13, 2013 at 11:04 AM, Noah Misch wrote: >> So, in short, ERROR + ERROR*10 = PANIC, but FATAL + ERROR*10 = FATAL. >> That's bizarre. > > Quite so. > >> Given that that's where we are, promoting an ERROR during FATAL >> processing to PANIC doesn't seem like it's losing much; we're >> ess

Re: [HACKERS] Turning recovery.conf into GUCs

On 11/13/13, 12:17 AM, Jaime Casanova wrote: > I have rebased Michael Paquier's patch and did a few changes: > > * changed standby.enabled filename to recovery.trigger > * make archive_command a SIGHUP parameter again > * make restore_command a SIGHUP parameter > * rename restore_command variable

Re: [HACKERS] strncpy is not a safe version of strcpy

* Andres Freund (and...@2ndquadrant.com) wrote: > FWIW, argv0 is pretty much guaranteed to be shorter than MAXPGPATH since > MAXPGPATH is the longest a path can be, and argv[0] is either the executable's > name (if executed via PATH) or the path to the executable. Err, it's the longest that *we* t

Re: [HACKERS] additional json functionality

On Thu, Nov 14, 2013 at 1:54 PM, Hannu Krosing wrote: > On 11/14/2013 08:17 PM, Merlin Moncure wrote: >> On Thu, Nov 14, 2013 at 11:34 AM, David E. Wheeler >> wrote: >>> On Nov 14, 2013, at 7:07 AM, Merlin Moncure wrote: >>> This is exactly what needs to be done, full stop (how about: hstor

Re: [HACKERS] Logging WAL when updating hintbit

On 11/14/13, 1:02 AM, Sawada Masahiko wrote: > I attached patch adds new wal_level 'all'. Compiler warning: pg_controldata.c: In function ‘wal_level_str’: pg_controldata.c:72:2: warning: enumeration value ‘WAL_LEVEL_ALL’ not handled in switch [-Wswitch] -- Sent via pgsql-hackers mailing lis

  1   2   >