I think this is a bug, because database encoding logging must work even in this
case. The main problem is with pacemaker module pgsqlms, which launch pg_ctl in
empty environment and thus with broken logging.
Let me explain on examples.
Empty databases:
-bash-4.2$ psql -p 5433 -l
In
https://www.cybertec-postgresql.com/en/ideas-for-scaling-postgresql-to-multi-terabyte-and-beyond/
it is mentioned:
"GIN, the most know non-default index type perhaps, has been actually around
for ages (full-text search) and in short is perfect for indexing columns where
there are lot of re
On 10/17/18 2:29 AM, Олег Самойлов wrote:
I think this is a bug, because database encoding logging must work even
in this case. The main problem is with pacemaker module pgsqlms, which
launch pg_ctl in empty environment and thus with broken logging.
I suggest filing an issue here:
https://git
Don’t agree. Pgsqlms just run pg_ctl with POSIX locale, this is not a bug. But
unreadable messages when locale charset don’t match database charset is bug of
pg_ctl. When messages come from within connection all fine, why don’t do the
same for messages on start/stop?
> 17 окт. 2018 г., в 15:13,
It turned out that enabling ODBC trace was causing PG to crash. Once disabled
it started working, but found another issue.
All object names in DB2 is assumed to be upper case. odbc_fdw sends queries
like this
select "fld1","fld2" from "schema_name"."table_name".
So the foreign table in PG ha
Hi,
On 2018-10-17 11:17:11 -0400, Ravi Krishna wrote:
> It turned out that enabling ODBC trace was causing PG to crash. Once
> disabled it started working, but found another issue.
> All object names in DB2 is assumed to be upper case. odbc_fdw sends queries
> like this
>
>
> select "fld1","
>
> Please note that odbc_fdw is not maintained by the postgresql developers, but
> a separate project.
Translation: You are on your own. We are hoping this will make our migration
out of DB2 quicker. Oh well.
On 10/17/18 10:57 AM, Ravi Krishna wrote:
Please note that odbc_fdw is not maintained by the postgresql developers, but a
separate project.
Translation: You are on your own. We are hoping this will make our migration
out of DB2 quicker. Oh well.
No it means you need to take this up wi
On October 17, 2018 10:57:37 AM PDT, Ravi Krishna wrote:
>
>>
>> Please note that odbc_fdw is not maintained by the postgresql
>developers, but a separate project.
>
>
>Translation: You are on your own. We are hoping this will make our
>migration out of DB2 quicker. Oh well.
Come on. We can'
>
> Come on. We can't realistically support & debug random postgres extending
> projects, nor do we have control over them. And you're not necessarily on
> your own, you could report the issue to odbcfdw's authors/github tracker. Or
> pay a company for support.
>
On a related note is fdw for
Hi,
On 2018-10-17 14:12:01 -0400, Ravi Krishna wrote:
> >
> > Come on. We can't realistically support & debug random postgres extending
> > projects, nor do we have control over them. And you're not necessarily on
> > your own, you could report the issue to odbcfdw's authors/github tracker.
>
On 10/17/18 11:12 AM, Ravi Krishna wrote:
Come on. We can't realistically support & debug random postgres extending
projects, nor do we have control over them. And you're not necessarily on your own,
you could report the issue to odbcfdw's authors/github tracker. Or pay a company
for support
On 2018-10-17 11:02:40 -0700, Adrian Klaver wrote:
> On 10/17/18 10:57 AM, Ravi Krishna wrote:
> >
> > >
> > > Please note that odbc_fdw is not maintained by the postgresql developers,
> > > but a separate project.
> >
> >
> > Translation: You are on your own. We are hoping this will make our
13 matches
Mail list logo
