Re: [HACKERS] Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist

Hello 2013/11/19 Robert Haas > On Tue, Nov 19, 2013 at 3:53 AM, Dean Rasheed > wrote: > > 1). Keep the existing syntax: > > > > DROP TRIGGER [ IF EXISTS ] name ON table_name [ CASCADE | RESTRICT ]; > > > > but make it tolerate a non-existent table when "IF EXISTS" is specified. > > I don't lov

[HACKERS] new unicode table border styles for psql

Hello I wrote new styles for psql table borders. http://postgres.cz/wiki/Pretty_borders_in_psql This patch is simply and I am think so some styles can be interesting for final presentation. Do you think so this feature is generally interesting and should be in core? Regards Pavel

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

on 20 November 2013 23:44 Gavin Flower wrote: >On 20/11/13 23:43, Haribabu kommi wrote: >>I tried using of stat'ing in two directories, which is having a problem in >>windows. >>So modified old approach to detect limited errors. Updated patch attached. >>This will detect and throw an error in t

Re: [HACKERS] COPY table FROM STDIN doesn't show count tag

On 21 November 2013 10:13, Tom Lane wrote: > Amit Khandekar writes: > > Rather than a behaviour change, it is a bug that we are fixing. User > > already expects to see copy status printed, so as per user there would be > > no behaviour change. > > This is arrant nonsense. It's a behavior change

Re: [HACKERS] COPY table FROM STDIN doesn't show count tag

Amit Khandekar writes: > Rather than a behaviour change, it is a bug that we are fixing. User > already expects to see copy status printed, so as per user there would be > no behaviour change. This is arrant nonsense. It's a behavior change. You can't make it not that by claiming something abou

Re: [HACKERS] Extra functionality to createuser

On Wed, Nov 20, 2013 at 9:53 PM, Christopher Browne wrote: > Wait, that doesn't work if more than one role is added, as they get > merged together by the quoting. > > A somewhat ugly amount of quoting can be done at the shell level to > induce double quotes. > > $ createuser -g "\"test_rol'e_3\""

Re: [HACKERS] noob's query

On Thu, Nov 21, 2013 at 7:44 AM, Asit Mahato wrote: > Hi All, > > I would like to contribute to postgresql. But when i find a bug or issue > which i would like to fix then a lot of questions arise to me. Those are > below: > > 1)This one (the bug or issue in to do list i have selected) may be to h

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

On Thu, Nov 21, 2013 at 2:14 AM, Tom Lane wrote: > Peter Eisentraut writes: >> The argument elsewhere in this thread was that the reason for putting >> this in the connection options was so that you do *not* have to patch up >> every client to be able to use this functionality. If you have to ad

Re: [HACKERS] Easily reading debug_print_plan

