Re: [HACKERS] parallel mode and parallel contexts

On Tue, Apr 21, 2015 at 11:38 PM, Robert Haas wrote: > > > After thinking about it a bit more, I realized that even if we settle > on some solution to that problem, there's another issues: the > wait-edges created by this system don't really have the same semantics > as regular lock waits. Suppos

Re: [HACKERS] a fast bloat measurement tool (was Re: Measuring relation free space)

On Fri, Apr 24, 2015 at 8:05 PM, Tomas Vondra wrote: > > > > On 04/24/15 14:58, Amit Kapila wrote: >> >> On Fri, Apr 24, 2015 at 8:46 AM, Abhijit Menon-Sen > > wrote: >> > >> > At 2015-04-24 08:35:40 +0530, amit.kapil...@gmail.com >>

Re: [HACKERS] Shouldn't CREATE TABLE LIKE copy the relhasoids property?

"David G. Johnston" writes: > On Saturday, April 25, 2015, Tom Lane wrote: >> Still another case that needs to be thought about is "create table likeit >> (like base) without oids" where base does have OIDs. Probably the right >> thing here is to let the WITHOUT OIDS spec override what we see in

Re: [HACKERS] Shouldn't CREATE TABLE LIKE copy the relhasoids property?

On Saturday, April 25, 2015, Tom Lane wrote: > > It's perhaps debatable whether it should act that way, but in the absence > of complaints from the field, I'm hesitant to change these cases. It > might be better if the effective behavior were "table gets OIDs if > default_with_oids = true or WIT

Re: [HACKERS] Shouldn't CREATE TABLE LIKE copy the relhasoids property?

Bruce Momjian writes: > I have changed the default value back to the function call as it should > have been all along; patch attached. I will revisit this for 9.6 > unless I hear otherwise. I still don't like this patch one bit. I don't think that this code should be modifying stmt->options th

Re: [HACKERS] Shouldn't CREATE TABLE LIKE copy the relhasoids property?

On Sat, Apr 25, 2015 at 06:15:25PM -0400, Tom Lane wrote: > Robert Haas writes: > > No, I just misread your email. I thought you said you had attached > > the patch; rereading it, I see that you said you had applied the > > patch. Silly me. > > The real problem with this patch is it's wrong. S

Re: [HACKERS] forward vs backward slashes in msvc build code

On 04/25/2015 08:01 PM, Michael Paquier wrote: On Sun, Apr 26, 2015 at 2:19 AM, Andrew Dunstan wrote: On 04/25/2015 10:53 AM, Michael Paquier wrote: On Sat, Apr 25, 2015 at 9:58 PM, Peter Eisentraut wrote: On 4/24/15 12:22 AM, Michael Paquier wrote: Now that the stuff related to the move fr

[HACKERS] Temporal extensions

Hi all, My apologies I couldn't directly respond to the earlier thread on this subject (http://www.postgresql.org/message-id/50d99278.3030...@dc.baikal.ru) but I wasn't subscribed to the list at that point. I've been working on a conversion of several utilities I wrote for another engine, and was

Re: [HACKERS] inherit support for foreign tables

Etsuro Fujita writes: > On 2015/04/16 16:05, Etsuro Fujita wrote: >> I agree with you on this point. However, ISTM there is a bug in >> handling OIDs on foreign tables; while we now allow for ALTER SET >> WITH/WITHOUT OIDS, we still don't allow the default_with_oids parameter >> for foreign table

Re: [HACKERS] PL/pgSQL, RAISE and error context

+1 On Sat, Apr 25, 2015 at 10:23 PM, Pavel Stehule wrote: > Hi > > 2015-04-24 19:16 GMT+02:00 Joel Jacobson : > >> On Fri, Apr 24, 2015 at 6:07 PM, Pavel Stehule >> wrote: >> >> Example: >> >> >> >> context_messages = -warning, -error, +notice >> > >> > >> > I prefer your first proposal - and

