The following bug has been logged online:
Bug reference: 4646
Logged by: Jason
Email address: jdmarsh...@gmail.com
PostgreSQL version: 8.2
Operating system: Windows XP
Description:Default password is patently absurd
Details:
I let the installer pick a password for m
The following bug has been logged online:
Bug reference: 4647
Logged by: Juho Saarikko
Email address: juho.saari...@gmail.com
PostgreSQL version: 8.3.6
Operating system: Linux
Description:Geometric functions reorder their parameters randomly
Details:
According to th
Dear All
While taking backup through Pg_dump or accessing pgacees. following errorrs are coming.
SnapShot of Errors Attached.
PLease help Urgently.
Regards
swadesh
<><><>
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
The following bug has been logged online:
Bug reference: 4648
Logged by: Konstantin
Email address: kostya2...@rambler.ru
PostgreSQL version: 8.1.16
Operating system: Red Hat Enterprise Linux 4
Description:needless deadlock on tables having foreign-key
Details:
Prepa
Jason wrote:
I let the installer pick a password for me. What it picked was 31
characters long, and included characters that I can't actually type on my
keyboard. Quite possibly some can't even be displayed on my system, as
several are listed as "?". One of the other characters is the section
> that password is ONLY used for the Windows Service login, not anything you'd
> ever see again.
Only when reusing the service account to do a PostgreSQL update... or
when doing the not so uncommon "uninstall, reinstall" raindance fix
for windows (which indeed helps if some bad application overwro
The following bug has been logged online:
Bug reference: 4649
Logged by: Tommy
Email address: csck...@gmail.com
PostgreSQL version: 8.3
Operating system: CentOS 5.1
Description:unclear in create trigger - complete example
Details:
please add hyperlink
http://www.po
Harald Armin Massa wrote:
that password is ONLY used for the Windows Service login, not anything you'd
ever see again.
Only when reusing the service account to do a PostgreSQL update... or
when doing the not so uncommon "uninstall, reinstall" raindance fix
for windows (which indeed helps i
John,
> the postgres windows uninstaller probably should be offering to delete the
> postgres user account when it deletes the service, since the installer
> created that account in the first place.
deleting the postgres-windows-account is not really what someone
should wish for. As the files of
Konstantin wrote:
Preparation:
a) Create tables and insert a few rows.
CREATE TABLE parent (pid integer PRIMARY KEY);
CREATE TABLE child (id integer PRIMARY KEY, pid integer REFERENCES
parent(pid) );
INSERT INTO parent VALUES(1);
INSERT INTO child VALUES(1,1);
b) open two sessions via psql to d
The following bug has been logged online:
Bug reference: 4650
Logged by: Thue Janus Kristensen
Email address: thu...@gmail.com
PostgreSQL version: 8.3.5
Operating system: Linux
Description:can't specify table schema in CREATE TABLE AS
Details:
According to
http://ww
* Heikki Linnakangas [Thu, 12 Feb
2009 13:54:11 +0200]:
Hmm, the first UPDATE should've blocked already. It should've fired a
RI
trigger to lock the parent tuple in shared mode, but it looks like
that's not happening for some reason.
To tell the truth I expected another behavior.
Consider ex
On Thu, Feb 12, 2009 at 6:22 PM, Thue Janus Kristensen wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4650
> Logged by: Thue Janus Kristensen
> Email address: thu...@gmail.com
> PostgreSQL version: 8.3.5
> Operating system: Linux
> Description:
Konstantin wrote:
* Heikki Linnakangas [Thu, 12 Feb
2009 13:54:11 +0200]:
Hmm, the first UPDATE should've blocked already. It should've fired a
RI
trigger to lock the parent tuple in shared mode, but it looks like
that's not happening for some reason.
To tell the truth I expected another be
Heikki Linnakangas writes:
> Hmm, the first UPDATE should've blocked already. It should've fired a RI
> trigger to lock the parent tuple in shared mode, but it looks like
> that's not happening for some reason.
Read the special code in AfterTriggerSaveEvent. This behavior is
exactly what is ex
Tommy wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4649
> Logged by: Tommy
> Email address: csck...@gmail.com
> PostgreSQL version: 8.3
> Operating system: CentOS 5.1
> Description:unclear in create trigger - complete example
> Details:
>
"Juho Saarikko" writes:
> According to the online documentation, the ## operator is supposed to return
> "Closest point to first operand on second operand". However, in reality it
> seems to decide reorder its parameters as a function of them.
In the example you give, it looks like close_lseg (wh
* Tom Lane [Thu, 12 Feb 2009 10:54:34 -0500]:
Heikki Linnakangas writes:
> Hmm, the first UPDATE should've blocked already. It should've fired
a
RI
> trigger to lock the parent tuple in shared mode, but it looks like
> that's not happening for some reason.
Read the special code in AfterTrig
Konstantin wrote:
* Tom Lane [Thu, 12 Feb 2009 10:54:34 -0500]:
Heikki Linnakangas writes:
> Hmm, the first UPDATE should've blocked already. It should've fired
a
RI
> trigger to lock the parent tuple in shared mode, but it looks like
> that's not happening for some reason.
Read the specia
Harald Armin Massa wrote:
John,
the postgres windows uninstaller probably should be offering to delete the
postgres user account when it deletes the service, since the installer
created that account in the first place.
deleting the postgres-windows-account is not really what someone
s
Heikki Linnakangas writes:
> Hmm, the comment specifically talks about deferrable RI checks. I wonder
> if we could skip that when there's no deferred triggers queued?
The point of the comment is that if the FK isn't deferred then it will
have been executed already (at completion of the precedin
* Heikki Linnakangas [Thu, 12 Feb
2009 19:34:46 +0200]:
It's certainly not ideal. It's an implementation artifact of the way
MVCC and RI triggers work. The purpose is to protect from this
potential
bug:
As I can see you are agree with problem existence and problem will not
be solved soo
Konstantin writes:
> I just want to emphasize that mentioned implementation artifact born not
> obvious issues at applications side.
[ shrug... ] The "implementation artifact" is that you didn't get a
deadlock *earlier*. You can't expect to update referenced rows and
referencing rows in the sa
23 matches
Mail list logo
