Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

Hello All, I assigned my self as reviewer of the patch. I gone through the mail chain discussion and in that question has been raised about the feature and its implementation, so would like to know what is the current status of this project/patch. Regards, On Thu, Jun 12, 2014 at 5:53 PM, Ian B

Re: [HACKERS] PATCH: Allow empty targets in unaccent dictionary

Hi. At 2014-04-20 01:06:43 +0200, alhash...@alhashash.net wrote: > > To use unaccent dictionary for these languages, we need to allow empty > targets to remove diacritics instead of replacing them. Your patch should definitely add a test case or two to sql/unaccent.sql and expected/unaccent.out s

Re: [HACKERS] pg_resetxlog to clear backup start/end locations.

Hello, thank you for the suggestion. I dont' touch what '-n' option shows and rewrite documents for the option a bit. And '-n' won't show the changes of backup location. === > > There are some changes which haven't been shown by '-n' option, > > even not displayed at all. I think these should

Re: [HACKERS] idle_in_transaction_timeout

On Sun, Jun 22, 2014 at 6:54 AM, Vik Fearing wrote: > On 06/21/2014 08:23 PM, Kevin Grittner wrote: >> OK, so I think we want to see a patch based on v1 (FATAL approach) >> with a change of the name to idle_in_transaction_session_timeout >> and the units changed to milliseconds. I don't see why t

Re: [HACKERS] Cluster name in ps output

Hi. I reviewed the version of this patch without log_line_prefix support, since that seemed to be generally acceptable in followup discussion. The patch didn't apply any more because of some changes to guc.c, but it was trivial to regenerate (fixed patch attached). > diff --git a/src/backend/uti

Re: [HACKERS] makeAndExpr(), etc. confined to gram.y?

Amit Langote writes: > Is there a reason why they've been left out of > makefuncs.h/makefuncs.c? Perhaps they are not supposed to be used > outside gram.y at all? For example, previously a caller (potentially) > outside parser could do a makeA_Expr(AEXPR_AND, ...). I guess this is > no longer poss

Re: [HACKERS] [BUGS] BUG #10728: json_to_recordset with nested json objects NULLs columns

Andrew Dunstan writes: >>> I currently don't have lots of time to devote to this, sadly, but >>> Michael's patch looks like a good minimal fix. > This problem is also manifest in json_populate_recordset, which also > uses the function in question, and is in 9.3: I've pushed this patch back thro

[HACKERS] makeAndExpr(), etc. confined to gram.y?

Hi, A recent commit titled "Avoid recursion when processing simple lists of AND'ed or OR'ed clauses." (2146f13408cdb85c738364fe8f7965209e08c6be) got rid of AEXPR_AND, etc. and instead created makeAndExpr(), etc. in gram.y Is there a reason why they've been left out of makefuncs.h/makefuncs.c? Per

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

Abhijit, * Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: > At 2014-06-24 14:02:11 -0400, sfr...@snowman.net wrote: > > > > Will you (collectively) be working in this direction for 9.5? > > We have some time available to work on it, but not so much that I want > to write any more code without a

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

At 2014-06-24 14:02:11 -0400, sfr...@snowman.net wrote: > > Will you (collectively) be working in this direction for 9.5? We have some time available to work on it, but not so much that I want to write any more code without a clearer idea of what might be accepted eventually for inclusion. -- Abh

Re: [HACKERS] pg_resetxlog to clear backup start/end locations.

