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 any
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 c
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 l
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
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, th
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 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 respo
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 g
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:
> https://www.postgresql.org/docs/d
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
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.
> >
> > Th
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 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 exc
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 64-
>
>
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
pr
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:
https://www.postgresql.org/docs/devel/static/multibyte.html#MUL
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 277
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
18 matches
Mail list logo
