[HACKERS] proposal: interprocess EXPLAIN PID

Hello I propose a enhancing of EXPLAIN statement about possibility get a plan of other PostgreSQL process. With some other enhancing this technique can be interesting for monitoring long duration queries. Notes, comments? Regards Pavel Stehule

Re: [HACKERS] Autonomous Transaction (WIP)

On 09 April 2014 21:25, Robert Haas Wrote: > >> > Deadlock Detection: > >> I'm not sure how this would work out internally > > In order to resolve deadlock, two member variable will be created in > the structure PROLOCK: > > Bitmask for lock types currently held by autonomous > transaction

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

On Fri, Apr 11, 2014 at 3:14 AM, Bruce Momjian wrote: > > Can someone with Windows expertise comment on whether this should be > applied? I don't think this is a complete fix, for example what about platform where _CreateRestrictedToken() is not supported. For Example, the current proposed fix w

Re: [HACKERS] Get more from indices.

# Sorry for accidentialy sending the previous mail unfinished. ## ...and I seem to have bombed uncertain files off out of my ## home directory by accident, too :( = Hi, sorry for the absense. I've been back. Thank you for continuing this discussion. Attached is the patch following the discu

Re: [HACKERS] Get more from indices.

Hi, sorry for the absense. I've been back. Attached is the patch following the discussion below. > >> (2014/04/10 0:08), Tom Lane wrote: > >>> TBH I think that's barely the tip of the iceberg of cases where this > >>> patch will get the wrong answer. > > > >>> Also, I don't see it doing anything

Re: [HACKERS] [BUG FIX] Compare returned value by socket() against PGINVALID_SOCKET instead of < 0

On Fri, Apr 11, 2014 at 10:00 AM, Amit Kapila wrote: > On Thu, Apr 10, 2014 at 5:21 PM, Bruce Momjian wrote: >> On Thu, Apr 10, 2014 at 11:05:49AM +0530, Amit Kapila wrote: > >> Ah, yes, good point. This is going to require backpatching then. > > I also think so. > >>> I think it's better to use

Re: [HACKERS] [BUG FIX] Compare returned value by socket() against PGINVALID_SOCKET instead of < 0

On Thu, Apr 10, 2014 at 5:21 PM, Bruce Momjian wrote: > On Thu, Apr 10, 2014 at 11:05:49AM +0530, Amit Kapila wrote: > Ah, yes, good point. This is going to require backpatching then. I also think so. >> I think it's better to use check like below, just for matter of >> consistency with other

Re: [HACKERS] Adding unsigned 256 bit integers

pgmp is also worth mentioning here, and it's likely to be more efficient than the numeric type or something you hack up yourself: http://pgmp.projects.pgfoundry.org/ Best, Leon On Thu, Apr 10, 2014 at 10:11 AM, k...@rice.edu wrote: > On Thu, Apr 10, 2014 at 09:13:47PM +0800, Olivier Lalonde

Re: [HACKERS] WIP patch (v2) for updatable security barrier views

Dean, Craig, all, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > This is reflected in the change to the regression test output where, > in one of the tests, the ctids for the table to update are no longer > coming from the same table. I think a better approach is to push down > the rowmark int

Re: [HACKERS] Get more from indices.

(2014/04/10 22:25), Tom Lane wrote: > Etsuro Fujita writes: >> (2014/04/10 0:08), Tom Lane wrote: >>> TBH I think that's barely the tip of the iceberg of cases where this >>> patch will get the wrong answer. > >>> Also, I don't see it doing anything to check the ordering >>> of multiple index col

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

On Fri, Apr 11, 2014 at 12:12 PM, Bruce Momjian wrote: > On Fri, Apr 11, 2014 at 11:58:58AM +1000, Haribabu Kommi wrote: >> On Fri, Apr 11, 2014 at 7:44 AM, Bruce Momjian wrote: >> > >> > Can someone with Windows expertise comment on whether this should be >> > applied? >> >> I tested the same in

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

On Fri, Apr 11, 2014 at 11:58:58AM +1000, Haribabu Kommi wrote: > On Fri, Apr 11, 2014 at 7:44 AM, Bruce Momjian wrote: > > > > Can someone with Windows expertise comment on whether this should be > > applied? > > I tested the same in windows and it is working as specified. > The same background

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

On Fri, Apr 11, 2014 at 7:44 AM, Bruce Momjian wrote: > > Can someone with Windows expertise comment on whether this should be > applied? I tested the same in windows and it is working as specified. The same background running server can be closed with ctrl+break command. > -

Re: [HACKERS] WAL replay bugs

