On 2020-05-05 18:05, Robert Haas wrote:
This reminds me: I think that the issues in
http://postgr.es/m/ca+tgmoyafyrrdrz94p_qdt+1oong6smovbkghkvsftoncrf...@mail.gmail.com
should be considered here - we should guarantee that there's a
snapshot registered continuously from before the call to
SearchS
On 2020-05-04 20:57, Peter Eisentraut wrote:
New patch attached. I'll park it until PG14 opens.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Only as a homework, is this function completely useless?
ItemPointerData
systable_scan_next(Relation heapRelation,
Oid indexId,
bool indexOK,
Snapshot snapshot,
int nkeys, ScanKey key)
{
SysScanDesc scan;
HeapTuple htup;
ItemPointerData tid;
scan = systable_beginscan(heapRelation,
Em ter., 5 de mai. de 2020 às 18:11, Alvaro Herrera <
alvhe...@2ndquadrant.com> escreveu:
> On 2020-May-05, Ranier Vilela wrote:
>
> > And in that specific case, leaving resources blocked, which perhaps, in
> my
> > humble opinion, could be released quickly.
>
> I very much doubt that you can meas
On 2020-May-05, Ranier Vilela wrote:
> And in that specific case, leaving resources blocked, which perhaps, in my
> humble opinion, could be released quickly.
I very much doubt that you can measure any difference at all between
these two codings of the function.
I agree with the principle you me
Em ter., 5 de mai. de 2020 às 14:57, Robert Haas
escreveu:
> On Tue, May 5, 2020 at 1:43 PM Ranier Vilela wrote:
> > I see, the famous "cliché".
>
> By using the word cliché, and by putting it in quotes, you seem to
> suggest that you consider my argument dubious. However, I stand by it.
> Code
On Tue, May 5, 2020 at 1:43 PM Ranier Vilela wrote:
> I see, the famous "cliché".
By using the word cliché, and by putting it in quotes, you seem to
suggest that you consider my argument dubious. However, I stand by it.
Code shouldn't be changed without understanding the reasons behind the
curren
Em ter., 5 de mai. de 2020 às 14:29, Robert Haas
escreveu:
> On Tue, May 5, 2020 at 1:22 PM Ranier Vilela wrote:
> > Ok, so the question. If (3) is not safe, obvious we shouldn't use, and
> must call table_close, after systable_endscan.
> > Now (1) and (2), I would have no hesitation in using it
On Tue, May 5, 2020 at 1:22 PM Ranier Vilela wrote:
> Ok, so the question. If (3) is not safe, obvious we shouldn't use, and must
> call table_close, after systable_endscan.
> Now (1) and (2), I would have no hesitation in using it.
> I work with ERP, and throughout the time, the later, lock reso
Em ter., 5 de mai. de 2020 às 13:06, Robert Haas
escreveu:
> On Fri, May 1, 2020 at 5:32 PM Ranier Vilela wrote:
> > I can suggest improvements?
> >
> > 1. In case Object is cached, delay open_table until the last moment, for
> the row to be blocked as little as possible and close the table as q
On Fri, May 1, 2020 at 5:32 PM Ranier Vilela wrote:
> I can suggest improvements?
>
> 1. In case Object is cached, delay open_table until the last moment, for the
> row to be blocked as little as possible and close the table as quickly as
> possible.
> 2. In case Object is cached and the tuple i
-
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 0916fd395efe65f280c3acdb2172953adbb34afa Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Mon, 4 May 2020 20:22:44 +0200
Subject: [PATCH v2] Unify drop-by-O
Em sáb., 2 de mai. de 2020 às 05:01, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> escreveu:
> On 2020-05-01 23:31, Ranier Vilela wrote:
> > I can suggest improvements?
> >
> > 1. In case Object is cached, delay open_table until the last moment, for
> > the row to be blocked as little as po
On 2020-05-01 23:31, Ranier Vilela wrote:
I can suggest improvements?
1. In case Object is cached, delay open_table until the last moment, for
the row to be blocked as little as possible and close the table as
quickly as possible.
2. In case Object is cached and the tuple is invalid, do not o
Em sex., 1 de mai. de 2020 às 11:39, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> escreveu:
> [proposal for PG 14]
>
> There are a number of Remove${Something}ById() functions that are
> essentially identical in structure and only different in which catalog
> they are working on. This pat
On Fri, May 1, 2020 at 10:51 AM Pavel Stehule wrote:
> +1
+1 from me, too, but I have a few suggestions:
+DropGenericById(const ObjectAddress *object)
How about "Generic" -> "Object" or "Generic" -> "ObjectAddress"?
+ elog(ERROR, "cache lookup failed for %s entry %u",
+ elog(ERROR, "could not
pá 1. 5. 2020 v 16:39 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> [proposal for PG 14]
>
> There are a number of Remove${Something}ById() functions that are
> essentially identical in structure and only different in which catalog
> they are working on. This patch ref
http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From a4d3112c9385e3f489f9327e58c0995f51e003f4 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Fri, 1 May 2020 13:29:38 +0200
Subject: [PATCH] Unify drop-by-OID functions
There are a numbe
18 matches
Mail list logo
