Re: [HACKERS] Patch: clean up addRangeTableEntryForFunction

Robert Haas wrote: > On Tue, Jan 22, 2013 at 11:45 AM, David Fetter wrote: > > I've been working with Andrew Gierth (well, mostly he's been doing the > > work, as usual) to add WITH ORDINALITY as an option for set-returning > > functions. In the process, he found a minor opportunity to clean up >

Re: [HACKERS] Reduce maximum error in tuples estimation after vacuum.

Hello, > I could see the same output with your latest script, also I could reproduce > the test if I run the test with individual sql statements. > One of the main point for reproducing individual test was to keep autovacuum > = off. I see. Autovacuum's nap time is 60 sconds for the default setti

Re: [HACKERS] A better way than tweaking NTUP_PER_BUCKET

Hi all, I have been working on a patch for the above discussed functionalities. I made an array of int32s, one for each bucket in a hash table(the array is per hash table). I am using the hash value directly to set the corresponding bit in the bit field.Specifically: bitfield_orvalue = 1

Re: [HACKERS] [PATCH] Add an ldapoption to disable chasing LDAP referrals

On Wed, Jul 3, 2013 at 3:04 AM, James Sewell wrote: > Hey Peter, > > You are correct, it is the same as the referrals option in pam_ldap. It's > also the -C (sometimes -R - it seems ldapsearch options are pretty > non-standard) option in ldapsearch. > > As far as I'm aware you can't pass this in

Re: [HACKERS] Improvement of checkpoint IO scheduler for stable transaction responses

Hi, I tested and changed segsize=0.25GB which is max partitioned table file size and default setting is 1GB in configure option (./configure --with-segsize=0.25). Because I thought that small segsize is good for fsync phase and background disk write in OS in checkpoint. I got significant improveme

[HACKERS] possible/feasible to specify field and value in error msg?

Hi, I have some complicated query that truncates and fills a table and i get this message: ERROR: smallint out of range STATEMENT: This is in postgres 8.4 I don't know where the error is, and the query takes rather long. So it is going to be a bit cumbersome for me to debug this. Would it be po

Re: [HACKERS] proposal: simple date constructor from numeric values

2013/7/2 Pavel Stehule : > 2013/7/1 Peter Eisentraut : >> On 7/1/13 3:47 AM, Pavel Stehule wrote: >>> and it is a part of our ToDo: "Add function to allow the creation of >>> timestamps using parameters" >>> >>> so we can have a functions with signatures >> >> I would just name them date(...), time

Re: [HACKERS] proposal: simple date constructor from numeric values

2013/7/3 Pavel Stehule : > 2013/7/2 Pavel Stehule : >> 2013/7/1 Peter Eisentraut : >>> On 7/1/13 3:47 AM, Pavel Stehule wrote: and it is a part of our ToDo: "Add function to allow the creation of timestamps using parameters" so we can have a functions with signatures >>> >>> I w

Re: [HACKERS] proposal: simple date constructor from numeric values

On 1 July 2013 17:47, Pavel Stehule wrote: > 2013/6/29 Pavel Stehule : >> long time I am thinking about simple function for creating date or >> timestamp values based on numeric types without necessity to create >> format string. >> >> What do you think about this idea? > I found so same idea was

[HACKERS] [9.3 bug fix] ECPG does not escape backslashes

Hello, I happened to find a trivial bug of ECPG while experimenting with 9.3 beta 2. Please find attached the patch to fix this. This is not specific to 9.3. Could you commit and backport this? [Bug description] Running "ecpg c:\command\a.pgc" produces the following line in a.c: #line 1

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Wednesday, July 03, 2013 2:58 AM Alvaro Herrera wrote: > Amit Kapila escribió: > > > I have changed the file name to postgresql.auto.conf and I have > changed the > > name of SetPersistentLock to AutoFileLock. > > > > Zoltan, > > > > Could you please once check the attached Patch if you have ti

Re: [HACKERS] Custom gucs visibility

> > > If we haven't loaded the .so yet, where would we get the list of > > > custom GUCs from? > > > > This has come up before. We could show the string value of the GUC, > > if it's been set in postgresql.conf, but we do not have correct > > values for any of the other columns in pg_settings; nor

Re: [HACKERS] proposal: simple date constructor from numeric values

