Hello again,
since we've had similar trouble without own server sockets, I had a deeper
look into this one.
The trouble is that under AIX, once you have bound an IP V4 socket to a
port, it seems you can't bind a IP V6 socket to the same port. The other
way round works. And AIX seems to return
Excerpts from rikard.pavelic's message of sáb feb 25 10:23:18 -0300 2012:
> But I would expect second alter to pass and enforcing not null and default
> when adding this column in table and not enforcing not null and default when
> adding into composite type for another table.
>
> Is this by des
Curd Reinert writes:
> The trouble is that under AIX, once you have bound an IP V4 socket to a
> port, it seems you can't bind a IP V6 socket to the same port. The other
> way round works. And AIX seems to return addrinfo with IP V4 addresses in
> front.
Seems like that is a bug to file with
Ryan Lowe writes:
> Thanks for all the responses, but I think I'm being unclear here. Let's
> walk through this case step-by-step. I start with a happy instance of
> Postgres:
This example does not have anything to do with the actual behavior of
Postgres, at least not on any system I know about
The following bug has been logged on the website:
Bug reference: 6498
Logged by: kanishka
Email address: nish2...@gmail.com
PostgreSQL version: 9.0.6
Operating system: Linux 2.6.41.4-1.fc15.i686 / fedora 15
Description:
here is an example of what i believe the system
Thanks for all the responses, but I think I'm being unclear here. Let's
walk through this case step-by-step. I start with a happy instance of
Postgres:
% pstree -anpcul postgres
postgres,1944 -D /data/pgsql # Main process
├─postgres,1948 # Logger process
├─postgres,
nish2...@gmail.com writes:
> this doesn't loop infinitely:
> insert into acyc values ('a','b') ,('b','c');
> with recursive paths as (
> select frm, too, 1 as lvl from acyc
> union all
> select fnd.frm, a.too, lvl + 1 from acyc a join paths fnd on fnd.too =
> a.frm ) select * from paths;
Why w
On Feb 29, 2012, at 9:26 AM, Ryan Lowe wrote:
> Thanks for all the responses, but I think I'm being unclear here.
The point Tom was making is that this is indistinguishable from the scenario:
1. Client sends commit.
2. Server successfully commits data.
3. Server starts to write response.
4. Net
Christophe Pettus writes:
> On Feb 29, 2012, at 9:26 AM, Ryan Lowe wrote:
>> Thanks for all the responses, but I think I'm being unclear here.
> The point Tom was making is that this is indistinguishable from the scenario:
> 1. Client sends commit.
> 2. Server successfully commits data.
> 3. Ser
On Feb 29, 2012, at 1:15 PM, Tom Lane wrote:
> But there's a quite separate question as to
> whether the behavior Ryan is claiming for a pre-commit crash is actually
> possible. I don't believe it, and I failed to reproduce his test
> scenario.
Did you check it with killing the postmaster (as R
Christophe Pettus writes:
> On Feb 29, 2012, at 1:15 PM, Tom Lane wrote:
>> But there's a quite separate question as to
>> whether the behavior Ryan is claiming for a pre-commit crash is actually
>> possible. I don't believe it, and I failed to reproduce his test
>> scenario.
> Did you check it
> You might wish to believe that you can ignore the problem, but you can't.
> No matter what Postgres does or doesn't do, external issues such as
> network failures can create the problem of a transaction possibly being
> committed while the client remains in doubt whether it happened or not.
I th
but {5} union {5} = {5, 5}
so ('a', 'c', 2) union all ('a','c', 2) = {('a', 'c', 2), ('a', 'c', 2)}
the second ('a', 'c', 2) should result from joining the latest working
table in paths which includes {('a', 'b', 1), ('b', 'c', 1), ('a',
'c', 2)} with {('a','b'), ('b', 'c')} specifically ('a', 'b'
13 matches
Mail list logo
