Re: [HACKERS] UNION ALL on partitioned tables won't use indices.

On Thu, Oct 24, 2013 at 07:39:53PM +0900, Kyotaro HORIGUCHI wrote: > 1. Observed symptom > > As you know, UNION ALL accompanied with ORDER BY uses indexes if > available. > So do simple queries on partitioned (inheritance) tables. > Nevertheless, UNION ALL on partitioned tables doesn't. This is

[HACKERS] COPY TO

hello. in copy.c is one function that its name is CopyOneRowTO. in this function have one foreach loop. in this loop first if have this condition: !cstate->binary what means this condition and when true this condition? thank you.

[HACKERS] Re: Server is not getting started with log level as debug5 on master after commit 3147ac

On Fri, Nov 22, 2013 at 9:30 AM, Amit Kapila wrote: > In master branch, server is not getting started with log level as debug5. > > Simple steps to reproduce the problem: > a. initdb -D ..\..\Data > b. change log_min_messages = debug5 in postgresql.conf > c. start server (pg_ctl start -D ..\..\Dat

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

On Thu, Nov 21, 2013 at 9:54 PM, Amit Kapila wrote: > On Thu, Nov 21, 2013 at 8:14 PM, Tom Lane wrote: >> Amit Kapila writes: >>> Here what I have in mind is that: >> >> Why would you make psql behave differently from our other command-line >> clients? > >No, psql should not behave different

Re: [HACKERS] Building on S390

Greg Stark writes: > On Fri, Nov 22, 2013 at 8:51 PM, Peter Eisentraut wrote: >> According to the Debian build logs, postgres-xc compiles the entire >> backend with -fPIC. Not sure what sense that makes. > Debian policy is to always use -fPIC > IIRC -fpic is good enough as long as the total si

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

On Wed, Nov 20, 2013 at 10:21 AM, Peter Eisentraut wrote: > 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 entir

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

Andres Freund wrote: > On 2013-11-22 13:34:18 -0800, Kevin Grittner wrote: >> Oddly, it didn't complain about creating users within a read-only >> transaction.  That seems like a potential bug. > > There's lots of things that escape XactReadOnly. I've thought (and I > think suggested) before that

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

Bruce Momjian wrote: > On Fri, Nov 22, 2013 at 01:55:10PM -0800, Kevin Grittner wrote: > >> It does nothing about pg_upgrade, which is sort of a separate >> issue.  My inclination is that connections to the new cluster >> should set this and connections to the old should not. > > It is going to be

Re: [HACKERS] Can we trust fsync?

On Sat, Nov 23, 2013 at 8:06 AM, Peter Geoghegan wrote: > On Fri, Nov 22, 2013 at 2:57 PM, Bruce Momjian wrote: >> The program is diskchecker: >> >> http://brad.livejournal.com/2116715.html >> >> I got the author to re-host the source code on github a few years ago. > > It might be worth

Re: [HACKERS] Building on S390

On Fri, Nov 22, 2013 at 8:51 PM, Peter Eisentraut wrote: > On 11/22/13, 12:41 PM, Michael Meskes wrote: > > Checking the Debian logs it appears that all calls use *both* which > seems to do > > the right thing. And yes, it appears there is a change in XC that makes > it > > break. But still, I wo

Re: [HACKERS] Can we trust fsync?

On Fri, Nov 22, 2013 at 03:27:29PM -0800, Josh Berkus wrote: > On 11/22/2013 03:23 PM, Bruce Momjian wrote: > > On Fri, Nov 22, 2013 at 03:06:31PM -0800, Peter Geoghegan wrote: > >> On Fri, Nov 22, 2013 at 2:57 PM, Bruce Momjian wrote: > >>> The program is diskchecker: > >>> > >>> http://b

Re: [HACKERS] Can we trust fsync?

On 11/22/2013 03:23 PM, Bruce Momjian wrote: > On Fri, Nov 22, 2013 at 03:06:31PM -0800, Peter Geoghegan wrote: >> On Fri, Nov 22, 2013 at 2:57 PM, Bruce Momjian wrote: >>> The program is diskchecker: >>> >>> http://brad.livejournal.com/2116715.html >>> >>> I got the author to re-host the

Re: [HACKERS] Can we trust fsync?

On Fri, Nov 22, 2013 at 03:06:31PM -0800, Peter Geoghegan wrote: > On Fri, Nov 22, 2013 at 2:57 PM, Bruce Momjian wrote: > > The program is diskchecker: > > > > http://brad.livejournal.com/2116715.html > > > > I got the author to re-host the source code on github a few years ago. > > It m

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

On Fri, Nov 22, 2013 at 01:55:10PM -0800, Kevin Grittner wrote: > It does nothing about pg_upgrade, which is sort of a separate > issue.  My inclination is that connections to the new cluster > should set this and connections to the old should not. It is going to be tricky to conditionally set/res

Re: [HACKERS] Can we trust fsync?

On Fri, Nov 22, 2013 at 2:57 PM, Bruce Momjian wrote: > The program is diskchecker: > > http://brad.livejournal.com/2116715.html > > I got the author to re-host the source code on github a few years ago. It might be worth re-implementing this for -contrib. The fact that we mention diskche

Re: [HACKERS] Can we trust fsync?

On Fri, Nov 22, 2013 at 11:16:06AM -0500, Tom Lane wrote: > Greg Stark writes: > > On Thu, Nov 21, 2013 at 1:43 AM, Tom Lane wrote: > >> Also, it's not that hard to do plug-pull testing to verify that your > >> system is telling the truth about fsync. This really ought to be part > >> of accepta

Re: [HACKERS] Patch for fail-back without fresh backup

On Thu, Nov 21, 2013 at 11:43:34PM +0100, Andres Freund wrote: > On 2013-11-21 14:40:36 -0800, Jeff Janes wrote: > > But if the transaction would not have otherwise generated WAL (i.e. a > > select that did not have to do any HOT pruning, or an update with zero rows > > matching the where condition

Re: [HACKERS] why semicolon after begin is not allowed in postgresql?

On 11/22/2013 05:24 PM, AK wrote: I am reading the following in the documentation: "Tip: A common mistake is to write a semicolon immediately after BEGIN. This is incorrect and will result in a syntax error." So, "common mistake" means semicolons after BEGIN seem consistent to many people - it

Re: [HACKERS] why semicolon after begin is not allowed in postgresql?

AK wrote: > I am reading the following in the documentation: "Tip: A common > mistake is to write a semicolon immediately after BEGIN. This is > incorrect and will result in a syntax error." > > So, "common mistake" means semicolons after BEGIN seem consistent > to many people - it seems consiste

Re: [HACKERS] why semicolon after begin is not allowed in postgresql?

On Fri, Nov 22, 2013 at 4:34 PM, Mike Blackwell wrote: > I believe the section you are reading refers to the BEGIN keyword in the > procedural language plpgsql, not the SQL 'BEGIN' command. The issue stems > from confusing two distinct languages both of which, along with several more > procedural

Re: [HACKERS] why semicolon after begin is not allowed in postgresql?

I believe the section you are reading refers to the BEGIN keyword in the procedural language plpgsql, not the SQL 'BEGIN' command. The issue stems from confusing two distinct languages both of which, along with several more procedural languages, are documented in the same manual.

Re: [HACKERS] why semicolon after begin is not allowed in postgresql?

On 11/22/2013 02:24 PM, AK wrote: I am reading the following in the documentation: "Tip: A common mistake is to write a semicolon immediately after BEGIN. This is incorrect and will result in a syntax error." So, "common mistake" means semicolons after BEGIN seem consistent to many people - it s

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

Andres Freund wrote: > FWIW, I am less than convinced that it is correct for > pg_dump[all] to emit SET default_transaction_readonly = off; It doesn't change the database setting, just the connection which is issuing commands to create global object -- ones that don't reside in the database we a

[HACKERS] why semicolon after begin is not allowed in postgresql?

I am reading the following in the documentation: "Tip: A common mistake is to write a semicolon immediately after BEGIN. This is incorrect and will result in a syntax error." So, "common mistake" means semicolons after BEGIN seem consistent to many people - it seems consistent to me as well. If Po

Re: [HACKERS] Why is UPDATE with column-list syntax not implemented

On Fri, Nov 22, 2013 at 6:36 PM, AK wrote: > Claudio, > > Can you elaborate how rules can help? Well... that specific example: > UPDATE accounts SET (contact_last_name, contact_first_name) = > (SELECT last_name, first_name FROM salesmen > WHERE salesmen.id = accounts.sales_id); Can be

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

On 2013-11-22 13:34:18 -0800, Kevin Grittner wrote: > I changed my postgres database to default to read only (which is > not insane, given that I've seen so many people accidentally run > DDL there rather than in the database they intended) FWIW, I am less than convinced that it is correct for pg_

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

Kevin Grittner wrote: This covers pg_dumpall globals.  Tested with a read-only postgres database and with default_transaction_read_only = on in the postgresql.conf file. It does nothing about pg_upgrade, which is sort of a separate issue.  My inclination is that connections to the new cluster sh

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

On 2013-11-22 13:34:18 -0800, Kevin Grittner wrote: > Oddly, it didn't complain about creating users within a read-only > transaction.  That seems like a potential bug. There's lots of things that escape XactReadOnly. I've thought (and I think suggested) before that we should put in another layer

Re: [HACKERS] Why is UPDATE with column-list syntax not implemented

Thank you, Tom! -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-is-UPDATE-with-column-list-syntax-not-implemented-tp5779600p5779899.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@p

Re: [HACKERS] Why is UPDATE with column-list syntax not implemented

Claudio, Can you elaborate how rules can help? -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-is-UPDATE-with-column-list-syntax-not-implemented-tp5779600p5779896.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hacke

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

Andres Freund wrote: > On 2013-11-22 13:07:29 -0800, Kevin Grittner wrote: >> Andres Freund wrote: >> >>> are you sure it also unsets default_transaction_readonly for >>> the roles etc. it creates? >> >> I'm not sure I understand.  Could you give an example of what >> you're concerned about? > >

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

Andres Freund writes: > On 2013-11-22 13:07:29 -0800, Kevin Grittner wrote: >> I'm not sure I understand.  Could you give an example of what >> you're concerned about? > pg_dumpall first spits out global data (users, databases, tablespaces) > and then invokes pg_dump for every single database. So

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

On 2013-11-22 13:07:29 -0800, Kevin Grittner wrote: > Andres Freund wrote: > > > are you sure it also unsets default_transaction_readonly for > > the roles etc. it creates? > > I'm not sure I understand.  Could you give an example of what > you're concerned about? pg_dumpall first spits out glo

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

Andres Freund wrote: > are you sure it also unsets default_transaction_readonly for > the roles etc. it creates? I'm not sure I understand.  Could you give an example of what you're concerned about? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

On 2013-11-22 12:45:25 -0800, Kevin Grittner wrote: > Tom Lane wrote: > > > That looks sane for pg_dump, but I would rather have expected > > that pg_dumpall would need to emit the same thing (possibly more > > than once due to reconnections). > > I was kinda surprised myself.  I changed it for

Re: [HACKERS] Building on S390

On 11/22/13, 12:41 PM, Michael Meskes wrote: > Checking the Debian logs it appears that all calls use *both* which seems to > do > the right thing. And yes, it appears there is a change in XC that makes it > break. But still, I would think there has to be a correct set of options. According to th

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

Tom Lane wrote: > That looks sane for pg_dump, but I would rather have expected > that pg_dumpall would need to emit the same thing (possibly more > than once due to reconnections). I was kinda surprised myself.  I changed it for pg_dump, tested that, and then tested pg_dumpall to get a baseline

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

Kevin Grittner writes: > Kevin Grittner wrote: >> See the attached patch. > Trying that again. That looks sane for pg_dump, but I would rather have expected that pg_dumpall would need to emit the same thing (possibly more than once due to reconnections). regards, tom la

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

Kevin Grittner wrote: > See the attached patch. Trying that again. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Companydiff --git a/src/bin/pg_dump/pg_backup_archiver.c b/src/bin/pg_dump/pg_backup_archiver.c index 63a8009..199ffb0 100644 --- a/src/bin/pg_dump/pg_

Re: [HACKERS] Building on S390

Michael Meskes writes: > On Fri, Nov 22, 2013 at 11:27:45AM -0500, Tom Lane wrote: >> Furthermore, if we change that convention now, we're going to increase >> the risk of such mixing failures for other people. > Sure, but if this a bug we should. I'm not saying it is, I simply don't know. Well,

Re: [HACKERS] Why is UPDATE with column-list syntax not implemented

AK writes: > 9.3 documentation says: > According to the standard, the column-list syntax should allow a list of > columns to be assigned from a single row-valued expression, such as a > sub-select: > UPDATE accounts SET (contact_last_name, contact_first_name) = > (SELECT last_name, first_name

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

Bruce Momjian wrote: >> Not sure about backpatching.  default_transaction_read_only has been >> around since 7.4.  Setting it to true would cause pg_dump to fail unless >> you changed the database setting, and pg_dumpall would fail completely >> as there is no way to turn off the database setting

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

On 2013-11-22 14:43:15 -0500, Robert Haas wrote: > The patch as proposed puts forward a particular way of > doing that, and I think that neither that method *nor any other* > should be part of core. Working on something like that, updated the patch state to "waiting on author". Thanks, Andres Fr

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

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> Well, it's not insane on its face. The rowtype of f in the > Tom> first example is necessarily a built-on-the-fly record, but in > Tom> the second case using the properties of the underlying named > Tom> composite type is possible, and

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

On Thu, Nov 21, 2013 at 8:26 AM, Andres Freund wrote: > On 2013-11-21 08:22:05 -0500, Robert Haas wrote: >> On Thu, Nov 21, 2013 at 6:15 AM, Andres Freund >> wrote: >> >> > WRT performance: I agree that fixed-width identifiers are more >> >> > performant, that's why I went for them, but I am not

Re: [HACKERS] new unicode table border styles for psql

2013/11/22 Alvaro Herrera > Pavel Stehule escribió: > > > 2013/11/21 Peter Eisentraut > > > > Maybe make the border setting a string containing the various > characters > > > by index. Then everyone can create their own crazy borders. > > > > > I seriously though about it, but not sure if it is

Re: [HACKERS] MultiXact pessmization in 9.3

Andres Freund wrote: > On 2013-11-22 12:04:31 -0300, Alvaro Herrera wrote: > Yes, somewhat: <9.3 GetMultiXactIdMembers() didn't do any work if the > multixact was old enough: > if (MultiXactIdPrecedes(multi, OldestVisibleMXactId[MyBackendId])) > { > debug_elog2(DEBUG2, "G

Re: [HACKERS] Status of FDW pushdowns

On Fri, Nov 22, 2013 at 08:25:05AM -0600, Merlin Moncure wrote: > On Thu, Nov 21, 2013 at 6:43 PM, Shigeru Hanada > wrote: > > 2013/11/22 Tom Lane : > >> Merlin Moncure writes: > >>> On Thu, Nov 21, 2013 at 9:05 AM, Bruce Momjian wrote: > I know join pushdowns seem insignificant, but it hel

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

On 21 November 2013, Amit Khandekar mailto:amit.khande...@enterprisedb.com>> wrote: >Ok. we will then first fix the \COPY TO issue where it does not revert back >the overriden psql output file handle. Once this is solved, fix for both COPY >FROM and COPY TO, like how it is done in the patch earl

[HACKERS] Why is UPDATE with column-list syntax not implemented

9.3 documentation says: According to the standard, the column-list syntax should allow a list of columns to be assigned from a single row-valued expression, such as a sub-select: UPDATE accounts SET (contact_last_name, contact_first_name) = (SELECT last_name, first_name FROM salesmen WHE

Re: [HACKERS] Logging WAL when updating hintbit

On 20 November 2013 22:12, Sawada Masahiko Wrote > > > > 1. Patch applies cleanly to master HEAD. > > 2. No Compilation Warning. > > 3. It works as per the patch expectation. > > > > Some Suggestion: > > 1. Add new WAL level ("all") in comment in postgresql.conf > >wal_level = hot_standby

Re: [HACKERS] [PoC] pgstattuple2: block sampling to reduce physical read

On 16/09/13 16:20, Satoshi Nagayasu wrote: > Thanks for checking. Fixed to eliminate SnapshotNow. Looking forward to get a new patch, incorporating the comments, that are already given in the following mails: 1. Jaime Casanova: "The name pgstattuple2, doesn't convince me... maybe you can use pg

Re: [HACKERS] Logging WAL when updating hintbit

On 19 November 2013 22:19, Sawada Masahiko Wrote > >> > >> Thank you for comment. > >> Actually, I had thought to add separate parameter. > > > > I think that he said that if you can proof that amount of WAL is > > almost same and without less performance same as before, you might > not > > need t

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

Sending to hackers for comment; seems setting default_transaction_read_only to true via ALTER database/user or postgresql.conf can cause pg_dump, pg_dumpall, and pg_upgrade failures. We are considering the right solution:

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

On 20 November, Amit Khandekar wrote: I hope you meant to write test case as psql -d postgres -c "\copy tab from stdin; insert into tab values ('lll', 3)", as if we are reading from file, then the above issue does not come. >>>I meant COPY with a slash. \COPY is equivalent to COPY FRO

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On 14 November 2013, Kondo Mitsumasa wrote: > Subject: Re: [HACKERS] Add min and max execute statement time in > pg_stat_statement > > Oh! Sorry... > I forgot to attach my latest patch. * Is the patch in a patch format which has context? No * Does it apply cleanly to the current git master? Yes

Re: [HACKERS] PostgreSQL Service on Windows does not start. ~ "is not a valid Win32 application"

ON 11 November 2013, Naoya Anzai Wrote: >> >> Hi Amit, >> > > I have uploaded your patch for next commit fest, hope you can support > > it if there is any feedback for your patch by reviewer/committer. > Thanks! Okay, I will support you. 1. Patch applies cleanly to master HEAD. 2. No Compilatio

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

On 19 November 2013, Amit Khandekar wrote: >On 18 November 2013 18:00, Rajeev rastogi >mailto:rajeev.rast...@huawei.com>> wrote: >>On 18 November 2013, Amit Khandekar wrote: > >>Please find the patch for the same and let me know your suggestions. >>>In this call : > >>

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

On Fri, Nov 22, 2013 at 12:17:41PM -0500, Bruce Momjian wrote: > Good points. I have modified the attached patch to do as you suggested. Also, I have read through the thread and summarized the positions of the posters: 9.3 WARNING ERROR SET

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

> "Tom" == Tom Lane writes: Tom> [ I assume you forgot a create type footype here ] yeah, sorry Tom> Well, it's not insane on its face. The rowtype of f in the Tom> first example is necessarily a built-on-the-fly record, but in Tom> the second case using the properties of the underlyin

Re: [HACKERS] Building on S390

On Fri, Nov 22, 2013 at 11:27:45AM -0500, Tom Lane wrote: > I think this is probably nonsense. I spent ten years maintaining Postgres > for Red Hat, and I never saw any such failure on s390 in their packages. > If -fpic weren't good enough for shared libraries on s390, how'd any of > those builds

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

On Fri, Nov 22, 2013 at 10:24:35AM -0300, Alvaro Herrera wrote: > Bruce Momjian escribió: > > > OK, here is a patch which changes ABORT from NOTICE to WARNING, and SET > > from ERROR (which is new in 9.4) to WARNING. > > I don't like that this patch changes RequireTransactionChain() from > actual

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

Andrew Gierth writes: > Is this intended: [ I assume you forgot a create type footype here ] > create function foo() returns setof footype language plpgsql > as $f$ begin return next row(1,true); end; $f$; > select pg_typeof(f), row_to_json(f) from foo() with ordinality f(p,q); > pg_typeof |

Re: [HACKERS] Can we trust fsync?

On Fri, Nov 22, 2013 at 1:16 PM, Tom Lane wrote: >> The original mail was referencing a problem with syncing *meta* data >> though. The semantics around meta data syncs are much less clearly >> specified, in part because file systems traditionally made nearly all meta >> data operations synchronou

Re: [HACKERS] Building on S390

Michael Meskes writes: > I spend some time trying to figure out why PostgreSQL builds on > S390-Linux, but Postgres-XC doesn't. Well at least this holds for the Debian > packages. So far I haven't figured it out. However, it appears to me that the > build should fail for both. I'm not an S390 exp

Re: [HACKERS] Can we trust fsync?

Greg Stark writes: > On Thu, Nov 21, 2013 at 1:43 AM, Tom Lane wrote: >> Also, it's not that hard to do plug-pull testing to verify that your >> system is telling the truth about fsync. This really ought to be part >> of acceptance testing for any new DB server. > I've never tried it but I alwa

Re: [HACKERS] Can we trust fsync?

On Thu, Nov 21, 2013 at 1:43 AM, Tom Lane wrote: > Also, it's not that hard to do plug-pull testing to verify that your > system is telling the truth about fsync. This really ought to be part > of acceptance testing for any new DB server. > I've never tried it but I always wondered how easy it

[HACKERS] Building on S390

Hi, I spend some time trying to figure out why PostgreSQL builds on S390-Linux, but Postgres-XC doesn't. Well at least this holds for the Debian packages. So far I haven't figured it out. However, it appears to me that the build should fail for both. I'm not an S390 expert by any means, but I was

Re: [HACKERS] MultiXact pessmization in 9.3

On 2013-11-22 12:04:31 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > > While looking at the multixact truncation code (mail nearby), I've > > noticed that there's a significant difference in the way multixact > > members are accessed since fkey locks were introduced: > > > > <9.3 when h

Re: [HACKERS] Minor patch for the uuid-ossp extension

On 11/22/2013 10:19 AM, Alvaro Herrera wrote: Tom Lane wrote: roadrunn...@gmx.at writes: regression=# \echo Use '''CREATE EXTENSION "uuid-ossp"''' to load this file. Use 'CREATE EXTENSION "uuid-ossp"' to load this file. Does that look reasonable to people? +1 +1 cheers andrew -- Sent v

Re: [HACKERS] Minor patch for the uuid-ossp extension

Tom Lane wrote: > roadrunn...@gmx.at writes: > regression=# \echo Use '''CREATE EXTENSION "uuid-ossp"''' to load this file. > Use 'CREATE EXTENSION "uuid-ossp"' to load this file. > > Does that look reasonable to people? +1 -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreS

Re: [HACKERS] Minor patch for the uuid-ossp extension

roadrunn...@gmx.at writes: > When trying to add the extension with \i it writes an error message: > Use "CREATE EXTENSION uuid-ossp" to load this file. > Unfortunatly this does not work for extensions with dashes. Must CREATE > EXTENSION "uuid-ossp". Proposed patch is attached. [ memo to se

Re: [HACKERS] new unicode table border styles for psql

On Fri, Nov 22, 2013 at 8:45 AM, Alvaro Herrera wrote: > Pavel Stehule escribió: > >> 2013/11/21 Peter Eisentraut > >> > Maybe make the border setting a string containing the various characters >> > by index. Then everyone can create their own crazy borders. >> > >> I seriously though about it,

Re: [HACKERS] MultiXact pessmization in 9.3

Andres Freund wrote: > While looking at the multixact truncation code (mail nearby), I've > noticed that there's a significant difference in the way multixact > members are accessed since fkey locks were introduced: > > <9.3 when heap_lock_tuple finds a XMAX_IS_MULTI tuple it executes > MultiXact

Re: [HACKERS] commit fest 2013-11 week 1 report

On 22-11-2013 11:07, Pavel Golub wrote: > Is is possible to add small patch to the current commit fest? > No. Deadline was 11/15. Add it to next CF [1]. [1] https://commitfest.postgresql.org/action/commitfest_view?id=21 -- Euler Taveira Timbira - http://www.timbira.com.br

Re: [HACKERS] new unicode table border styles for psql

Pavel Stehule escribió: > 2013/11/21 Peter Eisentraut > > Maybe make the border setting a string containing the various characters > > by index. Then everyone can create their own crazy borders. > > > I seriously though about it, but not sure if it is good way. How about having a single "unico

Re: [HACKERS] address sanitizer crash

Peter Eisentraut writes: > AddressSanitizer (http://clang.llvm.org/docs/AddressSanitizer.html) > (also available through gcc, but I used clang), reports one bug, which > I traced down to this code in ruleutils.c: > [elsewhere:] > #define ViewSelectRuleName "_RETURN" > /* > * Get

Re: [HACKERS] new unicode table border styles for psql

2013/11/22 Merlin Moncure > On Fri, Nov 22, 2013 at 2:23 AM, Pavel Stehule > wrote: > > Hello > > > > > > 2013/11/21 Merlin Moncure > >> > >> On Thu, Nov 21, 2013 at 1:09 AM, Pavel Stehule > > >> wrote: > >> > Hello > >> > > >> > I wrote new styles for psql table borders. > >> > > >> > http:/

Re: [HACKERS] new unicode table border styles for psql

On Fri, Nov 22, 2013 at 2:23 AM, Pavel Stehule wrote: > Hello > > > 2013/11/21 Merlin Moncure >> >> On Thu, Nov 21, 2013 at 1:09 AM, Pavel Stehule >> wrote: >> > Hello >> > >> > I wrote new styles for psql table borders. >> > >> > http://postgres.cz/wiki/Pretty_borders_in_psql >> > >> > This pa

Re: [HACKERS] Status of FDW pushdowns

On Thu, Nov 21, 2013 at 6:43 PM, Shigeru Hanada wrote: > 2013/11/22 Tom Lane : >> Merlin Moncure writes: >>> On Thu, Nov 21, 2013 at 9:05 AM, Bruce Momjian wrote: I know join pushdowns seem insignificant, but it helps to restrict what data must be passed back because you would only pas

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

KaiGai On Tue, Nov 19, 2013 at 9:41 AM, Kohei KaiGai wrote: > Thanks for your review. > > 2013/11/19 Jim Mlodgenski : > > My initial review on this feature: > > - The patches apply and build, but it produces a warning: > > ctidscan.c: In function ‘CTidInitCustomScanPlan’: > > ctidscan.c:362:9:

Re: [HACKERS] commit fest 2013-11 week 1 report

Hello, Peter. Is is possible to add small patch to the current commit fest? You wrote: PE> We started with PE> Fri Nov 15 PE> Status Summary. Needs Review: 79, Waiting on Author: 7, Ready for PE> Committer: 5, Committed: 7, Returned with Feedback: 3, Rejected: 1. Total: 102. PE> We are now a

[HACKERS] address sanitizer crash

AddressSanitizer (http://clang.llvm.org/docs/AddressSanitizer.html) (also available through gcc, but I used clang), reports one bug, which I traced down to this code in ruleutils.c: [elsewhere:] #define ViewSelectRuleName "_RETURN" /* * Get the pg_rewrite tuple for the view's SE

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

On 2013-11-22 15:01:10 +0200, Heikki Linnakangas wrote: > On 21.11.2013 22:55, Andres Freund wrote: > >On 2013-11-20 12:48:50 +0200, Heikki Linnakangas wrote: > >>Looks ok for a back-patchable fix. > > > >Do you plan to commit this? Or who is going to? > > Ok, committed. Thanks! Greetings, Andr

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

Bruce Momjian escribió: > OK, here is a patch which changes ABORT from NOTICE to WARNING, and SET > from ERROR (which is new in 9.4) to WARNING. I don't like that this patch changes RequireTransactionChain() from actually requiring one, to a function that maybe requires a transaction chain, and m

[HACKERS] commit fest 2013-11 week 1 report

We started with Fri Nov 15 Status Summary. Needs Review: 79, Waiting on Author: 7, Ready for Committer: 5, Committed: 7, Returned with Feedback: 3, Rejected: 1. Total: 102. We are now at Fri Nov 22 Status Summary. Needs Review: 47, Waiting on Author: 28, Ready for Committer: 10, Committed: 1

Re: [HACKERS] Handling GIN incomplete splits

On Thu, Nov 21, 2013 at 9:44 PM, Heikki Linnakangas wrote: > Here's a new version. To ease the review, I split the remaining patch again > into two, where the first patch is just yet more refactoring. > > I also fixed some bugs in WAL logging and replay that I bumped into while > testing. Cool. He

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

On 21.11.2013 22:55, Andres Freund wrote: On 2013-11-20 12:48:50 +0200, Heikki Linnakangas wrote: On 19.11.2013 16:22, Andres Freund wrote: On 2013-11-19 15:20:01 +0100, Andres Freund wrote: Imo something the attached patch should be done. The description I came g> >>up with is: Fix Ho

Re: [HACKERS] Add \i option to bring in the specified file as a quoted literal

Amit Kapila escribió: > On Fri, Nov 22, 2013 at 1:33 AM, Alvaro Herrera > wrote: > > \ib homer ~/photos/homer.jpg > > insert into people (name, photo) values ('Homer', :homer); > > Isn't something similar already supported as mentioned in docs: > > One example use of this mechanism is to copy

[HACKERS] Minor patch for the uuid-ossp extension

When trying to add the extension with \i it writes an error message: Use "CREATE EXTENSION uuid-ossp" to load this file. Unfortunatly this does not work for extensions with dashes. Must CREATE EXTENSION "uuid-ossp". Proposed patch is attached. Regards Mario diff -Nurb contrib.orig/uuid-os

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

> "Tom" == Tom Lane writes: Tom> I've committed this patch after some significant editorialization, but Tom> leaving the use of TABLE( ... ) syntax in-place. If we decide that we Tom> don't want to risk doing that, we can change to some other syntax later. Is this intended: create funct

Re: [HACKERS] information schema parameter_default implementation

Review: information schema parameter_default implementation (v2) This is a review of the patch submitted in http://archives.postgresql.org/message-id/1384483678.5008.1.ca...@vanquo.pezone.net (information schema parameter_default implementation). Previous review from Amit Khandekar covers technic

Re: [HACKERS] [PATCH] Store Extension Options

On Thu, Nov 21, 2013 at 11:06 AM, Robert Haas wrote: > > On Wed, Nov 20, 2013 at 9:35 PM, Fabrízio de Royes Mello > wrote: > >> > So, with this patch we can do that: > >> > > >> > ALTER TABLE foo > >> >SET (ext.somext.do_replicate=true); > >> > > >> > When 'ext' is the fixed prefix, 'somext'

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

On 19.11.2013 16:20, Andres Freund wrote: On 2013-11-18 23:15:59 +0100, Andres Freund wrote: Afaics it's likely a combination/interaction of bugs and fixes between: * the initial HS code * 5a031a5556ff83b8a9646892715d7fef415b83c3 * f44eedc3f0f347a856eea8590730769125964597 Yes, the combination

Re: [HACKERS] PL/Python: domain over array support

On Fri, Nov 22, 2013 at 08:45:56AM -0200, Rodolfo Campero wrote: > There are other cosmetic changes in this patch, wrt previous version (not > preexistent code): > * adjusted alignment of variable name "rv" in line 12 > * reworded comment in line 850, resulting in more than 80 characters, so I >

Re: [HACKERS] [PERFORM] Cpu usage 100% on slave. s_lock problem.

On 21.11.2013 21:37, Merlin Moncure wrote: On Thu, Nov 21, 2013 at 10:37 AM, Heikki Linnakangas In my patch, I put the barrier inside the if (!LocalRecoveryInProgress) block. That codepath can only execute once in a backend, so performance is not an issue there. Does that look sane to you? oh

Re: [HACKERS] PL/Python: domain over array support

Marko, 2013/11/22 Marko Kreen > On Sat, Oct 26, 2013 at 11:17:19AM -0200, Rodolfo Campero wrote: > > The attached patch add support of domains over arrays to PL/Python (eg: > > CREATE DOMAIN my_domain AS integer[]). > > > > Basically it just uses get_base_element_type instead of get_element_type

Re: [HACKERS] Can we trust fsync?

On 11/21/2013 12: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 seeking opinions from folks here who've been deeply involved in write reliability work. With ex

Re: [HACKERS] Get more from indices.

Kyotaro HORIGUCHI wrote: > Hello. I found a bug(?) in thsi patch as I considered on another patch. > In truncate_useless_pathkeys, if query_pathkeys is longer than pathkeys made > from index columns old patch picked up the latter as IndexPath's pathkeys. > But the former is more suitable accordin

Re: [HACKERS] PL/Python: domain over array support

On Sat, Oct 26, 2013 at 11:17:19AM -0200, Rodolfo Campero wrote: > The attached patch add support of domains over arrays to PL/Python (eg: > CREATE DOMAIN my_domain AS integer[]). > > Basically it just uses get_base_element_type instead of get_element_type > in plpy_typeio.c, and uses domain_check

  1   2   >