Hello 2013/7/3 Brendan Jurd : > On 1 July 2013 17:47, Pavel Stehule wrote: >> 2013/6/29 Pavel Stehule : >>> long time I am thinking about simple function for creating date or >>> timestamp values based on numeric types without necessity to create >>> format string. >>> >>> What do you think about

Re: [HACKERS] proposal: enable new error fields in plpgsql (9.4)

On Wed, Jul 03, 2013 at 06:17:18AM +0200, Pavel Stehule wrote: > 2013/7/2 Noah Misch : > > Here's a revision bearing the discussed name changes and protocol > > documentation tweaks, along with some cosmetic adjustments. If this seems > > good to you, I will commit it. > > +1 Done. Rushabh, I n

Re: [HACKERS] proposal: enable new error fields in plpgsql (9.4)

2013/7/3 Noah Misch : > On Wed, Jul 03, 2013 at 06:17:18AM +0200, Pavel Stehule wrote: >> 2013/7/2 Noah Misch : >> > Here's a revision bearing the discussed name changes and protocol >> > documentation tweaks, along with some cosmetic adjustments. If this seems >> > good to you, I will commit it.

Re: [HACKERS] Move unused buffers to freelist

On Wednesday, July 03, 2013 12:27 PM Simon Riggs wrote: On 28 June 2013 05:52, Amit Kapila wrote:   >> As per my understanding Summarization of points raised by you and Andres >> which this patch should address to have a bigger win: >> 1. Bgwriter needs to be improved so that it can help in reduc

Re: [HACKERS] Move unused buffers to freelist

On 3 July 2013 12:56, Amit Kapila wrote: > >My perspectives here would be > > > * BufFreelistLock is a huge issue. Finding a next victim block needs to > be > an O(1) operation, yet it is currently much worse than that. Measuring > > contention on that lock hides that problem, since having share

Re: [HACKERS] Review: Patch to compute Max LSN of Data Pages

On Wednesday, July 03, 2013 1:26 AM Robert Haas wrote: > On Tue, Jun 25, 2013 at 1:42 PM, Andres Freund > wrote: > > I think the usecase for this utility isn't big enough to be included > in > > postgres since it really can only help in a very limited > > circumstances. And I think it's too likely

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On 3 July 2013 07:45, Amit Kapila wrote: > > postgresql.auto.conf is similar enough to postgresql.conf that it will > prevent tab completion from working as it does now. As a result it will > cause > > people to bring that file up for editing when we wish to avoid that. > > This new file postg

Re: [HACKERS] Review: Patch to compute Max LSN of Data Pages

On Wed, Jul 3, 2013 at 8:44 AM, Amit Kapila wrote: >> Why does this patch need all of this fancy path-handling logic - >> specifically, remove_parent_refernces() and make_absolute_path()? >> Surely its needs are not that different from pg_ctl or pg_resetxlog or >> pg_controldata. If they all need

Re: [HACKERS] Move unused buffers to freelist

On Wednesday, July 03, 2013 6:10 PM Simon Riggs wrote: On 3 July 2013 12:56, Amit Kapila wrote:   >>>My perspectives here would be >>> * BufFreelistLock is a huge issue. Finding a next victim block needs to be an O(1) operation, yet it is currently much worse than that. Measuring >>> contention o

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On Tue, Jul 02, 2013 at 04:00:22PM -0400, Robert Haas wrote: > make you review patches against your will. Don't take it for more > than what Josh meant it as. And that was what? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On Tue, Jul 02, 2013 at 09:42:43PM -0700, Josh Berkus wrote: > Clearly I ticked off a bunch of people by publishing "the list". On the > other hand, in the 5 days succeeding the post, more than a dozen > additional people signed up to review patches, and we got some of the > "ready for committer"

Re: [HACKERS] Improvement of checkpoint IO scheduler for stable transaction responses

On Wed, Jul 3, 2013 at 4:18 AM, KONDO Mitsumasa wrote: > I tested and changed segsize=0.25GB which is max partitioned table file size > and > default setting is 1GB in configure option (./configure --with-segsize=0.25). > Because I thought that small segsize is good for fsync phase and background

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Wednesday, July 03, 2013 6:29 PM Simon Riggs wrote: On 3 July 2013 07:45, Amit Kapila wrote:   >>> postgresql.auto.conf is similar enough to postgresql.conf that it will prevent tab completion from working as it does now. As a result it will cause >>> people to bring that file up for editing wh

Re: [HACKERS] Improvement of checkpoint IO scheduler for stable transaction responses

