Hi *,
I’ve tried both setting the constraints temporarily to invalid (works)
and converting (painstakingly slow, as this is new for me) to triggers
(also works). Both can be dumped and restored.
I’ve also found out that I probably can ship the schema update that
converts the CHECK constraint to a
On Fri, 31 Mar 2017, Adrian Klaver wrote:
> > ① that using a CHECK constraint to check data from another table
> > is wrong (but not why), and
>
> Because that is a documented limitation:
>
> https://www.postgresql.org/docs/9.6/static/sql-createtable.html
>
> "Currently, CHECK expressions can
Hi *,
while I’d still appreciate help on the bugreport (context is this…
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859033 … one), I’ve
found this… http://dba.stackexchange.com/a/75635/65843 … which says
① that using a CHECK constraint to check data from another table
is wrong (but not wh
Dixi quod…
> ‣‣‣ What have I expected?
>
> That pg_dump recognises the dependency (there i̲s̲ a FOREIGN KEY reference
> in there) and reorders the tables dumped.
I’d actually be happy if there were a way to restore those dumps,
for example by temporarily disabling constraint checks during the
re
Package: postgresql-client-common
Version: 179
Severity: normal
I’ve created a testcase (MWE) here.
Step 1: initialise a new database user and DB, for the test:
user$ sudo su - postgres
postgres$ createuser -D -P -R -S testuser
postgres$ createdb -E UTF-8 -O testuser -T template0 -l de_DE.UTF-8
fail
Error: debian/control needs updating from debian/control.in. Run 'pg_buildext
updatecontrol'.
___
Pkg-postgresql-public mailing list
Pkg-postgresql-public@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-postgres
Hi,
this is the same bug as:
https://wiki.postgresql.org/wiki/May_2015_Fsync_Permissions_Bug#I.27ve_hit_this_bug_and_I_can.27t_restart_Postgres._What_do_I_do.3F
I *can* restart, but the upgrade isn’t in wheezy yet;
the workaround described there works for me though.
bye,
//mirabilos
--
tarent
Martin Pitt wrote:
> So I think the best we can do here is to document how to do the
> upgrade
What Aiko wrote is *mostly* what I did (apt-get, not aptitude), but:
On Sun, 12 Oct 2014, Aiko Barz wrote:
> Backup /etc/postgresql first. From my memory:
>
> $ su - postgres
> $ pg_dumpall > backup_t
reopen 764705
thanks
On Fri, 10 Oct 2014, Christoph Berg wrote:
> man pg_dump; man pg_dumpall
I find this an inacceptable close reason.
Yes, I did, in the meanwhile use pg_dumpall,
copied the /etc/postgresql/9.4/main directory,
pg_dropcluster, did the upgrade… manually com‐
pared /etc files aga
Package: postgresql-9.4
Version: 9.4~beta3-1
Preparing to unpack .../postgresql-9.4_9.4~beta3-1_x32.deb ...
Stopping PostgreSQL 9.4 database server: main.
ERROR: The database format changed between beta 2 and 3. Please dump your 9.4
clusters first and remove them before upgrading the package.
dpk
Christoph Berg dixit:
>it took me some time to make sense of this report. You'd tend to
>include all sorts of context in your bug reports which you use to bury
Yes, sorry about that. I was working through a number of issues
at the same time.
>the actual request - just putting "please M-A pg-comm
Package: postgresql-9.4
Version: 9.4~beta2-1
Severity: normal
Hi *,
I just crossgraded from i386 to x32 and can no longer access the DB:
tglase@tglase:~ $ sudo service postgresql start
Starting PostgreSQL 9.4 database server: mainThe PostgreSQL server failed to
start. Please check the log outpu
On Mon, 28 Jul 2014, Christoph Berg wrote:
> > So, how d̲o̲ I recover from this without making things worse, now?
>
> You can just start the old cluster again. (The only thing that could
> be changed there are the port number and start.conf, but judging from
> the errors you got it died way befor
On Fri, 25 Jul 2014, Thorsten Glaser wrote:
> What am I supposed to do now? I fear doing anything wrong
> will make the situation much worse?
So, how d̲o̲ I recover from this without making things worse, now?
Thanks,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn
Package: postgresql-common
Version: 159
Severity: important
tglase@tglase:~ $ sudo pg_dropcluster 9.4 main --stop
[sudo] password for tglase:
tglase@tglase:~ $ sudo pg_upgradecluster 9.3 main
Stopping old cluster...
pg_ctl: server does not shut down
HINT: The "-m fast" option immediately disconnec
Package: postgresql-common
Version: 159
Severity: normal
Hi!
/usr/share/doc/postgresql-9.4/README.Debian.gz still says:
|Then drop the default 9.3 cluster:
|
| pg_dropcluster 9.3 main --stop
|
|And then upgrade the 9.1 cluster to the latest installed version (e. g. 9.3):
|
| pg_upgradecluster
Package: dbconfig-common
Version: 1.8.47+nmu1
Severity: normal
Hi,
I’m working on packaging a web application that uses PostgreSQL
(well, will do once I finish converting it from SQLite2 to it).
When I 'apt-get purge packagename', dbconfig-common tries to
remove the database (as I tell it to), b
Martin Pitt dixit:
>Christoph Berg [2012-12-19 10:40 +0100]:
>> We could probably wait for the startup, but then exit 0 with the
>> message "cluster is still starting up".
>
>I like that idea. It should avoid postinst failures on slow
>architectures, but in the normal case a "/etc/init.d/postgresq
18 matches
Mail list logo