On Thu, Apr 10, 2014 at 6:21 PM, Heikki Linnakangas wrote: > On 04/10/2014 10:52 AM, sachin kotwal wrote: > >> >> I executed given steps many times to produce this bug. >> But still I unable to hit this bug. >> I used attached scripts to produce this bug. >> >> Can I get scripts to produce this

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On Apr11, 2014, at 01:30 , Tom Lane wrote: > Florian Pflug writes: >> As for evidence - have you looked at the patch I posted? I'd be very >> interested to know if it removes the performance differences you saw. > > (1) You can't really prove the absence of a performance issue by showing > that

Re: [HACKERS] psql \d+ and oid display

On Thu, Apr 10, 2014 at 07:58:55PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > It also has changed the OID status to only display if it exists. One > > question that came up with Robert is whether OID status should appear > > for \d as well, now that is only shows up when present. > > Yea

Re: [HACKERS] psql \d+ and oid display

Bruce Momjian writes: > It also has changed the OID status to only display if it exists. One > question that came up with Robert is whether OID status should appear > for \d as well, now that is only shows up when present. Yeah, I was wondering about that too. If part of the argument here is to

Re: [HACKERS] psql \d+ and oid display

On Thu, Apr 10, 2014 at 01:10:35PM -0400, Bruce Momjian wrote: > On Thu, Apr 10, 2014 at 01:05:32PM -0400, Greg Stark wrote: > > If it's conditional I think "when it matches a guc" is too hard for users to > > use. > > Yes, we gave up on having the OID display match the GUC; we just > display som

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

Florian Pflug writes: > My argument is that is costs us more complexity to duplicate everything > for the invertible case, *and* the result seems less flexible - not > from the POV of aggregate implementations, but from the POV of future > extensions. [ shrug... ] You can argue against any featu

Re: [HACKERS] psql \d+ and oid display

On Tue, Apr 1, 2014 at 10:45:29AM -0700, Jeff Janes wrote: > I am suggesting it for at least some other things. I'm rather aggrieved that > " > \d+" without argument shows you the size and the description/comment for every > table, but "\d+ foo" does not show you the size and description/comment

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On Apr11, 2014, at 00:07 , Tom Lane wrote: > Florian Pflug writes: >> I still think you're getting ahead of yourselves here. The number of >> aggregates which benefit from this is tiny SUM(int2,int4) and maybe >> BOOL_{AND,OR}. And in the SUM(int2,int4) case *only* on 64-bit archs - >> for the ot

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

Florian Pflug writes: > I still think you're getting ahead of yourselves here. The number of > aggregates which benefit from this is tiny SUM(int2,int4) and maybe > BOOL_{AND,OR}. And in the SUM(int2,int4) case *only* on 64-bit archs - > for the others, the state type is already pass-by-ref. That

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On Apr10, 2014, at 21:34 , Dean Rasheed wrote: > On 10 April 2014 19:54, Tom Lane wrote: >> So if we go with that terminology, perhaps these names for the >> new CREATE AGGREGATE parameters: >> >> initfuncapplies to plain aggregation, mutually exclusive with >> initcond >> msfunc

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

Dean Rasheed writes: > I was imagining that firsttrans would only be passed the first value > to be aggregated, not any previous state, and that it would be illegal > to specify both an initcond and a firsttrans function. > The forward transition function would only be called for values after > t

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

Can someone with Windows expertise comment on whether this should be applied? --- On Tue, Jan 7, 2014 at 12:44:33PM +0100, Christian Ullrich wrote: > Hello all, > > when pg_ctl start is used to run PostgreSQL in a console

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On Apr10, 2014, at 02:13 , Florian Pflug wrote: > On Apr9, 2014, at 23:17 , Florian Pflug wrote: >> On Apr9, 2014, at 21:35 , Tom Lane wrote: >>> A quick test says that avg(int4) >>> is about five percent slower than sum(int4), so that's the kind of hit >>> we'd be taking on non-windowed aggrega

Re: [HACKERS] trailing comment ghost-timing

On Mon, Mar 31, 2014 at 02:06:28PM -0400, Bruce Momjian wrote: > Where are we on this? It seem odd that psql sends /* */ comments to the > server, but not "--" comments. Should this be documented or changed? > > I am confused why changing the behavior would affect the regression test > output as

Re: [HACKERS] Partial match fix for fast scan

On 04/10/2014 10:00 PM, Alexander Korotkov wrote: On Thu, Apr 10, 2014 at 8:22 PM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: On Thu, Apr 10, 2014 at 11:09 AM, Alexander Korotkov wrote: GIN partial match appears to be broken after fast scan. Following simple test case raises

Re: [HACKERS] Problem with displaying "wide" tables in psql

