Re: [HACKERS] Autonomous Transaction (WIP)

2014-07-01 8:29 GMT+02:00 Amit Kapila : > On Tue, Jul 1, 2014 at 11:46 AM, Rajeev rastogi > wrote: > > On 30 June 2014 22:50, Pavel Stehule Wrote: > > > > >I didn't find a related message. > > >? > > > > I think there have been some confusion, the design idea were never > rejected but yes there w

Re: [HACKERS] inherit support for foreign tables

(2014/07/01 15:13), Ashutosh Bapat wrote: On Tue, Jul 1, 2014 at 7:39 AM, Etsuro Fujita mailto:fujita.ets...@lab.ntt.co.jp>> wrote: We may want to modify use_physical_tlist(), to return false, in case of foreign tables. BTW, it does return false for inheritance trees. Yeah, but please consid

Re: [HACKERS] Long paths for tablespace leads to uninterruptible hang in Windows

On Sat, Feb 15, 2014 at 1:26 PM, Amit Kapila wrote: > On Fri, Feb 14, 2014 at 8:27 AM, Bruce Momjian wrote: > > On Tue, Jan 7, 2014 at 12:33:33PM +0530, Amit Kapila wrote: > >> Still they have not told anything about other API's > >> (rmdir, RemoveDirectory) which has same problem. > > > > Wher

Re: [HACKERS] Autonomous Transaction (WIP)

On Tue, Jul 1, 2014 at 11:46 AM, Rajeev rastogi wrote: > On 30 June 2014 22:50, Pavel Stehule Wrote: > > >I didn't find a related message. > >? > > I think there have been some confusion, the design idea were never rejected but yes there were few feedback/ concern, which I had clarified. Also some

Re: [HACKERS] inherit support for foreign tables

Hello, Sorry, this was no relation with this patch. ForeignNext materializes the slot, which would be any of physical and virtual tuple, when system column was requested. If it was a virtual one, file_fdw makes this, heap_form_tuple generates the tuple as DatumTuple. The result is a jumble of vir

Re: [HACKERS] Autonomous Transaction (WIP)

2014-07-01 8:16 GMT+02:00 Rajeev rastogi : > On 30 June 2014 22:50, Pavel Stehule Wrote: > > 2014-06-30 12:38 GMT+02:00 Abhijit Menon-Sen : > > >>If I understand correctly, the design of this patch has already been > >>considered earlier and rejected. So I guess the patch should also be > >>marke

Re: [HACKERS] Autonomous Transaction (WIP)

On 30 June 2014 22:50, Pavel Stehule Wrote: 2014-06-30 12:38 GMT+02:00 Abhijit Menon-Sen mailto:a...@2ndquadrant.com>>: >>If I understand correctly, the design of this patch has already been >>considered earlier and rejected. So I guess the patch should also be >>marked rejected? >I didn't find a

Re: [HACKERS] inherit support for foreign tables

On Tue, Jul 1, 2014 at 7:39 AM, Etsuro Fujita wrote: > (2014/06/30 20:17), Ashutosh Bapat wrote: > >> On Mon, Jun 30, 2014 at 4:17 PM, Etsuro Fujita >> mailto:fujita.ets...@lab.ntt.co.jp>> wrote: >> > > (2014/06/30 17:47), Ashutosh Bapat wrote: >> > > BTW, why aren't you using the t

Re: [HACKERS] inherit support for foreign tables

If we are going to change that portion of the code, we may as well go a bit forward and allow any expressions to be fetched from a foreign server (obviously, if that server is capable of doing so). It will help, when we come to aggregate push-down or whole query push-down (whenever that happens). S

Re: [HACKERS] pg_receivexlog add synchronous mode

> > > > Synchronous(synchronous_commit = on) mode offers the ability to > > > confirm WAL have been streamed in the same way as synchronous > > > replication. > > > > If an output is used as a different disk from the directory where > > > > the > > > transaction log should be stored. > > > > Preven

Re: [HACKERS] better atomics - v0.5

