On 2023-09-11 17:04:54 +0100, Graeme wrote:
> Preparing to upgrade my small cluster from Mageia 8/Pg 9 to Mageia 9/Pg 15.
> I'm
> at the point of running pg_upgrade but have received anerror message:
>
> /mga8/usr/bin/postgres: error while loading shared libraries: libssl.so.1.1:
> cannot open sh
On 11/09/2023 17:04, Graeme wrote:
Preparing to upgrade my small cluster from Mageia 8/Pg 9 to Mageia
9/Pg 15. I'm at the point of running pg_upgrade but have received
anerror message:
/mga8/usr/bin/postgres: error while loading shared libraries:
libssl.so.1.1: cannot open shared object fil
> Hello friends,
>
> I want to migrate a large Oracle table to PostgreSQL, which is
> approximately 200GB in size and includes a LOB segment. This table has a
> primary key column named "ID," which increments by one unit (similar to a
> sequence). During the migration of this large table, sometimes
Preparing to use pg_update, I used initdb to create the new pgsql/data,
but pg_update has exited with
encodings for database "template1" do not match: old "UTF8", new
"SQL_ASCII"
Should I delete pgsql/data and re-create with initdb -E "UTF8"?
Thanks,
Graeme
On 2023-09-08 17:19:01 +0700, duc hiep ha wrote:
> I want to migrate a large Oracle table to PostgreSQL, which is approximately
> 200GB in size and includes a LOB segment. This table has a primary key column
> named "ID," which increments by one unit (similar to a sequence). During the
> migration
El día martes, septiembre 12, 2023 a las 02:19:19 +0200, Peter J. Holzer
escribió:
> > - Or can we add additional parameters to the ora2pg.conf file to control
> > this
> > process and ensure that the data is imported sequentially, following the
> > primary key from smallest to largest?
AFAIK,
> On 12 Sep 2023, at 14:26, Matthias Apitz wrote:
>
> El día martes, septiembre 12, 2023 a las 02:19:19 +0200, Peter J. Holzer
> escribió:
>
>>> - Or can we add additional parameters to the ora2pg.conf file to control
>>> this
>>> process and ensure that the data is imported sequentially, foll
I have not tried this in a while but I think a SELECT with a "hint" will return
rows in the order of the index in the hint. This does NOT work for distributed
queries.
> On 09/12/2023 9:10 AM EDT Daniel Gustafsson wrote:
>
>
> > On 12 Sep 2023, at 14:26, Matthias Apitz wrote:
> >
> > El
On 12/09/2023 15:52, Adrian Klaver wrote:
On 9/12/23 04:49, Graeme wrote:
Preparing to use pg_update, I used initdb to create the new
pgsql/data, but pg_update has exited with
I'm guessing that is actually pg_upgrade:
https://www.postgresql.org/docs/current/pgupgrade.html
encodings for dat
On 9/12/23 04:49, Graeme wrote:
Preparing to use pg_update, I used initdb to create the new pgsql/data,
but pg_update has exited with
I'm guessing that is actually pg_upgrade:
https://www.postgresql.org/docs/current/pgupgrade.html
encodings for database "template1" do not match: old "UTF8"
On 9/12/23 03:51, Graeme wrote:
On 11/09/2023 17:04, Graeme wrote:
Ta
Graeme Gemmill
Tom, Adrian, Ray: thanks for your comments. I see the problem now,
trying to gat a Mga8 module to link against Mga9 libraries. I suspecy a
carefully placed sym-link or two will sort the problem.
I'
For a view, how does one show what schema was used to qualify a relation,
when the query used to create the view originally left the relation
unqualified?
The qualification of the view query seems static in all uses of the view.
Using pg_get_viewdef() returns the unqualified relation, but Postgres
On Wed, 2023-09-13 at 01:58 -0400, Pete O'Such wrote:
> For a view, how does one show what schema was used to qualify a relation, when
> the query used to create the view originally left the relation unqualified?
>
> The qualification of the view query seems static in all uses of the view.
> Using
13 matches
Mail list logo