On 2013-07-03 17:18:29 +0900, KONDO Mitsumasa wrote: > Hi, > > I tested and changed segsize=0.25GB which is max partitioned table file size > and > default setting is 1GB in configure option (./configure --with-segsize=0.25). > Because I thought that small segsize is good for fsync phase and back

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On Wed, Jul 3, 2013 at 9:21 AM, Michael Meskes wrote: > On Tue, Jul 02, 2013 at 04:00:22PM -0400, Robert Haas wrote: >> make you review patches against your will. Don't take it for more >> than what Josh meant it as. > > And that was what? An attempt to prod a few more people into helping review

Re: [HACKERS] Review: Patch to compute Max LSN of Data Pages

> -Original Message- > From: Robert Haas [mailto:robertmh...@gmail.com] > Sent: Wednesday, July 03, 2013 6:40 PM > To: Amit Kapila > Cc: Andres Freund; Josh Berkus; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Review: Patch to compute Max LSN of Data Pages > > On Wed, Jul 3, 201

Re: [HACKERS] Review: Patch to compute Max LSN of Data Pages

On Wed, Jul 3, 2013 at 9:51 AM, Amit Kapila wrote: > amit@linux:~> md test > amit@linux:~> cd test > amit@linux:~/test> ln -s ~/test link_test > amit@linux:~/test> ls > link_test > amit@linux:~/test> cd link_test > amit@linux:~/test/link_test> ls > link_test > amit@linux:~/test/link_test> cd link_

Re: [HACKERS] Support for REINDEX CONCURRENTLY