On Mon, Jun 30, 2014 at 2:54 PM, Andres Freund wrote: > On 2014-06-30 11:04:53 +0530, Amit Kapila wrote: > > On Sun, Jun 29, 2014 at 2:54 PM, Andres Freund wrote: > > > Yes, intentionally so. It's often important to get/set the current value > > > without the cost of emitting a memory barrier. I

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On 01 July 2014 03:48, Alvaro Wrote, > > In particular, pgpipe is almost an exact duplicate between them, > > except the copy in vac_parallel.c has fallen behind changes made to > > parallel.c. (Those changes would have fixed the Windows warnings). > I > > think that this function (and perhaps ot

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On 01 July 2014 03:31, Jeff Janes Wrote, > > I get a compiler warning when building on Windows. When I started > looking into that, I see that two files have too much code duplication > between them: Thanks for Reviewing, > > src/bin/scripts/vac_parallel.c (new file) > src/bin/pg_dump/paral

[HACKERS] TODO item: immutable date_trunc with timezone arg

Currently it's unsafe/not possible to use some funtions, like date_trunc, in immutable functions and expression indexes. It'd be really useful to have an immutable version that took the timezone as an argument. Maybe this is a worthwhile beginner TODO item for the wiki? I'm sure there are other f

Re: [HACKERS] Escaping from blocked send() reprised.

Hello, The replies follow are mainly as a memo for myself so please don't be bothered to answer until the time comes. At Mon, 30 Jun 2014 11:27:47 -0400, Robert Haas wrote in > You should probably add your patch here, so it doesn't get forgotten about: > > https://commitfest.postgresql.org/act

Re: [HACKERS] heap vacuum & cleanup locks

On Mon, Jun 30, 2014 at 7:55 PM, Greg Stark wrote: > On Wed, Nov 2, 2011 at 3:19 PM, Robert Haas wrote: >> On Tue, Jun 7, 2011 at 3:24 PM, Greg Stark wrote: >>> Well it's super-exclusive-vacuum-lock avoidance techniques. Why >>> shouldn't it make more sense to try to reduce the frequency and imp

Re: [HACKERS] Spinlocks and compiler/memory barriers

On Mon, Jun 30, 2014 at 6:28 PM, Andres Freund wrote: > On 2014-06-30 19:22:59 +0200, Andres Freund wrote: >> On 2014-06-30 12:46:29 -0400, Robert Haas wrote: >> >, which if I understand you correctly are ARM without GCC >> > atomics, Sparc, and MIPS. >> >> I've to revise my statement on MIPS, it

Re: [HACKERS] inherit support for foreign tables

Hello, > > BTW, why aren't you using the tlist passed to this function? I guess > >> create_scan_plan() passes tlist after processing it, so that should be > >> used rather than rel->reltargetlist. > >> > > > > I think that that would be maybe OK, but I think that it would not be > > efficient to

Re: [HACKERS] inherit support for foreign tables

(2014/06/30 22:48), Tom Lane wrote: > Etsuro Fujita writes: >> Done. I think this is because create_foreignscan_plan() makes reference >> to attr_needed, which isn't computed for inheritance children. > > I wonder whether it isn't time to change that. It was coded like that > originally only be

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

On Mon, Jun 30, 2014 at 09:16:45PM +, Christian Ullrich wrote: > * From: Noah Misch [mailto:n...@leadboat.com] > > Yes; the consequence of ignoring ^C is that the test postmaster would > > persist indefinitely after the ^C. The system under test doesn't care per > > No it won't, please see be

Re: [HACKERS] inherit support for foreign tables

(2014/06/30 20:17), Ashutosh Bapat wrote: On Mon, Jun 30, 2014 at 4:17 PM, Etsuro Fujita mailto:fujita.ets...@lab.ntt.co.jp>> wrote: (2014/06/30 17:47), Ashutosh Bapat wrote: BTW, why aren't you using the tlist passed to this function? I guess create_scan_plan() passes t

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

Abhijit Menon-Sen writes: > At 2014-06-30 15:19:17 -0400, t...@sss.pgh.pa.us wrote: >> It's not unlikely that we want this patch *and* an improvement that >> allows multi-character src strings > I think it's enough to apply just this patch, but I wouldn't object to > doing both if it were easy. I

Re: [HACKERS] better atomics - v0.5

On Mon, Jun 30, 2014 at 07:44:47PM +0200, Andres Freund wrote: > On 2014-06-30 13:15:23 -0400, Robert Haas wrote: > > I'm personally not convinced that we're approaching this topic in the > > right way. I'm not convinced that it's at all reasonable to try to > > emulate atomics on platforms that d

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

Well, the issue from our point of view is that a lot of what we care about testing is extremely low-level hardware behavior, like whether spinlocks work as expected across processors. It's not clear that a simulator would provide a sufficiently accurate emulation. OTOH, the really nasty issues l

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

Last I checked, NetBSD doesn't support any sort of multiprocessor VAX. Multiprocessor VAXes exist, but you're stuck with either Ultrix or VMS on them. Pat On Sun, Jun 29, 2014 at 2:06 PM, Tom Lane wrote: > Dave McGuire writes: > > On 06/29/2014 10:54 AM, Andres Freund wrote: > >> Maybe I'm j

Re: [HACKERS] Cluster name in ps output

Hi, On 2014-06-28 15:08:45 +0200, Andres Freund wrote: > Otherwise it looks good to me. So, I'd looked at it with an eye towards committing it and found some more things. I've now * added the restriction that the cluster name can only be ASCII. It's shown from several clusters with differing en

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

Dave McGuire skrev 2014-06-29 21:01: On 06/29/2014 02:58 PM, Patrick Finnegan wrote: Last I checked, NetBSD doesn't support any sort of multiprocessor VAX. Multiprocessor VAXes exist, but you're stuck with either Ultrix or VMS on them. Hi Pat, it's good to see your name in my inbox. N

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

On Sun, Jun 29, 2014 at 3:01 PM, Dave McGuire wrote: > On 06/29/2014 02:58 PM, Patrick Finnegan wrote: > > Last I checked, NetBSD doesn't support any sort of multiprocessor VAX. > > Multiprocessor VAXes exist, but you're stuck with either Ultrix or VMS > > on them. > > Hi Pat, it's good to see

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

On Sun, Jun 29, 2014 at 3:12 PM, Dave McGuire wrote: > On 06/29/2014 03:10 PM, Patrick Finnegan wrote: > > And it also runs on the 11/780 which can have multiple CPUs... but I've > > never seen support for using more than one CPU (and the NetBSD page > > still says "NetBSD/vax can only make use o

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

On 06/29/2014 03:10 PM, Patrick Finnegan wrote: > And it also runs on the 11/780 which can have multiple CPUs... but I've > never seen support for using more than one CPU (and the NetBSD page > still says "NetBSD/vax can only make use of one CPU on multi-CPU > machines"). If that has changed, I'd

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

On 06/29/2014 10:24 AM, Tom Lane wrote: >>> Is there anyone in the NetBSD/VAX community who would be willing to >>> host a PG buildfarm member? > >> I could put together a simh-based machine (i.e., fast) on a vm, if >> nobody else has stepped up for this. > > No other volunteers have emerged, s

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

Jeff Janes wrote: > In particular, pgpipe is almost an exact duplicate between them, > except the copy in vac_parallel.c has fallen behind changes made to > parallel.c. (Those changes would have fixed the Windows warnings). I > think that this function (and perhaps other parts as > well--"exit_h

Re: [HACKERS] heap vacuum & cleanup locks

Zombie thread arise! I was searching for old threads on a specific problem and came across this patch that was dropped due to concerns about SnapshotNow: On Wed, Nov 2, 2011 at 3:19 PM, Robert Haas wrote: > On Tue, Jun 7, 2011 at 3:24 PM, Greg Stark wrote: >> Well it's super-exclusive-vacuum-lo

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

Abhijit Menon-Sen writes: > At 2014-06-30 15:19:17 -0400, t...@sss.pgh.pa.us wrote: >> Anyway, this raises the question of whether the current patch is >> actually a desirable way to do things, or whether it would be better >> if the unaccenting rules were like "base-char accent-char" -> >> "base-

Re: [HACKERS] bad estimation together with large work_mem generates terrible slow hash joins

On 30.6.2014 23:12, Tomas Vondra wrote: > Hi, > > attached is v5 of the patch. The main change is that scaling the number > of buckets is done only once, after the initial hash table is build. The > main advantage of this is lower price. This also allowed some cleanup of > unecessary code. > > Ho

Re: [HACKERS] Spinlocks and compiler/memory barriers

On 2014-06-30 19:22:59 +0200, Andres Freund wrote: > On 2014-06-30 12:46:29 -0400, Robert Haas wrote: > >, which if I understand you correctly are ARM without GCC > > atomics, Sparc, and MIPS. > > I've to revise my statement on MIPS, it actually looks safe. I seem to > have missed that it has its

Re: [HACKERS] WAL format and API changes (9.5)

On Tue, Jul 1, 2014 at 5:51 AM, Heikki Linnakangas wrote: > Thanks for the review! > > > On 06/27/2014 09:12 AM, Michael Paquier wrote: >> >> Looking at this patch, it does not compile when assertions are enabled >> because of this assertion in heapam.c: >> Assert(recdata == data + datalen); >> It

[HACKERS] Fresh initdb contains a few deleted B-Tree pages

I would like to put on the record that there are a few deleted B-Tree pages in a freshly initdb'd database. As my btreecheck tools shows: mgd=# select bt_index_verify(indexrelid::regclass::text) from pg_index; NOTICE: 0: page 12 of index "pg_attribute_relid_attnam_index" is deleted LOCATION:

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On Fri, Jun 27, 2014 at 4:10 AM, Dilip kumar wrote: ... > > Updated patch is attached in the mail.. Thanks Dilip. I get a compiler warning when building on Windows. When I started looking into that, I see that two files have too much code duplication between them: src/bin/scripts/vac_parallel.

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

* From: Noah Misch [mailto:n...@leadboat.com] > On Mon, Jun 30, 2014 at 07:28:03PM +, Christian Ullrich wrote: > > * From: Noah Misch [mailto:n...@leadboat.com] > > > I liked the proposal here; was there a problem with it? > > > http://www.postgresql.org/message- > > > id/ca+tgmoz3ake4enctmq

Re: [HACKERS] bad estimation together with large work_mem generates terrible slow hash joins

Hi, attached is v5 of the patch. The main change is that scaling the number of buckets is done only once, after the initial hash table is build. The main advantage of this is lower price. This also allowed some cleanup of unecessary code. However, this new patch causes warning like this: WAR

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

On Mon, Jun 30, 2014 at 07:28:03PM +, Christian Ullrich wrote: > * From: Noah Misch [mailto:n...@leadboat.com] > > > I liked the proposal here; was there a problem with it? > > http://www.postgresql.org/message- > > id/ca+tgmoz3ake4enctmqmzsykc_0pjl_u4c_x47ge48uy1upb...@mail.gmail.com > > You

Re: [HACKERS] better atomics - v0.5

On 2014-06-30 13:45:52 -0400, Tom Lane wrote: > Robert Haas writes: > > I'm personally not convinced that we're approaching this topic in the > > right way. I'm not convinced that it's at all reasonable to try to > > emulate atomics on platforms that don't have them. I would punt the > > problem

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

At 2014-06-30 15:19:17 -0400, t...@sss.pgh.pa.us wrote: > > Anyway, this raises the question of whether the current patch is > actually a desirable way to do things, or whether it would be better > if the unaccenting rules were like "base-char accent-char" -> > "base-char". It might be useful to b

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

* From: Noah Misch [mailto:n...@leadboat.com] > I liked the proposal here; was there a problem with it? > http://www.postgresql.org/message- > id/ca+tgmoz3ake4enctmqmzsykc_0pjl_u4c_x47ge48uy1upb...@mail.gmail.com You're referring to the suggestion of accepting and ignoring the option on non-Windo

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

Abhijit Menon-Sen writes: > I've attached a patch to contrib/unaccent as outlined in my review the > other day. I went to commit this, and while testing I realized that the current implementation of unaccent_lexize is only capable of coping with "src" strings that are single characters in the cur

Re: [HACKERS] Cluster name in ps output

On 2014-06-30 12:10:53 -0700, Josh Berkus wrote: > Abjit, all: > > If we're adding log_line_prefix support for cluster_name (something I > think is a good idea), we need to also add it to CSVLOG. So, where do > we put it in CSVLog? That was shot down (unfortunately imo), and I don't think anybod

Re: [HACKERS] Cluster name in ps output

Abjit, all: If we're adding log_line_prefix support for cluster_name (something I think is a good idea), we need to also add it to CSVLOG. So, where do we put it in CSVLog? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postg

Re: [HACKERS] better atomics - v0.5

On 2014-06-30 19:44:47 +0200, Andres Freund wrote: > On 2014-06-30 13:15:23 -0400, Robert Haas wrote: > > People who write code that uses atomics are not > > likely to think about how those algorithms will actually perform when > > those atomics are merely emulated, and I suspect that means that in

Re: [HACKERS] better atomics - v0.5

On 2014-06-30 12:54:10 -0400, Tom Lane wrote: > Robert Haas writes: > > ... this again is my point: why can't we make the same argument about > > two spinlocks situated on the same cache line? I don't have a bit of > > trouble believing that doing the same thing with a couple of spinlocks > > cou

Re: [HACKERS] better atomics - v0.5

Robert Haas writes: > I'm personally not convinced that we're approaching this topic in the > right way. I'm not convinced that it's at all reasonable to try to > emulate atomics on platforms that don't have them. I would punt the > problem into the next layer and force things like lwlock.c to h

Re: [HACKERS] Set new system identifier using pg_resetxlog

Andres Freund wrote: > c) We already allow to set pretty much all aspects of the control file >via resetxlog - there seems little point of not having the ability to >change the system identifier. I think it's pretty much a given that pg_resetxlog is a tool that can have disastrous effects

Re: [HACKERS] better atomics - v0.5

On 2014-06-30 13:15:23 -0400, Robert Haas wrote: > On Mon, Jun 30, 2014 at 12:54 PM, Tom Lane wrote: > > The existing coding rules also discourage spinlocking within a spinlock, > > and the reason for that is that there's no very clear upper bound to the > > time required to obtain a spinlock, so

Re: [HACKERS] Does changing attribute order breaks something?

geohas writes: > Are there any known issues when changing the attnums? > airport=# update pg_attribute set attnum = 3 where attname = 'abc' and > attrelid = 18328; > UPDATE 1 > airport=# update pg_attribute set attnum = 2 where attname = 'foo' and > attrelid = 18328; > UPDATE 1 I assume you quic

Re: [HACKERS] Spinlocks and compiler/memory barriers

On 2014-06-30 12:46:29 -0400, Robert Haas wrote: > >> But trying to use a spinlock > >> acquire-release to shore up problems with the spinlock release > >> implementation makes my head explode. > > > > Well, it actually makes some sense. Nearly any TAS() implementation is > > going to have some mem

Re: [HACKERS] Autonomous Transaction (WIP)

2014-06-30 12:38 GMT+02:00 Abhijit Menon-Sen : > If I understand correctly, the design of this patch has already been > considered earlier and rejected. So I guess the patch should also be > marked rejected? > I didn't find a related message. ? Regards Pavel > > -- Abhijit >

Re: [HACKERS] better atomics - v0.5

On Mon, Jun 30, 2014 at 12:54 PM, Tom Lane wrote: > The existing coding rules also discourage spinlocking within a spinlock, > and the reason for that is that there's no very clear upper bound to the > time required to obtain a spinlock, so that there would also be no clear > upper bound to the ti

Re: [HACKERS] [WIP] Better partial index-only scans

Abhijit Menon-Sen writes: > I don't think it's fair to mark this as returned with feedback without a > more detailed review (I think of returned with feedback as providing a > concrete direction to follow). I've set it back to "needs review". > Does anyone else want to look at this patch? I offe

Re: [HACKERS] better atomics - v0.5

Robert Haas writes: > ... this again is my point: why can't we make the same argument about > two spinlocks situated on the same cache line? I don't have a bit of > trouble believing that doing the same thing with a couple of spinlocks > could sometimes work out well, too, but Tom is adamantly op

Re: [HACKERS] better atomics - v0.5

On 2014-06-30 12:15:06 -0400, Robert Haas wrote: > More broadly, it doesn't seem consistent. I think that other projects > also sometimes write code that acquires a spinlock while holding > another spinlock, and we don't do that; in fact, we've elevated that > to a principle, regardless of whether

Re: [HACKERS] Spinlocks and compiler/memory barriers

On Mon, Jun 30, 2014 at 12:20 PM, Andres Freund wrote: > On 2014-06-30 11:38:31 -0400, Robert Haas wrote: >> On Mon, Jun 30, 2014 at 11:17 AM, Andres Freund >> wrote: >> >> Now, we want to make these >> >> operations compiler fences as well, and AIUI your proposal for that is >> >> to make NEW_S

[HACKERS] Does changing attribute order breaks something?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Are there any known issues when changing the attnums? like : airport=# update pg_attribute set attnum = 3 where attname = 'abc' and attrelid = 18328; UPDATE 1 airport=# update pg_attribute set attnum = 2 where attname = 'foo' and attrelid = 183

Re: [HACKERS] delta relations in AFTER triggers

David Fetter wrote: > It's missing a few pieces like surfacing transition table names. > I'll work on those.  Also, it's not clear to me how to access the > pre- and post- relations at the same time, this being necessary > for many use cases.  I guess I need to think more about how that > would

Re: [HACKERS] Spinlocks and compiler/memory barriers

On 2014-06-30 11:38:31 -0400, Robert Haas wrote: > On Mon, Jun 30, 2014 at 11:17 AM, Andres Freund > wrote: > >> Now, we want to make these > >> operations compiler fences as well, and AIUI your proposal for that is > >> to make NEW_S_UNLOCK(lock) = out of line function call + S_LOCK(dummy) > >>

Re: [HACKERS] [WIP] Better partial index-only scans

Joshua Yanovski writes: > Proof of concept initial patch for enabling index only scans for > partial indices even when an attribute is not in the target list, as > long as it is only used in restriction clauses that can be proved by > the index predicate. This also works for index quals, though t

Re: [HACKERS] better atomics - v0.5

On Sat, Jun 28, 2014 at 4:25 AM, Andres Freund wrote: >> > To make pin/unpin et al safe without acquiring the spinlock the pincount >> > and the flags had to be moved into one variable so that when >> > incrementing the pincount you automatically get the flagbits back. If >> > it's currently valid

[HACKERS] 9.4 logical replication - walsender keepalive replies

In 9.4 we've the below block of code to walsender.c as /* * We only send regular messages to the client for full decoded * transactions, but a synchronous replication and walsender shutdown * possibly are waiting for a later location. So we send pings * containing the flush location every no

Re: [HACKERS] Spinlocks and compiler/memory barriers

On Mon, Jun 30, 2014 at 11:17 AM, Andres Freund wrote: >> > Solaris seems to run with TSO enabled for SPARC (whereas linux uses RMO, >> > relaxed memory ordering), so it's probably fine to just use the compiler >> > barrier. >> >> If it isn't, that's a change that has nothing to do with making >>

Re: [HACKERS] Array of composite types returned from python

Just writing to check in. I haven't done anything to look into allowing arrays of composites for input to PL/Python function. I made the submitted modification for a specific project that I'm working on that involves python code that returns data structures. I also have no idea about a more e

Re: [HACKERS] Escaping from blocked send() reprised.

On Mon, Jun 30, 2014 at 4:13 AM, Kyotaro HORIGUCHI wrote: > Hello, I have received inquiries related to blocked communication > several times for these weeks with different symptoms. Then I > found this message from archive, > > http://postgresql.1045698.n5.nabble.com/Escaping-a-blocked-sendto-sys

Re: [HACKERS] delta relations in AFTER triggers

On Mon, Jun 30, 2014 at 11:03:06AM -0400, Robert Haas wrote: > On Sat, Jun 28, 2014 at 10:35 AM, Kevin Grittner wrote: > > David Fetter wrote: > >> On Sat, Jun 21, 2014 at 11:06:26AM -0700, Kevin Grittner wrote: > > > >>> Here is v2. > > > >> I've taken the liberty of making an extension that use

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

* Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Jun 30, 2014 at 9:39 AM, Stephen Frost wrote: > >> I think the fact that pgaudit does X and you think it should do Y is a > >> perfect example of why we're nowhere close to being ready to push > >> anything into core. We may very well want to

Re: [HACKERS] Spinlocks and compiler/memory barriers

On 2014-06-30 10:05:44 -0400, Robert Haas wrote: > On Mon, Jun 30, 2014 at 9:26 AM, Andres Freund wrote: > > I think it continues in the tradition of making s_lock.h ever harder to > > follow. But it's still better than what we have now from a correctness > > perspective. > > Well, as you and I h

Re: [HACKERS] delta relations in AFTER triggers

On Sat, Jun 28, 2014 at 10:35 AM, Kevin Grittner wrote: > David Fetter wrote: >> On Sat, Jun 21, 2014 at 11:06:26AM -0700, Kevin Grittner wrote: > >>> Here is v2. > >> I've taken the liberty of making an extension that uses this. >> Preliminary tests indicate a 10x performance improvement over th

Re: [HACKERS] Proposal for CSN based snapshots

On 12 May 2014 17:14, Heikki Linnakangas wrote: > On 05/12/2014 06:26 PM, Andres Freund wrote: >>> >>> >With the new "commit-in-progress" status in clog, we won't need the >>> >sub-committed clog status anymore. The "commit-in-progress" status will >>> >achieve the same thing. >> >> Wouldn't that

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

On Mon, Jun 30, 2014 at 9:39 AM, Stephen Frost wrote: >> I think the fact that pgaudit does X and you think it should do Y is a >> perfect example of why we're nowhere close to being ready to push >> anything into core. We may very well want to do that someday, but not >> yet. > > That's fine- bu

Re: [HACKERS] RLS Design

* Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Jun 30, 2014 at 9:42 AM, Stephen Frost wrote: > > I don't see it as really solving the flexibility need and it feels quite > > a bit more complicated to reason about. Would someone who is EXEMPT > > from one policy on a given table still have

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

Abhijit, * Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: > At 2014-06-30 09:39:29 -0400, sfr...@snowman.net wrote: > > I certainly don't feel like it's the solution which extension authors > > are looking for and will be happy with > > I don't know if there are any other extension authors invol

Re: [HACKERS] RLS Design

On Mon, Jun 30, 2014 at 9:42 AM, Stephen Frost wrote: >> > I'm not a fan of the EXEMPT approach.. >> >> Just out of curiosity, why not? > > I don't see it as really solving the flexibility need and it feels quite > a bit more complicated to reason about. Would someone who is EXEMPT > from one pol

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

At 2014-06-30 09:39:29 -0400, sfr...@snowman.net wrote: > > I certainly don't feel like it's the solution which extension authors > are looking for and will be happy with I don't know if there are any other extension authors involved in this discussion, but I'm not shedding any tears over the idea

Re: [HACKERS] Spinlocks and compiler/memory barriers

On Mon, Jun 30, 2014 at 9:26 AM, Andres Freund wrote: > I think it continues in the tradition of making s_lock.h ever harder to > follow. But it's still better than what we have now from a correctness > perspective. Well, as you and I have discussed before, someday we probably need to get rid of

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

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Jun 27, 2014 at 2:23 PM, Stephen Frost wrote: > > I don't exactly see how an extension or contrib module is going to be > > able to have a reasonable catalog structure which avoids the risk that > > renaming an object (role, schema, t

Re: [HACKERS] inherit support for foreign tables

Etsuro Fujita writes: > Done. I think this is because create_foreignscan_plan() makes reference > to attr_needed, which isn't computed for inheritance children. I wonder whether it isn't time to change that. It was coded like that originally only because calculating the values would've been a

Re: [HACKERS] RLS Design

* Robert Haas (robertmh...@gmail.com) wrote: > On Sun, Jun 29, 2014 at 3:42 PM, Stephen Frost wrote: > >> > An interesting question we haven't much considered is: who can set up > >> > policies and add then to users? Maybe we should flip this around, and > >> > instead of adding users to policies

Re: [HACKERS] Spinlocks and compiler/memory barriers

Hi, On 2014-06-30 08:03:40 -0400, Robert Haas wrote: > On Sat, Jun 28, 2014 at 9:41 AM, Andres Freund wrote: > >> No, I think it's going to be *much* simpler than that. How about I > >> take a crack at this next week and then either (a) I'll see why it's a > >> bad idea and we can go from there

Re: [HACKERS] RLS Design

On Sun, Jun 29, 2014 at 3:42 PM, Stephen Frost wrote: >> > An interesting question we haven't much considered is: who can set up >> > policies and add then to users? Maybe we should flip this around, and >> > instead of adding users to policies, we should exempt users from >> > policies. >> > >>

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

On Fri, Jun 27, 2014 at 2:23 PM, Stephen Frost wrote: >> I disagree with Stephen's proposal that this should be in core, or >> that it needs its own dedicated syntax. I think contrib is a great >> place for extensions like this. That makes it a whole lot easier for >> people to develop customize

Re: [HACKERS] Priority table or Cache table

On Tue, Jun 3, 2014 at 9:50 AM, Haribabu Kommi wrote: > Sorry for the late reply. Thanks for the test. > Please find the re-based patch with a temp fix for correcting the problem. > I will a submit a proper patch fix later. > > Please note that the new patch still gives assertion error: TRAP: Fa

Re: [HACKERS] IMPORT FOREIGN SCHEMA statement

On Mon, Jun 30, 2014 at 6:01 PM, Ronan Dunklau wrote: > BOOLARRAYOID should be defined to 1000, not 1003 (which clashes against > NAMEARRAYOID). > Oops, a bad copy-paste. Thanks for catching that. I had a more detailed look at the postgres_fdw patch: 1) Having an example of options usable with p

