Re: [HACKERS] Avoid endless futile table locks in vacuuming.

I wrote: > Jeff Janes writes: >> If a partially-active table develops a slug of stable all-visible, >> non-empty pages at the end of it, then every autovacuum of that table >> will skip the end pages on the forward scan, think they might be >> truncatable, and take the

Re: [HACKERS] pgbench stats per script & other stuff

Hello Michaël, And then I also had a look at src/port/snprintf.c, where things get actually weird when no transactions are run for a script (emulated with 2 scripts, one with @1 and the second with @1): - 0 transactions (0.0% of total, tps = 0.00) - latency average = -1.#IO ms -

Re: [HACKERS] Fix compiler warnings in Cube Extension

On 29 December 2015 at 07:38, Tom Lane wrote: > David Rowley writes: > > My compiler is complaining about cube_coord() and cube_coord_llur() not > > returning a value on all code paths. > > Yeah, looking at that code, this would be expected from

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

Here is another preliminary result I would like to share. As always you will find corresponding patch in attachment. It has work in progress quality. The idea was suggested by colleague of mine Aleksander Lebedev. freeList is partitioned like in "no lock" patch. When there is no enough free

[HACKERS] Fix compiler warnings in Cube Extension

Hi, My compiler is complaining about cube_coord() and cube_coord_llur() not returning a value on all code paths. On looking at this I noticed that this is happening due the pattern used is not quite aligned with other code, as normally we do: if () ereport(); do stuff;

Re: [HACKERS] WIP: bloom filter in Hash Joins with batches

On 28 December 2015 at 23:23, Tomas Vondra wrote: > On 12/28/2015 03:15 AM, David Rowley wrote: > >> Maybe it would be better to, once the filter is built, simply count the >> > number of 1 bits and only use the filter if there's less than >> 1 bits compared to the

[HACKERS] request patch pg_recvlogical.c, pg_receivexlog.c for nls

Hello, at PostgreSQL version 9.5rc1, at line 934 in pg_recvlogical.c set_pglocale_pgservice(argv[0],PG_TEXTDOMAIN("pg_recvlogical")); this references invalid catalog file, because pg_basebackup, pg_recvlogical, pg_receivexlog commands use same catalog file pg_basebackup.mo

[HACKERS] Patch to fix misspellings of the word "segment"

I noticed this while reading nodeGather.c. I checked to find other misspellings of the word and found one more, so the attached fixes both. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services segment_spelling_fix.patch

Re: [HACKERS] Freeze avoidance of very large table.

On Mon, Dec 21, 2015 at 11:54 PM, Robert Haas wrote: > On Mon, Dec 21, 2015 at 3:27 AM, Kyotaro HORIGUCHI > wrote: >> Hello, >> >> At Fri, 18 Dec 2015 12:09:43 -0500, Robert Haas >> wrote in

Re: [HACKERS] pg_hba_lookup function to get all matching pg_hba.conf entries

On Thu, Dec 24, 2015 at 5:16 AM, Haribabu Kommi wrote: > On Thu, Dec 24, 2015 at 2:37 AM, Tom Lane wrote: > > "Shulgin, Oleksandr" writes: > >> 1. Have you considered re-loading the HBA file upon call to this >

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Thu, Dec 24, 2015 at 5:50 PM, Ildus Kurbangaliev < i.kurbangal...@postgrespro.ru> wrote: > > On Tue, 15 Dec 2015 13:56:30 -0500 > Robert Haas wrote: > > > On Sun, Dec 13, 2015 at 6:35 AM, and...@anarazel.de > > wrote: > > > On 2015-12-12 21:15:52

Re: [HACKERS] WIP: bloom filter in Hash Joins with batches

On 12/28/2015 11:52 AM, David Rowley wrote: On 28 December 2015 at 23:44, Tomas Vondra > wrote: On 12/28/2015 11:38 AM, David Rowley wrote: If so, then a filter with all 1 bits set should be thrown away, as

