> "Michael" == Michael Paquier writes:
Michael> I have also been trying to shape that into a TAP test which
Michael> can be added into the in-core recovery test suite, and it
Michael> happens that the part which scans if all the pages of a
Michael> relation are not newer than what minReco
Tomas Vondra writes:
> BTW is the v19 really just a rebase of the preceding version?
> I'm asking because v18 was adding two types into pg_type.dat, namely
> jsonpath (6050) and _jsonpath (6051), while v19 only adds jsonpath
> (6050).
I haven't looked at this patch, but manual generation of array
st 7. 11. 2018 v 19:35 odesÃlatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Wed, 7 Nov 2018 at 17:09, Pavel Stehule
> wrote:
> >
> > I don't agree. If we use a same syntax for some objects types, we
> should to enforce some consistency.
>
> Just to make it clear, consistency between w
On Thu, Nov 08, 2018 at 05:04:35AM +, Andrew Gierth wrote:
> How? It's OK (and normal) for in-core pages to have newer LSNs than
> minRecoveryPoint, it's only on-disk pages that must not be more recent
> than that. And pageinspect will show the in-core page...
If the standby is stopped cleanly
On Sun, Nov 4, 2018 at 6:37 AM Haribabu Kommi wrote:
>
> On Sun, Nov 4, 2018 at 11:17 AM Michael Paquier wrote:
>>
>> On Sat, Nov 03, 2018 at 03:56:14PM +0530, Amit Kapila wrote:
>> > Before trying out any solution or deciding which is better, I think we
>> > want to understand why the variabilit
On 19 October 2018 at 01:47, Alexander Kuzmenkov
wrote:
> Here is a version that compiles.
I had a quick read through this and I think its missing about a 1-page
comment section detailing when we can and when we cannot remove these
self joins, and what measures we must take when we do remove them
> "Michael" == Michael Paquier writes:
>> How? It's OK (and normal) for in-core pages to have newer LSNs than
>> minRecoveryPoint, it's only on-disk pages that must not be more
>> recent than that. And pageinspect will show the in-core page...
Michael> If the standby is stopped cleanly o
On 2018/11/08 12:59, Amit Langote wrote:
> It might be okay to split the big switch in partition_bounds_create() into
> different functions for different partitioning methods for clarity as you
> say, but let's avoid creating new files for range, list, and hash.
>
> I will post an updated patch wi
On Thu, Nov 08, 2018 at 06:00:29AM +, Andrew Gierth wrote:
> I think it would be nice to have a test that didn't rely on that, too.
Yes, I don't disagree with you and I thought about it. Fetching the
value from the control file is easy, doing the comparison between two
LSNs is also simple by
On 11/8/18, David Rowley wrote:
> On 8 November 2018 at 10:02, Robert Haas wrote:
>> It might be useful for some users to explain that certain things will
>> should work for values < X, may work for values between X and Y, and
>> will definitely not work above Y. Or maybe we can provide a narrat
On 2018/11/07 20:46, David Rowley wrote:
> On 5 November 2018 at 20:17, Amit Langote
> wrote:
>> On 2018/11/04 19:07, David Rowley wrote:
>>> Perhaps a better design would be to instead of having random special
>>> partitioned-table-only fields in ResultRelInfo, just have an extra
>>> struct ther
On 07/11/2018 19:03, Tom Lane wrote:
> Peter Eisentraut writes:
>> Committed, thanks.
>
> It seems unfortunate that there is no test coverage in the committed
> patch. I realize that it may be hard to test given the filesystem
> dependency, but how will we know if it works at all?
You can use s
Hi,
Thank you updating the patch and adding notes to the documentation about
the points I raised.
On 2018/11/07 9:53, Michael Paquier wrote:
> On Tue, Nov 06, 2018 at 07:04:17PM +0900, Amit Langote wrote:
>> Agree with keeping it simple. Maybe, we could (should?) document that the
>> only ON COM
101 - 113 of 113 matches
Mail list logo
