Re: [HACKERS] Should we cacheline align PGXACT?

On 22 August 2016 at 10:40, Andres Freund wrote: > On 2016-08-19 09:46:12 -0400, Tom Lane wrote: > > Alexander Korotkov writes: > > > originally this idea was proposed by Andres Freund while experimenting > with > > > lockfree Pin/UnpinBuffer [1].

Re: [HACKERS] Should we cacheline align PGXACT?

On 2016-08-20 14:33:13 -0400, Robert Haas wrote: > On Aug 19, 2016, at 2:12 AM, Alexander Korotkov > wrote: > > Hackers, > > > > originally this idea was proposed by Andres Freund while experimenting with > > lockfree Pin/UnpinBuffer [1]. > > The patch is attached as

Re: [HACKERS] replication slots replicated to standbys?

On Sun, Aug 21, 2016 at 1:24 PM, Craig Ringer wrote: > On 21 Aug 2016 12:36 AM, "Bruce Momjian" wrote: >> Seems like another good idea to use pg_basebackup rather than manually >> doing base backups; Magnus has been saying this for a while. > >

Re: [HACKERS] replication slots replicated to standbys?

On Sun, Aug 21, 2016 at 1:35 AM, Bruce Momjian wrote: > On Sat, Aug 20, 2016 at 01:43:42PM +0900, Michael Paquier wrote: >> Note as well that pg_basebackup omits its content and creates an empty >> directory. > > Are there any other error-prone things copied from the master?

Re: [HACKERS] Patch: initdb: "'" for QUOTE_PATH (non-windows)

On Sun, Aug 21, 2016 at 3:02 AM, Tom Lane wrote: > I wrote: >> A bigger issue here is that it seems fundamentally wrong for initdb to be >> including libpq, because it surely is never meant to be communicating >> with a running postmaster. Not sure what to do about that. We

Re: [HACKERS] synchronous_commit = remote_flush

On Sun, Aug 21, 2016 at 6:08 PM, Thomas Munro wrote: > On Fri, Aug 19, 2016 at 6:30 AM, Jim Nasby wrote: >> I'm wondering if we've hit the point where trying to put all of this in a >> single GUC is a bad idea... changing that probably

Re: [HACKERS] Should we cacheline align PGXACT?

On 2016-08-19 09:46:12 -0400, Tom Lane wrote: > Alexander Korotkov writes: > > originally this idea was proposed by Andres Freund while experimenting with > > lockfree Pin/UnpinBuffer [1]. > > The patch is attached as well as results of pgbench -S on 72-cores > >

[HACKERS] Logical decoding of sequence advances, part II

Hi all My earlier efforts at logical decoding of sequence advances were too simplistic[1], falling afoul of issues with sequences being both transactional and not transactional depending on whether the sequence is created in the current xact or not. TL;DR of solution: * extend SeqTableData and

Re: [HACKERS] replication slots replicated to standbys?

On 22 August 2016 at 10:31, Michael Paquier wrote: > On Sun, Aug 21, 2016 at 1:24 PM, Craig Ringer > wrote: > > On 21 Aug 2016 12:36 AM, "Bruce Momjian" wrote: > >> Seems like another good idea to use pg_basebackup

Re: [HACKERS] Declarative partitioning - another take

The parent-child relationship of multi-level partitioned tables is not retained when creating the AppendRelInfo nodes. We create RelOptInfo nodes for all the leaf and intermediate tables. The AppendRelInfo nodes created for these RelOptInfos set the topmost table as the parent of all the leaf and

[HACKERS] UTF-8 docs?

Just out of curiopusity, I wonder why we can't make the encoding of SGML docs to be UTF-8, rather than current ISO-8859-1. As long as everything is written in ASCII, the size of docs will be almost same even if UTF-8 is used. Plus, if the encoding is changed to UTF-8, it is very easy to translate

Re: [HACKERS] Should we cacheline align PGXACT?

On 2016-08-22 11:25:55 +0800, Craig Ringer wrote: > On 22 August 2016 at 10:40, Andres Freund wrote: > > > On 2016-08-19 09:46:12 -0400, Tom Lane wrote: > > > Alexander Korotkov writes: > > > > originally this idea was proposed by Andres Freund

Re: [HACKERS] Logical decoding of sequence advances, part II

On 22 August 2016 at 11:13, Craig Ringer wrote: > So yeah. I think extending SeqTableData and xl_seq_rec with xid is the way > to go. Objections? > Prototyping this shows that re-using SeqTableData to store the creator xid won't work out. We can't just store the

Re: [HACKERS] SP-GiST support for inet datatypes