Craig Ringer escribió: > On 11/20/2013 04:22 PM, Antonin Houska wrote: > > vim editor. The '%' shortcut can be used to jump between opening and > > closing brackets and thus skip smaller or bigger parts of the output. > > IMO, this output is primarily for hackers (as opposed to application > > deve

Re: [HACKERS] COPY table FROM STDIN doesn't show count tag

On 20 November 2013 18:11, Robert Haas wrote: > On Wed, Nov 20, 2013 at 4:56 AM, Amit Khandekar > wrote: > > So I think it is best to solve this as a different issue, and we should , > > for this commitfest, fix only COPY FROM. Once the \COPY existing issue > is > > solved, only then we can sta

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

On Wed, Nov 20, 2013 at 05:38:14PM -0500, Gurjeet Singh wrote: > On Wed, Nov 20, 2013 at 3:44 PM, Tom Lane wrote: > > > To my mind, the "create a socket and hope nobody else can get to it" > approach is exactly one of the main things we're trying to avoid here. > If you'll recall, aw

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

Tom Lane-2 wrote > We could conceivably say that we'll implicitly UNNEST() if the function > returns array, and not otherwise --- but that seems pretty inconsistent > and surprise-making to me. The use-cases for putting a scalar array returning function call into a TABLE construct, and NOT wantin

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

David Johnston writes: > Tom Lane-2 wrote >> We could conceivably say that we'll implicitly UNNEST() if the function >> returns array, and not otherwise --- but that seems pretty inconsistent >> and surprise-making to me. I'm not too sure what to do if a function >> returns setof array, either.

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

Tom Lane-2 wrote > Andrew Gierth < > andrew@.org > > writes: >> "Tom" == Tom Lane < > tgl@.pa > > writes: >> Tom> and this would result in producing the array elements as a table >> Tom> column. There is nothing in there about a function returning >> Tom> set. > >> In the spec, there is no

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

Robert Haas writes: > The original post on this thread includes this example, which mixes > SRFs and arrays by running the array through UNNEST: > select * from table(generate_series(10,20,5), unnest(array['fred','jim'])); > But if we think the spec calls for things to be implicitly unnested, >

Re: [HACKERS] [PATCH] Store Extension Options

On Thu, Nov 21, 2013 at 12:05 AM, Robert Haas wrote: > > On Wed, Nov 20, 2013 at 1:52 PM, Fabrízio de Royes Mello > wrote: > > The main goal of this patch is enable to an user the capability to store > > options > > (relations and attributes) related to extensions by using a fixed prefix > > call

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> and this would result in producing the array elements as a table > Tom> column. There is nothing in there about a function returning > Tom> set. > In the spec, there is no such thing as a function returning a set of > rows in the sense

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

Robert Haas wrote > select * from table(array(select generate_series(10,20,5)), > array['fred','jim']); Can we have our arrays and eat our functions too? (and is someone willing to bake such a complicated cake...) select * from table ( ARRAY | FUNCTION/SET [, ARRAY | FUNCTION/SET ]* ) The standa

[HACKERS] noob's query

Hi All, I would like to contribute to postgresql. But when i find a bug or issue which i would like to fix then a lot of questions arise to me. Those are below: 1)This one (the bug or issue in to do list i have selected) may be to hard to me. so from which one should i start? 2)which files are r

Re: [HACKERS] Can we trust fsync?

On 11/20/2013 03:45 PM, Craig Ringer wrote: I'm really concerned by this post on Linux's fsync and disk flush behaviour: http://milek.blogspot.com.au/2010/12/linux-osync-and-write-barriers.html and seeking opinions from folks here who've been deeply involved in write reliability work. The am

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

> "Tom" == Tom Lane writes: Tom> and this would result in producing the array elements as a table Tom> column. There is nothing in there about a function returning Tom> set. In the spec, there is no such thing as a function returning a set of rows in the sense that we use. Functions can

Re: [HACKERS] [PATCH] Store Extension Options

On Wed, Nov 20, 2013 at 1:52 PM, Fabrízio de Royes Mello wrote: > The main goal of this patch is enable to an user the capability to store > options > (relations and attributes) related to extensions by using a fixed prefix > called 'ext' in > the defined name. It's cant be useful for replication

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

