Re: [HACKERS] poll: CHECK TRIGGER?

Hello 2012/3/7 Tom Lane : > Robert Haas writes: >> Just to be clear, I am not proposing that we get rid of CHECK TRIGGER >> and keep CHECK FUNCTION.  I'm proposing that we get rid of all of the >> dedicated syntax support, and expose it all through one or more >> SQL-callable functions. > > This

Re: [HACKERS] Speed dblink using alternate libpq tuple storage

Hello, > > #- We expect PQisBusy(), PQconsumeInput()(?) and > > #- PQgetResult() to exit immediately and we can > > #- call PQgetResult(), PQskipResult() or > > #- PQisBusy() after. > > | 1 - OK ("I'm done with the row") > > |

Re: [HACKERS] pg_upgrade --logfile option documentation

On Thu, Mar 01, 2012 at 09:06:10PM -0500, Bruce Momjian wrote: > OK, combining your and Robert's ideas, how about I have pg_upgrade write > the server log to a file, and the pg_dump output to a file (with its > stderr), and if pg_upgrade fails, I report the failure and mention those > files. If pg

Re: [HACKERS] Custom Operators Cannot be Found for Composite Type Values

"David E. Wheeler" writes: > I’m doing some development with the new JSON type (actually, Andrew’s > backport to 9.1) and needed to do some very basic equivalence testing. So I > created a custom operator: > CREATE OR REPLACE FUNCTION json_eq( > json, > json > ) RETURNS

Re: [HACKERS] Patch: improve selectivity estimation for IN/NOT IN

I wrote: > Daniele Varrazzo writes: >> the attached patch improves the array selectivity estimation for = ANY >> and <> ALL, hence for the IN/NOT IN operators, to avoid the >> shortcoming described in >> . I've committed a mod

Re: [HACKERS] pg_stat_statements and planning time

On Thu, Mar 8, 2012 at 1:07 AM, Tom Lane wrote: > Fujii Masao writes: >> In the patch, I didn't change the column name "total_time" meaning >> the time spent in the executor because of the backward compatibility. >> But once new column "plan_time" is added, "total_time" is confusing and >> ISTM i

Re: [HACKERS] pg_stat_statements and planning time

On Thu, Mar 8, 2012 at 12:39 AM, Robert Haas wrote: > On Wed, Mar 7, 2012 at 6:45 AM, Fujii Masao wrote: >> pg_stat_statements is basically very helpful to find out slow queries. >> But since it doesn't report the time spent in the planner, we cannot >> find out slow queries which take most time

Re: [HACKERS] pg_basebackup streaming issue from standby

On Thu, Mar 8, 2012 at 10:36 AM, Thom Brown wrote: > I've just tried using pg_basebackup to take a backup of a standby with > "-x stream" but it never finishes. Thanks for the report! This is the same problem as I reported before. We are now discussing how to fix that. http://archives.postgresql.

[HACKERS] pg_basebackup streaming issue from standby

Hi, I've just tried using pg_basebackup to take a backup of a standby with "-x stream" but it never finishes. This is what I get: thom@swift:~/Development$ pg_basebackup -p 5489 -D data3 -x stream -Pv xlog start point: 0/620 pg_basebackup: starting background WAL receiver 78020/78020 kB (100

[HACKERS] Custom Operators Cannot be Found for Composite Type Values

Hackers, I’m doing some development with the new JSON type (actually, Andrew’s backport to 9.1) and needed to do some very basic equivalence testing. So I created a custom operator: CREATE OR REPLACE FUNCTION json_eq( json, json ) RETURNS BOOLEAN LANGUAGE SQL STRICT IMMU

Re: [HACKERS] Collect frequency statistics for arrays

Alexander Korotkov writes: > On Mon, Mar 5, 2012 at 1:11 AM, Tom Lane wrote: >> Couldn't we reduce the histogram size when there aren't many >> different counts? >> >> It seems fairly obvious to me that we could bound the histogram >> size with (max count - min count + 1), but maybe something ev

Re: [HACKERS] pgsql_fdw, FDW for PostgreSQL server

Shigeru Hanada writes: > Agreed. Attached fdw_helper patch doesn't contain GetFdwOptionValue() > any more, and pgsql_fdw patch accesses only necessary catalogs. I've committed the fdw_helper part of this, with some very minor improvements. regards, tom lane -- Sent via

Re: [HACKERS] RFC: Making TRUNCATE more "MVCC-safe"

On Wed, Mar 7, 2012 at 8:21 PM, Robert Haas wrote: > On Wed, Mar 7, 2012 at 2:06 PM, Simon Riggs wrote: >>> I am not thrilled with the design as it stands, but bulk loading is a >>> known and serious pain point for us, so it would be awfully nice to >>> improve it.  I'm not sure whether we should

