On 6/20/21 1:40 PM, Karsten Hilbert wrote:
Am Sun, Jun 20, 2021 at 01:14:06PM -0700 schrieb Adrian Klaver:
Any chance pg_dump (and/or pg_restore) might gain an option
--ignore-read-only ? That way, PostgreSQL need not decide
for users.
How about:
1) pg_dump -Fc -d read_only_db -U postgres
Am Sun, Jun 20, 2021 at 01:14:06PM -0700 schrieb Adrian Klaver:
> >Any chance pg_dump (and/or pg_restore) might gain an option
> >--ignore-read-only ? That way, PostgreSQL need not decide
> >for users.
>
> How about:
>
> 1) pg_dump -Fc -d read_only_db -U postgres -f read_only.out
>
> 2) In new c
On 6/20/21 12:34 PM, Karsten Hilbert wrote:
Am Sun, Jun 20, 2021 at 01:47:47PM -0400 schrieb Tom Lane:
Hence, the only way to make this scenario work would be for the
restore script to explicitly override default_transaction_read_only.
[...]
Also, doing so would result in ignoring default_tra
Am Sun, Jun 20, 2021 at 09:34:45PM +0200 schrieb Karsten Hilbert:
> Any chance pg_dump (and/or pg_restore) might gain an option
> --ignore-read-only ? That way, PostgreSQL need not decide
> for users.
Or, options --pre-dump-sql and -post-dump-sql ?
Users could then run setup/teardown SQL for t
Am Sun, Jun 20, 2021 at 01:47:47PM -0400 schrieb Tom Lane:
> Hence, the only way to make this scenario work would be for the
> restore script to explicitly override default_transaction_read_only.
[...]
> Also, doing so would result in ignoring default_transaction_read_only
> no matter what the sou
Vijaykumar Jain writes:
> i have db example which i want to migrate from one version to another.
> to do that i disable writes on the db by setting the tx flag, so that i can
> be sure it is still serving reads, but no additional data is written.
> i can take a pg_dump, the db is still serving the
>
> Hm. It's intentional that we reconnect after applying the database
> properties, so that they are in effect during the restore. It seems
> likely that failing to do so could result in misbehaviors.
>
> Hence, the only way to make this scenario work would be for the
> restore script to explici
Karsten Hilbert writes:
> I am testing the pg_restore of a database with
> default_transaction_read_only=on.
Hm. It's intentional that we reconnect after applying the database
properties, so that they are in effect during the restore. It seems
likely that failing to do so could result in misbeh
Dear Jain,
> Did I simulate your concern correctly ?
Nearly so, to my understanding. What you did (and thanks for
the followup) was ...
> postgres@db:~/playground/logical_replication$ rm -rf example
> postgres@db:~/playground/logical_replication$ initdb -D example 2>/dev/null
> >/dev/null
> post
On Sun, 20 Jun 2021 at 22:49, Vijaykumar Jain <
vijaykumarjain.git...@gmail.com> wrote:
>
>
> On Sun, 20 Jun 2021 at 22:17, Karsten Hilbert
> wrote:
>
>> Dear all,
>>
>> I am testing the pg_restore of a database with
>> default_transaction_read_only=on.
>>
>> It would seem the restore script lack
On Sun, 20 Jun 2021 at 22:17, Karsten Hilbert
wrote:
> Dear all,
>
> I am testing the pg_restore of a database with
> default_transaction_read_only=on.
>
> It would seem the restore script lacks a
>
> SET default_transaction_read_only TO 'off';
>
> in the setup section after re-connecting
Dear all,
I am testing the pg_restore of a database with
default_transaction_read_only=on.
The following issue ensues
sudo -u postgres pg_restore --verbose --create --dbname=template1
--exit-on-error -p 5432
/tmp/gnumed/gm-restore_2021-06-20_18-31-07/backup-gnumed_v22-GNUmed_Team-herme
On 20/06/2021 14:24, Vijaykumar Jain wrote:
This was a wrong suggestion. sorry.
i'll try to reproduce what resulted in functions not getting loaded
in your case.
ok i guess you have a typo there. the function name is *no_plan()*, but
you called *noplan() *
Aaaargh - you're right
>
>
> This was a wrong suggestion. sorry.
> i'll try to reproduce what resulted in functions not getting loaded in
> your case.
>
>
ok i guess you have a typo there. the function name is *no_plan()*, but you
called *noplan() *
tt=# select * from noplan();
ERROR: function noplan() does not exist
ignore,
I was wrong.
the script gets loaded by enabling the extension.
postgres@db:~/postgresql-14beta1/contrib/pgtap$ dropdb test
postgres@db:~/postgresql-14beta1/contrib/pgtap$
postgres@db:~/postgresql-14beta1/contrib/pgtap$ createdb test
postgres@db:~/postgresql-14beta1/contrib/pgtap$ psql test
On Sun, 20 Jun 2021 at 17:18, Ray O'Donnell wrote:
>
>
> gfc_booking6_dev=# select * from noplan();
> ERROR: function noplan() does not exist
> LINE 1: select * from noplan();
>^
> HINT: No function matches the given name and argument types. You might
> need to add expli
Hi all,
I'm just tipping my toe into the water with pgTAP for the first time,
and must be doing something wrong - I can't seem to get it working.
I'm on Kubuntu Hirsute, and I've installed both PostgreSQL 13 and pgTAP
from apt.postgresql.org:
sudo apt install postgresql-13
sudo apt in
17 matches
Mail list logo