On Wed, Nov 20, 2013 at 3:07 PM, Tom Lane wrote: > Andrew Gierth wrote: >> The spec syntax for table function calls, >> in , looks like TABLE(func(args...)) AS ... > >> This patch implements that, plus an extension: it allows multiple >> functions, TABLE(func1(...), func2(...), func3(...)) [WITH

Re: [HACKERS] Can we trust fsync?

Craig Ringer writes: > The amount of change in write reliablity behaviour in Linux across > kernel versions, file systems and storage abstraction layers is worrying > - different results for LVM vs !LVM, md vs !md, ext3 vs other, etc. Well, we pretty much *have to* trust fsync --- there's not a l

Re: [HACKERS] information schema parameter_default implementation

2013/11/20 Peter Eisentraut > Updated patch > I can't apply the patch; maybe I'm doing something wrong? $ git apply v2-0001-Implement-information_schema.parameters.parameter.patch v2-0001-Implement-information_schema.parameters.parameter.patch:49: trailing whitespace. CAST((ss.x).n A

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

On 2013-11-20 16:36:46 -0800, Christophe Pettus wrote: > > On Nov 20, 2013, at 3:57 PM, Andres Freund wrote: > > > On 2013-11-20 15:52:22 -0800, Josh Berkus wrote: > >> Oh, so this doesn't just happen when the base backup is first taken; > >> *any* time the standby is restarted, it can happen. (

Re: [HACKERS] Can we trust fsync?

> On 11/21/2013 07:45 AM, Craig Ringer wrote: >> I'm really concerned by this post on Linux's fsync and disk flush behaviour: >> >> http://milek.blogspot.com.au/2010/12/linux-osync-and-write-barriers.html > > ... and yes, I realise that's partly why we have the "fsync" param to > control differen

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

On Nov 20, 2013, at 3:57 PM, Andres Freund wrote: > On 2013-11-20 15:52:22 -0800, Josh Berkus wrote: >> Oh, so this doesn't just happen when the base backup is first taken; >> *any* time the standby is restarted, it can happen. (!!!) > > Yes. So, to be completely clear, any secondary running t

Re: [HACKERS] Can we trust fsync?

On 11/21/2013 07:45 AM, Craig Ringer wrote: > I'm really concerned by this post on Linux's fsync and disk flush behaviour: > > http://milek.blogspot.com.au/2010/12/linux-osync-and-write-barriers.html ... and yes, I realise that's partly why we have the "fsync" param to control different sync mode

Re: [HACKERS] Easily reading debug_print_plan

On 11/20/2013 10:36 PM, Tom Lane wrote: > Craig Ringer writes: >> I'm spending a lot of time staring at parse and plan trees at the >> moment, and I'm finding reading them rather cumbersome. > > Is there a particular reason you're doing that rather than looking at > EXPLAIN output? Only the latt

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

On 2013-11-20 15:52:22 -0800, Josh Berkus wrote: > Andres, > > > Everytime the server in HS mode allows connections ("consistent recovery > > state > > reached at ..." and "database system is ready to accept read only > > connections" in the log), the bug can be triggered. If there weren't too >

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

Andres, > Everytime the server in HS mode allows connections ("consistent recovery state > reached at ..." and "database system is ready to accept read only > connections" in the log), the bug can be triggered. If there weren't too > many transactions at that point, the problem won't occur until t

[HACKERS] Can we trust fsync?

I'm really concerned by this post on Linux's fsync and disk flush behaviour: http://milek.blogspot.com.au/2010/12/linux-osync-and-write-barriers.html and seeking opinions from folks here who've been deeply involved in write reliability work. The amount of change in write reliablity behaviour in

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

On 2013-11-20 10:48:41 -0800, Josh Berkus wrote: > > Presumably a replica created while all traffic was halted on the master > > would be clean, correct? This bug can only be triggered if there's > > heavy write load on the master, right? Kinda. It's unfortunately necessary to understand how HS w

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

With a pg_stat_statements.max of 1,000, on my system with the patch applied the additional amount of shared memory required is only 192KiB. That compares with about 1.17MiB for the same setting in master's version of pg_stat_statements. Surely with this huge reduction, we should revisit that defaul

Re: [HACKERS] Storage formats for JSON WAS: additional json functionality

On 2013-11-20 10:01:28 -0800, Josh Berkus wrote: > Greg, > > > Not being super familiar with either BSON our JSONB what advantages are we > > gaining from the difference? > > We have the JSONB/Hstore2 format *now*, and it can go into 9.4. That patch needs a *fair* amount of work though. Greetin

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

On 2013-11-20 15:44:03 -0500, Tom Lane wrote: > In practice, as long as psql and pg_dump and pg_upgrade can do it, I > think we've covered most of the interesting bases. I'd say vacuumdb/reindexdb should be added to that list. In my experience xid wraparound and corrupted system indexes are the mo

Re: [HACKERS] WITH ORDINALITY versus column definition lists

> "Tom" == Tom Lane writes: Tom> 1. Reinsert HEAD's prohibition against directly combining WITH Tom> ORDINALITY with a coldeflist (with a better error message and a Tom> HINT suggesting that you can get what you want via the TABLE Tom> syntax). That gets my vote. -- Andrew (irc:Rhodium

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

On Wed, Nov 20, 2013 at 3:44 PM, Tom Lane wrote: > > To my mind, the "create a socket and hope nobody else can get to it" > approach is exactly one of the main things we're trying to avoid here. > If you'll recall, awhile back we had a big discussion about how pg_upgrade > could positively guaran

Re: [HACKERS] additional json functionality

On Wed, Nov 20, 2013 at 12:50 PM, Greg Stark wrote: >> For one thing, our storage format is different from theirs (better, >> frankly), and as a result is not compliant with their "standard". > > Not being super familiar with either BSON our JSONB what advantages are we > gaining from the differen

Re: [HACKERS] Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

Robert Haas wrote: > Well, Tom and I are on opposite sides of this, I suppose.  I > prefer ERROR for everything other than the top-level transaction > commands, and see no benefit from opting for a wishy-washy > warning. +1 If the user issued a local command outside of a transaction there is an

Re: [HACKERS] [PATCH] Add transforms feature

On Wed, Nov 20, 2013 at 11:51 AM, Peter Eisentraut wrote: > This is a transition problem. Nobody is required to install the > transforms into their existing databases. They probably shouldn't. Sure, but that's like saying "nobody's required to use this behavior-changing GUC, so it's OK to have

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

On Wed, Nov 20, 2013 at 4:55 AM, Fujii Masao wrote: >> Not that I can see, but it's not very future-proof. If libpq changes >> its idea of what will provoke database-name expansion, this will again >> be broken. > > Yeah, I agree that we should make the logic of pg_isready more future-proof > in

Re: [HACKERS] Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

On Wed, Nov 20, 2013 at 04:31:12PM -0500, Robert Haas wrote: > On Wed, Nov 20, 2013 at 4:19 PM, Bruce Momjian wrote: > > On Wed, Nov 20, 2013 at 10:16:00AM -0500, Bruce Momjian wrote: > >> > > The attached patch changes ABORT from NOTICE to WARNING, and documents > >> > > that all other are errors

Re: [HACKERS] Autoconf 2.69 update

On Wed, Nov 20, 2013 at 4:31 AM, Oskari Saarenmaa wrote: > ISTM autoconf has been better with backwards compatibility lately. Maybe the > fatal error could be changed to a warning and/or the check for version == > 2.63 be replaced with a check for version >= 2.63? Without a strict > requirement f

Re: [HACKERS] Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

On Wed, Nov 20, 2013 at 4:19 PM, Bruce Momjian wrote: > On Wed, Nov 20, 2013 at 10:16:00AM -0500, Bruce Momjian wrote: >> > > The attached patch changes ABORT from NOTICE to WARNING, and documents >> > > that all other are errors. This "top-level" logic idea came from Robert >> > > Haas, and it h

Re: [HACKERS] Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

On Wed, Nov 20, 2013 at 10:16:00AM -0500, Bruce Momjian wrote: > > > The attached patch changes ABORT from NOTICE to WARNING, and documents > > > that all other are errors. This "top-level" logic idea came from Robert > > > Haas, and it has some level of consistency. > > > > This patch utterly fa

Re: [HACKERS] WITH ORDINALITY versus column definition lists

Tom Lane-2 wrote > David Johnston < > polobo@ > > writes: >> Just to clarify we are still allowing simple aliasing: > >> select * from generate_series(1,2) with ordinality as t(f1,f2); > > Right, that works (and is required by spec, I believe). It's what to > do with our column-definition-lis

Re: [HACKERS] WITH ORDINALITY versus column definition lists

David Johnston writes: > Just to clarify we are still allowing simple aliasing: > select * from generate_series(1,2) with ordinality as t(f1,f2); Right, that works (and is required by spec, I believe). It's what to do with our column-definition-list extension that's at issue. > Not sure if th

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

Peter Eisentraut writes: > The argument elsewhere in this thread was that the reason for putting > this in the connection options was so that you do *not* have to patch up > every client to be able to use this functionality. If you have to add > separate options everywhere, then you might as well

Re: [HACKERS] WITH ORDINALITY versus column definition lists

Tom Lane-2 wrote > David Johnston < > polobo@ > > writes: >> Tom Lane-2 wrote >>> It seems to me that we don't really want this behavior of the coldeflist >>> not including the ordinality column. It's operating as designed, maybe, >>> but it's unexpected and confusing. We could either >>> >>>

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

On Wed, Nov 20, 2013 at 3:32 PM, Peter Eisentraut wrote: > On 11/20/13, 3:24 PM, Robert Haas wrote: >> The point is that client applications should expose whether or not to >> set this function as a command-line switch separate from whatever they >> accept in terms of connection strings. So pg_du

Re: [HACKERS] Easily reading debug_print_plan

On Wed, Nov 20, 2013 at 9:36 AM, Tom Lane wrote: > We could in principle change to a different text representation for > stored rules. Compactness would be an issue if it were materially > bigger than the existing formatting, but offhand it seems like JSON > is morally equivalent to what we do no

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

On 11/20/13, 3:24 PM, Robert Haas wrote: > The point is that client applications should expose whether or not to > set this function as a command-line switch separate from whatever they > accept in terms of connection strings. So pg_dump should have a flag > called --standalone-server or something

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

On Wed, Nov 20, 2013 at 10:13 AM, Peter Eisentraut wrote: > On 11/14/13, 1:41 AM, Amit Kapila wrote: >>Security Concern >>- >>If a user can specify libpq connection options, he can now execute >> any file he wants by passing it as standalone_backend. >> >>

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

On 11/20/13, 10:48 AM, Tom Lane wrote: > Perhaps more to the point, I think this approach actually breaks one of > the principal good-thing-in-emergencies attributes of standalone mode, > namely being sure that nobody but you can connect. With this, you're > right back to having a race condition a

Re: [HACKERS] GIN improvements part2: fast scan

On Wed, Nov 20, 2013 at 3:06 AM, Alexander Korotkov wrote: > On Fri, Nov 15, 2013 at 11:19 AM, Alexander Korotkov > wrote: > >> On Fri, Nov 15, 2013 at 12:34 AM, Heikki Linnakangas < >> hlinnakan...@vmware.com> wrote: >> >>> On 14.11.2013 19:26, Alexander Korotkov wrote: >>> On Sun, Jun 30,

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

On 11/20/13, 11:31 AM, Stephen Frost wrote: > Couldn't that be an issue for people who have multiple major versions of > binaries installed? In particular, the "default" on the system for psql > might be 9.3 while the cluster you're trying to recover may be 9.2. Of > course, in that case you migh

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

Andrew Gierth wrote: > The spec syntax for table function calls, > in , looks like TABLE(func(args...)) AS ... > This patch implements that, plus an extension: it allows multiple > functions, TABLE(func1(...), func2(...), func3(...)) [WITH ORDINALITY] > and defines this as meaning that the funct

Re: [HACKERS] Replication Node Identifiers and crashsafe Apply Progress

On Tue, Nov 19, 2013 at 1:20 PM, Andres Freund wrote: > On 2013-11-19 12:47:29 -0500, Robert Haas wrote: >> On Tue, Nov 19, 2013 at 11:57 AM, Andres Freund >> wrote: >> > Agreed. As an alternative we could just have a single - probably longer >> > than NAMEDATALEN - string to identify replicatio

Re: [HACKERS] Dynamic Shared Memory stuff

On Wed, Nov 20, 2013 at 8:32 AM, Heikki Linnakangas wrote: > I'm trying to catch up on all of this dynamic shared memory stuff. A bunch > of random questions and complaints: > > What kind of usage are we trying to cater with the dynamic shared memory? Parallel sort, and then parallel other stuff.

Re: [HACKERS] WITH ORDINALITY versus column definition lists

David Johnston writes: > Tom Lane-2 wrote >> It seems to me that we don't really want this behavior of the coldeflist >> not including the ordinality column. It's operating as designed, maybe, >> but it's unexpected and confusing. We could either >> >> 1. Reinsert HEAD's prohibition against dir

[HACKERS] [PATCH] Store Extension Options

Hi all, The main goal of this patch is enable to an user the capability to store options (relations and attributes) related to extensions by using a fixed prefix called 'ext' in the defined name. It's cant be useful for replication solutions. So, with this patch we can do that: ALTER TABLE foo

Re: [HACKERS] additional json functionality

On 11/20/2013 01:36 PM, Tom Lane wrote: You'd have to make the data self-identifying (which I think was the plan already), and ensure that *every* function taking "json" could cope with both formats on input. The typmod could only be expected to be enforced when storing or explicitly casting t

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

On 11/20/2013 10:30 AM, Josh Berkus wrote: > Andrews, Kevin: Andres, that is. > > Presumably a replica created while all traffic was halted on the master > would be clean, correct? This bug can only be triggered if there's > heavy write load on the master, right? > Also, just to verify: If s

Re: [HACKERS] nested hstore patch

On Nov 20, 2013, at 6:19 AM, Peter Eisentraut wrote: > openjade:hstore.sgml:206:16:E: document type does not allow element > "VARLISTENTRY" here; assuming missing "VARIABLELIST" start-tag Thanks, I fixed this one. David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] Add CREATE support to event triggers

On Fri, Nov 8, 2013 at 10:33 AM, Alvaro Herrera wrote: > Hello, > > Attached you can find a very-much-WIP patch to add CREATE info support > for event triggers (normalized commands). This patch builds mainly on > two things: > > 1. Dimitri's "DDL rewrite" patch he submitted way back, in >http

Re: [HACKERS] additional json functionality

David Johnston writes: >> On 11/18/2013 06:13 AM, Peter Eisentraut wrote: >>> We could do something like SQL/XML and specify the level of "validity" >>> in a typmod, e.g., json(loose), json(strict), etc. > Three things: > 1) How would this work in the face of functions that erase typemod > infor

