From: | Lucas <lucas75(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Preventing deadlock on parallel backup |
Date: | 2016-09-08 22:07:11 |
Message-ID: | CAEWGB6_jv4QcJtuTdhpqkwrmWH1n+o0a89QuUWhkd4tDskV=tw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom,
Yes, it is what I mean. Is what pg_dump uses to get things synchronized. It
seems to me a clear marker that the same task is using more than one
connection to accomplish the one job.
Em 08/09/2016 6:34 PM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> escreveu:
> Lucas <lucas75(at)gmail(dot)com> writes:
> > The queue jumping logic can not use the distributed transaction id?
>
> If we had such a thing as a distributed transaction id, maybe the
> answer could be yes. We don't.
>
> I did wonder whether using a shared snapshot might be a workable proxy
> for that, but haven't pursued it.
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-09-08 22:07:48 | mdtruncate leaking fd.c handles? |
Previous Message | Alvaro Herrera | 2016-09-08 22:04:58 | Re: CVE-2016-1238 fix breaks (at least) pg_rewind tests |