On 2013-07-03 10:03:26 +0900, Michael Paquier wrote: > +static int > +toast_open_indexes(Relation toastrel, > +LOCKMODE lock, > +Relation **toastidxs, > +int *num_indexes) > + /* > + * Free inde

Re: [HACKERS] refresh materialized view concurrently

Robert Haas wrote: > Hitoshi Harada wrote: >> Other than these, I've found index is opened with NoLock, >> relying on ExclusiveLock of parent matview, and ALTER INDEX SET >> TABLESPACE or something similar can run concurrently, but it is >> presumably safe.  DROP INDEX, REINDEX would be blocked b

Re: [HACKERS] dynamic background workers

On Mon, Jun 24, 2013 at 3:51 AM, Michael Paquier wrote: > 3) Why not adding an other function in worker_spi.c being the opposite > of worker_spi_launch to stop dynamic bgworkers for a given index > number? This would be only a wrapper of pg_terminate_backend, OK, but > at least it would give the u

Re: [HACKERS] refresh materialized view concurrently

Kevin Grittner writes: > Robert Haas wrote: >> I doubt very much that this is safe.  And even if it is safe >> today, I think it's a bad idea, because we're likely to try to >> reduce lock levels in the future.  Taking no lock on a relation >> we're opening, even an index, seems certain to be a b

Re: [HACKERS] refresh materialized view concurrently

On Wed, Jul 3, 2013 at 10:25 AM, Tom Lane wrote: > Kevin Grittner writes: >> Robert Haas wrote: >>> I doubt very much that this is safe. And even if it is safe >>> today, I think it's a bad idea, because we're likely to try to >>> reduce lock levels in the future. Taking no lock on a relation

Re: [HACKERS] New regression test time

On Wed, Jul 3, 2013 at 2:28 AM, Simon Riggs wrote: >> It's sad to simply reject meaningful automated tests on the basis of doubt >> that they're important enough to belong in every human-in-the-loop test >> run. >> I share the broader vision for automated testing represented by these >> patches. >

Re: [HACKERS] refresh materialized view concurrently

Robert Haas writes: > On Wed, Jul 3, 2013 at 10:25 AM, Tom Lane wrote: >> I don't believe that that happens. If it does, it's a bug. Either the >> planner or the executor should be taking a lock on each index touched >> by a query. > It seems Kevin's right. Not sure why that doesn't break. A

Re: [HACKERS] refresh materialized view concurrently

On Wed, Jul 3, 2013 at 10:47 AM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Jul 3, 2013 at 10:25 AM, Tom Lane wrote: >>> I don't believe that that happens. If it does, it's a bug. Either the >>> planner or the executor should be taking a lock on each index touched >>> by a query. > >> It

Re: [HACKERS] Add more regression tests for ASYNC

On Mon, May 13, 2013 at 8:37 PM, Robins Tharakan wrote: > Hi, > > Patch to add more regression tests to ASYNC (/src/backend/commands/async). > Take code-coverage from 39% to 75%. > > Any and all feedback is obviously welcome. > > p.s.: Please let me know whether these tests are useless or would no

Re: [HACKERS] refresh materialized view concurrently

Robert Haas writes: > On Wed, Jul 3, 2013 at 10:47 AM, Tom Lane wrote: >> Are we somehow not going through ExecOpenIndices? > I dunno. I just did a quick black-box test: > CREATE TABLE foo (a int primary key); > BEGIN; > INSERT INTO foo VALUES (1); > SELECT relation::regclass, locktype, mode,

[HACKERS] (trivial patch) remove superfluous semicolons from pg_dump

I noticed an instance of 'appendPQExpBuffer(query, ";");' in pg_dump.c which seems pointless and mildly confusing. There's another seemingly useless one in pg_dumpall.c. Attached patch removes both (if that makes any sense). Regards Ian Barwick pg_dump-cull-semicolons.patch Description: Binary

Re: [HACKERS] Add some regression tests for SEQUENCE

On Tue, May 7, 2013 at 6:40 PM, Robins Tharakan wrote: > Have provided an updated patch as per Fabien's recent response on Commitfest > site. > Any and all feedback is appreciated. I think you should rename the roles used here to regress_rol_seq1 etc. to match the CREATE OPERATOR patch. And you

Re: [HACKERS] possible/feasible to specify field and value in error msg?

On Wed, Jul 3, 2013 at 10:54:48AM +0200, Willy-Bas Loos wrote: > Hi, > > I have some complicated query that truncates and fills a table and i get this > message: > ERROR: smallint out of range > STATEMENT: > This is in postgres 8.4 > I don't know where the error is, and the query takes rather l

Re: [HACKERS] dynamic background workers

Andres Freund escribió: > Just as a datapoint, if you benchmark the numbers of forks that can be > performed by a single process (i.e. postmaster) the number is easily in > the 10s of thousands. Now forking that much has some scalability > implications inside the kernel, but still. > I'd be surpri

Re: [HACKERS] Patch to add regression tests for SCHEMA

On Wed, May 8, 2013 at 9:19 PM, Robins Tharakan wrote: > Please find attached an updated patch with the said changes. > I'll try to update the other patches (if they pertain to this feedback) and > update on their respective threads (as well as on Commitfest). This patch updates the parallel sche

Re: [HACKERS] possible/feasible to specify field and value in error msg?

On Wed, Jul 3, 2013 at 11:14:18AM -0400, Bruce Momjian wrote: > On Wed, Jul 3, 2013 at 10:54:48AM +0200, Willy-Bas Loos wrote: > > Hi, > > > > I have some complicated query that truncates and fills a table and i get > > this > > message: > > ERROR: smallint out of range > > STATEMENT: > > Thi

Re: [HACKERS] refresh materialized view concurrently

On 2013-07-03 11:08:32 -0400, Tom Lane wrote: > Robert Haas writes: > > On Wed, Jul 3, 2013 at 10:47 AM, Tom Lane wrote: > >> Are we somehow not going through ExecOpenIndices? > > > I dunno. I just did a quick black-box test: > > > CREATE TABLE foo (a int primary key); > > BEGIN; > > INSERT IN

Re: [HACKERS] proposal: simple date constructor from numeric values

On 3 July 2013 21:41, Pavel Stehule wrote: > I am thinking so for these functions exists some consensus - minimally > for function "date"(year, month, int) - I dream about this function > ten years :) > > I am not sure about "datetime": > a) we use "timestamp" name for same thing in pg > b) we can

Re: [HACKERS] Add regression tests for ROLE (USER)

On Thu, May 9, 2013 at 4:29 AM, Fabien COELHO wrote: > This updated version works for me and addresses previous comments. > > I think that such tests are definitely valuable, especially as many corner > cases which must trigger errors are covered. > > I recommend to apply it. I'm attaching an upd

Re: [HACKERS] proposal: simple date constructor from numeric values

Peter Eisentraut escribió: > On 7/1/13 3:47 AM, Pavel Stehule wrote: > > CREATE OR REPLACE FUNCTION construct_time(hour int DEFAULT 0, mi int > > DEFAULT 0, sec int DEFAULT 0, ms float DEFAULT 0.0); > > If we are using integer datetime storage, we shouldn't use floats to > construct them. I thin

Re: [HACKERS] proposal: simple date constructor from numeric values

2013/7/3 Alvaro Herrera : > Peter Eisentraut escribió: >> On 7/1/13 3:47 AM, Pavel Stehule wrote: > >> > CREATE OR REPLACE FUNCTION construct_time(hour int DEFAULT 0, mi int >> > DEFAULT 0, sec int DEFAULT 0, ms float DEFAULT 0.0); >> >> If we are using integer datetime storage, we shouldn't use fl

Re: [HACKERS] Add regression tests for COLLATE

On Thu, May 9, 2013 at 9:27 PM, Robins Tharakan wrote: > One workaround is to use DROP COLLATION IF EXISTS, that conveys the message > without UTF8 in the message string. > > But three other tests use ALTER COLLATION and I see no way but to comment / > disable them. Currently have them disabled (w

Re: [HACKERS] proposal: simple date constructor from numeric values

Alvaro Herrera writes: > Peter Eisentraut escribió: >> On 7/1/13 3:47 AM, Pavel Stehule wrote: >>> CREATE OR REPLACE FUNCTION construct_time(hour int DEFAULT 0, mi int >>> DEFAULT 0, sec int DEFAULT 0, ms float DEFAULT 0.0); >> >> If we are using integer datetime storage, we shouldn't use floats

Re: [HACKERS] preserving forensic information when we freeze

On 2013-07-02 16:29:56 -0400, Robert Haas wrote: > On Mon, Jun 24, 2013 at 8:12 AM, Andres Freund wrote: > > Agreed. And it also improves the status quo when debugging. I wish this > > would have been the representation since the beginning. > > > > Some remarks: > > * I don't really like that Heap

Re: [HACKERS] proposal: simple date constructor from numeric values

2013/7/3 Tom Lane : > Alvaro Herrera writes: >> Peter Eisentraut escribió: >>> On 7/1/13 3:47 AM, Pavel Stehule wrote: CREATE OR REPLACE FUNCTION construct_time(hour int DEFAULT 0, mi int DEFAULT 0, sec int DEFAULT 0, ms float DEFAULT 0.0); >>> >>> If we are using integer datetime storag

Re: [HACKERS] Add regression tests for COLLATE

Robert Haas writes: > I did remove those, plus made some other cleanups, and committed this. > I think that there's now some duplication between this and the > collate.linux.utf8 test that should be cleaned up by removing the > duplicative stuff from that test, assuming this holds up OK when the

Re: [HACKERS] Add regression tests for COLLATE

On Wed, Jul 3, 2013 at 1:11 PM, Tom Lane wrote: > Robert Haas writes: >> I did remove those, plus made some other cleanups, and committed this. >> I think that there's now some duplication between this and the >> collate.linux.utf8 test that should be cleaned up by removing the >> duplicative st

Re: [HACKERS] Add regression tests for COLLATE

On Wed, Jul 3, 2013 at 1:26 PM, Robert Haas wrote: >> Please revert. > > OK, sure, but just for my education and general enlightenment ... what > platform is that? Ah, never mind. I see that the buildfarm is quickly turning red - NetBSD, OmniOS, and HP/UX are all unhappy. I think that's a kille

Re: [HACKERS] Add regression tests for COLLATE

On 2013-07-03 13:29:18 -0400, Robert Haas wrote: > On Wed, Jul 3, 2013 at 1:26 PM, Robert Haas wrote: > >> Please revert. > > > > OK, sure, but just for my education and general enlightenment ... what > > platform is that? > > Ah, never mind. I see that the buildfarm is quickly turning red - > N

Re: [HACKERS] New regression test time

On 3 July 2013 15:43, Robert Haas wrote: > > > Let's have a new schedule called minute-check with the objective to run > the > > common tests in 60 secs. > > > > We can continue to expand the normal schedules from here. > > > > Anybody that wants short tests can run that, everyone else can run the

Re: [HACKERS] Support for REINDEX CONCURRENTLY

On Wed, Jul 3, 2013 at 11:16 PM, Andres Freund wrote: > On 2013-07-03 10:03:26 +0900, Michael Paquier wrote: >> index 9ee9ea2..23e0373 100644 >> --- a/src/bin/pg_dump/pg_dump.c >> +++ b/src/bin/pg_dump/pg_dump.c >> @@ -2778,10 +2778,9 @@ binary_upgrade_set_pg_class_oids(Archive *fout, >> PQE

Re: [HACKERS] Support for REINDEX CONCURRENTLY

On 2013-07-04 02:32:32 +0900, Michael Paquier wrote: > > Wouldn't it make more sense to fetch the toast index oid in the query > > ontop instead of making a query for every relation? > With something like a CASE condition in the upper query for > reltoastrelid? This code path is not only taken by i

Re: [HACKERS] Add regression tests for COLLATE

Andres Freund writes: > On 2013-07-03 13:29:18 -0400, Robert Haas wrote: >> I think that's a killer blow for this particular patch. I'm going to >> set this to rejected in the CF app. > Can't we use a alternative expected file for those? Alternative expected files are a PITA to maintain, at lea

Re: [HACKERS] proposal: simple date constructor from numeric values

Hello > So my vote is for make_time(hour int, min int, sec float8). > so here is a patch Regards Pavel > regards, tom lane make_date.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subsc

Re: [HACKERS] Add regression tests for COLLATE

On Wed, Jul 3, 2013 at 1:38 PM, Tom Lane wrote: > Andres Freund writes: >> On 2013-07-03 13:29:18 -0400, Robert Haas wrote: >>> I think that's a killer blow for this particular patch. I'm going to >>> set this to rejected in the CF app. > >> Can't we use a alternative expected file for those? >

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

> Clearly I ticked off a bunch of people by publishing "the list". On the > other hand, in the 5 days succeeding the post, more than a dozen > additional people signed up to review patches, and we got some of the > "ready for committer" patches cleared out -- something which nothing > else I did,

Re: [HACKERS] Support for REINDEX CONCURRENTLY

On Thu, Jul 4, 2013 at 2:41 AM, Fujii Masao wrote: > On Thu, Jul 4, 2013 at 2:36 AM, Andres Freund wrote: >> On 2013-07-04 02:32:32 +0900, Michael Paquier wrote: >>> > Wouldn't it make more sense to fetch the toast index oid in the query >>> > ontop instead of making a query for every relation? >

Re: [HACKERS] Redesigning checkpoint_segments

On 6/6/13 4:09 PM, Heikki Linnakangas wrote: > On 06.06.2013 20:24, Josh Berkus wrote: >>> Yeah, something like that :-). I was thinking of letting the estimate >>> decrease like a moving average, but react to any increases immediately. >>> Same thing we do in bgwriter to track buffer allocations:

Re: [HACKERS] LATERAL quals revisited

I wrote: > So attached is a draft patch for this. It's not complete yet because > there are various comments that are now wrong and need to be updated; > but I think the code is functioning correctly. Hm, spoke too soon :-(. This query causes an assertion failure, with or without my draft patch:

Re: [HACKERS] Support for REINDEX CONCURRENTLY

On Thu, Jul 4, 2013 at 3:26 AM, Fujii Masao wrote: > On Thu, Jul 4, 2013 at 2:41 AM, Fujii Masao wrote: >> On Thu, Jul 4, 2013 at 2:36 AM, Andres Freund wrote: >>> On 2013-07-04 02:32:32 +0900, Michael Paquier wrote: > Wouldn't it make more sense to fetch the toast index oid in the query >>

Re: [HACKERS] New regression test time

On 07/03/2013 07:43 AM, Robert Haas wrote: > Let's have a new schedule called minute-check with the objective to run the >> common tests in 60 secs. Note that we're below 60s even with assert and CLOBBER_CACHE_ALWAYS, at least on my laptop. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts

Re: [HACKERS] refresh materialized view concurrently

Tom Lane wrote: > Robert Haas writes: >> Tom Lane wrote: >>> Are we somehow not going through ExecOpenIndices? > >> I dunno.  I just did a quick black-box test: >> >> [ begin; insert; without commit ] >> >> No foo_pkey anywhere. > > That proves nothing, as we don't keep such locks after the quer

Re: [HACKERS] Fix pgstattuple/pgstatindex to use regclass-type as the argument

On Wed, Jun 26, 2013 at 12:39 AM, Robert Haas wrote: > On Thu, Jun 20, 2013 at 2:32 PM, Fujii Masao wrote: >> On Thu, Jun 20, 2013 at 11:43 AM, Satoshi Nagayasu wrote: >>> (2013/06/17 4:02), Fujii Masao wrote: On Sat, Mar 9, 2013 at 3:23 PM, Satoshi Nagayasu wrote: > > It is o

Re: [HACKERS] Add regression tests for COLLATE

Robert Haas escribió: > I agree. I think it'd be a good idea to get the buildfarm to run the > existing collate.utf8.linux test regularly on platforms where it > passes, +1 -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

Re: [HACKERS] preserving forensic information when we freeze

On Wed, Jul 3, 2013 at 1:07 PM, Andres Freund wrote: > Well, nothing would prevent using the HeapTupleHeaderGetRawXmin() in > those places. Exactly the number of callsites is what makes me think > that somebody will get this wrong in the future. Well, I guess I could go rework the whole patch tha

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On Wed, Jul 3, 2013 at 2:24 PM, Cédric Villemain wrote: > > Clearly I ticked off a bunch of people by publishing "the list". On the > > other hand, in the 5 days succeeding the post, more than a dozen > > additional people signed up to review patches, and we got some of the > > "ready for committ

[HACKERS] Re: [COMMITTERS] pgsql: Revert "Hopefully-portable regression tests for CREATE/ALTER/DRO

The buildfarm is sad. Do you have a pointer about the issue? Is it that builds are performed in some particular locale? -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] big test separation POC

Here is a v2 which is more likely to work under VPATH. Here is a POC v4 which relies on multiple --schedule instead of creating concatenated schedule files. -- Fabien.diff --git a/src/test/regress/GNUmakefile b/src/test/regress/GNUmakefile index d5935b6..8a39f7d 100644 --- a/src/test/regres

Re: [HACKERS] New regression test time

On 07/03/2013 02:50 PM, Josh Berkus wrote: On 07/03/2013 07:43 AM, Robert Haas wrote: Let's have a new schedule called minute-check with the objective to run the common tests in 60 secs. Note that we're below 60s even with assert and CLOBBER_CACHE_ALWAYS, at least on my laptop. I find that

Re: [HACKERS] Add regression tests for COLLATE

On 07/03/2013 03:00 PM, Alvaro Herrera wrote: Robert Haas escribió: I agree. I think it'd be a good idea to get the buildfarm to run the existing collate.utf8.linux test regularly on platforms where it passes, +1 I can probably whip up a module for it. (I created the buildfarm module sys

Re: [HACKERS] preserving forensic information when we freeze

On Wed, Jul 3, 2013 at 8:07 PM, Andres Freund wrote: > On 2013-07-02 16:29:56 -0400, Robert Haas wrote: >> There's no possibility of getting confused here; if X is still around >> at all, it's xmax is of the same generation as Y's xmin. Otherwise, >> we've had an undetected XID wraparound. > > An

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

Tatsuo, > Because I did not register the patch into CF page myself. I should > have not posted it until I find any patch which I can take care > of. Sorry for this. My apologies! I did post the list of patches I'd added to the CF in my "patch sweep" to -hackers, but I forgot to match it against

Re: [HACKERS] Improvement of checkpoint IO scheduler for stable transaction responses

On 04/07/13 01:31, Robert Haas wrote: On Wed, Jul 3, 2013 at 4:18 AM, KONDO Mitsumasa wrote: I tested and changed segsize=0.25GB which is max partitioned table file size and default setting is 1GB in configure option (./configure --with-segsize=0.25). Because I thought that small segsize is goo

Re: [HACKERS] refresh materialized view concurrently

Kevin Grittner writes: > OK.  I had seen that no locks were held after the insert and wasn't > aware that we acquired and then released them for each insert > within a transaction.  On the other hand, we acquire locks on all > indexes even for a HOT UPDATE which uses a seqscan, and hold those > un

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

Michael Meskes wrote: >> So, as an experiment, call it a mixed result. I would like to have some >> other way to motivate reviewers than public shame. I'd like to have > > Doesn't shame imply that people knew that were supposed to review patches in > the first place? An implication that is not t

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

Le mercredi 3 juillet 2013 21:03:42, Christopher Browne a écrit : > On Wed, Jul 3, 2013 at 2:24 PM, Cédric Villemain wrote: > > > Clearly I ticked off a bunch of people by publishing "the list". On > > > the other hand, in the 5 days succeeding the post, more than a dozen > > > additional people

Re: [HACKERS] [PATCH] big test separation POC

On 2013-07-03 21:07:03 +0200, Fabien COELHO wrote: > > >>Here is a v2 which is more likely to work under VPATH. > > Here is a POC v4 which relies on multiple --schedule instead of creating > concatenated schedule files. > > -- > Fabien. > diff --git a/src/test/regress/GNUmakefile b/src/test/re

Re: [HACKERS] refresh materialized view concurrently

Tom Lane wrote: > Kevin Grittner writes: >> we acquire locks on all indexes even for a HOT UPDATE which uses >> a seqscan, and hold those until end of transaction.  Is there a >> reason for that? > > Sounds dubious to me; although in the HOT code it might be that > there's no convenient place to

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On Wed, Jul 3, 2013 at 12:34:50PM -0700, Josh Berkus wrote: > Michael Meskes wrote: > >> So, as an experiment, call it a mixed result. I would like to have some > >> other way to motivate reviewers than public shame. I'd like to have > > > > Doesn't shame imply that people knew that were suppos

Re: [HACKERS] refresh materialized view concurrently

Kevin Grittner writes: > Further testing shows that any UPDATE or DELETE statement acquires > a RowExclusiveLock on every index on the table and holds it until > end of transaction, whether or not any rows are affected and > regardless of whether an index scan or a seqscan is used.  In fact, > jus

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On Wed, Jul 03, 2013 at 09:47:13AM -0400, Robert Haas wrote: > An attempt to prod a few more people into helping review. > > I can see that this pissed you off, and I'm sorry about that. But I > don't think that was his intent. I hoped for this kind of answer from him but ... Michael -- Michae

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On Wed, Jul 03, 2013 at 04:03:08PM -0400, Bruce Momjian wrote: > I do understand Josh's frustration that something different had to be > done. As a matter of fact I do, too. I just think the style of blaming people in public like this is not ideal. As I said I didn't even notice this email in the

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On Wed, Jul 03, 2013 at 12:34:50PM -0700, Josh Berkus wrote: > If you didn't feel obligated, you wouldn't be pissed at me. You'd just > blow it off (like Bruce did). I think you're angry with me because you > feel guilty. That is outrageous bullshit! > My *personal* viewpoint is that all commit

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On 07/03/2013 02:03 PM, Michael Meskes wrote: > I won't go into details here because frankly why I have no time for reviewing > a > patch is none of your business. Then just send an email saying "Sorry, I don't have any time for patch review this time. Maybe next time". It's pretty simple. I

Re: [HACKERS] [v9.4] row level security -- needs a reviewer

Hackers, Please, oh please, won't someone review this? This patch has been 3 years in the making, so I suspect that it will NOT be a fast review. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] request a new feature in fuzzystrmatch

On 06/29/2013 01:37 PM, Joe Conway wrote: > On 06/25/2013 01:37 PM, Liming Hu wrote: >>> please remove "dameraulevenshteinnocompatible" related stuff, I >>> just followed the template you created. >>> "dameraulevenshteinnocompatible" was used in my first testing. > >>> diff -cNr >>> /opt/src/pgsq

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On 2013-07-03 14:16:09 -0700, Josh Berkus wrote: > On 07/03/2013 02:03 PM, Michael Meskes wrote: > > I won't go into details here because frankly why I have no time for > > reviewing a > > patch is none of your business. > > Then just send an email saying "Sorry, I don't have any time for patch

Re: [HACKERS] Bugfix and new feature for PGXS

On Mon, Jul 1, 2013 at 5:04 PM, Andrew Dunstan wrote: > These changes are fairly small and mostly non-invasive, but if I've broken > something we should find out about it fairly quickly, I hope. Turns out you broke something. Specifically, contrib/spi now only installs autoinc.control instead of

Re: [HACKERS] Re: [COMMITTERS] pgsql: Revert "Hopefully-portable regression tests for CREATE/ALTER/DRO

On Wed, Jul 3, 2013 at 3:04 PM, Fabien COELHO wrote: >> The buildfarm is sad. > > Do you have a pointer about the issue? > > Is it that builds are performed in some particular locale? Tom posted an example of the error message on the related pgsql-hackers thread. On some systems, no locales can

Re: [HACKERS] [PATCH] Remove useless USE_PGXS support in contrib

Peter, Cedric, etc.: Where are we on this patch? Seems like discussion died out. Should it be bounced? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresq

Re: [HACKERS] Bugfix and new feature for PGXS

On 07/03/2013 05:52 PM, Robert Haas wrote: On Mon, Jul 1, 2013 at 5:04 PM, Andrew Dunstan wrote: These changes are fairly small and mostly non-invasive, but if I've broken something we should find out about it fairly quickly, I hope. Turns out you broke something. Specifically, contrib/spi n

  1   2   >