Re: [HACKERS] WITH ORDINALITY versus column definition lists

Tom Lane-2 wrote > It seems to me that we don't really want this behavior of the coldeflist > not including the ordinality column. It's operating as designed, maybe, > but it's unexpected and confusing. We could either > > 1. Reinsert HEAD's prohibition against directly combining WITH ORDINALITY

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

Andres Freund writes: > On 2013-11-20 11:08:33 -0500, Tom Lane wrote: >> Andres Freund writes: >>> Something like PQstartSingleUser(dsn) returning a established connection >>> seems better to me. >> That just pushes the problem up a level --- how are you going to tell >> psql, pg_dump, or other

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

Andrews, Kevin: Presumably a replica created while all traffic was halted on the master would be clean, correct? This bug can only be triggered if there's heavy write load on the master, right? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list

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

On 20/11/13 23:43, Haribabu kommi wrote: On 19 November 2013 19:12 Fujii Masao wrote: On Tue, Nov 19, 2013 at 9:14 PM, Haribabu kommi wrote: On 18 November 2013 23:30 Fujii Masao wrote: On Tue, Nov 19, 2013 at 12:01 AM, Haribabu kommi wrote: Thanks for newer version of the patch! I found t

Re: [HACKERS] additional json functionality

On 11/20/2013 12:50 PM, Greg Stark wrote: On Sat, Nov 16, 2013 at 12:32 AM, 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://b