Re: [HACKERS] WIP: bloom filter in Hash Joins with batches

On 12/28/2015 11:38 AM, David Rowley wrote: On 28 December 2015 at 23:23, Tomas Vondra > wrote: On 12/28/2015 03:15 AM, David Rowley wrote: Maybe it would be better to, once the filter is built, simply count

Re: [HACKERS] WIP: bloom filter in Hash Joins with batches

On 12/28/2015 03:15 AM, David Rowley wrote: On 18 December 2015 at 04:34, Tomas Vondra > wrote: I think ultimately we'll need to measure the false positive rate, so that we can use it to dynamically disable the bloom

Re: [HACKERS] WIP: bloom filter in Hash Joins with batches

On 28 December 2015 at 23:44, Tomas Vondra wrote: > On 12/28/2015 11:38 AM, David Rowley wrote: > >> If so, then a filter with all 1 bits set should be thrown away, as >> > it'll never help us, and the filter should generally become more >> worthwhile as it contains

Re: [HACKERS] Performance degradation in commit ac1d794

On Sat, Dec 26, 2015 at 5:41 PM, Andres Freund wrote: > On 2015-12-26 12:22:48 +0100, Andres Freund wrote: > > > > 3) Replace the postmaster_alive_fds socketpair by some other > signalling > > > >mechanism. E.g. sending a procsignal to each backend, which sets > the > > >

Re: [HACKERS] request patch pg_recvlogical.c, pg_receivexlog.c for nls

Michael Paquier wrote: > On Mon, Dec 28, 2015 at 5:07 PM, Ioseph Kim wrote: > > at PostgreSQL version 9.5rc1, > > at line 934 in pg_recvlogical.c > > > > set_pglocale_pgservice(argv[0],PG_TEXTDOMAIN("pg_recvlogical")); > > > > this references invalid catalog file,

Re: [HACKERS] request patch pg_recvlogical.c, pg_receivexlog.c for nls

On Mon, Dec 28, 2015 at 5:07 PM, Ioseph Kim wrote: > Hello, > > at PostgreSQL version 9.5rc1, > at line 934 in pg_recvlogical.c > > set_pglocale_pgservice(argv[0],PG_TEXTDOMAIN("pg_recvlogical")); > > this references invalid catalog file, because pg_basebackup, >

Re: [HACKERS] [PROPOSAL] Backup and recovery of pg_statistic

Here's the patch with an 'array_elemtype' procedure which returns array's element type as an oid. It should apply to the commit fc995b. I wasn't sure if I shoud start a new thread. -- Dmitry Ivanov Postgres Professional: http://www.postgrespro.com Russian Postgres Companydiff --git

Re: [HACKERS] pg_upgrade tests running calling psql without --no-psqlrc

2015-12-28 14:21 GMT+01:00 Michael Paquier : > Hi all, > > Since commit d5563d7d, -c does not imply any more --no-psqlrc hence > the tests of pg_upgrade may run with a custom psqlrc file loaded. I > think that we had better add -X to avoid that, like in the patch >

Re: [HACKERS] Patch: pg_trgm: gin index scan performance for similarity search

On Fri, Dec 25, 2015 at 11:10 AM, Teodor Sigaev wrote: > Good catch, committed. > Thank you!

Re: [HACKERS] pam auth - add rhost item

Hi. New patch available. The new status of this patch is: Needs review -- 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] pam auth - add rhost item

Hi. I send new patch: https://github.com/grzsmp/postgres/commit/3e3a1f187b71acef3f8dc0745da753fb5be821fa On 12/27/2015 05:31 PM, Grzegorz Sampolski wrote: > Hi there! > I'm alive and working on new patch. > So, I takes into account all suggestions from Tomas and I'll > add additional parameter

[HACKERS] pg_upgrade tests running calling psql without --no-psqlrc

Hi all, Since commit d5563d7d, -c does not imply any more --no-psqlrc hence the tests of pg_upgrade may run with a custom psqlrc file loaded. I think that we had better add -X to avoid that, like in the patch attached. Thoughts? -- Michael diff --git a/src/bin/pg_upgrade/test.sh

Re: [HACKERS] 9.5rc1 brin_summarize_new_values

Alvaro Herrera writes: > This creates a new sub-section at the bottom of "9.26 System > Administration Functions" named "Indexing Helper Functions", containing > a table with a single row which is for this function. Perhaps call it "Index Maintenance Functions"? > We

Re: [HACKERS] custom function for converting human readable sizes to bytes

On Tue, Dec 22, 2015 at 10:45 AM, Pavel Stehule wrote: > Hi > > 2015-12-21 16:11 GMT+01:00 Robert Haas : > >> On Sun, Dec 20, 2015 at 4:54 AM, Pavel Stehule >> wrote: >> > new update: >> > >> > 1. unit searching is case

Re: [HACKERS] oldest/newestCommitTs output by pg_controldata

On 12/28/2015 09:53 AM, Alvaro Herrera wrote: >>> The name is just as misleading at the source-code level, maybe more so >>> since they're all just numbers in C. +1 for changing it everywhere >>> before somebody makes a mistake based on the incorrect names. >> >> Ok, I'm on it now > > Great,

Re: [HACKERS] oldest/newestCommitTs output by pg_controldata

Joe Conway writes: > I think the attached does the job. Note I settled on > (new|old)estCommitTsXid as that seemed most descriptive and not horribly > longer than before. It did mean, however, that I needed to add a single > space to all the output in pg_resetxlog and

Re: [HACKERS] oldest/newestCommitTs output by pg_controldata

Joe Conway wrote: > On 12/28/2015 09:03 AM, Tom Lane wrote: > > Joe Conway writes: > >> Ok, but now next question -- should we just change the user visible > >> output to oldestCommitXID/newestCommitXID, or should we change the > >> variable name everywhere it appears in

Re: [HACKERS] 9.5rc1 brin_summarize_new_values

Jeff Janes wrote: > Another issue is: it seems to have no SGML documentation. Is that OK? Here's a patch (which I had to write afresh, because I couldn't find anything in my brin development tree. Maybe I was just remembering something I planned to do and never got around to.) This creates a

Re: [HACKERS] pg_upgrade tests running calling psql without --no-psqlrc

Michael Paquier writes: > Since commit d5563d7d, -c does not imply any more --no-psqlrc hence > the tests of pg_upgrade may run with a custom psqlrc file loaded. I > think that we had better add -X to avoid that, like in the patch > attached. Yeah. "grep" found a few

Re: [HACKERS] oldest/newestCommitTs output by pg_controldata

On 12/26/2015 06:32 PM, Michael Paquier wrote: > On Sun, Dec 27, 2015 at 10:08 AM, Joe Conway wrote: >> In looking at the exposing pg_controldata as function patch again, it >> struck me that the following output seems wrong: >> >> -- >> Latest checkpoint's

Re: [HACKERS] oldest/newestCommitTs output by pg_controldata

Joe Conway writes: > Ok, but now next question -- should we just change the user visible > output to oldestCommitXID/newestCommitXID, or should we change the > variable name everywhere it appears in source as well? Looks like each > one appears about 25-30 times scattered

Re: [HACKERS] oldest/newestCommitTs output by pg_controldata

On 12/28/2015 09:03 AM, Tom Lane wrote: > Joe Conway writes: >> Ok, but now next question -- should we just change the user visible >> output to oldestCommitXID/newestCommitXID, or should we change the >> variable name everywhere it appears in source as well? Looks like each

Re: [HACKERS] pgbench stats per script & other stuff