Re: [HACKERS] forward vs backward slashes in msvc build code

On Sun, Apr 26, 2015 at 2:19 AM, Andrew Dunstan wrote: > > On 04/25/2015 10:53 AM, Michael Paquier wrote: >> >> On Sat, Apr 25, 2015 at 9:58 PM, Peter Eisentraut wrote: >>> >>> On 4/24/15 12:22 AM, Michael Paquier wrote: Now that the stuff related to the move from contrib/ to src/bin/, >

Re: [HACKERS] Shouldn't CREATE TABLE LIKE copy the relhasoids property?

Robert Haas writes: > No, I just misread your email. I thought you said you had attached > the patch; rereading it, I see that you said you had applied the > patch. Silly me. The real problem with this patch is it's wrong. Specifically, it broke the other case I mentioned in my original email:

Re: [HACKERS] Allow SQL/plpgsql functions to accept record

Robert Haas writes: > On Wed, Apr 22, 2015 at 6:12 PM, Jim Nasby wrote: >> As for allowing SQL and plpgsql functions to accept a record, I think our >> JSON functionality just provided plenty of reason we should allow accepting >> them, even if you can't do much with it: you *can* hand it to row_

Re: [HACKERS] PL/pgSQL, RAISE and error context

Hi 2015-04-24 19:16 GMT+02:00 Joel Jacobson : > On Fri, Apr 24, 2015 at 6:07 PM, Pavel Stehule > wrote: > >> Example: > >> > >> context_messages = -warning, -error, +notice > > > > > > I prefer your first proposal - and there is a precedent for plpgsql - > > plpgsql_extra_checks > > > > It is cl

Re: [HACKERS] Bug in planner

David Rowley writes: > On 24 April 2015 at 21:43, Teodor Sigaev wrote: >> I faced with planner error: >> ERROR: could not find RelOptInfo for given relids > I've done a little debugging on this too and I get the idea that in > eqjoinsel() that min_righthand incorrectly does not have a bit set f

Re: [HACKERS] INSERT ... ON CONFLICT syntax issues

On Sat, Apr 25, 2015 at 12:35 PM, Peter Geoghegan wrote: >>> > That >>> > it has 'morphing' characteristics imo just makes it worse, rather than >>> > better. Besides being confusing that it has different meanings, it's far >>> > from inconceivable that somebody wants to return values from the >>>

Re: [HACKERS] INSERT ... ON CONFLICT syntax issues

On Sat, Apr 25, 2015 at 12:23 PM, Andres Freund wrote: > 95% of all users will know NEW/OLD from triggers, not rules. Where NEW > is used in a quite comparable way. I don't think it's comparable. >> >> Seems pretty descriptive of the situation to me - I actually put a lot >> >> of thought into t

Re: [HACKERS] INSERT ... ON CONFLICT syntax issues

On 2015-04-25 11:50:59 -0700, Peter Geoghegan wrote: > On Sat, Apr 25, 2015 at 11:24 AM, Andres Freund wrote: > >> > c) Right now the UPDATE can refer to pseudo relations 'TARGET' and > >> >'EXCLUDED'. I think especially the latter doesn't fit anymore at > >> >all. How about 'CONFLICTING'

Re: [HACKERS] INSERT ... ON CONFLICT syntax issues

On Sat, Apr 25, 2015 at 11:50 AM, Peter Geoghegan wrote: > To be fair, there is one unrelated slight difference with RETURNING > and conventional UPDATEs: You cannot return the EXCLUDED tuple (in the > same way that you can reference the joined-FROM tuple within > conventional UPDATEs). This is be

Re: [HACKERS] INSERT ... ON CONFLICT syntax issues

On Sat, Apr 25, 2015 at 11:24 AM, Andres Freund wrote: >> > b) unclear whether the WHERE belongs to colb or the whole index >> >expression. The equivalent for aggregates, which I bet is going to be >> >used less often, caused a fair amount of confusing. >> >> I don't see those two situatio