Re: [HACKERS] Storage formats for JSON WAS: additional json functionality

Greg, > Not being super familiar with either BSON our JSONB what advantages are we > gaining from the difference? We have the JSONB/Hstore2 format *now*, and it can go into 9.4. This makes it inherently superior to any theoretical format. So any further discussion (below) is strictly academic,

Re: [HACKERS] additional json functionality

On 11/20/2013 04:52 AM, Robert Haas wrote: > I confess to being a bit perplexed by why we want hstore and json to > share a common binary format. hstore doesn't store hierarchical data; > json does. If we design a binary format for json, doesn't that just > obsolete store? Why go to a lot of tro

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

On 11/20/2013 01:55 AM, Fujii Masao wrote: > Yeah, I agree that we should make the logic of pg_isready more future-proof > in 9.4dev. One idea is to expose internal_ping() as a libpq function. Then, > instead of just calling PQpingParams(), we can do PQconnectStartParams(), > libpq-function-version

[HACKERS] WITH ORDINALITY versus column definition lists

Consider the following case of a function that requires a column definition list (example borrowed from the regression tests): create function array_to_set(anyarray) returns setof record as $$ select i AS "index", $1[i] AS "value" from generate_subscripts($1, 1) i $$ language sql strict immutabl

Re: [HACKERS] additional json functionality