Hi. Thanks for your tests. I've fixed problem with headers, but got new one with data. I'll try to solve it tomorrow. 2014-04-10 18:45 GMT+04:00 Greg Stark : > Ok, So I've hacked on this a bit. Below is a test case showing the > problems I've found. > > 1) It isn't using the "newline" and "wra

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On 10 April 2014 19:54, Tom Lane wrote: > Dean Rasheed writes: >> On 10 April 2014 19:04, Tom Lane wrote: >>> What about names for the invertible-aggregate infrastructure? >>> I'm tempted to prefix "inv" to all the existing names, but then >>> "invsfunc" means the alternate forward function ...

Re: [HACKERS] Partial match fix for fast scan

On Thu, Apr 10, 2014 at 8:22 PM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > On Thu, Apr 10, 2014 at 11:09 AM, Alexander Korotkov > wrote: > >> Hi, >> >> GIN partial match appears to be broken after fast scan. Following simple >> test case raises assertion failure. >> >> create

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

Dean Rasheed writes: > On 10 April 2014 19:04, Tom Lane wrote: >> What about names for the invertible-aggregate infrastructure? >> I'm tempted to prefix "inv" to all the existing names, but then >> "invsfunc" means the alternate forward function ... can we use >> "invifunc" for the inverse transi

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On 10 April 2014 19:04, Tom Lane wrote: > Dean Rasheed writes: >> On 10 April 2014 15:18, Tom Lane wrote: >>> This idea of a separate firsttrans function is interesting but perhaps >>> orthogonal to the current patch. Also, I don't quite understand how >>> it would work for aggregates with null

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

Dean Rasheed writes: > On 10 April 2014 15:18, Tom Lane wrote: >> This idea of a separate firsttrans function is interesting but perhaps >> orthogonal to the current patch. Also, I don't quite understand how >> it would work for aggregates with null initvalues; don't you end up >> with exactly t

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On 10 April 2014 15:18, Tom Lane wrote: > Dean Rasheed writes: >> On 10 April 2014 01:13, Florian Pflug wrote: >>> However, I still believe the best approach at this point is to just work >>> on making int4_avg_accum faster. I still see no principal reason what it >>> has to be noticeably slower

Re: [HACKERS] psql \d+ and oid display

On Thu, Apr 10, 2014 at 01:05:32PM -0400, Greg Stark wrote: > If it's conditional I think "when it matches a guc" is too hard for users to > use. Yes, we gave up on having the OID display match the GUC; we just display something if and only if it oids are present. Robert is talking about the "Id

Re: [HACKERS] psql \d+ and oid display

If it's conditional I think "when it matches a guc" is too hard for users to use. I think "say nothing if oids are off and say something of their on" would be fine. It would result in clutter for users which oids on by default but that's a non default setting. And the consequences of having oids

Re: [HACKERS] Minor performance improvement in transition to external sort

On 6 February 2014 18:21, Jeff Janes wrote: > On Tue, Feb 4, 2014 at 2:22 PM, Jeremy Harris wrote: >> >> The attached patch replaces the existing siftup method for heapify with >> a siftdown method. Tested with random integers it does 18% fewer >> compares and takes 10% less time for the heapify,

Re: [HACKERS] psql \d+ and oid display

