Re: Ref: BUG#1321: SSL error: sslv3 alert handshake failure - Mailing list pgsql-bugs

I have the answer for one of the two questions i asked:

(a) all clients for a server will have same postgresql.key and .crt.

(b) I still don't know:
Machine A needs to talk (replicate for example: pgreplicator) to
machine B. They both are servers on the same network with certificates
from the same CA. Do they both might need to authenticate, or in other
words is it true that:
(1) Machine A has to send its postgresql (.key,.crt) to Machine B and
(2) Machine B has to send its postgresql (.key,.crt) to Machine A.

thanks,
vish

On 8/25/05, vishal saberwal <vishalsaberwal@gmail.com> wrote:
> thanks tom for the list on updates on 8.0.4,
>=20
> quick questions,
>=20
> Do all my clients have to have same postgresql.key and postgresql.crt,
> or can i have different keys and certificates on each client
> authenticating with the same server?
>=20
> Also, in case of multi master replication with multiple servers, what
> keys they need to have in common?
>=20
> thanks,
> vish
>=20
> On 8/24/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > vishal saberwal <vishalsaberwal@gmail.com> writes:
> > > Guess i can stay on 8.0.1 until we get 8.0.4 ... (is it right for me
> > > to ask what data-loss you are talking about) ...
> >
> > Yeah, they're all documented in the pgsql-committers archives.
> > Let's see...
> >
> > 2005-08-19 20:39  tgl
> >
> >         * src/: backend/access/heap/heapam.c, backend/commands/async.c,
> >         backend/commands/trigger.c, backend/commands/vacuum.c,
> >         backend/executor/execMain.c, backend/utils/time/tqual.c,
> >         include/access/heapam.h, include/access/htup.h,
> >         include/executor/executor.h, include/utils/tqual.h: Repair prob=
lems
> >         with VACUUM destroying t_ctid chains too soon, and with
> >         insufficient paranoia in code that follows t_ctid links.  (We m=
ust
> >         do both because even with VACUUM doing it properly, the
> >         intermediate state with a dangling t_ctid link is visible
> >         concurrently during lazy VACUUM, and could be seen afterwards if
> >         either type of VACUUM crashes partway through.) Also try to imp=
rove
> >         documentation about what's going on.  Patch is a bit bulky beca=
use
> >         passing the XMAX information around required changing the APIs =
of
> >         some low-level heapam.c routines, but it's not conceptually very
> >         complicated.  Per trouble report from Teodor and subsequent
> >         analysis.  This needs to be back-patched, but I'll do that after
> >         8.1 beta is out.
> >
> > 2005-06-25 18:47  tgl
> >
> >         * doc/src/sgml/backup.sgml, src/backend/commands/dbcommands.c
> >         (REL8_0_STABLE), doc/src/sgml/backup.sgml,
> >         src/backend/commands/dbcommands.c: Force a checkpoint before
> >         committing a CREATE DATABASE command.  This should fix the rece=
nt
> >         reports of "index is not a btree" failures, as well as preventi=
ng a
> >         more obscure race condition involving changes to a template
> >         database just after copying it with CREATE DATABASE.
> >
> > 2005-05-31 15:10  tgl
> >
> >         * src/backend/access/transam/: xlog.c (REL7_3_STABLE), xlog.c
> >         (REL7_4_STABLE), xlog.c (REL7_2_STABLE), xlog.c (REL8_0_STABLE),
> >         xlog.c: Add test to WAL replay to verify that xl_prev points ba=
ck
> >         to the previous WAL record; this is necessary to be sure we
> >         recognize stale WAL records when a WAL page was only partially
> >         written during a system crash.
> >
> > I seem to recall another one, but am not seeing it in the logs right
> > now.  There are also the usual quota of plain old crashing bugs.
> >
> >                         regards, tom lane
> >
>