On Sat, Nov 16, 2013 at 12:32 AM, 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 fro

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

On 06.11.2013 17:36, Alvaro Herrera wrote: Just for my own illumination, can someone explain this bit? + If a posting list is too large to store in-line in a key entry, a posting tree + is created. A posting tree is a B-tree structure, where the ItemPointer is + used as the key. At the leaf-leve

Re: [HACKERS] [PATCH] Add transforms feature

On 11/15/13, 11:04 AM, Dimitri Fontaine wrote: > - Documentation style seems to be to be different from the "man page" > or "reference docs" style that we use elsewhere, and is instead > deriving the general case from examples. Reads strange. Which specific section do you have in mind?

Re: [HACKERS] Logging WAL when updating hintbit

On Wed, Nov 20, 2013 at 9:19 PM, Dilip kumar wrote: > On 19 November 2013 22:19, Sawada Masahiko Wrote >>> > >> >> Thanks! >> I took it wrong. >> I think that there are quite a few difference amount of WAL. >> >> > Did you test about amount of WAL size in your patch? >> >> Not yet. I will do that.

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

On 2013-11-20 18:25:56 +0200, Heikki Linnakangas wrote: > Isn't it possible that the standby has already incorrectly set > HEAP_XMIN_INVALID hint bit on a page? The full page images generated by > VACUUM FREEZE will correct the damage, but if not, e.g. because > full_page_writes=off, strange things

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

