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
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
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
>
>
> 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
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
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 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
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
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
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
>
> 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
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
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
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
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 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 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
17 matches
Mail list logo
