Hi,
I'm trying to use the SPI to save the executed plans in the ExecutorEnd. When
the plan involves multiple workers, the insert operations would trigger an
error: cannot execute INSERT during a parallel operation.
I wonder if there's a different hook I can use when there's a gather node? or
On Thu, Apr 11, 2019 at 6:06 AM Rafia Sabih wrote:
> Reading about it reminds me of this work -- TAG column storage(
> http://www09.sigmod.org/sigmod/record/issues/0703/03.article-graefe.pdf ).
> Isn't this storage system inspired from there, with TID as the TAG?
>
> It is not referenced here so
On Sat, Apr 13, 2019 at 04:27:56PM -0400, Tom Lane wrote:
> Tomas Vondra writes:
> > On Thu, Apr 11, 2019 at 02:55:10PM +0500, Ibrar Ahmed wrote:
> >> On Thu, Apr 11, 2019 at 2:44 PM Erikjan Rijkers wrote:
> Is it possible to have commit-message or at least git hash in
> commitfest. It
On 04/13/19 15:56, Tomas Vondra wrote:
> I think it might be useful to actually have that directly in the CF app,
> not just in the thread. There would need to a way to enter multiple
> hashes, because patches often have multiple pieces.
The CF app already recognizes (some) attachments in the
On Wed, Apr 10, 2019 at 08:09:34PM -0300, Euler Taveira wrote:
Em qua, 10 de abr de 2019 às 16:33, Alvaro Herrera
escreveu:
On 2019-Apr-10, Bruce Momjian wrote:
> On Thu, Apr 11, 2019 at 04:14:11AM +1200, David Rowley wrote:
> > I still think we should start with a warning about
Hello devs,
The attached patch implements a new SHOW_ALL_RESULTS option for psql,
which shows all results of a combined query (\;) instead of only the last
one.
This solves a frustration that intermediate results were hidden from view
for no good reason that I could think of.
For that,
Tomas Vondra writes:
> On Thu, Apr 11, 2019 at 02:55:10PM +0500, Ibrar Ahmed wrote:
>> On Thu, Apr 11, 2019 at 2:44 PM Erikjan Rijkers wrote:
Is it possible to have commit-message or at least git hash in
commitfest. It will be very easy to track commit against commitfest
item.
On Thu, Apr 11, 2019 at 02:55:10PM +0500, Ibrar Ahmed wrote:
On Thu, Apr 11, 2019 at 2:44 PM Erikjan Rijkers wrote:
On 2019-04-11 11:36, Ibrar Ahmed wrote:
> Hi,
>
> Is it possible to have commit-message or at least git hash in
> commitfest. It will be very easy to track commit against
On Thu, Apr 11, 2019 at 11:25:29AM +0200, Chris Travers wrote:
On Wed, Apr 10, 2019 at 5:21 PM Andres Freund wrote:
Hi,
On April 10, 2019 8:13:06 AM PDT, Alvaro Herrera
wrote:
>On 2019-Mar-31, Darafei "Komяpa" Praliaskouski wrote:
>
>> Alternative point of "if your
I started looking at this the other night but I see Magnus beat me in
committing it...
On Fri, Apr 12, 2019 at 8:18 AM Magnus Hagander wrote:
> On Sun, Apr 7, 2019 at 6:28 PM Julien Rouhaud wrote:
>> Thanks for looking it it!
>> On Sun, Apr 7, 2019 at 4:36 PM Magnus Hagander wrote:
>> >
>> >
Andreas Karlsson wrote:
> The Debian packagers already use pg_createcluster for their script which
> wraps initdb, and while pg_initdb is a bit misleading (it creates a
> cluster rather than a database) it is not that bad.
But that renaming wouldn't achieve anything in relation to the
Amit Langote writes:
> On Sat, Apr 13, 2019 at 4:47 AM Tom Lane wrote:
>> I concluded that that's not parenthetical but pretty relevant...
> Hmm, do you mean we should grow the same "keep_" logic for
> rd_partcheck as we have for rd_partkey and rd_partdesc? I don't see
> it in the updated
Thanks for the updated patch.
On Sat, Apr 13, 2019 at 4:47 AM Tom Lane wrote:
> Robert Haas writes:
> > As a parenthetical note, I observe that relcache.c seems to know
> > almost nothing about rd_partcheck. rd_partkey and rd_partdesc both
> > have handling in RelationClearRelation(), but
I wrote:
> Whether it would be nice or not is irrelevant to my point: this code
> doesn't work, and it's unlikely that it would ever be part of a working
> solution. I don't think there's any way that it'd be sane to attempt
> catalog accesses during RelationCacheInitializePhase3.
BTW, to
Andres Freund writes:
> On 2019-04-12 14:17:11 -0400, Tom Lane wrote:
>> While looking at the pending patch to clean up management of
>> rd_partcheck, I noticed that RelationCacheInitializePhase3 has code that
>> purports to reload rd_partkey and rd_partdesc, but none for rd_partcheck.
>>
On Sat, Apr 13, 2019 at 3:36 PM Tomas Vondra
wrote:
> On Fri, Apr 12, 2019 at 08:56:35PM +0200, Fred .Flintstone wrote:
> >So there is no regression potential.
> >
>
> I fail to understand how you came to this conclusion? Andreas pointed
> out Debian already uses pg_createcluster, so there
Please don't top post. It makes it unnecessarily difficult to follow the
discussion. See https://wiki.postgresql.org/wiki/Mailing_Lists
On Fri, Apr 12, 2019 at 08:56:35PM +0200, Fred .Flintstone wrote:
So there is no regression potential.
I fail to understand how you came to this conclusion?
On 27/03/2019 22:28, Peter Eisentraut wrote:
> On 2019-03-26 16:28, Euler Taveira wrote:
>> I don't remember why we didn't consider table without stats to be
>> ANALYZEd. Isn't it the case to fix autovacuum? Analyze
>> autovacuum_count + vacuum_count = 0?
>
> When the autovacuum system was
18 matches
Mail list logo
