Re: [BUGS] BUG #7596: Problem with /etc/init.d/postgresql.9.x file

[John R Pierce]

On 10/11/12 2:29 AM, david.peyrie...@meteo.fr wrote:

In my case, I've 5 databases on same server. Each database is start/stop
with this file 'service postgresql9.x start'.



one database 'cluster' (instance of the postmaster, with a corresponding 
$PGDATA directory) can have any number of databases associated with it, 
they all share the same PID file.


I'm not sure of ANY advantage of running multiple different instances of 
postgres for seperate databases.


the way the newer RHEL  init.d files are setup, if you DO want to run 
multiple copies, you create seperate init.d files, like postgresql-9.1a, 
postgresql-9.1b, etc, these can all be symlinks to the same 
postgresql-9.1 file.  you then create corresponding files in 
/etc/sysconfig/pgsql/ with PGDATA=/path/to/unique/pgdata  and 
PGPORT=54xx unique ports... like, as an example...



# cat /etc/sysconfig/pgsql/postgresql-9.0b
PGENGINE=/usr/pgsql-${PGMAJORVERSION}/bin
PGPORT=5433
PGDATA=/ssd/pgsql/${PGMAJORVERSION}/data
PGLOG=/ssd/pgsql/${PGMAJORVERSION}/pgstartup.log

# ls -la /etc/rc.d/init.d/postgresql-9.0b
lrwxrwxrwx 1 root root 14 Oct 23  2011 /etc/rc.d/init.d/postgresql-9.0b 
-> postgresql-9.0



by doing it this way, you're not editing any files that are under RPM 
package management, so you're not going to get bit during updates.






--
john r pierceN 37, W 122
santa cruz ca mid-left coast



--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #7596: Problem with /etc/init.d/postgresql.9.x file

[david.peyrieres]

Hi, 
with rpm.


Ashesh Vashi a écrit :
On Thu, Oct 11, 2012 at 2:59 PM,  wrote:
  
  The
following bug has been logged on the website:

Bug reference:      7596
Logged by:          David PEYRIERES
Email address:      david.peyrie...@meteo.fr
PostgreSQL version: 9.1.4
Operating system:   Red Hat
Description:
  
  Hi David,
  
  
  How did you install postgresql?
  
  --
  
  
  Thanks & Regards,
  Ashesh
Vashi
  
  
  
Hello.
I found a little bug in /etc/init.d/postgresql-9.x file (ok in 8.4 -
since
9.x versions ?).
In my case, I've 5 databases on same server. Each database is start/stop
with this file 'service postgresql9.x start'.
Unfortunately, it uses only same file for status "pidfile:
/var/run/postmaster-9.2.pid".
In my case and with this configuration, I have only one file for all
databases.
So, I've modified this file on all servers :

1 - pidfile="/var/run/${NAME}.pid

2 - and case test :

case "$1" in
  
 status)
   status -p /var/run/postmaster-9.1.pid
by
   status -p $pidfile



Thanks for all.






--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

  
  


-- 









David
PEYRIERES
Direction
des Sytèmes d'Information
Division Etudes et Développements

Tel :   +33 (0)5.61.07.83.36 
Fax :  +33 (0)5.61.07.81.09 
david.peyrie...@meteo.fr

METEO FRANCE 
www.meteo.fr 
42 avenue Gustave Coriolis 
31057 TOULOUSE Cédex 

Re: [BUGS] Fwd: race in pg_ctl start -w

[Tom Lane]

Heikki Linnakangas  writes:
> Hmm, starting with 9.3, postmaster can not only create and append to the 
> end of file, it can also inject a line in the middle, shifting the 
> following lines forwards. In theory, if a new line is injected into the 
> middle of the file between fgets() calls, readfile() could read part of 
> the same line twice. Not sure what consequences that could have; pg_ctl 
> might try to connect to wrong address or socket directory.

Hm.  IIRC, the postmaster is careful to write the whole thing in a
single write() call, which in principle is atomic.  Perhaps you're
right that we'd better have pg_ctl read it in a single read() to
ensure that it sees a consistent file state.  Otherwise we're making
assumptions about what sort of buffering underlies the stdio functions.

> Then again, I don't think read/write on a 
> file is guaranteed to be atomic either, so I guess there's always the 
> theoretical possibility of a partial read.