On Thu, Apr 10, 2014 at 12:23:40PM -0400, Robert Haas wrote: > > What might make more sense is this: > > > > if ((tableinfo.relkind == 'r' || tableinfo.relkind == 'm') && > > /* > > * No need to display default values; we already display a > > * REPLIC

Re: [HACKERS] psql \d+ and oid display

On Wed, Apr 9, 2014 at 11:42 AM, Bruce Momjian wrote: > On Wed, Apr 9, 2014 at 09:27:11AM -0400, Robert Haas wrote: >> On Wed, Apr 9, 2014 at 1:02 AM, Tom Lane wrote: >> > Robert Haas writes: >> >> Well, that's sorta my concern. I mean, right now we've got people >> >> saying "what the heck is

Re: [HACKERS] Partial match fix for fast scan

On Thu, Apr 10, 2014 at 11:09 AM, Alexander Korotkov wrote: > Hi, > > GIN partial match appears to be broken after fast scan. Following simple > test case raises assertion failure. > > create extension btree_gin; > create table test as (select id, random() as val from > generate_series(1,100)

Re: [HACKERS] Problem with displaying "wide" tables in psql

Ok, So I've hacked on this a bit. Below is a test case showing the problems I've found. 1) It isn't using the "newline" and "wrap" indicators or dividing lines. 2) The header is not being displayed properly when it contains a newline. I can hack in the newline and wrap indicators but the header

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

Dean Rasheed writes: > On 10 April 2014 01:13, Florian Pflug wrote: >> However, I still believe the best approach at this point is to just work >> on making int4_avg_accum faster. I still see no principal reason what it >> has to be noticeably slower - the only additional work it absolutely *has*

Re: [HACKERS] Adding unsigned 256 bit integers

On Thu, Apr 10, 2014 at 09:13:47PM +0800, Olivier Lalonde wrote: > I was wondering if there would be any way to do the following in PostgreSQL: > > UPDATE cryptotable SET work = work + 'some big hexadecimal number' > > where work is an unsigned 256 bit integer. Right now my column is a > char

[HACKERS] Partial match fix for fast scan

Hi, GIN partial match appears to be broken after fast scan. Following simple test case raises assertion failure. create extension btree_gin; create table test as (select id, random() as val from generate_series(1,100) id); create index test_idx on test using gin (val); vacuum test; select * f

Re: [HACKERS] Adding unsigned 256 bit integers

On 04/10/2014 09:13 PM, Olivier Lalonde wrote: > I was wondering if there would be any way to do the following in PostgreSQL: > > UPDATE cryptotable SET work = work + 'some big hexadecimal number' For readers finding this in the archives, this question also appears here: http://dba.stackexch

Re: [HACKERS] Adding unsigned 256 bit integers

On 04/10/2014 09:13 AM, Olivier Lalonde wrote: I was wondering if there would be any way to do the following in PostgreSQL: UPDATE cryptotable SET work = work + 'some big hexadecimal number' where work is an unsigned 256 bit integer. Right now my column is a character varying(64) column

Re: [HACKERS] Get more from indices.

Etsuro Fujita writes: > (2014/04/10 0:08), Tom Lane wrote: >> TBH I think that's barely the tip of the iceberg of cases where this >> patch will get the wrong answer. >> Also, I don't see it doing anything to check the ordering >> of multiple index columns > I think that the following code in in

[HACKERS] Adding unsigned 256 bit integers

I was wondering if there would be any way to do the following in PostgreSQL: UPDATE cryptotable SET work = work + 'some big hexadecimal number' where work is an unsigned 256 bit integer. Right now my column is a character varying(64) column (hexadecimal representation of the number) but I wou

Re: [HACKERS] [BUG FIX] Compare returned value by socket() against PGINVALID_SOCKET instead of < 0

On Thu, Apr 10, 2014 at 11:05:49AM +0530, Amit Kapila wrote: > On Tue, Apr 8, 2014 at 11:32 PM, Bruce Momjian wrote: > > On Sun, Apr 6, 2014 at 11:45:59AM +0530, Amit Kapila wrote: > > In fact, this C program compiled by gcc on Debian issues no compiler > > warnings and returns 'hello', showing t

Re: [HACKERS] WIP patch (v2) for updatable security barrier views

On 4/9/14 9:56 PM, Stephen Frost wrote: As for docs and testing, those are things we would certainly be better off with and may mean that this isn't able to make it into 9.4, which is fair, but I wouldn't toss it out solely due to that. We have a git repo with multiple worked out code examples,

Re: [HACKERS] Autonomous Transaction (WIP)

On 10 April 2014 11:18, Pavan Deolasee Wrote: >>I could think of few global variables like transaction properties >>related(i.e. read-only mode, isolation level etc). As I plan to keep >>transaction properties of autonomous transaction same as main transaction, so >>there is no need to have the

Re: [HACKERS] small typo about comment in xlog.c

On 04/10/2014 07:19 AM, Tomonari Katsumata wrote: > Hi, > > I'm reading xlog.c, and I noticed a comment of > do_pg_abort_backup is typo. > > ... > 10247 * NB: This is only for aborting a non-exclusive backup that > doesn't write > 10248 * backup_label. A backup started with pg_stop_backup() needs

[HACKERS]

On 10 April 2014 11:18, Pavan Deolasee Wrote: >>I could think of few global variables like transaction properties >>related(i.e. read-only mode, isolation level etc). As I plan to keep >>transaction properties of autonomous transaction same as main transaction, so >>there is no need to have the

Re: [HACKERS] Get more from indices.

(2014/04/10 0:08), Tom Lane wrote: > Kyotaro HORIGUCHI writes: >> Oops! I found a bug in this patch. The previous v8 patch missed >> the case that build_index_pathkeys() could build a partial >> pathkeys from the index tlist. > > TBH I think that's barely the tip of the iceberg of cases where thi

Re: [HACKERS] WAL replay bugs

On 04/10/2014 10:52 AM, sachin kotwal wrote: I executed given steps many times to produce this bug. But still I unable to hit this bug. I used attached scripts to produce this bug. Can I get scripts to produce this bug? wal_replay_bug.sh

Re: [HACKERS] WAL replay bugs

I executed given steps many times to produce this bug. But still I unable to hit this bug. I used attached scripts to produce this bug. Can I get scripts to produce this bug? wal_replay_bug.sh - Thanks and Regar