On Fri, Feb 17, 2017 at 2:17 PM, Prabakaran, Vaishnavi
wrote:
> On 22 November 2016 at 18:32, Craig Ringer wrote:
> I am interested in this patch and addressed various below comments from
> reviewers. And, I have separated out code and test module into 2 patches. So,
> If needed, test patch can
On 2017/02/21 15:35, Amit Langote wrote:
>> drop table list_parted cascade;
>> -NOTICE: drop cascades to 3 other objects
>> -DETAIL: drop cascades to table part_ab_cd
>> probably we should remove cascade from there, unless you are testing CASCADE
>> functionality. Similarly for other blocks like
On Tue, Feb 21, 2017 at 12:48 AM, Stephen Frost wrote:
> * Fujii Masao (masao.fu...@gmail.com) wrote:
>> On Fri, Feb 17, 2017 at 11:17 PM, Peter Eisentraut
>> 1) Expose all the columns except subconninfo in pg_subscription to
>> non-superusers. In this idea, the tab-completion and psql meta-co
Hi Ashutosh,
Thanks for taking a look at the patch.
On 2017/02/20 21:49, Ashutosh Bapat wrote:
> Thanks for working on all the follow on work for partitioning feature.
>
> May be you should add all those patches in the next commitfest, so
> that we don't forget those.
I think adding these as on
Hello,
This is just a correction from "index" to "table". I was a bit confused when I
first read this part.
Regards
Takayuki Tsunakawa
brin_trivial_doc_fix.patch
Description: brin_trivial_doc_fix.patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
On Mon, Feb 20, 2017 at 11:18 PM, Robert Haas wrote:
> On Mon, Feb 20, 2017 at 5:55 AM, Thomas Munro
> wrote:
>> On Sun, Feb 19, 2017 at 9:59 PM, Dilip Kumar wrote:
>>> So basically, what I want to propose is that Only during
>>> ExecReScanBitmapHeapScan we can free all the DSA pointers because
On Tue, Feb 21, 2017 at 9:57 AM, Amit Langote
wrote:
> On 2017/02/21 12:10, Ashutosh Bapat wrote:
>> I think, that's a limitation till we implement global indexes. But
>> nothing in the current implementation stops us from implementing it.
>> In fact, I remember, a reply from Robert to another thr
On 2017/02/21 12:10, Ashutosh Bapat wrote:
> I think, that's a limitation till we implement global indexes. But
> nothing in the current implementation stops us from implementing it.
> In fact, I remember, a reply from Robert to another thread on
> partitioning started in parallel to Amit's thread
On Mon, Feb 20, 2017 at 8:35 PM, Kuntal Ghosh
wrote:
>
> + char *query_data;
> + query_data = estate->es_sourceText;
> estate->es_sourceText is a const char* variable. Assigning this const
> pointer to a non-const pointer violates the rules
> constant-correctness. So, either you should c
On Tue, Feb 21, 2017 at 7:14 AM, Thomas Munro
wrote:
> On Fri, Jan 20, 2017 at 2:49 AM, Kevin Grittner wrote:
>> Attached is v9 which fixes bitrot from v8. No other changes.
>>
>> Still needs review.
Based on a suggestion from Robert off-list I tried inserting into a
delta relation from a trigg
On Tue, Feb 21, 2017 at 2:03 AM, Bruce Momjian wrote:
> On Mon, Feb 20, 2017 at 02:37:44PM +0530, Robert Haas wrote:
>> On Mon, Feb 20, 2017 at 2:09 AM, Simon Riggs wrote:
>> > On 15 February 2017 at 15:46, Robert Haas wrote:
>> >>> It leaves me asking what else is missing.
>> >>
>> >> There is
On 2017/02/16 10:45, Amit Langote wrote:
> Also attaching 0002 (unchanged) for tab-completion support for the new
> partitioning syntax.
Robert already spawned a new thread titled "tab completion for
partitioning" for this [0].
> 0003 changes how ExecFindPartition() shows the row for which
> get_
Simon pointed out in a nearby thread [0] that the detail part of
partition-not-found error should show just the partition keys. I posted a
patch on that thread [1], but to avoid confusion being caused by multitude
of patches over there I'm re-posting it here.
* What the patch does:
Currently we
On Fri, Jan 20, 2017 at 2:49 AM, Kevin Grittner wrote:
> Attached is v9 which fixes bitrot from v8. No other changes.
>
> Still needs review.
This patch still applies, builds cleanly after a small modification,
includes regression tests and the tests past. The modification I
needed to make was
On Mon, Feb 20, 2017 at 9:41 PM, Aleksander Alekseev
wrote:
>> Speaking about flaws, it looks like there is a memory leak in
>> array_to_utf procedure - result is allocated twice.
Pushed a fix for this one on my branch.
> And a few more things I've noticed after a closer look:
>
> * build_client
On Tue, Feb 21, 2017 at 01:27:53AM +0100, Tomas Vondra wrote:
> On 02/21/2017 12:13 AM, Bruce Momjian wrote:
> >At the risk of asking a stupid question, we already have optimizer
> >statistics on expression indexes. In what sense are we using this for
> >multi-variate statistics, and in what sense
Hi,
Attached is v9 of this patch series. This addresses most of the points
raised in the review, namely:
1) change most 'debug' stuff to 'static inline' in memdebug.h
2) fixed and reworded a bunch of comments
3) get rid of the block-level bitmap tracking free chunks
Instead of the bitmap, I
On 02/21/2017 12:13 AM, Bruce Momjian wrote:
At the risk of asking a stupid question, we already have optimizer
statistics on expression indexes. In what sense are we using this for
multi-variate statistics, and in what sense can't we.
We're not using that at all, because those are really ort
On Mon, Feb 20, 2017 at 3:51 PM, Bruce Momjian wrote:
> So we don't have any other cases where we warn about possible corruption
> except this?
I'm not sure that I understand the distinction you're making.
> Also, I will go back to my previous concern, that while I like the fact
> we can detect
On Mon, Feb 20, 2017 at 03:29:07PM -0800, Peter Geoghegan wrote:
> Marking all indexes as invalid would be an enormous overkill. We don't
> even know for sure that the values the user has indexed happens to be
> affected. In order for there to have been a bug in ICU in the first
> place, the likeli
On Mon, Feb 20, 2017 at 3:19 PM, Bruce Momjian wrote:
> Well, the release notes are a clear-enough communication for a need to
> reindex. I don't see a LOG message as similar. Don't we have other
> cases where we have to warn administrators? We can mark the indexes as
> invalid but how would we
On Mon, Feb 20, 2017 at 02:54:22PM -0800, Peter Geoghegan wrote:
> On Mon, Feb 20, 2017 at 2:38 PM, Bruce Momjian wrote:
> > I can't think of any cases where we warn of possible corruption only in
> > the server logs.
>
> It's just like any case where there was a bug in Postgres that could
> have
At the risk of asking a stupid question, we already have optimizer
statistics on expression indexes. In what sense are we using this for
multi-variate statistics, and in what sense can't we.
FYI, I just wrote a blog post about expression index statistics:
http://momjian.us/main/blogs/pgb
On Mon, Feb 20, 2017 at 2:38 PM, Bruce Momjian wrote:
> I can't think of any cases where we warn of possible corruption only in
> the server logs.
It's just like any case where there was a bug in Postgres that could
have subtly broken index builds. We don't make the next point release
force users
On Wed, Feb 15, 2017 at 10:35:34PM -0800, Peter Geoghegan wrote:
> On Wed, Feb 15, 2017 at 9:17 PM, Peter Eisentraut
> wrote:
> > Stable operating systems shouldn't do major library upgrades, so I feel
> > pretty confident about this.
>
> There is one case where it *is* appropriate for a bugfix r
Hi.
While verifying the logical replication of PostgreSQL 10-devel, I found the
following problem.
* When you run the SUBSCRIPTION command against a table in the same
PostgreSQL server, hang up.
* Canceling the hung SUBSCRIPTION command with CTRL + C causes a server
process occurs Segfault, and th
On Mon, Feb 20, 2017 at 02:37:44PM +0530, Robert Haas wrote:
> On Mon, Feb 20, 2017 at 2:09 AM, Simon Riggs wrote:
> > On 15 February 2017 at 15:46, Robert Haas wrote:
> >>> It leaves me asking what else is missing.
> >>
> >> There is certainly a lot of room for improvement here but I don't
> >>
On Wed, Feb 15, 2017 at 12:08:19PM -0500, Robert Haas wrote:
> On Wed, Feb 15, 2017 at 11:34 AM, Alvaro Herrera
> wrote:
> > I think new-style partitioning is supposed to consider each partition as
> > an implementation detail of the table; the fact that you can manipulate
> > partitions separatel
On Thu, Feb 16, 2017 at 10:41 AM, Robert Haas wrote:
>> 2. The current btree vacuum code requires 2 vacuums to fully reuse
>> half-dead pages. So skipping an index vacuum might mean that second
>> index scan never happens at all, which would be bad.
>
> Maybe. If there are a tiny number of those
On 20 February 2017 at 10:27, Amit Kapila wrote:
> On Mon, Feb 20, 2017 at 3:01 PM, Simon Riggs wrote:
>> On 20 February 2017 at 09:15, Amit Kapila wrote:
>>> On Mon, Feb 20, 2017 at 7:26 AM, Masahiko Sawada
>>> wrote:
On Fri, Feb 17, 2017 at 3:41 AM, Robert Haas wrote:
> On Thu, Feb
On Thu, Feb 16, 2017 at 6:19 PM, Thomas Munro
wrote:
> Specifically, DeleteChildTargetLocks() assumes it can walk
> MySerializableXact->predicateLocks and throw away locks that are
> covered by a new lock (ie throw away tuple locks because a covering
> page lock has been acquired) without let or h
Robert Haas writes:
> On Mon, Feb 20, 2017 at 7:37 PM, Tom Lane wrote:
>> The question to be asked is whether there is still anybody out there
>> using float timestamps. I'm starting to get dubious about it myself.
> I'm wondering if it has any effect that pg_config.h.win32 says
> /* Define to
Robert Haas writes:
> On Mon, Feb 20, 2017 at 6:19 AM, Tom Lane wrote:
>> The thing that you really have to worry about for this kind of proposal
>> is "what if the query errors out and we never get to ExecEndNode"?
>> It's particularly nasty if you're talking about parallel queries where
>> mayb
I wrote:
> I noticed while researching bug #14555 that fd.c contains two separate
> cases like
> vfdP->seekPos = lseek(vfdP->fd, (off_t) 0, SEEK_CUR);
> Assert(vfdP->seekPos != (off_t) -1);
> This seems, um, unwise. It might somehow fail to fail in production
> builds, because elsewher
Hi
Today I played with xml_recv function and with xml processing functions.
xml_recv function ensures correct encoding from document encoding to server
encoding. But the decl section holds original encoding info - that should
be obsolete after encoding. Sometimes we solve this issue by removing d
On Thu, Feb 16, 2017 at 11:40 AM, Masahiko Sawada wrote:
> On Thu, Feb 16, 2017 at 7:52 AM, Petr Jelinek
> wrote:
>> On 15/02/17 06:43, Masahiko Sawada wrote:
>>> On Tue, Feb 14, 2017 at 1:13 AM, Fujii Masao wrote:
On Mon, Feb 13, 2017 at 4:05 PM, Masahiko Sawada
wrote:
> On Sat,
On Mon, Feb 20, 2017 at 6:15 PM, Amit Kapila wrote:
> On Mon, Feb 20, 2017 at 7:26 AM, Masahiko Sawada
> wrote:
>> On Fri, Feb 17, 2017 at 3:41 AM, Robert Haas wrote:
>>> On Thu, Feb 16, 2017 at 6:17 AM, Simon Riggs wrote:
On 15 February 2017 at 08:07, Masahiko Sawada
wrote:
>
On 20 February 2017 at 17:32, Robert Haas wrote:
>>> Have you checked whether this
>>> patch makes any noticeable performance difference?
>>
>> No, but then we're reducing the number of calls to PgXact directly;
>> there is no heuristic involved, its just a pure saving.
>
> Well, it's adding a br
On Mon, Feb 20, 2017 at 6:19 AM, Tom Lane wrote:
> Thomas Munro writes:
>> One practical problem that came up was the need for executor nodes to
>> get a chance to do that kind of cleanup before the DSM segment is
>> detached. In my patch series I introduced a new node API
>> ExecNodeDetach to a
On Mon, Feb 20, 2017 at 5:55 AM, Thomas Munro
wrote:
> On Sun, Feb 19, 2017 at 9:59 PM, Dilip Kumar wrote:
>> So basically, what I want to propose is that Only during
>> ExecReScanBitmapHeapScan we can free all the DSA pointers because at
>> that time we can be sure that all the workers have comp
On Mon, Feb 20, 2017 at 10:49 PM, Simon Riggs wrote:
>> Regarding reduce_pgxact_access_AtEOXact.v1.patch, it took me a few
>> minutes to figure out that the comment was referring to
>> ProcArrayEndTransaction(), so it might be good to be more explicit
>> about that if we go forward with this.
>
>
> On Feb 19, 2017, at 8:14 PM, Jim Nasby wrote:
>
> On 2/19/17 11:02 AM, David Christensen wrote:
>> My design notes for the patch were submitted to the list with little
>> comment; see:
>> https://www.postgresql.org/message-id/1E6E64E9-634B-43F4-8AA2-CD85AD92D2F8%40endpoint.com
>>
>> I have
On 20 February 2017 at 16:53, Robert Haas wrote:
> On Mon, Feb 20, 2017 at 6:02 PM, Simon Riggs wrote:
>> On 15 February 2017 at 19:15, Andres Freund wrote:
>>
>>> I think I previously
>>> mentioned, even just removing the MyPgXact->xmin assignment in
>>> SnapshotResetXmin() is measurable perfor
On Mon, Feb 20, 2017 at 7:37 PM, Tom Lane wrote:
> The question to be asked is whether there is still anybody out there
> using float timestamps. I'm starting to get dubious about it myself.
> Certainly, no packager that I'm aware of has shipped a float-timestamp
> build since we switched the def
On Mon, Feb 20, 2017 at 6:02 PM, Simon Riggs wrote:
> On 15 February 2017 at 19:15, Andres Freund wrote:
>
>> I think I previously
>> mentioned, even just removing the MyPgXact->xmin assignment in
>> SnapshotResetXmin() is measurable performance wise and cache-hit ratio
>> wise.
>
> Currently, we
On 02/11/2017 01:38 AM, Tomas Vondra wrote:
Incidentally, I've been dealing with a checksum failure reported by a
customer last week, and based on the experience I tend to agree that we
don't have the tools needed to deal with checksum failures. I think such
tooling should be a 'must have' for e
On Wed, Feb 15, 2017 at 9:33 PM, David G. Johnston
wrote:
> On Wed, Feb 15, 2017 at 12:24 PM, Robert Haas wrote:
>>
>> So it seems like an ALIGN or NORMALIZE option is kind of like a JOIN,
>> except apparently there's no join type and the optimizer can never
>> reorder these operations with each
On Fri, Feb 17, 2017 at 7:21 PM, Mithun Cy wrote:
>
> To implement such an incremental addition of bucket blocks I have to
> increase the size of array hashm_spares in meta page by four times.
> Also, mapping methods which map a total number of buckets to a
> split-point position of hashm_spares a
Re: Tom Lane 2017-02-20 <13825.1487607...@sss.pgh.pa.us>
> Still, it'd be worth comparing the assembly code for your test program.
I was compiling the program on jessie and on sid, and running the
jessie binary on sid made it output the same as the sid binary, so the
difference isn't in the binary
Hi,
while investigating some checksum-related issues, I needed to perform
some forensics on a copy of a btree page (taken from another instance
using 'dd').
But I've ran into two pageinspect limitations, hopefully addressed by
this patch:
1) bt_page_items(bytea) not defined
We have heap_p
Christoph Berg writes:
> Re: Tom Lane 2017-02-20 <30737.1487598...@sss.pgh.pa.us>
>> Hmph. We haven't touched that code in awhile, and certainly not in the
>> 9.4.x branch. I'd have to agree that this must be a toolchain change.
> FYI, in the meantime we could indeed trace it back to an libc is
Re: Tom Lane 2017-02-20 <30737.1487598...@sss.pgh.pa.us>
> Hmph. We haven't touched that code in awhile, and certainly not in the
> 9.4.x branch. I'd have to agree that this must be a toolchain change.
FYI, in the meantime we could indeed trace it back to an libc issue on
Jessie:
$ cat sqrt.c
Tomas Vondra writes:
> On 02/20/2017 04:37 PM, Tom Lane wrote:
>> But that's using gcc. Perhaps clang behaves differently?
> AFAIK it happens because clang treats missing declarations as warnings,
> which confuses configure:
> https://bugs.llvm.org//show_bug.cgi?id=20820
Ah, right. Looks like
On 02/20/2017 04:37 PM, Tom Lane wrote:
Aleksander Alekseev writes:
In theory - could we just always use our internal strl* implementations?
Hmm, maybe configure's test to see if a declaration has been provided
is going wrong? I notice that anchovy, which is supposedly current
Arch Linux, do
Greetings,
* Fujii Masao (masao.fu...@gmail.com) wrote:
> On Fri, Feb 17, 2017 at 11:17 PM, Peter Eisentraut
> wrote:
> > On 2/13/17 12:07, Fujii Masao wrote:
> >> Anyway IMO that we can expose all the
> >> columns except the sensitive information (i.e., subconninfo field)
> >> in pg_subscription
On Fri, Feb 17, 2017 at 11:17 PM, Peter Eisentraut
wrote:
> On 2/13/17 12:07, Fujii Masao wrote:
>> Anyway IMO that we can expose all the
>> columns except the sensitive information (i.e., subconninfo field)
>> in pg_subscription to even non-superusers.
>
> You mean with column privileges?
Yes.
Aleksander Alekseev writes:
> In theory - could we just always use our internal strl* implementations?
Hmm, maybe configure's test to see if a declaration has been provided
is going wrong? I notice that anchovy, which is supposedly current
Arch Linux, doesn't think the platform has it:
checkin
I've come across a number of times where the statistics on materialized
views become stale producing bad plans. It turns out that autovacuum only
touches a materialized view when it is first created and ignores it on a
refresh. When you have a materialized view like yesterdays_sales the data
in the
On Mon, Feb 20, 2017 at 10:11 AM, Rafia Sabih
wrote:
> On Sun, Feb 19, 2017 at 10:11 PM, Robert Haas wrote:
>> + query_data = (char *) palloc0(strlen(estate->es_queryString) + 1);
>> + strcpy(query_data, estate->es_queryString);
>>
>> It's unnecessary to copy the query string here; yo
Hi,
When building with a new-ish gcc (6.3.0 right now, but I've seen this
for a while) with optimization I get a number of warnings:
In file included from /home/andres/src/postgresql/src/include/postgres.h:48:0,
from
/home/andres/src/postgresql/src/backend/parser/parse_collate.c
In theory - could we just always use our internal strl* implementations?
On Mon, Feb 20, 2017 at 09:26:44AM -0500, Tom Lane wrote:
> Aleksander Alekseev writes:
> > I've just tried to build PostgreSQL with Clang 3.9.1 (default version
> > currently available in Arch Linux) and noticed that it ou
Aleksander Alekseev writes:
> I've just tried to build PostgreSQL with Clang 3.9.1 (default version
> currently available in Arch Linux) and noticed that it outputs lots of
> warning messages. Most of them are result of a bug in Clang itself:
>
> postinit.c:846:3: note: include the header or exp
Hello.
I've just tried to build PostgreSQL with Clang 3.9.1 (default version
currently available in Arch Linux) and noticed that it outputs lots of
warning messages. Most of them are result of a bug in Clang itself:
```
postinit.c:846:3: note: include the header or explicitly
provide a declarati
Petr Jelinek writes:
> It's definitely not hard, we already have
> IntegerTimestampToTimestampTz() which does the opposite conversion anyway.
It's not the functions that are hard, it's making sure that you have used
them in the correct places, and declared relevant variables with the
appropriate
Andres Freund writes:
> On 2017-02-20 11:58:12 +0100, Petr Jelinek wrote:
>> That being said, I did wonder myself if we should just deprecate float
>> timestamps as well.
> I think we need a proper deprecation period for that, given that the
> conversion away will be painful for pg_upgrade using
Christoph Berg writes:
> The point/polygon regression tests have started to fail on 32-bit
> powerpc on Debian Jessie. So far I could reproduce the problem with
> PostgreSQL 9.4.10+11 and 9.6.1, on several different machines. Debian
> unstable is unaffected.
Hmph. We haven't touched that code in
Hi
When I did tests of own XML import functions I found a strange error.
I successfully imported XML to PostgreSQL. This document is readable
without any visual defects. But when I tested this document against any
libxml2 function I found a error -
ERROR: could not parse XML document
DETAIL: i
Hi,
On 2017-02-20 11:44:58 +0100, Adam Dratwiński wrote:
> Hello everyone,
>
> I am writing a custom logical replication decoder, and I took test decoder
> from Postgres sources as an example.
>
> Could anyone tell me how to read "unchanged toast datum" in case it is
> VARTT_IS_EXTERNAL_ONDISK.
Hello everyone,
I am writing a custom logical replication decoder, and I took test decoder
from Postgres sources as an example.
Could anyone tell me how to read "unchanged toast datum" in case it is
VARTT_IS_EXTERNAL_ONDISK.
In the test decoder it is ignored:
https://github.com/postgres/postgre
The point/polygon regression tests have started to fail on 32-bit
powerpc on Debian Jessie. So far I could reproduce the problem with
PostgreSQL 9.4.10+11 and 9.6.1, on several different machines. Debian
unstable is unaffected.
The failure looks like this:
https://buildd.debian.org/status/fetch.p
Thanks for working on all the follow on work for partitioning feature.
May be you should add all those patches in the next commitfest, so
that we don't forget those.
On Mon, Feb 20, 2017 at 7:46 AM, Amit Langote
wrote:
> Re-posting the patch I posted in a nearby thread [0].
>
> On 2017/02/16 2:0
And a few more things I've noticed after a closer look:
* build_client_first_message does not free `state->client_nonce` if
second malloc (for `buf`) fails
* same for `state->client_first_message_bare`
* ... and most other procedures declared in fe-auth-scram.c file
(see malloc and strdup call
=?gb2312?B?amFzb255c2xpKMDu1L7JrSk=?= writes:
> Yes, it seems the pg_stat_sql function can fit the individual need of
> collecting tags of query. However the new function can not return other
> values of query at the same time, such as block number info, run time and so
> on. Returning these
On 15 February 2017 at 19:15, Andres Freund wrote:
> I think I previously
> mentioned, even just removing the MyPgXact->xmin assignment in
> SnapshotResetXmin() is measurable performance wise and cache-hit ratio
> wise.
Currently, we issue SnapshotResetXmin() pointlessly at end of xact, so
patch
Speaking about flaws, it looks like there is a memory leak in
array_to_utf procedure - result is allocated twice.
On Mon, Feb 20, 2017 at 02:51:13PM +0300, Aleksander Alekseev wrote:
> Hi!
>
> Currently I don't see any significant flaws in these patches. However I
> would like to verify that impl
On 20/02/17 12:04, Andres Freund wrote:
> On 2017-02-20 11:58:12 +0100, Petr Jelinek wrote:
>> That being said, I did wonder myself if we should just deprecate float
>> timestamps as well.
>
> I think we need a proper deprecation period for that, given that the
> conversion away will be painful fo
Hi!
Currently I don't see any significant flaws in these patches. However I
would like to verify that implemented algorithms are compatible with
algorithms implemented by third party.
For instance, for user 'eax' and password 'pass' I got the following
record in pg_authid:
```
scram-sha-256:
xtz
Further to the patch I just submitted
(https://www.postgresql.org/message-id/CA%2BOCxow-X%3DD2fWdKy%2BHP%2BvQ1LtrgbsYQ%3DCshzZBqyFT5jOYrFw%40mail.gmail.com)
I'd like to propose the addition of a default role, pg_monitor.
The intent is to make it easy for users to setup a role for fully
monitoring
Hi
Following various conversations on list and in person, including the
developer meeting in Brussels earlier this month, here is a patch that
implements pg_ls_logdir() and pg_ls_waldir() functions.
The ultimate aim of this (and followup work I'll be doing) is to
provide functionality to enable m
On 2017-02-20 11:58:12 +0100, Petr Jelinek wrote:
> That being said, I did wonder myself if we should just deprecate float
> timestamps as well.
I think we need a proper deprecation period for that, given that the
conversion away will be painful for pg_upgrade using people with big
clusters. So I
On 20/02/17 08:03, Andres Freund wrote:
> On 2017-02-19 10:49:29 -0500, Tom Lane wrote:
>> Robert Haas writes:
>>> On Sun, Feb 19, 2017 at 3:31 AM, Tom Lane wrote:
Thoughts? Should we double down on trying to make this work according
to the "all integer timestamps" protocol specs, or c
My colleague Rahila reported compilation issue with
the patch. Issue was only coming with we do the clean
build on the branch.
Fixed the same into latest version of patch.
Thanks,
On Tue, Jan 31, 2017 at 11:09 AM, Rushabh Lathia
wrote:
>
>
> On Tue, Jan 31, 2017 at 8:54 AM, Michael Paquier <
On 2017/02/19 18:53, Robert Haas wrote:
> On Fri, Feb 17, 2017 at 1:12 PM, Amit Langote wrote:
>> Do you mean that if database-wide analyze is to be run, we should also
>> exclude those RELKIND_RELATION relations that are partitions?
>>
>> So the only way to update a partition's statistics is to di
On Mon, Feb 20, 2017 at 3:01 PM, Simon Riggs wrote:
> On 20 February 2017 at 09:15, Amit Kapila wrote:
>> On Mon, Feb 20, 2017 at 7:26 AM, Masahiko Sawada
>> wrote:
>>> On Fri, Feb 17, 2017 at 3:41 AM, Robert Haas wrote:
On Thu, Feb 16, 2017 at 6:17 AM, Simon Riggs wrote:
> On 15 Feb
Hi,
>> On Thu, Feb 16, 2017 at 5:07 AM, Alexander Korotkov
> >> wrote:
> >> > On Wed, Feb 15, 2017 at 8:49 PM, Alvaro Herrera
> >> >
> >> > wrote:
> >> >> Alexander Korotkov wrote:
> >> >>
> >> >> > Difference between master, pgxact-align-2 and pgxact-align-3
> doesn't
> >> >> > exceed
> >> >> >
On Mon, Feb 20, 2017 at 3:36 PM, Thomas Munro
wrote:
> On Thu, Feb 16, 2017 at 8:53 PM, Robert Haas wrote:
>> Generally speaking, we don't throw
>> serialization errors today at READ COMMITTED, so if we do so here,
>> that's going to be a noticeable and perhaps unwelcome change.
>
> Yes we do:
>
On Thu, Feb 16, 2017 at 8:53 PM, Robert Haas wrote:
> Generally speaking, we don't throw
> serialization errors today at READ COMMITTED, so if we do so here,
> that's going to be a noticeable and perhaps unwelcome change.
Yes we do:
https://www.postgresql.org/docs/9.6/static/transaction-iso.html
On Mon, Feb 20, 2017 at 1:45 AM, Tom Lane wrote:
> The versions of autocommit that have actually stood the test of time were
> implemented on the client side (in psql and JDBC, and I think ODBC as
> well), where the scope of affected code was lots smaller. I wonder
> whether there's any hope of p
On 20 February 2017 at 09:15, Amit Kapila wrote:
> On Mon, Feb 20, 2017 at 7:26 AM, Masahiko Sawada
> wrote:
>> On Fri, Feb 17, 2017 at 3:41 AM, Robert Haas wrote:
>>> On Thu, Feb 16, 2017 at 6:17 AM, Simon Riggs wrote:
On 15 February 2017 at 08:07, Masahiko Sawada
wrote:
> It'
On Mon, Feb 20, 2017 at 2:40 AM, Jim Nasby wrote:
> Even if the project decided that "Users" and users is stupid and that we
> should deprecate it, I think the odds of also deciding to tell existing
> users to re-write their apps are zero.
But if the feature can't be turned on without also enforc
On 16 February 2017 at 20:53, Robert Haas wrote:
> On Thu, Feb 16, 2017 at 5:47 AM, Greg Stark wrote:
>> On 13 February 2017 at 12:01, Amit Khandekar wrote:
>>> There are a few things that can be discussed about :
>>
>> If you do a normal update the new tuple is linked to the old one using
>> th
On Mon, Feb 20, 2017 at 1:58 PM, Dilip Kumar wrote:
> On Mon, Feb 20, 2017 at 12:05 PM, Rushabh Lathia
> wrote:
>> Thanks Amit for raising this point. I was not at all aware of mark/restore.
>> I tried to come up with the case, but haven't found such case.
>>
>> For now here is the patch with com
Hello,
On Thu, Feb 16, 2017 at 3:37 PM, Kuntal Ghosh
wrote:
> On Mon, Feb 6, 2017 at 11:09 PM, Beena Emerson
> wrote:
> >
> > Hello,
> > PFA the updated patches.
> I've started reviewing the patches.
> 01-add-XLogSegmentOffset-macro.patch looks clean to me. I'll post my
> detailed review after
On Mon, Feb 20, 2017 at 7:26 AM, Masahiko Sawada wrote:
> On Fri, Feb 17, 2017 at 3:41 AM, Robert Haas wrote:
>> On Thu, Feb 16, 2017 at 6:17 AM, Simon Riggs wrote:
>>> On 15 February 2017 at 08:07, Masahiko Sawada wrote:
It's a bug. Attached latest version patch, which passed make check.
On Mon, Feb 20, 2017 at 2:09 AM, Simon Riggs wrote:
> On 15 February 2017 at 15:46, Robert Haas wrote:
>>> It leaves me asking what else is missing.
>>
>> There is certainly a lot of room for improvement here but I don't
>> understand your persistent negativity about what's been done thus far.
>>
On Mon, Feb 20, 2017 at 12:05 PM, Rushabh Lathia
wrote:
> Thanks Amit for raising this point. I was not at all aware of mark/restore.
> I tried to come up with the case, but haven't found such case.
>
> For now here is the patch with comment update.
I think for reproducing this you need plan some
On 2017/02/13 18:24, Rushabh Lathia wrote:
I started reviewing the patch again. Patch applied cleanly on latest source
as well as regression pass through with the patch. I also performed
few manual testing and haven't found any regression. Patch look
much cleaner the earlier version, and don't ha
97 matches
Mail list logo
