Re: [HACKERS] Write Ahead Logging for Hash Indexes

Hi All, Below is the backtrace for the issue reported in my earlier mail [1]. >From the callstack it looks like we are trying to release lock on a meta page twice in _hash_expandtable(). (gdb) bt #0 0x007b01cf in LWLockRelease (lock=0x7f55f59d0570) at lwlock.c:1799 #1

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Sep 14, 2016 at 5:32 PM, Robert Haas wrote: > On Wed, Sep 14, 2016 at 5:45 AM, Pavan Deolasee > wrote: > > Another interesting bit about these small tables is that the largest used > > offset for these tables never went beyond 291 which

Re: [HACKERS] Hash Indexes

On Wed, Sep 14, 2016 at 12:29 AM, Jesper Pedersen wrote: > On 09/13/2016 07:26 AM, Amit Kapila wrote: >> >> Attached, new version of patch which contains the fix for problem >> reported on write-ahead-log of hash index thread [1]. >> > > I have been testing patch in

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Wed, Sep 14, 2016 at 4:36 PM, Ashutosh Sharma wrote: > Hi All, > > Below is the backtrace for the issue reported in my earlier mail [1]. > From the callstack it looks like we are trying to release lock on a > meta page twice in _hash_expandtable(). > Thanks for the

Re: [HACKERS] Surprising behaviour of \set AUTOCOMMIT ON