I think it is as long as the file is less than a bufferload.

> This makes me a bit uncomfortable with the 9.3 change that 
> postmaster.pid file is no longer strictly append-only (commit c9b0cbe9). 
> Could we delay appending the socket directory and listen address 
> information to the file until we know both, and then append both in one 
> call after that?

IIRC, there were compatibility reasons for doing it that way, so I'm
disinclined to change it.

regards, tom lane


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Fwd: race in pg_ctl start -w

[Heikki Linnakangas]

On 11.10.2012 20:29, Tom Lane wrote:

Heikki Linnakangas  writes:

A straightforward fix would be to just allocate one large-enough buffer
to begin with, e.g 8k, and read the whole file in one go. I'll write up
a patch for that.


This makes the readfile function very usage-specific though.  The fix
I was thinking about was to modify the second loop to force it to fall
out once the predetermined number of lines had been read.

Or maybe we should use just one loop with realloc, instead of reading
the file twice.


Hmm, starting with 9.3, postmaster can not only create and append to the 
end of file, it can also inject a line in the middle, shifting the 
following lines forwards. In theory, if a new line is injected into the 
middle of the file between fgets() calls, readfile() could read part of 
the same line twice. Not sure what consequences that could have; pg_ctl 
might try to connect to wrong address or socket directory.


Although in practice, fgets() is buffered, and the buffer is probably 
large enough to hold the whole file, so it probably gets slurped into 
memory as one unit anyway. Then again, I don't think read/write on a 
file is guaranteed to be atomic either, so I guess there's always the 
theoretical possibility of a partial read.


This makes me a bit uncomfortable with the 9.3 change that 
postmaster.pid file is no longer strictly append-only (commit c9b0cbe9). 
Could we delay appending the socket directory and listen address 
information to the file until we know both, and then append both in one 
call after that?


Gah, how can a trivial thing like this be so complicated..

- Heikki


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Fwd: race in pg_ctl start -w

[Tom Lane]

Heikki Linnakangas  writes:
> A straightforward fix would be to just allocate one large-enough buffer 
> to begin with, e.g 8k, and read the whole file in one go. I'll write up 
> a patch for that.

This makes the readfile function very usage-specific though.  The fix
I was thinking about was to modify the second loop to force it to fall
out once the predetermined number of lines had been read.

Or maybe we should use just one loop with realloc, instead of reading
the file twice.

>> It also flagged a very similar issue (looks like the code was copied &
>> pasted) in initdb.c.  I haven't looked into whether that one is as
>> likely to be subject to a race as the pg_ctl one, but it could be
>> problematic as well.

> I don't think it's a problem for initdb, because the files that it reads 
> should not change on the fly. Nevertheless, I guess we might as well add 
> a check there.

Yeah, I would prefer to keep the code the same in initdb and pg_ctl,
just because somebody is likely to copy one or the other in future.
The fixed-size-buffer solution does not work for initdb.

regards, tom lane


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] Fwd: race in pg_ctl start -w

[Heikki Linnakangas]

Forwarding this to pgsql-bugs, since this isn't a security issue, as 
pg_ctl can only be called an admin. My replies inline.



 Original Message 
Subject: [pgsql-security] race in pg_ctl start -w
Date: Thu, 11 Oct 2012 12:39:02 -0400
From: Dave Vitek 
To: 

Hi,

I don't really think this is a security issue since pg_ctl isn't really
an appealing target, but in theory you could hijack the process if you
got very very lucky.  Feel free to forward this to the bugs list if you
decide it isn't sensitive.

We recently ran into a crash when using pg_ctl to start the postgres
daemon.  The command was:
pg_ctl start -w -t 600 -D

It was a segv inside the body of malloc and didn't want to repro.

The good news is, we develop a static analysis tool called CodeSonar for
detecting bugs like this.  It has been flagging the problem since 2009,
but we've generally been ignoring reports in third-party code (there are
a lot of them).  We analyze postgres on a regular basis because it is
used by CS's web UI.


So, the problem is that there's a race condition in the readfile() 
function that pg_ctl uses to read postmaster.pid. It does essentially this:


1. open postmaster.pid
2. Read through the file one byte at a time, and count newlines.
3. Allocate buffers to hold that many lines.
4. Rewind and read the file again, this time copying the lines to the 
allocated buffers