On 2013-11-20 17:19:42 +0100, Andres Freund wrote: > > That just pushes the problem up a level --- how are you going to tell > > psql, pg_dump, or other programs that they should do that? > > An explicit parameter. A program imo explicitly needs to be aware that a > PQconnect() suddenly starts for

Re: [HACKERS] additional json functionality

Hannu Krosing-3 wrote > On 11/18/2013 06:49 PM, Josh Berkus wrote: >> On 11/18/2013 06:13 AM, Peter Eisentraut wrote: >>> On 11/15/13, 6:15 PM, Josh Berkus wrote: Thing is, I'm not particularly concerned about *Merlin's* specific use case, which there are ways around. What I am concerned

Re: [HACKERS] review: autovacuum_work_mem

On Mon, Nov 18, 2013 at 11:36 PM, Peter Geoghegan wrote: > Please reply to the original thread in future (even if the Reply-to > Message-ID is the same, I see this as a separate thread). > sorry about that, when i added "review" to the subject gmail removed the thread info. for reference the origi

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

* Tom Lane (t...@sss.pgh.pa.us) wrote: > I think we'd be better off trying to fix the security issue by > constraining what can be executed as a "standalone backend". Would > it work to insist that psql/pg_dump launch the program named postgres > from the same bin directory they're in, rather than

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

On 20.11.2013 17:06, Kevin Grittner wrote: Andres Freund wrote: On 2013-11-20 06:21:13 -0800, Kevin Grittner wrote: So as long as there are no open transactions or prepared transactions on the master which started before the release with the fix is applied, VACUUM FREEZE would be guar

Re: [HACKERS] Extra functionality to createuser

Wait, that doesn't work if more than one role is added, as they get merged together by the quoting. A somewhat ugly amount of quoting can be done at the shell level to induce double quotes. $ createuser -g "\"test_rol'e_3\"" usequoted3 I note that similar (with not quite identical behaviour) iss