Hello, >Looking at the other variables hooks, they already emit errors and can >deny the effect of a change corresponding to a new value, without >informing the caller. Why would autocommit be different? The only type of psql_error inside hooks is as follows, psql_error("unrecognized value

Re: [HACKERS] Printing bitmap objects in the debugger

On Wed, Sep 14, 2016 at 3:46 PM, Pavan Deolasee wrote: > > > lately I'm using LVM debugger (which probably does not have something > equivalent), > And I was so clueless about lldb's powerful scripting interface. For example, you can write something like this in

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Sep 14, 2016 at 5:45 AM, Pavan Deolasee wrote: > Another interesting bit about these small tables is that the largest used > offset for these tables never went beyond 291 which is the value of > MaxHeapTuplesPerPage. I don't know if there is something that

Re: [HACKERS] sequences and pg_upgrade

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, failed Thank you for the patch. As I see there are no objections in

Re: [HACKERS] kqueue

Hi, On 14/09/2016 00:06, Tom Lane wrote: I'm inclined to think the kqueue patch is worth applying just on the grounds that it makes things better on OS X and doesn't seem to hurt on FreeBSD. Whether anyone would ever get to the point of seeing intra-kernel contention on these platforms is hard

Re: [HACKERS] Printing bitmap objects in the debugger

Ashutosh Bapat writes: > While working on partition-wise join, I had to examine Relids objects > many times. Printing the Bitmapset::words[] in binary format and then > inferring the relids takes time and is error prone. FWIW, I generally rely on pprint() to look

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Sep 14, 2016 5:18 PM, "Robert Haas" wrote: > > On Wed, Sep 14, 2016 at 8:16 AM, Pavan Deolasee > wrote: > > Ah, thanks. So MaxHeapTuplesPerPage sets the upper boundary for the per page > > bitmap size. Thats about 36 bytes for 8K page. IOW if

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Sep 14, 2016 at 8:16 AM, Pavan Deolasee wrote: > Ah, thanks. So MaxHeapTuplesPerPage sets the upper boundary for the per page > bitmap size. Thats about 36 bytes for 8K page. IOW if on an average there > are 6 or more dead tuples per page, bitmap will outperform

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On Wed, Sep 14, 2016 at 5:22 AM, Thomas Berger wrote: > Today, i found the time to read all the mails in this thread, and i think i > have to explain, why we decided to open a bug for this behavior. > > Pn Tuesday, 23. August 2016, 13:30:29 Robert Haas wrote: >> J. Random

Re: [HACKERS] Printing bitmap objects in the debugger

Tom Lane wrote: > Ashutosh Bapat writes: > > While working on partition-wise join, I had to examine Relids objects > > many times. Printing the Bitmapset::words[] in binary format and then > > inferring the relids takes time and is error prone. > > FWIW, I

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Wed, Sep 14, 2016 at 12:55 AM, Dilip Kumar wrote: > 2. Results > ./pgbench -c $threads -j $threads -T 10 -M prepared postgres -f script.sql > scale factor: 300 > Clients head(tps)grouplock(tps) granular(tps) > --- -

Re: [HACKERS] Printing bitmap objects in the debugger

Alvaro Herrera writes: > I don't understand. Why don't you just use "call pprint(the bitmapset)" > in the debugger? Bitmapsets aren't Nodes, so pprint doesn't work directly on them. I usually find that I can pprint some node containing the value(s) I'm interested in,

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Wed, Sep 14, 2016 at 8:59 PM, Robert Haas wrote: > Sure, but you're testing at *really* high client counts here. Almost > nobody is going to benefit from a 5% improvement at 256 clients. I agree with your point, but here we need to consider one more thing, that on head

Re: [HACKERS] condition variables

On Tue, Sep 13, 2016 at 10:55 PM, Peter Geoghegan wrote: > On Thu, Aug 11, 2016 at 2:47 PM, Robert Haas wrote: >> Another approach to the problem is to use a latch wait loop. That >> almost works. Interrupts can be serviced, and you can recheck shared >>

Re: [HACKERS] Surprising behaviour of \set AUTOCOMMIT ON

Rahila Syed writes: >> Looking at the other variables hooks, they already emit errors and can >> deny the effect of a change corresponding to a new value, without >> informing the caller. Why would autocommit be different? > These instances where psql_error occurs inside

Re: [HACKERS] WIP: Covering + unique indexes.

One more update. I added ORDER BY clause to regression tests. It was done as a separate bugfix patch by Tom Lane some time ago, but it definitely should be included into the patch. -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff

Re: [HACKERS] Printing bitmap objects in the debugger

Ashutosh Bapat wrote: > Hi All, > While working on partition-wise join, I had to examine Relids objects > many times. Printing the Bitmapset::words[] in binary format and then > inferring the relids takes time and is error prone. Instead I wrote a > function bms_to_char() which allocates a

Re: [HACKERS] Push down more full joins in postgres_fdw

On Tue, Sep 13, 2016 at 11:38 PM, Ashutosh Bapat wrote: > On Tue, Sep 13, 2016 at 10:28 PM, Robert Haas wrote: >> On Tue, Sep 6, 2016 at 9:07 AM, Ashutosh Bapat >> wrote: >>> That's not true with the alias

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Sep 14, 2016 at 12:17 PM, Robert Haas wrote: > > I am kind of doubtful about this whole line of investigation because > we're basically trying pretty hard to fix something that I'm not sure > is broken.I do agree that, all other things being equal, the TID >

Re: [HACKERS] palloc() too large on pg_buffercache with large shared_buffers

On Wed, Sep 14, 2016 at 12:13 AM, Kouhei Kaigai wrote: > It looks to me pg_buffercache tries to allocate more than 1GB using > palloc(), when shared_buffers is more than 256GB. > > # show shared_buffers ; > shared_buffers > > 280GB > (1 row) > > # SELECT

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

Robert Haas writes: > Interesting. I think that our documentation should only describe the > way we use unit suffixes in one central place, but other places (like > pg_size_pretty) could link to that central place. > I don't believe that there is any general unanimity

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Sep 14, 2016 at 12:17 PM, Robert Haas wrote: > For instance, one idea to grow memory usage incrementally would be to > store dead tuple information separately for each 1GB segment of the > relation. So we have an array of dead-tuple-representation objects, > one

[HACKERS] GiST: interpretation of NaN from penalty function

Hi hackers! Currently GiST treats NaN penalty as zero penalty, in terms of generalized tree this means "perfect fit". I think that this situation should be considered "worst fit" instead. Here is a patch to highlight place in the code. I could not construct test to generate bad tree, which would

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Sep 14, 2016 at 8:47 PM, Robert Haas wrote: > > > I am kind of doubtful about this whole line of investigation because > we're basically trying pretty hard to fix something that I'm not sure > is broken.I do agree that, all other things being equal, the TID >

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On 14 September 2016 at 11:19, Pavan Deolasee wrote: >> In >> theory we could even start with the list of TIDs and switch to the >> bitmap if the TID list becomes larger than the bitmap would have been, >> but I don't know if it's worth the effort. >> > > Yes, that

Re: [HACKERS] Logical Replication WIP

(continuing, uh, a bit happier) On 2016-09-09 00:59:26 +0200, Petr Jelinek wrote: > +/* > + * Relcache invalidation callback for our relation map cache. > + */ > +static void > +logicalreprelmap_invalidate_cb(Datum arg, Oid reloid) > +{ > + LogicalRepRelMapEntry *entry; > + > + /* Just

Re: [HACKERS] GiST: interpretation of NaN from penalty function

Andrew Borodin writes: > Currently GiST treats NaN penalty as zero penalty, in terms of > generalized tree this means "perfect fit". I think that this situation > should be considered "worst fit" instead. On what basis? It seems hard to me to make any principled argument

Re: [HACKERS] GiST penalty functions [PoC]

Here is v6 of cube penalty patch. There was a warning about unused edge function under systems without __STDC_IEC_559__ defined, this patch fixes it. Regards, Andrey Borodin. diff --git a/contrib/cube/cube.c b/contrib/cube/cube.c index 3feddef..ad868ac 100644 --- a/contrib/cube/cube.c +++

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

Robert Haas wrote: > Actually, I think that probably *is* worthwhile, specifically because > it might let us avoid multiple index scans in cases where we currently > require them. Right now, our default maintenance_work_mem value is > 64MB, which is enough to hold a little over ten million

Re: [HACKERS] Tuplesort merge pre-reading

Addressed all your comments one way or another, new patch attached. Comments on some specific points below: On 09/12/2016 01:13 AM, Peter Geoghegan wrote: Other things I noticed: * You should probably point out that typically, access to batch memory will still be sequential, despite your

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

Pavan Deolasee writes: > On Wed, Sep 14, 2016 at 10:53 PM, Alvaro Herrera > wrote: >> One thing not quite clear to me is how do we create the bitmap >> representation starting from the array representation in midflight >> without using twice as

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Sep 14, 2016 at 10:53 PM, Alvaro Herrera wrote: > > > One thing not quite clear to me is how do we create the bitmap > representation starting from the array representation in midflight > without using twice as much memory transiently. Are we going to write >

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Sep 14, 2016 at 1:23 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> Actually, I think that probably *is* worthwhile, specifically because >> it might let us avoid multiple index scans in cases where we currently >> require them. Right now, our default

Re: [HACKERS] Comment on GatherPath.single_copy

On Thu, Sep 1, 2016 at 3:15 AM, Kyotaro HORIGUCHI wrote: > At Wed, 31 Aug 2016 07:26:22 -0400, Tom Lane wrote in > <5934.1472642...@sss.pgh.pa.us> >> Robert Haas writes: >> > On Tue, Aug 30, 2016 at 6:38 PM, Tom Lane

Re: [HACKERS] Logical Replication WIP

Hi, On 2016-09-14 21:17:42 +0200, Petr Jelinek wrote: > > > +/* > > > + * Gather Relations based o provided by RangeVar list. > > > + * The gathered tables are locked in access share lock mode. > > > + */ > > > > Why access share? Shouldn't we make this ShareUpdateExclusive or > > similar, to

Re: [HACKERS] WAL consistency check facility

On Thu, Sep 8, 2016 at 1:20 PM, Michael Paquier wrote: > >> 2. For BRIN/UPDATE+INIT, block numbers (in rm_tid[0]) are different in >> REVMAP page. This happens only for two cases. I'm not sure what the >> reason can be. > > Hm? This smells like a block reference bug.

Re: [HACKERS] Logical Replication WIP

On 9/14/16 11:21 AM, Andres Freund wrote: >> +ExecInsert(NULL, /* mtstate is only used for onconflict handling which >> we don't support atm */ >> > + remoteslot, >> > + remoteslot, >> > + NIL, >> > +

Re: [HACKERS] Hash Indexes

Hi, On 09/14/2016 07:24 AM, Amit Kapila wrote: On Wed, Sep 14, 2016 at 12:29 AM, Jesper Pedersen wrote: On 09/13/2016 07:26 AM, Amit Kapila wrote: Attached, new version of patch which contains the fix for problem reported on write-ahead-log of hash index thread

Re: [HACKERS] WAL consistency check facility

On Tue, Sep 13, 2016 at 9:04 PM, Michael Paquier wrote: > It seems to me that you need to think about the way to document things > properly first, with for example: > - Have a first documentation patch that explains what is a resource > manager for WAL, and what are the

Re: [HACKERS] Logical Replication WIP

On 2016-09-14 13:20:02 -0500, Peter Eisentraut wrote: > On 9/14/16 11:21 AM, Andres Freund wrote: > >> + ExecInsert(NULL, /* mtstate is only used for onconflict handling which > >> we don't support atm */ > >> > + remoteslot, > >> > +

Re: [HACKERS] Choosing parallel_degree

On Thu, Sep 1, 2016 at 9:39 AM, Simon Riggs wrote: >>> > Can I change this to a lower setting? I would have done this before >>> > applying >>> > the patch, but you beat me to it. >>> >>> I don't have a problem with reducing the lock level there, if we're >>> convinced that

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

On Fri, Sep 2, 2016 at 2:33 AM, Haribabu Kommi wrote: > On Wed, Aug 31, 2016 at 3:19 AM, Alvaro Herrera > wrote: >> Haribabu Kommi wrote: >> >>> Apart from the above, here are the following list of command tags that >>> are generated in the

Re: [HACKERS] Logical Replication WIP

On 14/09/16 20:50, Andres Freund wrote: On 2016-09-14 13:20:02 -0500, Peter Eisentraut wrote: On 9/14/16 11:21 AM, Andres Freund wrote: + ExecInsert(NULL, /* mtstate is only used for onconflict handling which we don't support atm */ + remoteslot, +

Re: [HACKERS] Logical Replication WIP

On 14/09/16 00:48, Andres Freund wrote: First read through the current version. Hence no real architectural comments. Hi, Thanks for looking! On 2016-09-09 00:59:26 +0200, Petr Jelinek wrote: diff --git a/src/backend/commands/publicationcmds.c b/src/backend/commands/publicationcmds.c

Re: [HACKERS] Choosing parallel_degree

On 14 September 2016 at 14:48, Robert Haas wrote: > On Thu, Sep 1, 2016 at 9:39 AM, Simon Riggs wrote: > Can I change this to a lower setting? I would have done this before > applying > the patch, but you beat me to it. I

Re: [HACKERS] What is the posix_memalign() equivalent for the PostgreSQL?

On Fri, Sep 2, 2016 at 1:17 PM, Andres Freund wrote: > On 2016-09-02 13:05:37 -0400, Tom Lane wrote: >> Anderson Carniel writes: >> > If not, according to your experience, is there a >> > significance difference between the performance of the O_DIRECT or

Re: [HACKERS] pageinspect: Hash index support

On Tue, Aug 30, 2016 at 10:06 AM, Alvaro Herrera wrote: > Jesper Pedersen wrote: > > Hi, > > > > Attached is a patch that adds support for hash indexes in pageinspect. > > > > The functionality (hash_metap, hash_page_stats and hash_page_items) > follows > > the B-tree

Re: [HACKERS] Choosing parallel_degree

On Wed, Sep 14, 2016 at 3:54 PM, Simon Riggs wrote: >> I do think this comment is confusing: >> >> + *This value is not locked by the transaction, so this value may >> + *be changed while a SELECT that has used these values for planning >> + *is

Re: [HACKERS] Printing bitmap objects in the debugger

On Wed, Sep 14, 2016 at 3:43 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > Hi All, > While working on partition-wise join, I had to examine Relids objects > many times. Printing the Bitmapset::words[] in binary format and then > inferring the relids takes time and is error prone.

[HACKERS] Error running custom plugin: “output plugins have to declare the _PG_output_plugin_init symbol”

Hi, I'm kind of new to Postgres and I'm trying to create a custom output plugin for logical replication (Postgres is 9.5.4 version and I'm building the project from a Windows 8/64 bit machine - same machine where the db is installed). I started from the code of the sample test_decoding, and I was

Re: [HACKERS] pgbench - allow to store select results into variables

Hi Fabien, On 2016/09/13 17:41, Fabien COELHO wrote: > > Hello Amit, > >> [...] >> There still seems to be a change in behavior of the -r option due to the >> patch. Consider the following example: >> >> select a from a where a = 1 \; >> select a+1 from a where a = 1; >> ... >> - statement

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 09/15/2016 02:03 AM, Andreas Karlsson wrote: On 09/12/2016 06:51 PM, Heikki Linnakangas wrote: Changes since last version: * Added more error checks to the my_BIO_s_socket() function. Check for NULL result from malloc(). Check the return code of BIO_meth_set_*() functions; looking at

Re: [HACKERS] pg_basebackup wish list

On 9/13/16 7:24 PM, Michael Paquier wrote: > PostgresNode.pm had better use the new --noclean option in its calls, > the new default is not useful for debugging. We don't do it for initdb either. Is that a problem? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] pg_basebackup wish list

On Thu, Sep 15, 2016 at 9:26 AM, Peter Eisentraut wrote: > On 9/13/16 7:24 PM, Michael Paquier wrote: >> PostgresNode.pm had better use the new --noclean option in its calls, >> the new default is not useful for debugging. > > We don't do it for initdb either.

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

On 9/12/16 11:16 PM, Michael Paquier wrote: >> I don't think tar file output in pg_basebackup needs to be fsynced. >> > It's just a backup file like what pg_dump produces, and we don't fsync >> > that either. The point of this change is to leave a data directory in >> > a synced state equivalent

Re: [HACKERS] Hash Indexes

On Tue, May 10, 2016 at 5:09 AM, Amit Kapila wrote: > > > Although, I don't think it is a very good idea to take any performance > data with WIP patch, still I couldn't resist myself from doing so and below > are the performance numbers. To get the performance data, I

Re: [HACKERS] Logical Replication WIP

On 14/09/16 18:21, Andres Freund wrote: (continuing, uh, a bit happier) On 2016-09-09 00:59:26 +0200, Petr Jelinek wrote: +/* + * Relcache invalidation callback for our relation map cache. + */ +static void +logicalreprelmap_invalidate_cb(Datum arg, Oid reloid) +{ +

Re: [HACKERS] Logical Replication WIP

On 14/09/16 21:53, Andres Freund wrote: Hi, On 2016-09-14 21:17:42 +0200, Petr Jelinek wrote: +/* + * Gather Relations based o provided by RangeVar list. + * The gathered tables are locked in access share lock mode. + */ Why access share? Shouldn't we make this ShareUpdateExclusive or

Re: [HACKERS] Tracking timezone abbreviation removals in the IANA tz database

On Fri, Sep 2, 2016 at 8:55 AM, Tom Lane wrote: > I had thought that this wouldn't really affect us because PG's > interpretations of zone abbreviations are driven by the info in > timezone/tznames/ rather than the IANA files in timezone/data/. > I forgot however that the

Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)

Andres Freund writes: > On 2016-09-12 19:35:22 -0400, Tom Lane wrote: >> Anyway I'll draft a prototype and then we can compare. > Ok, cool. Here's a draft patch that is just meant to investigate what the planner changes might look like if we do it in the pipelined-result

Re: [HACKERS] Tracking timezone abbreviation removals in the IANA tz database

Robert Haas writes: > I suggest that if you (or someone else who understands it, if there is > any such person) were willing to either improve the existing > documentation or maybe even write a whole new chapter on how we do > time zone handling, it would be most welcome.

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 09/12/2016 06:51 PM, Heikki Linnakangas wrote: Changes since last version: * Added more error checks to the my_BIO_s_socket() function. Check for NULL result from malloc(). Check the return code of BIO_meth_set_*() functions; looking at OpenSSL sources, they always succeed, but all the

Re: [HACKERS] palloc() too large on pg_buffercache with large shared_buffers

> On Wed, Sep 14, 2016 at 12:13 AM, Kouhei Kaigai wrote: > > It looks to me pg_buffercache tries to allocate more than 1GB using > > palloc(), when shared_buffers is more than 256GB. > > > > # show shared_buffers ; > > shared_buffers > > > > 280GB > > (1

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On 15/09/16 03:45, Robert Haas wrote: On Wed, Sep 14, 2016 at 5:22 AM, Thomas Berger wrote: Today, i found the time to read all the mails in this thread, and i think i have to explain, why we decided to open a bug for this behavior. Pn Tuesday, 23. August 2016,

Re: [HACKERS] kqueue

Michael Paquier writes: > From an OSX laptop with -S, -c 1 and -M prepared (9 runs, removed the > three best and three worst): > - HEAD: 9356/9343/9369 > - HEAD + patch: 9433/9413/9461.071168 > This laptop has a lot of I/O overhead... Still there is a slight >

Re: [HACKERS] Proposal: speeding up GIN build with parallel workers

On 01/17/2016 10:03 PM, Jeff Janes wrote: On Fri, Jan 15, 2016 at 3:29 PM, Peter Geoghegan wrote: On Fri, Jan 15, 2016 at 2:38 PM, Constantin S. Pan wrote: I have a draft implementation which divides the whole process between N parallel workers, see the

Re: [HACKERS] kqueue

On Wed, Sep 14, 2016 at 3:32 PM, Tom Lane wrote: > Michael Paquier writes: >> From an OSX laptop with -S, -c 1 and -M prepared (9 runs, removed the >> three best and three worst): >> - HEAD: 9356/9343/9369 >> - HEAD + patch: 9433/9413/9461.071168 >>

Re: [HACKERS] WAL consistency check facility

On Wed, Sep 14, 2016 at 2:56 PM, Kuntal Ghosh wrote: > Master > --- > - If wal_consistency check is enabled or needs_backup is set in > XLogRecordAssemble(), we do a fpw. > - If a fpw is to be done, then fork_flags is set with BKPBLOCK_HAS_IMAGE, > which in

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Sep 14, 2016 at 8:47 AM, Pavan Deolasee wrote: > >> > Sawada-san offered to reimplement the patch based on what I proposed > upthread. In the new scheme of things, we will allocate a fixed size bitmap > of length 2D bits per page where D is average page density

[HACKERS] Printing bitmap objects in the debugger

Hi All, While working on partition-wise join, I had to examine Relids objects many times. Printing the Bitmapset::words[] in binary format and then inferring the relids takes time and is error prone. Instead I wrote a function bms_to_char() which allocates a StringInfo, calls outBitmapset() to

Re: [HACKERS] [PATCH] SortSupport for macaddr type

On 26/08/2016 19:44, Brandur wrote: > Hello, > Hello, > I've attached a patch to add SortSupport for Postgres' macaddr which has the > effect of improving the performance of sorting operations for the type. The > strategy that I employ is very similar to that for UUID, which is to create >

Re: [HACKERS] Write Ahead Logging for Hash Indexes

Hi All, I am getting following error when running the test script shared by Jeff -[1] . The error is observed upon executing the test script for around 3-4 hrs. 57869 INSERT XX000 2016-09-14 07:58:01.211 IST:ERROR: lock buffer_content 1 is not held 57869 INSERT XX000 2016-09-14 07:58:01.211

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

Today, i found the time to read all the mails in this thread, and i think i have to explain, why we decided to open a bug for this behavior. Pn Tuesday, 23. August 2016, 13:30:29 Robert Haas wrote: > J. Random User: I'm having a problem! > Mailing List: Gee, how big are your tables? > J. Random

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Wed, Sep 14, 2016 at 10:25 AM, Dilip Kumar wrote: > I have tested performance with approach 1 and approach 2. > > 1. Transaction (script.sql): I have used below transaction to run my > bench mark, We can argue that this may not be an ideal workload, but I > tested this

Re: [HACKERS] Declarative partitioning - another take

I have Continued with testing declarative partitioning with the latest patch. Got some more observation, given below -- Observation 1 : Getting overlap error with START with EXCLUSIVE in range partition. create table test_range_bound ( a int) partition by range(a); --creating a partition to

Re: [HACKERS] WAL consistency check facility

On Wed, Sep 14, 2016 at 11:31 AM, Michael Paquier wrote: > On Wed, Sep 14, 2016 at 2:56 PM, Kuntal Ghosh > wrote: >> Master >> --- >> - If wal_consistency check is enabled or needs_backup is set in >> XLogRecordAssemble(), we do

Re: [HACKERS] Printing bitmap objects in the debugger

On 2016/09/15 0:04, Tom Lane wrote: > Alvaro Herrera writes: >> I don't understand. Why don't you just use "call pprint(the bitmapset)" >> in the debugger? > > Bitmapsets aren't Nodes, so pprint doesn't work directly on them. > I usually find that I can pprint some

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

On Thu, Sep 15, 2016 at 9:44 AM, Peter Eisentraut wrote: > On 9/12/16 11:16 PM, Michael Paquier wrote: >>> I don't think tar file output in pg_basebackup needs to be fsynced. >>> > It's just a backup file like what pg_dump produces, and we don't fsync >>> > that

Re: [HACKERS] kqueue

On Wed, Sep 14, 2016 at 9:09 AM, Matteo Beccati wrote: > Hi, > > On 14/09/2016 00:06, Tom Lane wrote: > >> I'm inclined to think the kqueue patch is worth applying just on the >> grounds that it makes things better on OS X and doesn't seem to hurt >> on FreeBSD. Whether anyone

Re: [HACKERS] kqueue

On Thu, Sep 15, 2016 at 10:48 AM, Keith Fiske wrote: > Thomas Munro brought up in #postgresql on freenode needing someone to test a > patch on a larger FreeBSD server. I've got a pretty decent machine (3.1Ghz > Quad Core Xeon E3-1220V3, 16GB ECC RAM, ZFS mirror on WD Red HDD) so

Re: [HACKERS] PATCH: Avoid use of __attribute__ when building with old Sun compiler versions

On Fri, Sep 2, 2016 at 11:55 AM, Andy Grundman wrote: > The use of __attribute__ is currently enabled by checking for > __SUNPRO_C. However, this compiler only added support for > __attribute__ keywords in version 5.10 [1]. This patch adds a version > check to only enable

Re: [HACKERS] Hash Indexes

On Tue, Sep 13, 2016 at 9:31 AM, Jeff Janes wrote: > === > > +Vacuum acquires cleanup lock on bucket to remove the dead tuples and or > tuples > +that are moved due to split. The need for cleanup lock to remove dead > tuples > +is to ensure that scans' returns

[HACKERS] Re: [HACKERS] Error running custom plugin: “output plugins have to declare the _PG_output_plugin_init symbol”

On Wed, Sep 14, 2016 at 4:03 PM, valeriof wrote: > Hi, I'm kind of new to Postgres and I'm trying to create a custom output > plugin for logical replication (Postgres is 9.5.4 version and I'm building > the project from a Windows 8/64 bit machine - same machine

Re: [HACKERS] Hash Indexes

On Thu, Sep 15, 2016 at 4:44 AM, Jeff Janes wrote: > On Tue, May 10, 2016 at 5:09 AM, Amit Kapila > wrote: >> >> >> >> Although, I don't think it is a very good idea to take any performance >> data with WIP patch, still I couldn't resist myself from

Re: [HACKERS] Logical Replication WIP

On 14 September 2016 at 04:56, Petr Jelinek wrote: > Not sure what you mean by negotiation. Why would that be needed? You know > server version when you connect and when you know that you also know what > capabilities that version of Postgres has. If you send unrecognized

Re: [HACKERS] Hash Indexes

On Thu, Sep 15, 2016 at 4:04 AM, Jeff Janes wrote: > On Tue, Sep 13, 2016 at 9:31 AM, Jeff Janes wrote: >> >> === >> >> +Vacuum acquires cleanup lock on bucket to remove the dead tuples and or >> tuples >> +that are moved due to split. The need

Re: [HACKERS] [PATCH v2] Add overflow checks to money type input function

On 9/9/16 3:19 AM, Fabien COELHO wrote: > >> I have updated the patch with additional tests and comments per your >> review. Final(?) version attached. > > Applied on head, make check ok. No more comments on the code which does > what it says. I'm fine with this patch. Pushed, thanks. --

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Thu, Sep 1, 2016 at 2:16 AM, Ivan Kartyshov wrote: > Hi hackers, > > Few days earlier I've finished my work on WAITLSN statement utility, so I’d > like to share it. > [...] > Your feedback is welcome! > > [waitlsn_10dev.patch] Hi Ivan, Thanks for working on this.

Re: [HACKERS] Printing bitmap objects in the debugger

On Wed, Sep 14, 2016 at 5:31 PM, Pavan Deolasee wrote: > > On Wed, Sep 14, 2016 at 3:46 PM, Pavan Deolasee > wrote: >> >> >> >> lately I'm using LVM debugger (which probably does not have something >> equivalent), > > > And I was so clueless