The race condition is that if another process (postmaster) changes the 
file between steps 2 and 4, so that there are now more lines, reading 
the file again can overrun the buffers allocated. In particular that can 
happen at postmaster startup, when postmaster initially creates the file 
empty, and then does a write() to fill it in.


It seems very unlucky if you actually hit that race condition, but I 
guess it's not impossible.


A straightforward fix would be to just allocate one large-enough buffer 
to begin with, e.g 8k, and read the whole file in one go. I'll write up 
a patch for that.



It also flagged a very similar issue (looks like the code was copied &
pasted) in initdb.c.  I haven't looked into whether that one is as
likely to be subject to a race as the pg_ctl one, but it could be
problematic as well.


I don't think it's a problem for initdb, because the files that it reads 
should not change on the fly. Nevertheless, I guess we might as well add 
a check there.



Here are the bug reports:
http://www.grammatech.com/products/codesonar/examples/pg_ctl_race.html
http://www.grammatech.com/products/codesonar/examples/initdb_race.html

I've just saved static HTML above, so none of the links, navigation
features, or images will work.  The files are posted on the website
because they seemed a bit big for sending to a list.  I haven't shared
them with anyone else outside the company.

- Dave


-. Heikki


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #6451: problem while installing gridsql

[ashu]

small correction in above msg

its not limit_connections='*'  but
  
listen_addresses='*'



--
View this message in context: 
http://postgresql.1045698.n5.nabble.com/BUG-6451-problem-while-installing-gridsql-tp5469996p5727648.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #7595: terminate process in an unusual way

[hikkis21c]

The following bug has been logged on the website:

Bug reference:  7595
Logged by:  seowoong kim
Email address:  hikkis...@hotmail.com
PostgreSQL version: 9.1.3
Operating system:   windows 7 (x64)
Description:

hi

I'm using postgreSQL 9.1.3 version.

there's some problem with connect to database and I knew after process
recovery. this problem solved after restart computer
after I saw postgresql's log
postgresql.conf file was default

this is log file's information
at first

I got this error

2012-10-10 16:01:55 KST PANIC:  could not write to log file 4, segment 232
at offset 15237120, length 16384: Invalid argument
this time it was doing usual operation

after this
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.

2012-10-10 16:01:55 KST LOG:  server process (PID 1870880) exited with exit
code 3
2012-10-10 16:01:55 KST LOG:  terminating any other active server processes
this comment printed 

and until database recovery 
2012-10-10 16:01:57 KST FATAL:  the database system is in recovery mode
this message printed continuously

recovery message is this

2012-10-10 16:37:35 KST LOG:  database system was interrupted; last known up
at 2012-10-10 16:00:51 KST
2012-10-10 16:37:35 KST LOG:  database system was not properly shut down;
automatic recovery in progress
2012-10-10 16:37:35 KST LOG:  redo starts at 4/E8E1E868
2012-10-10 16:37:35 KST LOG:  record with zero length at 4/E8E89EE0
2012-10-10 16:37:35 KST LOG:  redo done at 4/E8E89EA0
2012-10-10 16:37:35 KST LOG:  last completed transaction was at log time
2012-10-10 16:01:54.795+09
2012-10-10 16:37:35 KST LOG:  database system is ready to accept
connections


I'm just wondering what kind of problem is this and if this problem happen
again how I recover process without restart computer.





-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #6451: problem while installing gridsql

[ashu]

Hi Srinivas,

  The error comes becoz of two reasons.
  1)U didn't create XDBSYS
  2) limit_connections='*'  is not given in
/usr/local/pgsql/data/postgres.conf

to create XDBSYS
 
createdb XDBSYS -u gridsql

./gs-createmddb.sh -u admin -p secret


Ashu.



--
View this message in context: 
http://postgresql.1045698.n5.nabble.com/BUG-6451-problem-while-installing-gridsql-tp5469996p5727646.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #7598: Loss of view performance after dump/restore of the view definition

[vaclav . juza]

The following bug has been logged on the website:

Bug reference:  7598
Logged by:  Vaclav Juza
Email address:  vaclav.j...@xitee.com
PostgreSQL version: 9.2.1
Operating system:   Linux 2.6.18-128.el5 x86_64 (RHEL 5.3)
Description:

Hi,
when a view (with the below properites) is dump and restored (no matter if
using pg_dump, copied from pg_admin or using pg_views) it's performance is
worse than before. The view was using tables with columns of type "character
varying(xx)" and the dump inserts "::text" casts into the join conditions on
these columns.
In the real case we faced this problem, the performance loss was much higher
on PostgreSQL 9.2.1 (3 seconds vs. 3 minutes) than on 9.1.4 (1.3 seconds vs.
7 seconds) and both variants were slower on 9.2.1 than on 9.1.4. In the test
case below the behaviour is similar on both Postgres version.

The testcase was created in a way that it has similar constructs as the
real-word case.

The testcase is initialized with the following (on our hardware it runs cca
1 minute):
 TEST SETUP ===
set search_path=public, pg_catalog;

create table testtable
(
  ida character varying (10), idb character varying (10), idc character
varying (10),
  lvl numeric, val numeric
);
alter table testtable add constraint pk_testtable primary key (ida, idb,
idc, lvl);

create table testtable2
(
  ida character varying (10), idb character varying (10), idc character
varying (10),
  idd character varying (10),
  lvl numeric, val numeric
);
alter table testtable2 add constraint pk_testtable2 primary key (ida, idb,
idc, idd, lvl);

insert into testtable
select
  'a' || a.a, 'bb' || b.b, 'ccc' || c.c,
  (37*a.a + 53*b.b + 71*c.c + 101*lvl.lvl) % 512,
  ( 31*a.a + 17*b.b + 7*c.c + 11*lvl.lvl ) % 16
from
 generate_series(1, 5) a, generate_series(1, 50) b, generate_series(1, 500)
c,
 generate_series(1, 9) lvl;

insert into testtable2
select
  'a' || a.a, 'bb' || b.b, 'ccc' || 5*c.c, '' || d.d,
  (37*a.a + 53*b.b + 71*5*c.c + 101*3*lvl.lvl) % 512,
  (31*a.a + 17*b.b + 7*5*c.c + 11*3*lvl.lvl) % 3
from generate_series(1, 5) a, generate_series(1, 50) b, generate_series(1,
100) c,
  generate_series(1, 10) d,
  generate_series(1, 3) lvl;

create or replace view testview as
select t1.ida, t1.idb, t1.idc, t1.lvl, t1.val
from testtable t1
 join testtable2 t6
   on t6.ida=t1.ida and t6.idb=t1.idb and t6.idc=t1.idc and
t6.idd='1'
 and t6.lvl=
   (
  SELECT max(t7.lvl)
  from testtable2 t7
  where t7.ida=t6.ida and t7.idb=t6.idb and t7.idc=t6.idc
and t7.idd=t6.idd and t7.lvl<300
   )
where t1.lvl=
  (
SELECT max(t2.lvl)
from testtable t2
where t2.ida=t1.ida and t2.idb=t1.idb and t2.idc=t1.idc and t2.lvl<300
  )
  and (t1.ida, t1.idb, t1.idc) in
  ( select t3.ida, t3.idb, t3.idc
from testtable2 t3
  join testtable t5
on t5.ida=t3.ida and t5.idb=t3.idb and t5.idc=t3.idc
where t3.lvl=
(
  SELECT min(t4.lvl)
  from testtable2 t4
  where t4.ida=t3.ida and t4.idb=t3.idb and t4.idc=t3.idc and
t4.idd=t3.idd
   and t4.lvl<300
)
and t3.idd='8' and t3.val=0
  )
;

 END TEST SETUP ===

The following query:
  select * from testview where ida='a4';
has the following performance on our hardware:
-- pg 9.2.1: time~=1.2s, cost=119222.86..123174.62
-- pg 9.1.4: time~=1.1s, cost=105848.75..112083.82

After recreating the view from dump or simplier from pg_views:
  DO language plpgsql $$
  declare
  begin
execute ''::text ||
 (
   select 'CREATE OR REPLACE VIEW ' || viewname || ' AS ' ||definition
   from pg_views where schemaname='public' and viewname='testview'
 );
  end;
  $$

the same query
  select * from testview where ida='a4';
on the same hardware has the following performance:
-- pg 9.2.1: time~=2.5s, cost=578843.62..587364.78
-- pg 9.1.4: time~=2.5s, cost=513879.12..521655.37