Re: [HACKERS] patch for a locale-specific bug in regression tests (REL9_1_STABLE)

On Wed, Mar 7, 2012 at 4:02 PM, Tomas Vondra wrote: > Ok, so here's a fixed patch. I haven't used the 3e9a2672 commit > directly, because there seem to be additional changes. I've simply > renamed the 'sc' to 's0' and fixed the differences in output. Thanks, committed. -- Robert Haas Enterprise

Re: [HACKERS] Fix PL/Python metadata when there is no result

Peter Eisentraut writes: > On ons, 2012-03-07 at 16:49 -0500, Tom Lane wrote: >> Still, it seems rather arbitrary to say that the row count property is >> the thing to test for that purpose and no other is. Why not return None >> for any property that's not sensible? > Hmm, above you said you we

Re: [HACKERS] Fix PL/Python metadata when there is no result

On ons, 2012-03-07 at 16:49 -0500, Tom Lane wrote: > Peter Eisentraut writes: > > On ons, 2012-03-07 at 15:59 -0500, Tom Lane wrote: > >> Or are we talking about two different things? > > > I think so. I'm wondering here how to detect whether the execution of a > > statement has yielded a result

Re: [HACKERS] NULL's support in SP-GiST

On Wed, Mar 7, 2012 at 4:03 PM, Tom Lane wrote: > Robert Haas writes: >> I guess the question is whether this is a stop-ship item for spgist. >> If it is, then we're going to have to spend the time to fix this, but >> if not, then since it was submitted more than two weeks after the >> start of t

Re: [HACKERS] psql COPY vs. ON_ERROR_ROLLBACK, multi-command strings

On Sat, Feb 25, 2012 at 12:57 AM, Noah Misch wrote: > Thanks.  While testing a crashing function, I noticed that my above patch > added some noise to psql output when the server crashes: > > [local] test=# select crashme(); > The connection to the server was lost. Attempting reset: Failed. > The c

Re: [HACKERS] WIP: URI connection string support for libpq

On 03/07/2012 09:16 PM, Alexander Shulgin wrote: I would prefer src/interfaces/libpq/test, to keep it close to the code. Hm, actually that makes more sense and is not unprecedented (I see ecpg has it's own 'test' subdir.) Apparently I was under false impression that all regression tests are c

Re: [HACKERS] Command Triggers, patch v11

On 6 March 2012 23:25, Thom Brown wrote: > On 6 March 2012 21:18, Thom Brown wrote: >> On 6 March 2012 21:04, Dimitri Fontaine wrote: > [CASCADE will not run the command triggers for cascaded objects] If these are all expected, does it in any way compromise the effectiveness of DDL

Re: [HACKERS] Fix PL/Python metadata when there is no result

Peter Eisentraut writes: > On ons, 2012-03-07 at 15:59 -0500, Tom Lane wrote: >> Or are we talking about two different things? > I think so. I'm wondering here how to detect whether the execution of a > statement has yielded a result set at all. (For example, you ran SELECT > or INSERT ... RETU

Re: [HACKERS] Fix PL/Python metadata when there is no result

On ons, 2012-03-07 at 15:59 -0500, Tom Lane wrote: > > Which led me to think, how are you actually expected to know when no > > rows are expected to be returned, in PL/Python? You can look at > > result.status(), which returns a numeric SPI status, but that seems > > fragile. I notice that result

Re: [HACKERS] WARNING: concurrent insert in progress within table "resource"

2012/3/7 Robert Haas : > On Mon, Feb 27, 2012 at 10:54 AM, Pavel Stehule > wrote: >> yes >> >> 2012/2/27 Robert Haas : >>> On Sun, Feb 26, 2012 at 10:04 AM, Pavel Stehule >>> wrote: Hello I tested creating some larger indexes There was a warning: postgres=# CR

Re: [HACKERS] poll: CHECK TRIGGER?

Hello 2012/3/7 Tom Lane : > Robert Haas writes: >> Just to be clear, I am not proposing that we get rid of CHECK TRIGGER >> and keep CHECK FUNCTION.  I'm proposing that we get rid of all of the >> dedicated syntax support, and expose it all through one or more >> SQL-callable functions. > > This

Re: [HACKERS] poll: CHECK TRIGGER?

Robert Haas writes: > Well, I guess I'm still of the opinion that the real question is > whether the particular lint checks that Pavel's implemented are good > and useful things. Has anyone spent any time looking at *that*? I'm > not going to stand here and hold my breath over the interface, but

Re: [HACKERS] a slightly stale comment

On Wed, Mar 07, 2012 at 07:46:32AM +, Simon Riggs wrote: > There is much wisdom there and much wisdom in leaving ancient warnings > as we find them. The comment is a wise and insightful statement -- about a totally different system than we have today. > Are these the words you object to? > >

Re: [HACKERS] elegant and effective way for running jobs inside a database

Merlin Moncure writes: > sure, I get that, especially in regards to procedures. a server > ticker though is a pretty small thing and it's fair to ask if maybe > that should be exposed instead of (or perhaps in addition to) a job > scheduling system. I don't want to have a server-side ticker at a

Re: [HACKERS] NULL's support in SP-GiST

Robert Haas writes: > I guess the question is whether this is a stop-ship item for spgist. > If it is, then we're going to have to spend the time to fix this, but > if not, then since it was submitted more than two weeks after the > start of the CommitFest, it seems we should postpone it to 9.3.

Re: [HACKERS] patch for a locale-specific bug in regression tests (REL9_1_STABLE)

On 7.3.2012 21:39, Robert Haas wrote: > On Wed, Mar 7, 2012 at 3:08 PM, Tomas Vondra wrote: >> On 7.3.2012 17:56, Robert Haas wrote: >>> On Tue, Mar 6, 2012 at 1:59 PM, Tomas Vondra wrote: I've noticed a locale-specific bug in regression tests, I discovered thanks to the new "magpie" bu

Re: [HACKERS] Fix PL/Python metadata when there is no result

Peter Eisentraut writes: > On lör, 2012-02-25 at 18:03 +0100, Jean-Baptiste Quenot wrote: >> IMO raising an error is much better because: >> 1) It is not a valid usecase to retrieve result metadata when no rows >> are expected to be returned > Which led me to think, how are you actually expected

Re: [HACKERS] Checksums, state of play

On Wed, Mar 07, 2012 at 03:33:34PM -0500, Robert Haas wrote: > On Wed, Mar 7, 2012 at 3:09 PM, Simon Riggs wrote: > > Neither do I. It's pretty clear from our last discussion that the > > "fix" proposed doesn't actually work fully so I don't think its going > > to be either more robust or more cer

Re: [HACKERS] CLUSTER VERBOSE (9.1.3)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/7/2012 2:42 PM, Tom Lane wrote: > Larry Rosenman writes: >> On 3/7/2012 12:31 PM, Alvaro Herrera wrote: >>> Also, this isn't limited to CLUSTER; anything that rewrites >>> the table and indexes would benefit. Meaning ALTER TABLE that >>> does a

Re: [HACKERS] Fix PL/Python metadata when there is no result

On lör, 2012-02-25 at 18:03 +0100, Jean-Baptiste Quenot wrote: > IMO raising an error is much better because: > > 1) It is not a valid usecase to retrieve result metadata when no rows > are expected to be returned Which led me to think, how are you actually expected to know when no rows are expec

Re: [HACKERS] WARNING: concurrent insert in progress within table "resource"

On Mon, Feb 27, 2012 at 10:54 AM, Pavel Stehule wrote: > yes > > 2012/2/27 Robert Haas : >> On Sun, Feb 26, 2012 at 10:04 AM, Pavel Stehule >> wrote: >>> Hello >>> >>> I tested creating some larger indexes >>> >>> There was a warning: >>> >>> postgres=# CREATE INDEX idx_resource_name ON resource

Re: [HACKERS] pgsql_fdw, FDW for PostgreSQL server

On tis, 2012-03-06 at 13:39 -0500, Tom Lane wrote: > A bigger issue with postgresql_fdw_validator is that it supposes that > the core backend is authoritative as to what options libpq supports, > which is bad design on its face. It would be much more sensible for > dblink to be asking libpq what o

Re: [HACKERS] CLUSTER VERBOSE (9.1.3)

Larry Rosenman writes: > On 3/7/2012 12:31 PM, Alvaro Herrera wrote: >> Also, this isn't limited to CLUSTER; anything that rewrites the >> table and indexes would benefit. Meaning ALTER TABLE that does a >> full rewrite, and also VACUUM FULL. > +1. I think we should update ps_status as well as

Re: [HACKERS] elegant and effective way for running jobs inside a database

On Wed, Mar 7, 2012 at 2:14 PM, Simon Riggs wrote: > The stored procedure route sounds attractive but its a long way off > and doesn't address all of the states needs people have voiced. I'm > not against doing both, I just want to do the quickest and easiest. sure, I get that, especially in rega

Re: [HACKERS] patch for a locale-specific bug in regression tests (REL9_1_STABLE)

