Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

At 2014-06-29 22:25:54 +0530, a...@2ndquadrant.com wrote: > > I think the really right thing to do would be to have two separate > columns, one with "all", "sameuser", "samerole", "replication", or > empty; and the other an array of database names. After sleeping on it, I realised that the code wo

Re: [HACKERS] SQL access to database attributes

2014-06-29 21:09 GMT+02:00 Tom Lane : > Vik Fearing writes: > > On 06/21/2014 10:11 PM, Pavel Stehule wrote: > >> Is any reason or is acceptable incompatible change CONNECTION_LIMIT > >> instead CONNECTION LIMIT? Is decreasing parser size about 1% good enough > >> for breaking compatibility? > >

[HACKERS] Escaping from blocked send() reprised.

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-syscall-without-causing-a-restart-td5740855.html > Subject: Escaping a

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

On 06/29/2014 02:19 AM, Matheus de Oliveira wrote: > Hi Hackers, > > I have worked on that patch a little more. So now I have functional > patch (although still WIP) attached. The feature works as following: > > - Added a boolean parameter "only_temp_files" to pg_tablespace.spcoptions; > - This p

Re: [HACKERS] inherit support for foreign tables

I checked that it's reporting the right tableoid now. 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. On Mon, Jun 30, 2014 at 12:22 PM, Etsuro Fujita wrote: > (2014/

Re: [HACKERS] replicating DROP commands across servers

Hi. I thought I'd review this patch, since pgaudit uses the pg_event_trigger_dropped_objects function. I went through the patch line by line, and I don't really have anything to say about it. I notice that there are some XXX/FIXME comments in the code, but it's not clear if those need to (or can

Re: [HACKERS] IMPORT FOREIGN SCHEMA statement

Le lundi 30 juin 2014 16:43:38 Michael Paquier a écrit : > On Thu, Jun 19, 2014 at 11:00 PM, Michael Paquier > wrote: > > >> This seems to be related to re-using the table-name between > > > > invocations. The > > > > >> attached patch should fix point 2. As for point 1, I don't know the > > > > c

Re: [HACKERS] psql: show only failed queries

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 options entered via psql variables has psql option and psql comm

Re: [HACKERS] better atomics - v0.5

On 2014-06-30 11:04:53 +0530, Amit Kapila wrote: > On Sun, Jun 29, 2014 at 2:54 PM, Andres Freund wrote: > > On 2014-06-29 11:53:28 +0530, Amit Kapila wrote: > > > On Sat, Jun 28, 2014 at 1:48 PM, Andres Freund > > > I think it is better to have some discussion about it. Apart from this, > > > to

[HACKERS] uninitialized values in revised prepared xact code

Hi, I've just rerun valgrind for the first time in a while and saw the following splat. My guess is it exists since bb38fb0d43c, but that's blindly guessing: ==2049== Use of uninitialised value of size 8 ==2049==at 0x4FE66D: EndPrepare (twophase.c:1063) ==2049==by 0x4F231B: PrepareTransac

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

Thank you for sharing updated patch. I have compared it with MSVC and configure generated build i.e. *MacOSX (*--with-extra-version "-30JUN"*)* pc1dotnetpk:inst asif$ ./bin/psql -d postgres > psql (9.5devel-30JUN) > Type "help" for help. > postgres=# select version(); >

Re: [HACKERS] pg_receivexlog add synchronous mode

> Thanks for the review! > > +if (secs <= 0) > +secs = 1;/* Always sleep at least 1 sec */ > + > +sleeptime = secs * 1000 + usecs / 1000; > > The above is the code which caused that problem. 'usecs' should have been > reset to zero when 'secs' are round

Re: [HACKERS] Autonomous Transaction (WIP)

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? -- Abhijit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql

Re: [HACKERS] inherit support for foreign tables

(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 tlist after processing it, so that should be used rather than rel->reltargetl

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

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

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] 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] 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] 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] 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] [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] 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

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] 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] 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] 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] 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] 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] 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

* 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] 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] 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] 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

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] 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

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

* 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

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] 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] 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] 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] 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] 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] 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] 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] 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 >>

[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] 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

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] 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] 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

[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] 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

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] 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] [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

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] 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] 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] 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] 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] 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

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] 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

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] 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] 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] 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] 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

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] 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] 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] 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

* 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] 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.

[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] 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

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] 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] 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] 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] 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] 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] 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

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

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

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] 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] 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] 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] 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] 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] 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] 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] 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

  1   2   >