On Wed, Jun 25, 2014 at 11:13 AM, Kyotaro HORIGUCHI wrote: > Hello, > >> Ok, I'm doing modify it to reset backup locations by default and >> remove the new option '-b' to do that. Since this seems looking >> to be a bug for the poeple, I'll provide backpatches back >> to... 8.4? (Final release of

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On Tue, Jun 24, 2014 at 10:16 PM, John Klos wrote: >> Has anyone tried to build PostgreSQL for VAX lately? If so, did it >> compile? Did you have to use --disable-spinlocks to get it to compile? If >> it did compile, can you actually run it, and does it pass the regression >> tests and work as e

Re: [HACKERS] pg_resetxlog to clear backup start/end locations.

Hello, > Ok, I'm doing modify it to reset backup locations by default and > remove the new option '-b' to do that. Since this seems looking > to be a bug for the poeple, I'll provide backpatches back > to... 8.4? (Final release of 8.4 is scheduled at July 2014) I looked closer to pg_resetxlog an

Re: [HACKERS] Allowing join removals for more join types

On 24 June 2014 23:48, Tom Lane wrote: > Simon Riggs writes: >> Other than that it looks pretty good to commit, so I'll wait a week >> for other objections then commit. > > I'd like to review this before it goes in. I've been waiting for it to > get marked "ready for committer" though. I'll lea

Re: [HACKERS] Allowing NOT IN to use ANTI joins

On 24 June 2014 23:52, Tom Lane wrote: > Simon Riggs writes: >> On 24 June 2014 23:44, Tom Lane wrote: >>> Simon Riggs writes: Having said that, any join plan that relies upon a constraint will still be valid even if we drop a constraint while the plan executes because any new wr

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

Craig, * Craig Ringer (cr...@2ndquadrant.com) wrote: > On 06/24/2014 10:30 PM, Alvaro Herrera wrote: > > I haven't been following this thread, but this bit caught my attention. > > I'm not sure I agree that OR is always the right policy either. > > There is a case for a policy that says "forbid th

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

On 06/24/2014 10:30 PM, Alvaro Herrera wrote: > I haven't been following this thread, but this bit caught my attention. > I'm not sure I agree that OR is always the right policy either. > There is a case for a policy that says "forbid these rows to these guys, > even if they have read permissions f

[HACKERS] RLS Design

Dean, all, Changing the subject of this thread (though keeping it threaded) as we've really moved on to a much broader discussion. * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > On 24 June 2014 17:27, Stephen Frost wrote: > > Single policy vs Multiple, Overlapping policies vs Multiple, > >

Re: [HACKERS] [BUGS] BUG #10728: json_to_recordset with nested json objects NULLs columns

Merlin Moncure writes: > On Mon, Jun 23, 2014 at 8:43 PM, Tom Lane wrote: >> * Nested json arrays are a bit more problematic. What I'd ideally like >> is to spit them out in a form that would be successfully parsable as a SQL >> array of the appropriate element type. Unfortunately, I think that

Re: [HACKERS] Allowing NOT IN to use ANTI joins

Simon Riggs writes: > On 24 June 2014 23:44, Tom Lane wrote: >> Simon Riggs writes: >>> Having said that, any join plan that relies upon a constraint will >>> still be valid even if we drop a constraint while the plan executes >>> because any new writes will not be visible to the executing join

Re: [HACKERS] Allowing join removals for more join types

Simon Riggs writes: > Other than that it looks pretty good to commit, so I'll wait a week > for other objections then commit. I'd like to review this before it goes in. I've been waiting for it to get marked "ready for committer" though. regards, tom lane -- Sent via

Re: [HACKERS] Allowing NOT IN to use ANTI joins

On 24 June 2014 23:44, Tom Lane wrote: > Simon Riggs writes: >> Having said that, any join plan that relies upon a constraint will >> still be valid even if we drop a constraint while the plan executes >> because any new writes will not be visible to the executing join plan. > > mumble ... EvalPl

Re: [HACKERS] Allowing NOT IN to use ANTI joins

Simon Riggs writes: > Having said that, any join plan that relies upon a constraint will > still be valid even if we drop a constraint while the plan executes > because any new writes will not be visible to the executing join plan. mumble ... EvalPlanQual ? regards, tom l

Re: [HACKERS] Allowing NOT IN to use ANTI joins

On 11 June 2014 17:52, Greg Stark wrote: > On Wed, Jun 11, 2014 at 3:26 PM, Tom Lane wrote: >> If we didn't have mechanisms like this, we'd have far worse hazards from >> ALTER TABLE than whether the planner made an incorrect join optimization. >> Consider ALTER COLUMN TYPE for instance. > > Obvi

Re: [HACKERS] Allowing NOT IN to use ANTI joins

On 24 June 2014 11:32, David Rowley wrote: > So if anyone can point me in the right direction then that would be > really useful. Many things can be added simply, but most things can't. It seems we just don't have that information. If we did, Tom would have done this already. > On a more positi

Re: [HACKERS] Allowing join removals for more join types

On 23 June 2014 12:06, David Rowley wrote: >> It's not clear to me where you get the term "sortclause" from. This is >> either the groupclause or distinctclause, but in the test cases you >> provide this shows this has nothing at all to do with sorting since >> there is neither an order by or a s

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > Thinking about the examples upthread, a separate issue occurs to me > --- when defining a RLS qual, I think that there has to be a syntax to > specify an alias for the main table, so that correlated subqueries can > refer to it. I'm not sure

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

Thinking about the examples upthread, a separate issue occurs to me --- when defining a RLS qual, I think that there has to be a syntax to specify an alias for the main table, so that correlated subqueries can refer to it. I'm not sure if that's been mentioned in any of the discussions so far, but

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

On 24 June 2014 17:27, Stephen Frost wrote: > Single policy vs Multiple, Overlapping policies vs Multiple, Non-overlapping > policies > What I was describing upthread was multiple non-overlapping policies. I disagree that this will be more complicated to use. It's a strict superset of the singl

Bug in spg_range_quad_inner_consistent for adjacent operator (was Re: [HACKERS] Add a filed to PageHeaderData)

On 06/24/2014 08:48 PM, Pavan Deolasee wrote: FWIW I can reproduce this on HEAD with the attached patch. I could reproduce this on a 64-bit Ubuntu as well as 64-bit Mac OSX. Very confusing it is because I tried with various values for N in char[N] array and it fails for N=20. Other values I tried

Re: [HACKERS] How about a proper TEMPORARY TABLESPACE?

On Sun, Jun 22, 2014 at 2:35 AM, Craig Ringer wrote: > A way to put UNLOGGED objects in such a space and have them recovered > if they vanish would also be valuable, IMO. > > Not necessarily in the same patch, I'd just rather keep it in mind so > any chosen design doesn't preclude adding that lat

[HACKERS] Keepalive-related socket options under FreeBSD 9, 10

Since upgrading FreeBSD from 8 to 9, I've noticed the following messages showing up in logs when a connection with pgAdmin3 is made: LOG: getsockopt(TCP_KEEPCNT) failed: Protocol not available STATEMENT: SELECT setting FROM pg_settings WHERE name IN ('autovacuum', 'track_counts') LOG: getsockop

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

Dave McGuire wrote: > On 06/24/2014 12:42 PM, Tom Lane wrote: > > I think this means we can write off VAX on NetBSD/OpenBSD as a viable > > platform for Postgres :-(. I'm sad to hear it, but certainly have > > not got the cycles personally to prevent it. > > Nonono...NetBSD/vax has had shared

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On 06/24/2014 12:42 PM, Tom Lane wrote: > "Sebastian Reitenbach" writes: >> OK, that was easy: > >> $ cd /usr/ports/databases/postgresql >> $ make install >> ===> postgresql-client-9.3.4p0 requires shared libraries . > >> OpenBSD VAX is static only, so no pos

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On Jun 24, 2014, at 12:42 PM, Tom Lane wrote: > "Sebastian Reitenbach" writes: >> OK, that was easy: > >> $ cd /usr/ports/databases/postgresql >> $ make install >> ===> postgresql-client-9.3.4p0 requires shared libraries . > >> OpenBSD VAX is static only,

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On Jun 24, 2014, at 9:42 AM, Tom Lane wrote: > I think this means we can write off VAX on NetBSD/OpenBSD as a viable > platform for Postgres :-(. I'm sad to hear it, but certainly have > not got the cycles personally to prevent it. Why? NetBSD/vax has supported shared libraries for a long lon

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

Tom Lane skrev 2014-06-24 18:42: "Sebastian Reitenbach" writes: OK, that was easy: $ cd /usr/ports/databases/postgresql $ make install ===> postgresql-client-9.3.4p0 requires shared libraries . OpenBSD VAX is static only, so no postgresql on OpenBSD VAX before shared libraries will ever be ma

Re: [HACKERS] pg_receivexlog add synchronous mode

On Tue, Jun 24, 2014 at 3:18 PM, wrote: >> I found that this patch breaks --status-interval option of >> pg_receivexlog when -m option which the patch introduced is supplied. >> When -m is set, pg_receivexlog tries to send the feedback message as soon >> as it flushes WAL file even if status inte

Re: [HACKERS] idle_in_transaction_timeout

On 06/24/2014 10:17 AM, Tom Lane wrote: > Josh Berkus writes: >> On 06/23/2014 03:52 PM, Andres Freund wrote: >>> True. Which makes me wonder whether we shouldn't default this to >>> something non-zero -- even if it is 5 or 10 days. > >> I'd go for even shorter: 48 hours. I'd suggest 24 hours,

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

Dave McGuire writes: > On 06/24/2014 12:42 PM, Tom Lane wrote: >> I think this means we can write off VAX on NetBSD/OpenBSD as a viable >> platform for Postgres :-(. I'm sad to hear it, but certainly have >> not got the cycles personally to prevent it. > Nonono...NetBSD/vax has had shared libr

Re: [HACKERS] ALTER TABLESPACE MOVE command tag tweak

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > That it's more-or-less a bulk 'ALTER TABLE' operation is why I had been > > trying to think of a way to put it under that command. What if we had a > > more general way to reference 'all objects in a tablespace'? > > "tablespace.*

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

Abhijit, * Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: > At 2014-06-23 16:51:55 -0400, sfr...@snowman.net wrote: > > Are both the connected user and the current role that the command is > > running under logged? > > Yes, they are. -++ Ok, great, I coul

Re: [HACKERS] idle_in_transaction_timeout

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Andres Freund writes: > > On 2014-06-24 10:17:49 -0700, Tom Lane wrote: > >> BTW, has anyone thought about the interaction of this feature with > >> prepared transactions? I wonder whether there shouldn't be a similar but > >> separately-settable maximum t

Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal and patch

On 06/24/2014 06:08 PM, John Lumby wrote: The question is, if you receive the notification of the I/O completion using a signal or a thread, is it safe to release the lwlock from the signal handler or a separate thread? In the forthcoming new version of the patch that uses sigevent, the origin

Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal and patch

Thanks Heikki, > Date: Tue, 24 Jun 2014 17:02:38 +0300 > From: hlinnakan...@vmware.com > To: johnlu...@hotmail.com; st...@mit.edu > CC: klaussfre...@gmail.com; pgsql-hackers@postgresql.org > Subject: Re: Extended Prefetching using Asynchronous IO - proposal

Re: [HACKERS] Add a filed to PageHeaderData

On Tue, Jun 24, 2014 at 3:40 PM, Kevin Grittner wrote: > > Soroosh Sardari wrote: > > > I check this problem with a virgin source code of > > postgresql-9.3.2. So the bug is not for my codes. > > > By the way, following code has two different output and it is > > weird. > > I can confirm that I s

Re: [HACKERS] wrapping in extended mode doesn't work well with default pager

Hi. Is there any problem with the patch? 2014-06-17 0:21 GMT+04:00 Greg Stark : > On Mon, Jun 16, 2014 at 9:05 PM, Robert Haas > wrote: > > So, it seems like we need to do something about this one way or > > another. Who's working on that? > > So I'm fine finishing what I started. I've just b

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

* Fujii Masao (masao.fu...@gmail.com) wrote: > I'm not sure if this is good idea because this basically means that master > and every standbys must have the same audit settings and a user cannot > set what standby logs in standby side. Of course I guess that the audit > settings in standby would be

Re: [HACKERS] idle_in_transaction_timeout

Tom Lane wrote: > Josh Berkus writes: >>> Which makes me wonder whether we shouldn't default this to >>> something non-zero -- even if it is 5 or 10 days. > >> I'd go for even shorter: 48 hours.  I'd suggest 24 hours, but that >> would trip up some users who just need really long pg_dumps. > > F

Re: [HACKERS] idle_in_transaction_timeout

Andres Freund writes: > On 2014-06-24 10:17:49 -0700, Tom Lane wrote: >> BTW, has anyone thought about the interaction of this feature with >> prepared transactions? I wonder whether there shouldn't be a similar but >> separately-settable maximum time for a transaction to stay in the prepared >>

Re: [HACKERS] PostgreSQL in Windows console and Ctrl-C

On Tue, Jun 24, 2014 at 09:24:43AM +, Christian Ullrich wrote: > pg_ctl does not pass the option anywhere but on Windows, and postmaster.c > does not recognize it anywhere else. If it is encountered on a platform where > it does not make sense, it will be treated like any other (unknown) long

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

On Mon, Jun 23, 2014 at 9:50 PM, Stephen Frost wrote: > * Fujii Masao (masao.fu...@gmail.com) wrote: >> On Mon, Jun 23, 2014 at 7:51 PM, Abhijit Menon-Sen >> wrote: >> > At 2014-06-23 19:15:39 +0900, masao.fu...@gmail.com wrote: >> >> You added this into CF, but its patch has not been posted yet

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-24 10:17:49 -0700, Tom Lane wrote: > BTW, has anyone thought about the interaction of this feature with > prepared transactions? I wonder whether there shouldn't be a similar but > separately-settable maximum time for a transaction to stay in the prepared > state. If we could set a non

Re: [HACKERS] Atomics hardware support table & supported architectures

On 2014-06-24 10:22:08 -0700, Tom Lane wrote: > Andres Freund writes: > > On 2014-06-24 13:03:37 -0400, Noah Misch wrote: > >> If a change has the potential to make some architectures give wrong > >> answers only at odd times, that's a different kind of problem. For > >> that reason, actively bre

Re: [HACKERS] Atomics hardware support table & supported architectures

On Tue, Jun 24, 2014 at 07:09:08PM +0200, Andres Freund wrote: > On 2014-06-24 13:03:37 -0400, Noah Misch wrote: > > What I'm hearing is that you see two options, (1) personally authoring > > e.g. sparcv8 code or (2) purging the source tree of sparcv8 code before > > submitting the patch that would

Re: [HACKERS] idle_in_transaction_timeout

On 06/24/2014 07:17 PM, Tom Lane wrote: > BTW, has anyone thought about the interaction of this feature with > prepared transactions? I wonder whether there shouldn't be a similar but > separately-settable maximum time for a transaction to stay in the prepared > state. If we could set a nonzero d

Re: [HACKERS] Atomics hardware support table & supported architectures

Andres Freund writes: > On 2014-06-24 13:03:37 -0400, Noah Misch wrote: >> If a change has the potential to make some architectures give wrong >> answers only at odd times, that's a different kind of problem. For >> that reason, actively breaking Alpha is a good thing. > Not sure what you mean w

Re: [HACKERS] idle_in_transaction_timeout

Josh Berkus writes: > On 06/23/2014 03:52 PM, Andres Freund wrote: >> True. Which makes me wonder whether we shouldn't default this to >> something non-zero -- even if it is 5 or 10 days. > I'd go for even shorter: 48 hours. I'd suggest 24 hours, but that would > trip up some users who just nee

Re: [HACKERS] Atomics hardware support table & supported architectures

On 2014-06-24 13:03:37 -0400, Noah Misch wrote: > On Mon, Jun 23, 2014 at 05:16:15PM +0200, Andres Freund wrote: > > On 2014-06-23 10:29:54 -0400, Robert Haas wrote: > > > Telling people that > > > they can't have even the most minimal platform support code in > > > PostgreSQL unless they're willin

Re: [HACKERS] idle_in_transaction_timeout

Josh Berkus writes: > On 06/24/2014 07:50 AM, Vik Fearing wrote: >> Once the remote times out, the local transaction is doomed (and won't >> even know it until it tries to commit). If we don't allow the fdw to be >> special, then the local transaction can't run at all. Ever. > I'm unclear on ho

Re: [HACKERS] Atomics hardware support table & supported architectures

On Mon, Jun 23, 2014 at 05:16:15PM +0200, Andres Freund wrote: > On 2014-06-23 10:29:54 -0400, Robert Haas wrote: > > Telling people that > > they can't have even the most minimal platform support code in > > PostgreSQL unless they're willing to contribute and maintain a BF VM > > indefinitely is n

Re: [HACKERS] idle_in_transaction_timeout

On 06/24/2014 07:50 AM, Vik Fearing wrote: > On 06/24/2014 04:04 PM, Robert Haas wrote: >>> If the local transaction is actually idle in transaction and the local server doesn't have a timeout, we're no worse off than before this patch. >> >> I think we are. First, the correct timeout is a ma

Re: [HACKERS] [BUGS] BUG #10728: json_to_recordset with nested json objects NULLs columns

On Tue, Jun 24, 2014 at 9:08 AM, Andrew Dunstan wrote: > w.r.t. json arrays, I think you're chasing a chimera, since they are > heterogenous, unlike SQL arrays. But, there are many useful cases where the json is known to be well formed, right? Or do you mean that the difficulties stem from simpl

Re: [HACKERS] idle_in_transaction_timeout

2014-06-24 18:43 GMT+02:00 Josh Berkus : > On 06/23/2014 03:52 PM, Andres Freund wrote: > > On 2014-06-23 13:19:47 -0700, Kevin Grittner wrote: > > which already seems less clear (because the transaction belongs > > to idle) > >> > >> I have no idea what that means. > > > > It's "idle_in_t

Re: [HACKERS] idle_in_transaction_timeout

On 06/24/2014 06:43 PM, Josh Berkus wrote: A long idle in transaction state pretty much always indicates a >>> problematic interaction with postgres. >>> >> >>> >> True. Which makes me wonder whether we shouldn't default this to >>> >> something non-zero -- even if it is 5 or 10 days. >

Re: [HACKERS] Autonomous Transaction (WIP)

Hello There are lot of unnecessary block over one statement in code + if ((inAutoX) && (chunk == events->head) && ((char *)event < afterTriggers->events_stack[my_level].tailfree)) + { + continue; + } + and there a few too long line

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

"Sebastian Reitenbach" writes: > OK, that was easy: > $ cd /usr/ports/databases/postgresql > $ make install > ===> postgresql-client-9.3.4p0 requires shared libraries . > OpenBSD VAX is static only, so no postgresql on OpenBSD > VAX before shared libraries wi

Re: [HACKERS] idle_in_transaction_timeout

On 06/23/2014 03:52 PM, Andres Freund wrote: > On 2014-06-23 13:19:47 -0700, Kevin Grittner wrote: > which already seems less clear (because the transaction belongs > to idle) >> >> I have no idea what that means. > > It's "idle_in_transaction"_session_timeout. Not > "idle_in"_transaction_

Re: [HACKERS] Autonomous Transaction (WIP)

postgres=# select version(); version - PostgreSQL 9.5devel on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.8.2 20131212 (Red Hat 4.8.2-7), 64-bit (1 row) 2014-06-24 18:39 GMT+02

Re: [HACKERS] Autonomous Transaction (WIP)

Hello regress tests fails: plancache... ok limit... ok plpgsql ... ok copy2... ok temp ... FAILED domain ... ok rangefuncs ... ok pr

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

Robert, I feel like we are getting to the point of simply talking past each other and so I'll try anew, and I'll include my understanding of how the different approaches would address the specific use-case you outlined up-thread. Single policy - The current implementation approach onl

Re: [HACKERS] idle_in_transaction_timeout

On Tue, Jun 24, 2014 at 11:11 AM, Robert Haas [via PostgreSQL] < ml-node+s1045698n5808915...@n5.nabble.com> wrote: > On Tue, Jun 24, 2014 at 10:50 AM, Vik Fearing <[hidden email] > > wrote: > > > On 06/24/2014 04:04 PM, Robert Haas wrote: > >>>

Re: [HACKERS] idle_in_transaction_timeout

On Tue, Jun 24, 2014 at 10:50 AM, Vik Fearing wrote: > On 06/24/2014 04:04 PM, Robert Haas wrote: >>> If the local transaction is actually idle in transaction and the local >>> > server doesn't have a timeout, we're no worse off than before this patch. >> >> I think we are. First, the correct tim

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

On Tue, Jun 24, 2014 at 10:30 AM, Alvaro Herrera wrote: > Robert Haas wrote: >> > Right, if we were to support multiple policies on a given table then we >> > would have to support adding and removing them individually, as well as >> > specify when they are to be applied- and what if that "when" o

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

Well the latest NetBSD/vax package build doesn't seem to include any PostgreSQL packages http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/vax/6.0_2014Q1/ but I don't know why. I'll try a quick (hah :) build this end to see what happens David On 24 June 2014 02:12, Robert Haas wrote: > On Mon

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On Tuesday, June 24, 2014 13:37 CEST, "Sebastian Reitenbach" wrote: > On Tuesday, June 24, 2014 03:12 CEST, Robert Haas > wrote: > > > On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark wrote: > > > On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas > > > wrote: > > >> However, we don't know of anyone

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On Tuesday, June 24, 2014 03:12 CEST, Robert Haas wrote: > On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark wrote: > > On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas wrote: > >> However, we don't know of anyone who has tried to do this in a very > >> long time, and are therefore considering removing

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On 06/23/2014 06:58 PM, Greg Stark wrote: > On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas wrote: >> However, we don't know of anyone who has tried to do this in a very >> long time, and are therefore considering removing the remaining >> support for the VAX platform. Has anyone tried to build Post

Re: [HACKERS] idle_in_transaction_timeout

On 06/24/2014 04:04 PM, Robert Haas wrote: >> If the local transaction is actually idle in transaction and the local >> > server doesn't have a timeout, we're no worse off than before this patch. > > I think we are. First, the correct timeout is a matter of > remote-server-policy, not local-server

Re: [HACKERS] crash with assertions and WAL_DEBUG

Heikki Linnakangas wrote: > On 06/21/2014 01:58 PM, Heikki Linnakangas wrote: > >It's a bit difficult to attach the mark to the palloc calls, as neither > >the WAL_DEBUG or LWLOCK_STATS code is calling palloc directly, but > >marking specific MemoryContexts as sanctioned ought to work. I'll take a

Re: [HACKERS] idle_in_transaction_timeout

On Tue, Jun 24, 2014 at 10:05 AM, Robert Haas [via PostgreSQL] < ml-node+s1045698n580889...@n5.nabble.com> wrote: > On Tue, Jun 24, 2014 at 9:18 AM, Vik Fearing <[hidden email] > > wrote: > > > On 06/22/2014 05:11 PM, Kevin Grittner wrote: > >>

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

Robert Haas wrote: > > Right, if we were to support multiple policies on a given table then we > > would have to support adding and removing them individually, as well as > > specify when they are to be applied- and what if that "when" overlaps? > > Do we apply both and only a row which passed the

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-24 10:04:03 -0400, Robert Haas wrote: > On Tue, Jun 24, 2014 at 9:18 AM, Vik Fearing wrote: > > My reasoning for doing it the way I did is that if a transaction touches > > a foreign table and then goes bumbling along with other things the > > transaction is active but the connection to

Re: [HACKERS] crash with assertions and WAL_DEBUG

Hello, The patch on compilation gives following error, mcxt.c: In function ‘MemoryContextAllowInCriticalSection’: mcxt.c:322: error: ‘struct MemoryContextData’ has no member named ‘allowInCriticalSection’ The member in MemoryContextData is defined as 'allowInCritSection' while the MemoryContextA

Re: [HACKERS] [BUGS] BUG #10728: json_to_recordset with nested json objects NULLs columns

On 06/23/2014 09:43 PM, Tom Lane wrote: Andrew Dunstan writes: On 06/23/2014 07:34 PM, Tom Lane wrote: I'm not following your comment about 9.3. The json[b]_to_record[set] functions are new in 9.4, which is what makes me feel it's not too late to redefine their behavior. But changing behavi

Re: [HACKERS] idle_in_transaction_timeout

On Tue, Jun 24, 2014 at 9:18 AM, Vik Fearing wrote: > On 06/22/2014 05:11 PM, Kevin Grittner wrote: >> I found one substantive issue that had been missed in discussion, >> though. The patch modifies the postgres_fdw extension to make it >> automatically exempt from an attempt to set a limit like

Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal and patch

On 06/24/2014 04:29 PM, John Lumby wrote: On Mon, Jun 23, 2014 at 2:43 PM, John Lumby wrote: It is when some *other* backend gets there first with the ReadBuffer that things are a bit trickier. The current version of the patch did polling for that case but that drew criticism, and so an immine

Re: [HACKERS] idle_in_transaction_timeout

On 06/24/2014 03:29 PM, David G Johnston wrote: > On Tue, Jun 24, 2014 at 9:20 AM, Vik Fearing [via PostgreSQL] <[hidden > email] >wrote: > > On 06/22/2014 05:11 PM, Kevin Grittner wrote: > > I found one substantive issue that had been missed in discussion, > > though. The patch modif

Re: [HACKERS] idle_in_transaction_timeout

David G Johnston wrote: > Vik Fearing [via PostgreSQL] <[hidden email]>wrote: >> On 06/22/2014 05:11 PM, Kevin Grittner wrote: >>> I found one substantive issue that had been missed in discussion, >>> though.  The patch modifies the postgres_fdw extension to make it >>> automatically exempt from a

Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal and patch

> From: st...@mit.edu > Date: Mon, 23 Jun 2014 16:04:50 -0700 > Subject: Re: Extended Prefetching using Asynchronous IO - proposal and patch > To: johnlu...@hotmail.com > CC: klaussfre...@gmail.com; hlinnakan...@vmware.com; > pgsql-hackers@postgresql.org

Re: [HACKERS] idle_in_transaction_timeout

On Tue, Jun 24, 2014 at 9:20 AM, Vik Fearing [via PostgreSQL] < ml-node+s1045698n5808882...@n5.nabble.com> wrote: > On 06/22/2014 05:11 PM, Kevin Grittner wrote: > > I found one substantive issue that had been missed in discussion, > > though. The patch modifies the postgres_fdw extension to make

Re: [HACKERS] idle_in_transaction_timeout

On 06/22/2014 05:11 PM, Kevin Grittner wrote: > I found one substantive issue that had been missed in discussion, > though. The patch modifies the postgres_fdw extension to make it > automatically exempt from an attempt to set a limit like this on > the server to which it connects. I'm not sure t

Re: [HACKERS] [BUGS] BUG #10728: json_to_recordset with nested json objects NULLs columns

On Mon, Jun 23, 2014 at 8:43 PM, Tom Lane wrote: > * Nested json arrays are a bit more problematic. What I'd ideally like > is to spit them out in a form that would be successfully parsable as a SQL > array of the appropriate element type. Unfortunately, I think that that > ship has sailed becau

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

On Mon, Jun 23, 2014 at 6:51 AM, Abhijit Menon-Sen wrote: > There are some unresolved questions with #2 because the extensible > reloptions patch seems to have lost favour, but I'm pretty sure we > could figure out some alternative. I didn't particularly like the proposed *implementation* of exte

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On Tue, Jun 24, 2014 at 7:45 AM, Sebastian Reitenbach wrote: >> I'm building the vax packages for openbsd. What I can tell is that >> for 5.5 no postgresql packages were built. But that may be that >> due to the recent upgrade from gcc 2.95 to 3.3. >> I guess that not all dependencies to actually

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

On Mon, Jun 23, 2014 at 2:29 PM, Stephen Frost wrote: > What are these policies going to depend on? Will they be allowed to > overlap? I don't see multi-policy support as being very easily added. We discussed the point about overlap upthread, and I gave specific examples. If there's something

Re: [HACKERS] Add a filed to PageHeaderData

On Tue, Jun 24, 2014 at 3:27 PM, Andres Freund wrote: > On 2014-06-24 15:23:54 +0430, Soroosh Sardari wrote: > > On Tue, Jun 24, 2014 at 2:40 PM, Kevin Grittner > wrote: > > > > > Soroosh Sardari wrote: > > > > > > > I check this problem with a virgin source code of > > > > postgresql-9.3.2. So

Re: [HACKERS] Hooks Docu - list of hooks

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/06/14 12:59, Abhijit Menon-Sen wrote: > At 2014-06-24 12:49:17 +0200, li...@hasibether.at wrote: >> >> Is there a list of possible hooks, or maybe a little docu or overview? > > The best I found was "git grep _hook_type" and then read the code

Re: [HACKERS] Hooks Docu - list of hooks

At 2014-06-24 12:49:17 +0200, li...@hasibether.at wrote: > > Is there a list of possible hooks, or maybe a little docu or overview? The best I found was "git grep _hook_type" and then read the code to understand when and why the hook was called. > Especially hooks to catch Insert, Update and Dele

Re: [HACKERS] PostgreSQL in Windows console and Ctrl-C

From: "Christian Ullrich" On non-Windows platforms, the --background option is not passed, and the option handling is unmodified except for an additional pair of braces. The postmaster does not pass the option to its children on any platform. pg_ctl does not pass the option anywhere but on Wind

  1   2   >