On Wed, Mar 7, 2012 at 3:08 PM, Tomas Vondra wrote: > On 7.3.2012 17:56, Robert Haas wrote: >> On Tue, Mar 6, 2012 at 1:59 PM, Tomas Vondra wrote: >>> I've noticed a locale-specific bug in regression tests, I discovered >>> thanks to the new "magpie" buildfarm member (testing "cs_CZ" locale). >>>

Re: [HACKERS] NULL's support in SP-GiST

On Tue, Feb 28, 2012 at 5:20 PM, Jaime Casanova wrote: > On Thu, Feb 2, 2012 at 4:26 PM, Oleg Bartunov wrote: >> attached patch introduces NULLs indexing for SP-GiST. With this patch >> Sp-GiST supports IS NULL, IS NOT NULL clauses, as well as full index scan. > > I was looking at this. > It pass

Re: [HACKERS] Checksums, state of play

On Wed, Mar 7, 2012 at 3:09 PM, Simon Riggs wrote: > Neither do I. It's pretty clear from our last discussion that the > "fix" proposed doesn't actually work fully so I don't think its going > to be either more robust or more certain to give low false positives. > So I don't think more time "fixin

Re: [HACKERS] elegant and effective way for running jobs inside a database

On Wed, Mar 7, 2012 at 7:55 PM, Merlin Moncure wrote: > On Wed, Mar 7, 2012 at 2:15 AM, Simon Riggs wrote: >> We talked about this at last year's Dev meeting. And we got >> sidetracked into "what we really want is stored procedures". Maybe we >> want that, but its a completely separate thing. Ple

Re: [HACKERS] Checksums, state of play

Robert Haas writes: > So I think it's time to push this one out to 9.3. Frankly, I thought it was probably too late for 9.2 when it was first proposed, and the number of issues that have been identified since then just confirm that feeling. There is another point beyond the ones in your summary:

Re: [HACKERS] RFC: Making TRUNCATE more "MVCC-safe"

On Wed, Mar 7, 2012 at 2:06 PM, Simon Riggs wrote: >> I am not thrilled with the design as it stands, but bulk loading is a >> known and serious pain point for us, so it would be awfully nice to >> improve it.  I'm not sure whether we should only go as far as setting >> HEAP_XMIN_COMMITTED or whet

Re: [HACKERS] Checksums, state of play

On Wed, Mar 7, 2012 at 5:28 PM, Robert Haas wrote: > On Tue, Mar 6, 2012 at 2:27 PM, Bruce Momjian wrote: >> The feature is no where near complete, and we should not be designing >> features at this stage. > > I agree, on both counts.  Although Simon did a good job pulling > together something th

Re: [HACKERS] patch for a locale-specific bug in regression tests (REL9_1_STABLE)

On 7.3.2012 17:56, Robert Haas wrote: > On Tue, Mar 6, 2012 at 1:59 PM, Tomas Vondra wrote: >> I've noticed a locale-specific bug in regression tests, I discovered >> thanks to the new "magpie" buildfarm member (testing "cs_CZ" locale). >> The problem is in "foreign_data" where the output is sorte

Re: [HACKERS] poll: CHECK TRIGGER?

2012/3/7 Robert Haas : > On Wed, Mar 7, 2012 at 2:03 PM, Tom Lane wrote: >> Robert Haas writes: >>> On Wed, Mar 7, 2012 at 12:04 PM, Tom Lane wrote: More importantly, I do not agree with requiring the user to specify the language name --- that is, it should be check_function(procoid) a

Re: [HACKERS] poll: CHECK TRIGGER?

On Wed, Mar 7, 2012 at 2:03 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Mar 7, 2012 at 12:04 PM, Tom Lane wrote: >>> More importantly, I do not agree with requiring the user to specify the >>> language name --- that is, it should be check_function(procoid) and have >>> that look up a la

Re: [HACKERS] elegant and effective way for running jobs inside a database

On Wed, Mar 7, 2012 at 2:15 AM, Simon Riggs wrote: > We talked about this at last year's Dev meeting. And we got > sidetracked into "what we really want is stored procedures". Maybe we > want that, but its a completely separate thing. Please lets not get > distracted from a very simple thing becau

Re: [HACKERS] Memory usage during sorting

On Sat, Mar 3, 2012 at 4:15 PM, Jeff Janes wrote: > The better solution would be to reduce the overhead in the first > place.  While building the initial runs, there is no reason to have 3 > blocks worth of overhead for each tape, when only one tape is ever > being used at a time.  But that change

[HACKERS] PGXS ignores SHLIB_LINK when linking modules

Hi, I'm trying to write my first PostgreSQL C extension. I used the pgxn-utils skeleton as a base and specified some external libraries in SHLIB_LINK. However, this variable was ignored when linking the library (using pgxs from current git master). After spending quite a bit of time trying to und

