On 30/10/2018 15:03, p.piero...@mmbb.it wrote:
> I thought that the “BEGIN/END” block was used to create new transactions
> and that each of them could be managed individually.
In PL/pgSQL, BEGIN/END just create syntactic blocks, they don't manage
transactions.
COMMIT and ROLLBACK manage top-leve
On Fri, Nov 02, 2018 at 11:56:58PM -0400, Tom Lane wrote:
> > On Thu, Nov 01, 2018 at 11:43:56AM -0400, Tom Lane wrote:
> >> Yeah, apparently we've passed a null OLD tuple to an RI_FKey_cascade_del
> >> trigger, which surely shouldn't happen. It'd be interesting to look at
> >> the set of trigger
Karsten Hilbert writes:
> On Fri, Nov 02, 2018 at 11:56:58PM -0400, Tom Lane wrote:
>> I was feeling baffled about this, but it suddenly occurs to me that maybe
>> the bug fixed in 040a1df61/372102b81 explains this.
> So, I guess I can work around the issue by the above
> manoeuvre and report bac
Aleš Zelený writes:
> Hello,
>
> we are suing logical replication on 10.4 and it now hangs. After
> some timeout it is retarted again, replaying 18GB of data and then
> hangs (while 7GB of wals remains to be proceeded).
Timeout...
Have a look at the 2 setting wal sender/receiver timeout and yo
On Sat, Nov 03, 2018 at 11:39:49AM -0400, Tom Lane wrote:
> Karsten Hilbert writes:
> > On Fri, Nov 02, 2018 at 11:56:58PM -0400, Tom Lane wrote:
> >> I was feeling baffled about this, but it suddenly occurs to me that maybe
> >> the bug fixed in 040a1df61/372102b81 explains this.
>
> > So, I gu
Hello,
we reached the exactly same problem after upgrading to PostgreSQL 11 - the
server crashed on a DELETE statement with a trigger. We also observed an
AFTER DELETE trigger receiving NULL values in OLD. Now I see the problem
seems to be solved (theoretically). Unfortunately, we are not able t
writes:
> we reached the exactly same problem after upgrading to PostgreSQL 11 - the
> server crashed on a DELETE statement with a trigger. We also observed an
> AFTER DELETE trigger receiving NULL values in OLD. Now I see the problem
> seems to be solved (theoretically). Unfortunately, we are not
I'd be grateful for some help. I am trying to move a large database from
PostgreSQL 9.6 on Centos 6 to a different server using PostgreSQL 11 on
Centos 7. I can't do a pg_dump because it always fails on the largest
table. So tried to do pb_basebackup and copy that to the new PG 11 server.
Except th
On 11/03/2018 02:57 PM, Charles Martin wrote:
I'd be grateful for some help. I am trying to move a large database from
PostgreSQL 9.6 on Centos 6 to a different server using PostgreSQL 11 on
Centos 7. I can't do a pg_dump because it always fails on the largest table.
What error message?
--
A
On 11/03/2018 02:19 PM, obo...@email.cz wrote:
Hello,
we reached the exactly same problem after upgrading to PostgreSQL 11 - the
server crashed on a DELETE statement with a trigger.We also observed an
AFTER DELETE trigger receiving NULL values in OLD. Now I see the problem
seems to be solved
On 11/3/18 12:57 PM, Charles Martin wrote:
I'd be grateful for some help. I am trying to move a large database from
PostgreSQL 9.6 on Centos 6 to a different server using PostgreSQL 11 on
Centos 7. I can't do a pg_dump because it always fails on the largest
table.
I would answer Ron's questi
When I do a pg_dump using PG 9.6, I got this:
pg_dump: Dumping the contents of table "docfile" failed: PQgetCopyData()
failed.
pg_dump: Error message from server: server closed the connection
unexpectedly
This probably means the server terminated abnormally
before or while processing the reques
On 11/3/18 3:47 PM, Charles Martin wrote:
When I do a pg_dump using PG 9.6, I got this:
pg_dump: Dumping the contents of table "docfile" failed:
PQgetCopyData() failed.
pg_dump: Error message from server: server closed the connection
unexpectedly
Is this error the client reporting?
Is thi
13 matches
Mail list logo