Re: [HACKERS] Spinlocks and compiler/memory barriers

On Sat, Jun 28, 2014 at 9:41 AM, Andres Freund wrote: >> No, I think it's going to be *much* simpler than that. How about I >> take a crack at this next week and then either (a) I'll see why it's a >> bad idea and we can go from there or (b) you can review what I come up >> with and tell me why i

Re: [HACKERS] [BUGS] BUG #9652: inet types don't support min/max

At 2014-06-30 16:35:45 +0500, anaeem...@gmail.com wrote: > > pc1dotnetpk:postgresql asif$ patch -p0 < > > ~/core/min_max_support_for_inet_datatypes/inet_agg_v4.patch > > can't find file to patch at input line 3 > > Perhaps you used the wrong -p or --strip option? > > The text leading up to this was

Re: [HACKERS] Extending MSVC scripts to support --with-extra-version

On Mon, Jun 30, 2014 at 7:05 PM, Asif Naeem wrote: > Patch looks good to me. I think it is ready for committer. Thanks. Thanks for the extra checks and for taking the time to review it. -- Michael On Mon, Jun 30, 2014 at 7:05 PM, Asif Naeem wrote: Thank you for sharing up

Re: [HACKERS] [BUGS] BUG #9652: inet types don't support min/max

Hi Haribabu, I am not able to apply latest patch on REL9_4_STABLE or master branch i.e. pc1dotnetpk:postgresql asif$ git apply > ~/core/min_max_support_for_inet_datatypes/inet_agg_v4.patch > fatal: unrecognized input pc1dotnetpk:postgresql asif$ patch -p0 < > ~/core/min_max_support_for_inet_dat

Re: [HACKERS] psql: show only failed queries

2014-06-30 13:01 GMT+02:00 Abhijit Menon-Sen : > At 2014-06-30 12:48:30 +0200, pavel.steh...@gmail.com wrote: > > > > + > > + Print a failed SQL commands to standard error output. This is > > + equivalent to setting the variable ECHO to > > + errors. > > No "a", just "Print fa

Re: [HACKERS] inherit support for foreign tables

On Mon, Jun 30, 2014 at 4:17 PM, Etsuro Fujita wrote: > (2014/06/30 17:47), Ashutosh Bapat wrote: > >> I checked that it's reporting the right tableoid now. >> > > Thank you for the check. > > > BTW, why aren't you using the tlist passed to this function? I guess >> create_scan_plan() passes tli

Re: [HACKERS] Set new system identifier using pg_resetxlog

On 2014-06-30 19:57:58 +0900, Fujii Masao wrote: > On Sun, Jun 29, 2014 at 11:18 PM, Andres Freund > wrote: > > On 2014-06-29 19:44:21 +0530, Abhijit Menon-Sen wrote: > >> At 2014-06-27 00:51:02 +0200, p...@2ndquadrant.com wrote: > >> > > >> > Also based on Alvaro's comment, I replaced the scanf

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

On Mon, Jun 30, 2014 at 5:14 AM, Craig Ringer wrote: > Right now PostgreSQL appears to rely on the absence of the tablespace > directory as a flag to tell it "don't start up, something's badly wrong > here". > > Well, in fact the behavior is just to give a LOG message: LOG: could not open t

Re: [HACKERS] psql: show only failed queries

At 2014-06-30 12:48:30 +0200, pavel.steh...@gmail.com wrote: > > + > + Print a failed SQL commands to standard error output. This is > + equivalent to setting the variable ECHO to > + errors. No "a", just "Print failed SQL commands …". > --e. > +-e. If set to

Re: [HACKERS] Set new system identifier using pg_resetxlog

On Sun, Jun 29, 2014 at 11:18 PM, Andres Freund wrote: > On 2014-06-29 19:44:21 +0530, Abhijit Menon-Sen wrote: >> At 2014-06-27 00:51:02 +0200, p...@2ndquadrant.com wrote: >> > >> > Also based on Alvaro's comment, I replaced the scanf parsing code with >> > strtoul(l) function. >> >> As far as I

Re: [HACKERS] psql: show only failed queries

2014-06-30 11:20 GMT+02:00 Rajeev rastogi : > On 30 June 2014 12:24, Pavel Stehule Wrote: > > > > >>I have reviewed this patch. Please find my review comments below: > > >>1. Command start-up option (e.g. -a/--echo-all for --ECHO=all), for > new functionality is not provided. > > >all not opt

  1   2   >