Re: [HACKERS] WIP: URI connection string support for libpq

On 03/07/2012 08:03 PM, Peter Eisentraut wrote: On ons, 2012-03-07 at 18:31 +0200, Alex Shulgin wrote: I figured that adding this right into src/interfaces/libpq is polluting the source dir, so I've used src/test instead. I would prefer src/interfaces/libpq/test, to keep it close to the code

Re: [HACKERS] poll: CHECK TRIGGER?

2012/3/7 Tom Lane : > Robert Haas writes: >> On Wed, Mar 7, 2012 at 12:04 PM, Tom Lane wrote: >>> More importantly, I do not agree with requiring the user to specify the >>> language name --- that is, it should be check_function(procoid) and have >>> that look up a language-specific checker.  Oth

Re: [HACKERS] RFC: Making TRUNCATE more "MVCC-safe"

On Wed, Mar 7, 2012 at 5:39 PM, Robert Haas wrote: > On Wed, Mar 7, 2012 at 10:26 AM, Simon Riggs wrote: >> On Wed, Mar 7, 2012 at 2:59 PM, Robert Haas wrote: >>> All true. >> >> So gentlemen, do we think this is worth pursuing further for this release? >> >> I'm sure usual arguments apply all r

Re: [HACKERS] poll: CHECK TRIGGER?

Robert Haas writes: > On Wed, Mar 7, 2012 at 12:04 PM, Tom Lane wrote: >> More importantly, I do not agree with requiring the user to specify the >> language name --- that is, it should be check_function(procoid) and have >> that look up a language-specific checker.  Otherwise, scenarios like >>

Re: [HACKERS] pg_stat_statements and planning time

On Wed, Mar 7, 2012 at 8:07 AM, Tom Lane wrote: > Fujii Masao writes: >> In the patch, I didn't change the column name "total_time" meaning >> the time spent in the executor because of the backward compatibility. >> But once new column "plan_time" is added, "total_time" is confusing and >> ISTM i

Re: [HACKERS] CLUSTER VERBOSE (9.1.3)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/7/2012 12:31 PM, Alvaro Herrera wrote: > > Excerpts from Robert Haas's message of mié mar 07 11:57:41 -0300 > 2012: > >> Seems like a good enhancement to me, if someone can figure out >> how to do it cleanly. Unfortunately those debug messages

Re: [HACKERS] CLUSTER VERBOSE (9.1.3)

Excerpts from Robert Haas's message of mié mar 07 11:57:41 -0300 2012: > Seems like a good enhancement to me, if someone can figure out how to > do it cleanly. Unfortunately those debug messages may not be in a > place where it's real easy for them to know whether they're being > called from CLU

Re: [HACKERS] WIP: URI connection string support for libpq

On ons, 2012-03-07 at 18:31 +0200, Alex Shulgin wrote: > I figured that adding this right into src/interfaces/libpq is > polluting the source dir, so I've used src/test instead. I would prefer src/interfaces/libpq/test, to keep it close to the code. -- Sent via pgsql-hackers mailing list (pgsq

Re: [HACKERS] poll: CHECK TRIGGER?

2012/3/7 Tom Lane : > Robert Haas writes: >> Just to be clear, I am not proposing that we get rid of CHECK TRIGGER >> and keep CHECK FUNCTION.  I'm proposing that we get rid of all of the >> dedicated syntax support, and expose it all through one or more >> SQL-callable functions. > > This seems e

Re: [HACKERS] RFC: Making TRUNCATE more "MVCC-safe"

On Wed, Mar 7, 2012 at 10:26 AM, Simon Riggs wrote: > On Wed, Mar 7, 2012 at 2:59 PM, Robert Haas wrote: >> All true. > > So gentlemen, do we think this is worth pursuing further for this release? > > I'm sure usual arguments apply all round, so I'll skip that part. This patch is awfully late to

Re: [HACKERS] a slightly stale comment

Robert Haas wrote: > Simon Riggs wrote: >> I think its funny and scary, as well as being of historical >> interest. Well, I something of a similar reaction, but I think that's outweighed by the probable waste of time for anyone trying to make sense of it. > I think we should just remove it.

Re: [HACKERS] a slightly stale comment

On Wed, Mar 7, 2012 at 12:17 PM, Simon Riggs wrote: > On Wed, Mar 7, 2012 at 4:09 PM, Kevin Grittner > wrote: > >> What part of it do you find to be accurate or helpful? > > I think its funny and scary, as well as being of historical interest. > > But please suggest a new wording so we can discus

Re: [HACKERS] poll: CHECK TRIGGER?