On Wed, Dec 16, 2015 at 4:09 PM, Michael Paquier wrote: > Yeah, that's actually fine. I just had a look at Windows stuff, and > things seem to be correct on this side for double: > https://msdn.microsoft.com/en-us/library/aa691373%28v=vs.71%29.aspx > And then I also had

[HACKERS] Some 9.5beta2 backend processes not terminating properly?

After setting up 9.5beta2 on the Npgsql build server and running the Npgsql test suite against I've noticed some weird behavior. The tests run for a couple minutes, open and close some connection. With my pre-9.5 backends, the moment the test runner exits I can see that all backend processes exit

Re: [HACKERS] missing "SPI_finish" that isn't missing

On 12/24/15 16:37, Tom Lane wrote: > to make this coding pattern work is to set up a subtransaction, and either > commit it in the success path or roll it back upon catching an error. > (This is not terribly well documented, but the exception-block handling > in plpgsql provides a working model

Re: [HACKERS] missing "SPI_finish" that isn't missing

Chapman Flack writes: > Is there a particular, reasonably tidy idiom that has emerged as the usual, > customary approach to a task like this? You could construct a RangeVar node and then use RangeVarGetRelid, but I dunno that that's really any cleaner than inquiring about

[HACKERS] Testing Postgresql 9.5 RC1 with Alfresco 5.0.d

Hi there, The following wiki page: https://wiki.postgresql.org/wiki/HowToBetaTest#How_to_Test suggests that I should send the following report to this mailing list. Name: Boriss Mejías (Tchorix) Release: Postgresql 9.5 RC1 Test Type: Compatibility with Alfresco Community Edition 5.0.d Test

Re: [HACKERS] Using quicksort for every external sort run

On Fri, Dec 18, 2015 at 11:57 AM, Peter Geoghegan wrote: > BTW, I'm not necessarily determined to make the new special-purpose > allocator work exactly as proposed. It seemed useful to prioritize > simplicity, and currently so there is one big "huge palloc()" with > which we blow

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Shay Rojansky writes: > After setting up 9.5beta2 on the Npgsql build server and running the Npgsql > test suite against I've noticed some weird behavior. > The tests run for a couple minutes, open and close some connection. With my > pre-9.5 backends, the moment the test runner

Re: [HACKERS] 9.5rc1 brin_summarize_new_values

Tom Lane wrote: > Alvaro Herrera writes: > > This creates a new sub-section at the bottom of "9.26 System > > Administration Functions" named "Indexing Helper Functions", containing > > a table with a single row which is for this function. > > Perhaps call it "Index

Re: [HACKERS] oldest/newestCommitTs output by pg_controldata

On 12/28/2015 10:35 AM, Joe Conway wrote: > An alternative would be to not have a space at all for those two, e.g. > > "Latest checkpoint's oldestCommitTsXid:%u\n" > "Latest checkpoint's newestCommitTsXid:%u\n" > > That isn't too bad and would leave everything aligned. That seems like the

Re: [HACKERS] On columnar storage (2)

Konstantin Knizhnik wrote: > 3. Transpose of data and role of CS. > Let's look once again on Quote example above. Data is received in time > ascending order. But most queries require grouping it by symbol. So at some > stage we have to "transpose" data. To efficiently append data to timeseries

Re: [HACKERS] oldest/newestCommitTs output by pg_controldata

Joe Conway writes: > I retract my earlier suggestion of doing HEAD different from > REL9_5_STABLE, at least for the moment. My patch for pg_controldata > related functions is going to impact all this anyway, so we might as > well not fuss about it now. Seems reasonable. >

Re: [HACKERS] oldest/newestCommitTs output by pg_controldata

On 12/28/2015 10:30 AM, Alvaro Herrera wrote: > Tom Lane wrote: >> Joe Conway writes: >>> I think the attached does the job. Note I settled on >>> (new|old)estCommitTsXid as that seemed most descriptive and not horribly >>> longer than before. It did mean, however, that I

Re: [HACKERS] Fix compiler warnings in Cube Extension

David Rowley writes: > My compiler is complaining about cube_coord() and cube_coord_llur() not > returning a value on all code paths. Yeah, looking at that code, this would be expected from any compiler that doesn't know that ereport() doesn't return. On it now.

Re: [HACKERS] On columnar storage (2)

Konstantin Knizhnik wrote: Hi, > May be you know, that I have implemented IMCS (in-memory-columnar-store) as > PostgreSQL extension. > It was not so successful, mostly because people prefer to use standard SQL > rather than using some special functions for accessing columnar storage > (CS). Now

Re: [HACKERS] pam auth - add rhost item

On Mon, Dec 28, 2015 at 03:01:07PM +, Grzegorz Sampolski wrote: > Hi. > New patch available. Please attach the patch or patch set to your email just like else does. :) Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!:

Re: [HACKERS] oldest/newestCommitTs output by pg_controldata

Tom Lane wrote: > Joe Conway writes: > > I think the attached does the job. Note I settled on > > (new|old)estCommitTsXid as that seemed most descriptive and not horribly > > longer than before. It did mean, however, that I needed to add a single > > space to all the output in

Re: [HACKERS] oldest/newestCommitTs output by pg_controldata

On 12/28/2015 11:48 AM, Tom Lane wrote: > Joe Conway writes: >> I retract my earlier suggestion of doing HEAD different from >> REL9_5_STABLE, at least for the moment. My patch for pg_controldata >> related functions is going to impact all this anyway, so we might as >> well

Re: [HACKERS] pg_hba_lookup function to get all matching pg_hba.conf entries

On Mon, Dec 28, 2015 at 9:09 PM, Shulgin, Oleksandr wrote: > On Thu, Dec 24, 2015 at 5:16 AM, Haribabu Kommi > wrote: >> >> On Thu, Dec 24, 2015 at 2:37 AM, Tom Lane wrote: >> > "Shulgin, Oleksandr"

Re: [HACKERS] Testing Postgresql 9.5 RC1 with Alfresco 5.0.d

On 28 December 2015 at 22:56, Boriss Mejias wrote: > Hi there, > > The following wiki page: > https://wiki.postgresql.org/wiki/HowToBetaTest#How_to_Test > suggests that I should send the following report to this mailing list. > Thanks for testing. Do you have any

[HACKERS] pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format

I wonder why "Latest checkpoint's NextXID" is formated like this: 8<- printf(_("Latest checkpoint's NextXID: %u/%u\n"), ControlFile.checkPointCopy.nextXidEpoch, ControlFile.checkPointCopy.nextXid);

Re: [HACKERS] Patch to fix misspellings of the word "segment"

On 28 December 2015 at 21:35, David Rowley wrote: > I noticed this while reading nodeGather.c. I checked to find other > misspellings of the word and found one more, so the attached fixes both. > Here's another tiny patch which fixes a spelling mistake in tqueue.c

Re: [HACKERS] pam auth - add rhost item

On Tue, Dec 29, 2015 at 12:46:40AM +0100, Grzegorz Sampolski wrote: > Hi. > I thought link on commitfest to github url was sufficient. > Sorry. Attached new patch. Thanks! My understanding for the reason behind the policy is that it is to ensure that patch submissions are all together in a

Re: [HACKERS] GIN pending list clean up exposure to SQL

On Wed, Nov 25, 2015 at 9:29 AM, Jeff Janes wrote: > > I'll prepare a patch for core for the January commitfest, and see if > it flies. If not, there is always the extension to fall back to. Here is an updated patch. I've added type and permission checks, docs, and some

Re: [HACKERS] pam auth - add rhost item

Hi. I thought link on commitfest to github url was sufficient. Sorry. Attached new patch. On 12/28/2015 09:07 PM, David Fetter wrote: > Please attach the patch or patch set to your email just like else > does diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c index cdc5bf1..d42cc76