Expected:
The performance and execution plan of the query should be the same when the
view is dumped and restored.

Regards,
Vaclav Juza



-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown

[Amit kapila]

On Thursday, October 11, 2012 8:22 PM Heikki Linnakangas wrote:
On 11.10.2012 13:17, Amit Kapila wrote:
>>> How does this look now?
>
>> The Patch is fine and test results are also fine.

>Ok, thanks. Committed.

   Thank you very much.

With Regards,
Amit Kapila.


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #7597: exception 0xC0000005

[Tom Lane]

I wrote:
> I see it too.  I think the crash probably only occurs on a 32-bit build
> (or one where you've disabled int8-pass-by-value anyway).  Looks like
> something's confused about cross-data-type comparisons --- this is an
> int4 vs int8 comparison, so it shouldn't be ending up at int8eq.

Argh ... the reason we're ending up at int8eq is that findPartialMatch
is using the wrong set of equality functions.  hashtable->cur_eq_funcs
correctly references int8eq, but what we want to be using is the
SubPlanState's cur_eq_funcs.  Amazing it took this long for anybody
to notice, because that's been wrong a long time.

regards, tom lane


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown

[Heikki Linnakangas]

On 11.10.2012 13:17, Amit Kapila wrote:

How does this look now?


The Patch is fine and test results are also fine.


Ok, thanks. Committed.

- Heikki


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #7597: exception 0xC0000005

[Tom Lane]

Heikki Linnakangas  writes:
> On 11.10.2012 14:42, Craig Ringer wrote:
>> No crash here on version() = PostgreSQL 9.1.5 on
>> x86_64-redhat-linux-gnu, compiled by gcc (GCC) 4.7.0 20120507 (Red Hat
>> 4.7.0-5), 64-bit

> I can reproduce this on my Windows box with the script Bo provided, with 
> a fresh checkout from git master branch. Stack trace looks like this:

I see it too.  I think the crash probably only occurs on a 32-bit build
(or one where you've disabled int8-pass-by-value anyway).  Looks like
something's confused about cross-data-type comparisons --- this is an
int4 vs int8 comparison, so it shouldn't be ending up at int8eq.

regards, tom lane


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #7597: exception 0xC0000005

[Heikki Linnakangas]

On 11.10.2012 14:42, Craig Ringer wrote:

On 10/11/2012 06:07 PM, Bo Thorbjørn Jensen wrote:

Self-contained case attached.


No crash here on version() = PostgreSQL 9.1.5 on
x86_64-redhat-linux-gnu, compiled by gcc (GCC) 4.7.0 20120507 (Red Hat
4.7.0-5), 64-bit


I can reproduce this on my Windows box with the script Bo provided, with 
a fresh checkout from git master branch. Stack trace looks like this:


.  0  Id: 92c.71c Suspend: 1 Teb: 07ff`fffde000 Unfrozen
Child-SP  RetAddr   Call Site
`0053eb80 0001`3f929a31 postgres!int8eq+0x12 
[c:\postgresql\src\backend\utils\adt\int8.c @ 205]
`0053ebb0 0001`3f5321a0 postgres!FunctionCall2Coll+0xa1 
[c:\postgresql\src\backend\utils\fmgr\fmgr.c @ 1326]
`0053efb0 0001`3f573bf3 postgres!execTuplesUnequal+0xe0 
[c:\postgresql\src\backend\executor\execgrouping.c @ 168]
`0053f020 0001`3f572ad2 postgres!findPartialMatch+0xa3 
[c:\postgresql\src\backend\executor\nodesubplan.c @ 592]
`0053f090 0001`3f57293b postgres!ExecHashSubPlan+0x172 
[c:\postgresql\src\backend\executor\nodesubplan.c @ 156]
`0053f0e0 0001`3f541ccb postgres!ExecSubPlan+0xcb 
[c:\postgresql\src\backend\executor\nodesubplan.c @ 79]
`0053f120 0001`3f545c89 postgres!ExecEvalNot+0x5b 
[c:\postgresql\src\backend\executor\execqual.c @ 2670]
`0053f170 0001`3f54995b postgres!ExecQual+0x79 
[c:\postgresql\src\backend\executor\execqual.c @ 5124]
`0053f1d0 0001`3f56fe71 postgres!ExecScan+0x1ab 
[c:\postgresql\src\backend\executor\execscan.c @ 195]
`0053f240 0001`3f539034 postgres!ExecSeqScan+0x21 
[c:\postgresql\src\backend\executor\nodeseqscan.c @ 116]
`0053f270 0001`3f535ca0 postgres!ExecProcNode+0x114 
[c:\postgresql\src\backend\executor\execprocnode.c @ 399]
`0053f2c0 0001`3f533dda postgres!ExecutePlan+0x60 
[c:\postgresql\src\backend\executor\execmain.c @ 1394]
`0053f300 0001`3f533bc5 postgres!standard_ExecutorRun+0x20a 
[c:\postgresql\src\backend\executor\execmain.c @ 313]
`0053f380 0001`3f78fe80 postgres!ExecutorRun+0x45 
[c:\postgresql\src\backend\executor\execmain.c @ 251]
`0053f3b0 0001`3f78facb postgres!PortalRunSelect+0x130 
[c:\postgresql\src\backend\tcop\pquery.c @ 946]
`0053f420 0001`3f78a368 postgres!PortalRun+0x28b 
[c:\postgresql\src\backend\tcop\pquery.c @ 789]
`0053f5c0 0001`3f789277 postgres!exec_simple_query+0x4b8 
[c:\postgresql\src\backend\tcop\postgres.c @ 1061]
`0053f700 0001`3f707b70 postgres!PostgresMain+0x7c7 
[c:\postgresql\src\backend\tcop\postgres.c @ 3978]
`0053f900 0001`3f7065ae postgres!BackendRun+0x270 
[c:\postgresql\src\backend\postmaster\postmaster.c @ 3672]
`0053f960 0001`3f59cba9 postgres!SubPostmasterMain+0x2be 
[c:\postgresql\src\backend\postmaster\postmaster.c @ 4174]


- Heikki


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #7597: exception 0xC0000005

[Craig Ringer]

On 10/11/2012 06:07 PM, Bo Thorbjørn Jensen wrote:

Self-contained case attached.


No crash here on  version() = PostgreSQL 9.1.5 on 
x86_64-redhat-linux-gnu, compiled by gcc (GCC) 4.7.0 20120507 (Red Hat 
4.7.0-5), 64-bit

Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown

[Amit Kapila]

  On Wednesday, October 10, 2012 9:15 PM Heikki Linnakangas wrote:
> On 04.10.2012 13:12, Amit kapila wrote:
> > Following changes are done to support replication timeout in sender as
> well as receiver:
> >
> > 1. One new configuration parameter wal_receiver_timeout is added to
> detect timeout at receiver task.
> > 2. Existing parameter replication_timeout is renamed to
> wal_sender_timeout.
> 
> Ok. The other option would be to have just one GUC, I'm open to
> bikeshedding on this one. On one hand, there's no reason the timeouts
> have to the same, so it would be nice to have separate settings, but on
> the other hand, I can't imagine a case where a single setting wouldn't
> work just as well.

I think for below case, they are required to be separate:

1. M1 (Master), S1 (Standby 1), S2 (Standby 2)
2. S1 is standby for M1, and S2 is standby for S1. Basically a simple case
of cascaded replication
3. M1 and S1 are on local network but S2 is placed at geographically
different location. 
  (what I want to say is n/w between M1-S1 is of good speed and S1-S2 is
very slow)
4. In above case, user might want to configure different timeouts for sender
and receiver on S1.

> Attached is an updated patch. I reverted the merging of message types
> and fixed a bunch of cosmetic issues. There was one bug: in the main
> loop of walreceiver, you send the "ping" message on every wakeup after
> enough time has passed since last reception. That means that if the
> server doesn't reply promptly, you send a new ping message every 100 ms
> (NAPTIME_PER_CYCLE), until it gets a reply. Walsender had the same
> issue, but it was not quite as sever there because the naptime was
> longer. Fixed that.

Thanks.

> 
> How does this look now?

The Patch is fine and test results are also fine.

With Regards,
Amit Kapila.



-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #7597: exception 0xC0000005

[Bo Thorbjørn Jensen]

Self-contained case attached.


crash2.sql
Description: crash2.sql

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #7597: exception 0xC0000005

[bo]

The following bug has been logged on the website:

Bug reference:  7597
Logged by:  Bo T Jensen
Email address:  b...@budget123.dk
PostgreSQL version: 9.1.6
Operating system:   windows 7 home premium 64
Description:

Ive managed to boil this down to a repeatable example on a test setup, but
it was found originally on windows server 2008 (64 bit).

pg_log:
2012-10-11 11:29:49 CEST LOG:  server process (PID 4400) was terminated by
exception 0xC005
2012-10-11 11:29:49 CEST HINT:  See C include file "ntstatus.h" for a
description of the hexadecimal value.
2012-10-11 11:29:49 CEST LOG:  terminating any other active server
processes
2012-10-11 11:29:49 CEST WARNING:  terminating connection because of crash
of another server process
2012-10-11 11:29:49 CEST DETAIL:  The postmaster has commanded this server
process to roll back the current transaction and exit, because another
server process exited abnormally and possibly corrupted shared memory.
2012-10-11 11:29:49 CEST HINT:  In a moment you should be able to reconnect
to the database and repeat your command.
2012-10-11 11:29:49 CEST WARNING:  terminating connection because of crash
of another server process
2012-10-11 11:29:49 CEST DETAIL:  The postmaster has commanded this server
process to roll back the current transaction and exit, because another
server process exited abnormally and possibly corrupted shared memory.
2012-10-11 11:29:49 CEST HINT:  In a moment you should be able to reconnect
to the database and repeat your command.
2012-10-11 11:29:49 CEST LOG:  all server processes terminated;
reinitializing
2012-10-11 11:29:59 CEST FATAL:  pre-existing shared memory block is still
in use
2012-10-11 11:29:59 CEST HINT:  Check if there are any old server processes
still running, and terminate them.

Offending sql looks like this:
select 1 from reference
where username = 'user1'
and (refid, '127.0.0.1', 'manager1') not in (select refid, ip, manager from
loguser);

Kind regards
Bo T Jensen



-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #7596: Problem with /etc/init.d/postgresql.9.x file

[Ashesh Vashi]

On Thu, Oct 11, 2012 at 2:59 PM,  wrote:

> The following bug has been logged on the website:
>
> Bug reference:  7596
> Logged by:  David PEYRIERES
> Email address:  david.peyrie...@meteo.fr
> PostgreSQL version: 9.1.4
> Operating system:   Red Hat
> Description:
>
Hi David,

How did you install postgresql?

--

Thanks & Regards,
Ashesh Vashi

>
> Hello.
> I found a little bug in /etc/init.d/postgresql-9.x file (ok in 8.4 - since
> 9.x versions ?).
> In my case, I've 5 databases on same server. Each database is start/stop
> with this file 'service postgresql9.x start'.
> Unfortunately, it uses only same file for status "pidfile:
> /var/run/postmaster-9.2.pid".
> In my case and with this configuration, I have only one file for all
> databases.
> So, I've modified this file on all servers :
>
> 1 - pidfile="/var/run/${NAME}.pid
>
> 2 - and case test :
> 
> case "$1" in
>   
>  status)
>status -p /var/run/postmaster-9.1.pid
> by
>status -p $pidfile
>
>
>
> Thanks for all.
>
>
>
>
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>

[BUGS] BUG #7596: Problem with /etc/init.d/postgresql.9.x file

[david . peyrieres]

The following bug has been logged on the website:

Bug reference:  7596
Logged by:  David PEYRIERES
Email address:  david.peyrie...@meteo.fr
PostgreSQL version: 9.1.4
Operating system:   Red Hat
Description:

Hello.
I found a little bug in /etc/init.d/postgresql-9.x file (ok in 8.4 - since
9.x versions ?).
In my case, I've 5 databases on same server. Each database is start/stop
with this file 'service postgresql9.x start'.
Unfortunately, it uses only same file for status "pidfile:
/var/run/postmaster-9.2.pid".
In my case and with this configuration, I have only one file for all
databases. 
So, I've modified this file on all servers : 

1 - pidfile="/var/run/${NAME}.pid

2 - and case test :

case "$1" in
  
 status)
   status -p /var/run/postmaster-9.1.pid
by 
   status -p $pidfile



Thanks for all.
 





-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs