Hallo Michael,
I've now forward-ported this change to pg_verify_checksums, in order to
make this application useful for online clusters, see attached patch.
Patch does not seem to apply anymore, could you rebase it?
--
Fabien.
>
>
Interesting.
>
> So you were running 9.6.9 before, it triggered the issue (and was not
> able to recover). You took a filesystem snapshot, started a 9.6.10 on
> the snapshot, and it recovered without hitting the issue?
>
I am resposting this to the list and not only to Tomas. Tomas, I can’t
On Sat, Sep 1, 2018 at 6:03 PM Robert Haas wrote:
> On Wed, Aug 29, 2018 at 4:32 AM, Kyotaro HORIGUCHI
> wrote:
> > After the attached patch applied, the above messages becomes as
> > follows. (And index can be built being a bit sparse by fill
> > factor.)
> >
> >> ERROR: index row size 8016
On Fri, Aug 31, 2018 at 10:24 PM Dilip Kumar
wrote:
> On Fri, Aug 31, 2018 at 3:08 PM, Dilip Kumar wrote:
> > As Thomas has already mentioned upthread that we are working on an
> > undo-log based storage and he has posted the patch sets for the lowest
> > layer called undo-log-storage.
> >
> >
On Thu, Jul 19, 2018 at 11:51 PM Thomas Munro
wrote:
> On Thu, Jul 19, 2018 at 10:30 PM, Kyotaro HORIGUCHI
> > Yeah. That seems good. Couldn't we reuse prepared WaitEventSet in
> > other places? For example PgstatCollectorMain has the same
> > characteristics, where WaitLatchOrSocket is used with
Lars Kanis writes:
> The current documentation is inconsistent about the JOHAB character encoding
> on server side. While the first table says that it is not possible to use
> JOHAB on server side, it is still listed in table 23.2 as a server character
> set:
>
Michael Paquier writes:
> On Fri, Aug 31, 2018 at 07:59:58PM -0400, Tom Lane wrote:
>> The others you mention could be changed, probably, but I didn't
>> bother as they didn't seem performance-critical.
> It is not really critical indeed. There is an argument to change them
> so as other folks
On Wed, Aug 29, 2018 at 4:32 AM, Kyotaro HORIGUCHI
wrote:
> After the attached patch applied, the above messages becomes as
> follows. (And index can be built being a bit sparse by fill
> factor.)
>
>> ERROR: index row size 8016 exceeds maximum 7333 for index "y_cube_idx"
>
> I'm not sure why
The current documentation is inconsistent about the JOHAB character encoding on
server side. While the first table says that it is not possible to use JOHAB on
server side, it is still listed in table 23.2 as a server character set:
On Thu, Aug 30, 2018 at 2:44 PM Kyotaro HORIGUCHI
wrote:
> At Thu, 30 Aug 2018 13:42:42 +0300, Alexander Korotkov
> wrote in
>
> > It seems that http://commitfest.cputube.org/ runs only "make check" on
> > Windows. But my Postgres Pro colleagues checked that tests passed on
> > 32-bit and
Andres Freund writes:
> One concern I have with your approach is that it isn't particularly
> bullet-proof for cases where the rebuild is triggered by something that
> doesn't hold a conflicting lock.
Wouldn't that be a bug in the something-else? The entire relation cache
system is based on the
Alexander Korotkov writes:
> Thus, I would vote for removing GiST fillfactor altogether. Assuming
> we can't do this for compatibility reasons, I would vote for setting
> default GiST fillfactor to 100, and don't introduce new places where
> we take it into account.
We probably can't remove the
On 01/09/18 18:25, Jeremy Finzel wrote:
>
> Interesting.
>
> So you were running 9.6.9 before, it triggered the issue (and was not
> able to recover). You took a filesystem snapshot, started a 9.6.10 on
> the snapshot, and it recovered without hitting the issue?
>
>
> I am
On Sat, Sep 1, 2018 at 2:13 PM, Charles Cui wrote:
>Thanks again for supporting me to pass the GSoC summer project and I
> found that I have a learnt a lot during this project! Although the project
> is completed, I am thinking of contributing to PostgreSQL community in the
> long term. So,
On Wed, Jun 27, 2018 at 12:09:24PM +0200, Laurenz Albe wrote:
> Michael Paquier wrote:
> > > I have added it to the July commitfest.
> >
> > Have you looked at the possibility of removing the log file constraints
> > in pg_upgrade with the change you are doing here so as things would be
> > more
On Sat, Jul 21, 2018 at 3:34 AM Tom Lane wrote:
> Heikki Linnakangas writes:
> > No objections, if you want to make the effort. But IMHO the lseek+read
> > fallback is good enough on Windows. Unless you were thinking that we
> > could then remove the !HAVE_PREAD fallback altogether. Are there
On Sat, Sep 01, 2018 at 03:32:10PM -0400, Tom Lane wrote:
> Fair enough. I renamed the types as suggested, changed a few more
> places for consistency's sake, and pushed.
Thanks!
> There still remain some places where palloc(BLCKSZ) or equivalent is used,
> but there's no matching pfree. In a
Hi mentors and hackers,
Thanks again for supporting me to pass the GSoC summer project and I
found that I have a learnt a lot during this project! Although the project
is completed, I am thinking of contributing to PostgreSQL community in the
long term. So, the purpose of this email is to seek
On Fri, Jan 26, 2018 at 04:54:08PM +0300, a.parfe...@postgrespro.ru wrote:
> As it mentioned in pg_locale.c, the variable LC_MESSAGES is ignored in
> Windows(pg_locale.c:162).
That comment says "On Windows, setlocale(LC_MESSAGES) does not work". It says
nothing about the LC_MESSAGES environment
19 matches
Mail list logo