On Wed, Mar 7, 2012 at 12:04 PM, Tom Lane wrote: >> If we need both >> plpgsql_check_function(procoid) and plpgsql_check_trigger(tgoid), no >> problem. > > FWIW, I would suggest check_trigger(regclass, name) not tgoid, because > we do not have a regtrigger convenience type (and I don't think it's

Re: [HACKERS] poll: CHECK TRIGGER?

2012/3/7 Robert Haas : > On Wed, Mar 7, 2012 at 12:17 AM, Pavel Stehule > wrote: >> Robert, please, can you comment to this issue? And other, please. I am >> able to fix syntax to any form where we will have agreement. > > Well, so far I don't see that anyone has offered a compelling reason > why

Re: [HACKERS] Checksums, state of play

On Tue, Mar 6, 2012 at 2:27 PM, Bruce Momjian wrote: > The feature is no where near complete, and we should not be designing > features at this stage. I agree, on both counts. Although Simon did a good job pulling together something that basically works in a short amount of time, the edge cases

Re: [HACKERS] a slightly stale comment

On Wed, Mar 7, 2012 at 4:09 PM, Kevin Grittner wrote: > What part of it do you find to be accurate or helpful? I think its funny and scary, as well as being of historical interest. But please suggest a new wording so we can discuss it. --  Simon Riggs   http://www.2ndQuadrant.

Re: [HACKERS] poll: CHECK TRIGGER?

Robert Haas writes: > Just to be clear, I am not proposing that we get rid of CHECK TRIGGER > and keep CHECK FUNCTION. I'm proposing that we get rid of all of the > dedicated syntax support, and expose it all through one or more > SQL-callable functions. This seems entirely reasonable to me. Th

Re: [HACKERS] patch for a locale-specific bug in regression tests (REL9_1_STABLE)

On Tue, Mar 6, 2012 at 1:59 PM, Tomas Vondra wrote: > I've noticed a locale-specific bug in regression tests, I discovered > thanks to the new "magpie" buildfarm member (testing "cs_CZ" locale). > The problem is in "foreign_data" where the output is sorted by a column, > and "cs_CZ" behaves differ

Re: [HACKERS] [9.2] Confusion over CacheRegisterSyscacheCallback

On Wed, Mar 07, 2012 at 11:16:06AM -0500, Tom Lane wrote: > Marko Kreen writes: > > On Tue, Mar 06, 2012 at 04:27:11PM -0500, Tom Lane wrote: > >> Or you could do like setrefs.c does, and assume you know how to > >> calculate the hash value for an OID-keyed cache. > > > Ok, the hashoid() hack wor

Re: [HACKERS] poll: CHECK TRIGGER?

On Wed, Mar 7, 2012 at 12:17 AM, Pavel Stehule wrote: > Robert, please, can you comment to this issue? And other, please. I am > able to fix syntax to any form where we will have agreement. Well, so far I don't see that anyone has offered a compelling reason why this needs core syntax support. I

Re: [HACKERS] WIP: URI connection string support for libpq

Peter Eisentraut writes: >> I've included a (separate) test shell script based on Greg's cases in >> one of the updates. What would be preferred place to plug it in? >> Override installcheck in libpq Makefile? > > I think that would be the right place. I figured that adding this right into sr

Re: [HACKERS] [9.2] Confusion over CacheRegisterSyscacheCallback

Marko Kreen writes: > On Tue, Mar 06, 2012 at 04:27:11PM -0500, Tom Lane wrote: >> Or you could do like setrefs.c does, and assume you know how to >> calculate the hash value for an OID-keyed cache. > Ok, the hashoid() hack works. But please take it as report from > the ground that this API is u

Re: [HACKERS] a slightly stale comment

Simon Riggs wrote: > Dan Ports wrote: >> While mucking around in src/backend/utils/time/tqual.c today, I >> noticed the following comment attached to HeapTupleSatisfiesNow: >> [a comment explaining that if you think the code needs to be >> changed, you are wrong, because 2 phase locking will

Re: [HACKERS] pg_stat_statements and planning time

Fujii Masao writes: > In the patch, I didn't change the column name "total_time" meaning > the time spent in the executor because of the backward compatibility. > But once new column "plan_time" is added, "total_time" is confusing and > ISTM it should be renamed... Well, if we were tracking plann

Re: [HACKERS] review: CHECK FUNCTION statement

Hello multicheck for triggers are supported now CHECK TRIGGER ALL; CHECK TRIGGER ALL IN SCHEMA xxx FOR ROLE yyy; Regards Pavel Stehule check_function-2012-03-07-2.patch.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make chan

Re: Scaling XLog insertion (was Re: [HACKERS] Moving more work outside WALInsertLock)

On Mon, Mar 5, 2012 at 8:50 AM, Heikki Linnakangas wrote: > > That particular issue would be very hard to hit in practice, so I don't know > if this could explain the recovery failures that Jeff saw. I got the test > script running (thanks for that Jeff!), but unfortunately have not seen any > fai

Re: [HACKERS] pg_stat_statements and planning time

On Wed, Mar 7, 2012 at 6:45 AM, Fujii Masao wrote: > pg_stat_statements is basically very helpful to find out slow queries. > But since it doesn't report the time spent in the planner, we cannot > find out slow queries which take most time to do query planning, from > pg_stat_statements. Is there

Re: Scaling XLog insertion (was Re: [HACKERS] Moving more work outside WALInsertLock)

Simon Riggs writes: > On Wed, Mar 7, 2012 at 3:04 PM, Tom Lane wrote: >> Alvaro Herrera writes: >>> So they are undoubtely rare.  Not sure if as rare as Higgs bosons. >> Even if they're rare, having a major performance hiccup when one happens >> is not a side-effect I want to see from a patch w

Re: [HACKERS] RFC: Making TRUNCATE more "MVCC-safe"

On Wed, Mar 7, 2012 at 2:59 PM, Robert Haas wrote: > All true. So gentlemen, do we think this is worth pursuing further for this release? I'm sure usual arguments apply all round, so I'll skip that part. --  Simon Riggs   http://www.2ndQuadrant.com/  PostgreSQL Development, 24

Re: Scaling XLog insertion (was Re: [HACKERS] Moving more work outside WALInsertLock)

On Wed, Mar 7, 2012 at 3:04 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Just to keep things in perspective -- For a commit record to reach one >> megabyte, it would have to be a transaction that drops over 43k tables. >> Or have 64k smgr inval messages (for example, a TRUNCATE might send half

Re: Scaling XLog insertion (was Re: [HACKERS] Moving more work outside WALInsertLock)

Alvaro Herrera writes: > Just to keep things in perspective -- For a commit record to reach one > megabyte, it would have to be a transaction that drops over 43k tables. > Or have 64k smgr inval messages (for example, a TRUNCATE might send half > a dozen of these messages). Or have 262k subtransac

Re: [HACKERS] RFC: Making TRUNCATE more "MVCC-safe"

On Wed, Mar 7, 2012 at 7:49 AM, Noah Misch wrote: > On Tue, Mar 06, 2012 at 08:36:05AM -0500, Robert Haas wrote: >> On Tue, Mar 6, 2012 at 5:43 AM, Noah Misch wrote: >> >> Well, consider something like CLUSTER. ?It's perfectly OK for CLUSTER >> >> to operate on a table that has been truncated sin

Re: [HACKERS] CLUSTER VERBOSE (9.1.3)

On Wed, Mar 7, 2012 at 9:33 AM, Larry Rosenman wrote: >>> Is there any way to get more info out of CLUSTER VERBOSE so it >>> says what index it's working on AFTER the table re-write? >>> >>> INFO:  clustering "public.values" using sequential scan and sort >>> INFO:  "values": found 0 removable, 26

Re: [HACKERS] CLUSTER VERBOSE (9.1.3)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/6/2012 8:32 AM, Robert Haas wrote: > On Mon, Mar 5, 2012 at 4:40 PM, Larry Rosenman > wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> Is there any way to get more info out of CLUSTER VERBOSE so it >> says what index it's working on

Re: [HACKERS] elegant and effective way for running jobs inside a database

Excerpts from Simon Riggs's message of mié mar 07 05:15:03 -0300 2012: > We talked about this at last year's Dev meeting. And we got > sidetracked into "what we really want is stored procedures". Maybe we > want that, but its a completely separate thing. Please lets not get > distracted from a ve

Re: Scaling XLog insertion (was Re: [HACKERS] Moving more work outside WALInsertLock)

Excerpts from Simon Riggs's message of mié mar 07 05:35:44 -0300 2012: > On Tue, Mar 6, 2012 at 8:32 PM, Tom Lane wrote: > > Heikki Linnakangas writes: > >> On 06.03.2012 17:12, Tom Lane wrote: > >>> How long is the current locked code exactly --- does it contain a loop? > > > >> Perhaps best if

Re: [HACKERS] RFC: Making TRUNCATE more "MVCC-safe"

On Tue, Mar 06, 2012 at 08:36:05AM -0500, Robert Haas wrote: > On Tue, Mar 6, 2012 at 5:43 AM, Noah Misch wrote: > >> Well, consider something like CLUSTER. ?It's perfectly OK for CLUSTER > >> to operate on a table that has been truncated since CLUSTER's snapshot > >> was taken, and no serializati

Re: [HACKERS] pg_stat_statements and planning time

On Wed, Mar 7, 2012 at 9:00 PM, Simon Riggs wrote: > On Wed, Mar 7, 2012 at 11:45 AM, Fujii Masao wrote: > >> Attached patch extends pg_stat_statements so that it reports the >> planning time. Thought? > > If we successfully aggregate SQL in the current patch then this might > be useful as well.

Re: [HACKERS] foreign key locks, 2nd attempt

n Wed, Mar 7, 2012 at 11:37 AM, Gokulakannan Somasundaram wrote: >> >> Please explain in detail your idea of how it will work. > So we will take some kind of lock, which will stop such a happening. ... > May be someone can come up with better ideas than this. With respect, I don't call this a de

Re: [HACKERS] pg_stat_statements and planning time

On Wed, Mar 7, 2012 at 11:45 AM, Fujii Masao wrote: > Attached patch extends pg_stat_statements so that it reports the > planning time. Thought? If we successfully aggregate SQL in the current patch then this might be useful as well. Until we do that it's not much use. --  Simon Riggs 

[HACKERS] pg_stat_statements and planning time

Hi, pg_stat_statements is basically very helpful to find out slow queries. But since it doesn't report the time spent in the planner, we cannot find out slow queries which take most time to do query planning, from pg_stat_statements. Is there any reason why pg_stat_statements doesn't collect the p

Re: [HACKERS] foreign key locks, 2nd attempt

> > > Please explain in detail your idea of how it will work. > > OK. I will try to explain the abstract idea, i have. a) Referential integrity gets violated, when there are referencing key values, not present in the referenced key values. We are maintaining the integrity by taking a Select for Sha

Re: [HACKERS] foreign key locks, 2nd attempt

On Wed, Mar 7, 2012 at 10:18 AM, Gokulakannan Somasundaram wrote: >> >> Insert, Update and Delete don't take locks they simply mark the tuples >> they change with an xid. Anybody else wanting to "wait on the lock" >> just waits on the xid. We do insert a lock row for each xid, but not >> one per r

Re: [HACKERS] foreign key locks, 2nd attempt

> > > Insert, Update and Delete don't take locks they simply mark the tuples > they change with an xid. Anybody else wanting to "wait on the lock" > just waits on the xid. We do insert a lock row for each xid, but not > one per row changed. > I mean the foreign key checks here. They take a Select f

Re: [HACKERS] foreign key locks, 2nd attempt

On Wed, Mar 7, 2012 at 9:24 AM, Gokulakannan Somasundaram wrote: > I feel sad, that i followed this topic very late. But i still want to put > forward my views. > Have we thought on the lines of how Robert has implemented relation level > locks. In short it should go like this > > a) The locks for

Re: [HACKERS] [9.2] Confusion over CacheRegisterSyscacheCallback

On Tue, Mar 06, 2012 at 04:27:11PM -0500, Tom Lane wrote: > Marko Kreen writes: > > On Tue, Mar 06, 2012 at 11:10:38AM -0500, Tom Lane wrote: > >> Why would you need to know that? The reason the calculation function > >> is static is that there's no apparent need to expose that information > >> o

Re: [HACKERS] foreign key locks, 2nd attempt

I feel sad, that i followed this topic very late. But i still want to put forward my views. Have we thought on the lines of how Robert has implemented relation level locks. In short it should go like this a) The locks for enforcing Referential integrity should be taken only when the rarest of the

Re: Scaling XLog insertion (was Re: [HACKERS] Moving more work outside WALInsertLock)

On Tue, Mar 6, 2012 at 8:32 PM, Tom Lane wrote: > Heikki Linnakangas writes: >> On 06.03.2012 17:12, Tom Lane wrote: >>> How long is the current locked code exactly --- does it contain a loop? > >> Perhaps best if you take a look for yourself, the function is called >> ReserveXLogInsertLocation()

Re: [HACKERS] elegant and effective way for running jobs inside a database

2012/3/7 Simon Riggs : > On Tue, Mar 6, 2012 at 3:21 PM, Tom Lane wrote: > >> But having said that, it's not apparent to me why such a thing would >> need to live "inside the database" at all.  It's very easy to visualize >> a task scheduler that runs as a client and requires nothing new from the

Re: [HACKERS] elegant and effective way for running jobs inside a database

On Tue, Mar 6, 2012 at 3:21 PM, Tom Lane wrote: > But having said that, it's not apparent to me why such a thing would > need to live "inside the database" at all.  It's very easy to visualize > a task scheduler that runs as a client and requires nothing new from the > core code.  Approaching the

  1   2   >