Re: [HACKERS] additional json functionality

On 11/18/2013 06:49 PM, Josh Berkus wrote: > On 11/18/2013 06:13 AM, Peter Eisentraut wrote: >> On 11/15/13, 6:15 PM, Josh Berkus wrote: >>> Thing is, I'm not particularly concerned about *Merlin's* specific use >>> case, which there are ways around. What I am concerned about is that we >>> may hav

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

On 2013-11-20 11:08:33 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2013-11-20 10:48:20 -0500, Tom Lane wrote: > >> constraining what can be executed as a "standalone backend". Would > >> it work to insist that psql/pg_dump launch the program named postgres > >> from the same bin directo

Re: [HACKERS] Extra functionality to createuser

On Tue, Nov 19, 2013 at 11:54 PM, Amit Kapila wrote: > On further tests, I found inconsistency in behavior when some special > characters are used in role names. > > 1. Test for role name containing quotes > a. In psql, create a role containing quotes in role name. >create role amitk in ro

Re: [HACKERS] Handling GIN incomplete splits

On 19.11.2013 14:48, Michael Paquier wrote: Here is a review of the first three patches: 1) Further gin refactoring: make check passes (core tests and contrib tests). Code compiles without warnings. Committed. Then... About the patch... Even if I got little experience with code of gin, moving

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

Andres Freund writes: > On 2013-11-20 10:48:20 -0500, Tom Lane wrote: >> constraining what can be executed as a "standalone backend". Would >> it work to insist that psql/pg_dump launch the program named postgres >> from the same bin directory they're in, rather than accepting a path >> from the

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

On 2013-11-20 10:48:20 -0500, Tom Lane wrote: > constraining what can be executed as a "standalone backend". Would > it work to insist that psql/pg_dump launch the program named postgres > from the same bin directory they're in, rather than accepting a path > from the connection string? But why d

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

Peter Eisentraut writes: > I would consider sidestepping this entire issue by having the > stand-alone backend create a Unix-domain socket and have a client > connect to that in the normal way. Hmm. But that requires the "stand-alone backend" to take on at least some properties of a postmaster;

Re: [HACKERS] Autoconf 2.69 update

On 11/20/2013 10:28 AM, Magnus Hagander wrote: On Wed, Nov 20, 2013 at 3:58 PM, Andres Freund > wrote: On 2013-11-20 09:53:53 -0500, Tom Lane wrote: > As a rule, you're not supposed to bother including the configure output > script in a submitte

Re: [HACKERS] Autoconf 2.69 update

On Wed, Nov 20, 2013 at 3:58 PM, Andres Freund wrote: > > On 2013-11-20 09:53:53 -0500, Tom Lane wrote: > > As a rule, you're not supposed to bother including the configure output > > script in a submitted diff anyway. Certainly any committer worth his > > commit bit is going to ignore it and red

Re: [HACKERS] Shave a few instructions from child-process startup sequence

On 11/5/13, 2:47 AM, Gurjeet Singh wrote: > On Mon, Nov 4, 2013 at 12:20 AM, Tom Lane > wrote: > > But we're not buying much. A few instructions during postmaster > shutdown > is entirely negligible. > > > The patch is for ClosePostmasterPorts(), which is

Re: [HACKERS] Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

On Wed, Nov 20, 2013 at 10:04:22AM -0500, Tom Lane wrote: > Bruce Momjian writes: > > On Tue, Nov 19, 2013 at 10:21:47PM -0500, Tom Lane wrote: > >> My personal standpoint is that I don't care much whether these messages > >> are NOTICE or WARNING. What I'm not happy about is promoting cases that

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

On 2013-11-20 07:06:04 -0800, Kevin Grittner wrote: > > That's not a bad point. So the way to fix it would be: > > > > 1) Restart the standby to the new minor release, wait for catchup > > 2) Restart the primary (fast or smart) to the new minor release > > 3) Acquire enough new xids to make sure w

  1   2   >