Thanks Fujita-san for working on this. I took a quick look at the patch.
Here are some quick comments.
1. deparsePlaceHolderVar looks odd - each of the deparse* function is named
as deparse + .
PlaceHolderVar is not a parser node, so no string is going to be parsed as
a PlaceHolderVar. May be you
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 toplevel xid because TRUNCATE .
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 while experimenting
> > with
> > > > lockfree Pin/U
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
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 c
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].
> > > The patch is attached as well as results o
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 rather than manually
> >> doing base backups; Magnus has been saying this for a
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 x
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?
The contents of pg_sn
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
> > machine. As before it shows huge
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.
>
> The main time that's an issue is when you're rsync'
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 well as results of pgbench
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 could
>> consider mov
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 means a config
>> compatibility break, but I don't think that
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
> Assert? I took inspiration for that
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 should
> have been about f
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
>> system to find out the
>> pattern of the operati
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 all if a recovery.co
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 without difficulty. (I'd be curious how well
> this
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 a touching but
>>> unfounded faith that extensions using this feature will co
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 det
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
> this point...
Aside from t
> "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 quite surprisingly slow; ip4r
beats it int
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. This is
> not a fai
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 clean up such resources
> 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 b
Re: Thomas Munro 2016-08-21
> Right, we could just add it to guc.c after "on", so that you can "SET
> synchronous_commit TO remote_flush", but then "SHOW
> synchronous_commit" returns "on".
>
> The problem I was thinking about was this: if you add "remote_flush"
> before "on" in guc.c, then "SHO
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 seeing about what exactly
>>> "on" means, I've often wished we had "remote_flus
> ... 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 real
29 matches
Mail list logo