Emre Hasegeli writes: >> ... Several of the existing opclasses use fixed numbers of >> child nodes, so why does this need something they don't? > Currently, SP-GiST framework supports fixed number of child nodes, if > the index is growing by page splits, not by prefix splits.

Re: [HACKERS] WIP: About CMake v2

Hi Yury, >> I glad to hear it. I suppose you can just try build postgres and send all >> problems to github tracker. >> https://github.com/stalkerg/postgres_cmake/issues FYI, I had success using your "postgres_cmake" repo. I tested it up through "make check" and "make install". Here are the

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

On Sun, Aug 21, 2016 at 1:17 AM, Tom Lane wrote: > Haribabu Kommi writes: >> This is a new statistics view that is used to provide the number of >> SQL operations that are >> happened on a particular interval of time. This view is useful for the >>

Re: [HACKERS] dsm_unpin_segment

On Sun, Aug 21, 2016 at 7:54 PM, Thomas Munro wrote: > Here's the rationale I'm using: if it's helpful to programmers of > client code, especially client code that might include extensions, and > nowhere near a hot code path, then why not use elog rather than >

[HACKERS] Re: [sqlsmith] FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)", File: "xlog.c", Line: 10200)

On Sat, Aug 6, 2016 at 6:35 PM, Andreas Seltenreich wrote: > Michael Paquier writes: > >> Andreas, with the patch attached is the assertion still triggered? >> [2. text/x-diff; base-backup-crash-v2.patch] > > I didn't observe the crashes since applying this patch. There

Re: [HACKERS] SP-GiST support for inet datatypes

> "Tom" == Tom Lane writes: > Emre Hasegeli writes: >> Attached patches add SP-GiST support to the inet datatypes. Tom> I started to look at this patch. The reported speedup is pretty Tom> nice, but ... The builtin gist support for inet seems

Re: [HACKERS] synchronous_commit = remote_flush

On Fri, Aug 19, 2016 at 6:30 AM, Jim Nasby wrote: > I'm wondering if we've hit the point where trying to put all of this in a > single GUC is a bad idea... changing that probably means a config > compatibility break, but I don't think that's necessarily a bad thing at >

Re: [HACKERS] dsm_unpin_segment

On Sat, Aug 20, 2016 at 11:37 PM, Amit Kapila wrote: > On Tue, Aug 9, 2016 at 10:07 AM, Thomas Munro > wrote: >> On Tue, Aug 9, 2016 at 12:53 PM, Tom Lane wrote: >>> The larger picture here is that Robert is exhibiting

Re: [HACKERS] SP-GiST support for inet datatypes

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> I started to look at this patch. The reported speedup is pretty > Tom> nice, but ... > The builtin gist support for inet seems quite surprisingly slow; ip4r > beats it into the ground

Re: [HACKERS] standalone backend PANICs during recovery

On Sun, Aug 21, 2016 at 1:41 AM, Tom Lane wrote: > So at this point I'm pretty baffled as to what the actual use-case is > here. It is easier to attach a debugger in this case to analyze the problem? > I am tempted to say that a standalone backend should refuse to > start at

Re: [HACKERS] synchronous_commit = remote_flush

On Fri, Aug 19, 2016 at 7:32 PM, Masahiko Sawada wrote: > On Fri, Aug 19, 2016 at 5:25 AM, Robert Haas wrote: >> On Thu, Aug 18, 2016 at 12:22 AM, Thomas Munro >> wrote: >>> To do something about the confusion I keep

Re: [HACKERS] synchronous_commit = remote_flush

Re: Thomas Munro 2016-08-21

Re: [HACKERS] [PATCH] Alter or rename enum value

> Here is v4, which changes the command from ALTER VALUE to RENAME VALUE, > for consistency with RENAME ATTRIBUTE. It looks like we always use "ALTER ... RENAME ... old_name TO new_name" syntax, so it is better that way. I have noticed that all the other RENAMEs go through ExecRenameStmt(). We

Re: [HACKERS] [PATCH] Alter or rename enum value

Emre Hasegeli writes: >> +ReleaseCatCacheList(list); >> +heap_close(pg_enum, RowExclusiveLock); > Maybe we better release them before reporting error, too. I would > release the list after the loop, close the heap before ereport(). Transaction abort will

Re: [HACKERS] SP-GiST support for inet datatypes

> ... this part of the patch breaks the existing API for SP-GiST opclasses. > That is a hard sell. It may only matter for one existing opclass in core, > but unless we have reason to think nobody is using any custom SP-GiST > opclasses, that is not a pleasant thing to do. How important is it