Re: [HACKERS] INSERT ... ON CONFLICT syntax issues

On 2015-04-25 11:05:49 -0700, Peter Geoghegan wrote: > On Sat, Apr 25, 2015 at 2:01 AM, Andres Freund wrote: > > My problem with the WHERE being inside the parens in the above is that > > it's > > a) different from CREATE INDEX > > I don't think that that's an important goal. Given that it's use

Re: [HACKERS] Fwd: [GENERAL] 4B row limit for CLOB tables

On Fri, Apr 24, 2015 at 11:39:04PM -0500, Jim Nasby wrote: > On 4/24/15 7:11 PM, Álvaro Hernández Tortosa wrote: > >On 24/04/15 05:24, Tom Lane wrote: > ... > >>TBH, I've got very little enthusiasm for fixing this given the number > >>of reports of trouble from the field, which so far as I recall i

Re: [HACKERS] INSERT ... ON CONFLICT syntax issues

On Sat, Apr 25, 2015 at 2:01 AM, Andres Freund wrote: > My problem with the WHERE being inside the parens in the above is that > it's > a) different from CREATE INDEX I don't think that that's an important goal. > b) unclear whether the WHERE belongs to colb or the whole index >expression. T

Re: [HACKERS] forward vs backward slashes in msvc build code

On 04/25/2015 10:53 AM, Michael Paquier wrote: On Sat, Apr 25, 2015 at 9:58 PM, Peter Eisentraut wrote: On 4/24/15 12:22 AM, Michael Paquier wrote: Now that the stuff related to the move from contrib/ to src/bin/, modulescheck and tmp_install has been committed, shouldn't we give a new shot at

Re: [HACKERS] pg_dump: largeobject behavior issues (possible bug)

On 04/25/2015 12:32 PM, Tom Lane wrote: Andrew Dunstan writes: On 04/24/2015 06:41 PM, Tom Lane wrote: Yeah, this was brought up when we added per-large-object metadata; it was obvious that that patch would cause pg_dump to choke on large numbers of large objects. The (perhaps rather lame) a

Re: [HACKERS] pg_dump: largeobject behavior issues (possible bug)

Andrew Dunstan writes: > On 04/24/2015 06:41 PM, Tom Lane wrote: >> Yeah, this was brought up when we added per-large-object metadata; it was >> obvious that that patch would cause pg_dump to choke on large numbers of >> large objects. The (perhaps rather lame) argument was that you wouldn't >> h

Re: [HACKERS] pg_dump: largeobject behavior issues (possible bug)

On 04/24/2015 06:41 PM, Tom Lane wrote: Andrew Dunstan writes: On 04/23/2015 04:04 PM, Andrew Gierth wrote: The relevant code is getBlobs in pg_dump.c, which queries the whole of pg_largeobject_metadata without using a cursor (so the PGresult is already huge thanks to having >100 million rows

Re: [HACKERS] forward vs backward slashes in msvc build code

On Sat, Apr 25, 2015 at 9:58 PM, Peter Eisentraut wrote: > On 4/24/15 12:22 AM, Michael Paquier wrote: >> Now that the stuff related to the move from contrib/ to src/bin/, >> modulescheck and tmp_install has been committed, shouldn't we give a >> new shot at this patch? Attached is a rebased versio

Re: [HACKERS] Ignoring some binaries generated in src/test

On Sat, Apr 25, 2015 at 6:14 AM, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> The current logic in src/test/Makefile, particularly the way that >>> the modules subdirectory is handled, seems pretty ugly/convoluted >>> anyway. I wonder why it was done that way rather than just

Re: [HACKERS] collate.linux.utf8 test coverage

On Sat, Apr 25, 2015 at 4:51 AM, Andrew Dunstan wrote: > The optional buildfarm module that runs this test was broken by commit > dcae5faccab64776376d354decda0017c648bb53 > > Since nobody has responded to my complaint about this, I have disabled it on > crake, the only buildfarm machine that has a

Re: [HACKERS] improving speed of make check-world

On Sat, Apr 25, 2015 at 7:59 AM, Peter Eisentraut wrote: > On 4/23/15 1:22 PM, Jeff Janes wrote: >> Something about this commit (dcae5faccab64776376d354d) broke "make >> check" in parallel conditions when started from a clean directory. It >> fails with a different error each time, one example: >

Re: [HACKERS] Idea: closing the loop for "pg_ctl reload"

On April 22, 2015 06:04:42 PM Payal Singh wrote: > The following review has been posted through the commitfest application: > make installcheck-world: not tested > Implements feature: tested, failed > Spec compliant: not tested > Documentation:tested, failed > > Error

Re: [HACKERS] adding more information about process(es) cpu and memory usage

On Sat, Apr 25, 2015 at 4:23 PM, Julien Rouhaud wrote: > There are at least two projects that provides this kind of statistics > for backends: pg_proctab (https://github.com/markwkm/pg_proctab) and > pg_stat_kcache (https://github.com/dalibo/pg_stat_kcache). Michael also > wrote an article on this

Re: [HACKERS] forward vs backward slashes in msvc build code

On 4/24/15 12:22 AM, Michael Paquier wrote: > On Fri, Mar 13, 2015 at 6:04 PM, Michael Paquier > wrote: >> On Fri, Mar 13, 2015 at 6:20 AM, Alvaro Herrera wrote: >>> Peter Eisentraut wrote: This is contrib/chkpass not finding the crypt symbol, which is presumably in some library. But I

Re: [HACKERS] Can pg_dump make use of CURRENT/SESSION_USER

On Wed, Mar 18, 2015 at 2:24 PM, Robert Haas wrote: > > On Wed, Mar 18, 2015 at 1:23 PM, Fabrízio de Royes Mello > wrote: > >> > If we ever implement something like > >> > > >> > COMMENT ON CURRENT_DATABASE IS ... > >> > > >> > it will be useful, because you will be able to restore a dump into >

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On 24 April 2015 at 22:36, Jim Nasby wrote: > Instead of adding forcefsm, I think it would be more useful to accept a > target block number. That way we can actually control where the new tuple > goes. For this particular case we'd presumably go with normal FSM page > selection logic, but someon

Re: [HACKERS] Bug in planner

On 24 April 2015 at 21:43, Teodor Sigaev wrote: > Hi! > > I faced with planner error: > ERROR: could not find RelOptInfo for given relids > > Good find! I've simplified your query a bit, the following still shows the issue (using your schema): SELECT * FROM t1 WHERE NOT EXISTS (SELECT t2.c2 AS

[HACKERS] INSERT ... ON CONFLICT syntax issues

I'm separating this discussion out of the thread because I think this needs wider input. On 2015-04-24 19:21:37 -0700, Peter Geoghegan wrote: > I've *provisionally* pushed code that goes back to the old way, > Andres: > https://github.com/petergeoghegan/postgres/commit/2a5d80b27d2c5832ad26dde465

Re: [HACKERS] Row security violation error is misleading

On 25 April 2015 at 01:52, Stephen Frost wrote: > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >> The second patch [2] is the one that is actually relevant to this >> thread. This patch is primarily to apply the RLS checks earlier, >> before an update is attempted, more like a regular permissi

Re: [HACKERS] adding more information about process(es) cpu and memory usage

Le 24/04/2015 21:11, Jim Nasby a écrit : > On 4/24/15 6:29 AM, Robert Haas wrote: >> On Thu, Apr 23, 2015 at 9:28 PM, Tom Lane wrote: >>> The reason nobody's gotten around to that in the last fifteen years is >>> that per-process rusage isn't actually all that interesting; there's >>> too much tha