Is there any one who help me what the architecture of an extension should looks
like in PostgreSQL database.
Regards,
Yonathan Misgan
Assistant Lecturer, @ Debre Tabor University
Faculty of Technology
Department of Computer Science
Studying MSc in Computer Sc
I have done the hard code. But my question is related to the concept how these
extension components working together as a system. For example what the use
case diagram looks like for my extension and also the other architectural view
of the extension should look like.
Regards,
On Wed, Nov 13, 2019 at 11:01 AM Amit Kapila wrote:
>
> On Wed, Nov 13, 2019 at 9:48 AM Amit Kapila wrote:
> >
> > Yeah, 0,2,3 and 4 sounds reasonable to me. Earlier, Dilip also got
> > confused with option 1.
> >
>
> Let me try to summarize the discussion on this point and see if others
> have
Ah, my stupid.
At Wed, 13 Nov 2019 16:34:49 +0900, Michael Paquier wrote
in
> On Tue, Nov 12, 2019 at 11:27:16AM -0800, Andres Freund wrote:
> > It seems to me it'd be better to just remove the "get a more recent
> > flush pointer" block - it doesn't seem to currently surve a meaningful
> > pur
On Wed, Nov 13, 2019 at 3:57 PM k.jami...@fujitsu.com
wrote:
>
> On Wed, Oct. 2, 2019 5:40 PM, Fujii Masao wrote:
> > On Tue, Jul 10, 2018 at 3:04 PM Michael Paquier wrote:
> > >
> > > On Thu, Jul 05, 2018 at 01:42:20AM +0900, Fujii Masao wrote:
> > > > TBH, I have no numbers measured by the test
On Wed, Nov 13, 2019 at 3:53 PM Andrey Lepikhov
wrote:
>
>
>
> 12.11.2019 12:41, Fujii Masao пишет:
> > Ok, I changed the patch that way.
> > Attached is the latest version of the patch.
> >
> > Regards,
>
> I did not see any problems in this version of the patch. The information
> displayed by pg
On Wed, Nov 13, 2019 at 12:57 AM Andres Freund wrote:
>
> On 2019-11-11 13:53:40 -0300, Alvaro Herrera wrote:
>
> > /* Get a more recent flush pointer. */
> > if (!RecoveryInProgress())
> > RecentFlushPtr = GetFlushRecPtr();
> > else
> > RecentFlushPtr
On Wed, Nov 13, 2019 at 6:13 AM Kyotaro Horiguchi
wrote:
>
> At Wed, 13 Nov 2019 09:48:19 +1300, Thomas Munro
> wrote in
> >
> > Here's the version I'd like to commit in a day or two, once the dust
> > has settled on the minor release. Instead of adding yet another copy
> > of that code, I just
On Wed, Nov 13, 2019 at 11:39 AM Masahiko Sawada
wrote:
>
> On Wed, 13 Nov 2019 at 12:43, Dilip Kumar wrote:
> >
> >
> > In this function, if ParallelVacuumIsActive, we perform the parallel
> > vacuum for all the index for which parallel vacuum is supported and
> > once that is over we finish vac
On Tue, Oct 29, 2019 at 5:23 PM btfujiitkp
wrote:
> Thomas Munro writes:
>> On Sun, Sep 1, 2019 at 5:04 PM Thomas Munro
>> wrote:
>>> Adding to CF.
>
>> Rebased. An OID clashed so re-roll the dice. Also spotted a typo.
>
I have some questions in this code.
Thanks for looking at the patch.
On Wed, Nov 13, 2019 at 11:39 AM Masahiko Sawada
wrote:
>
> On Wed, 13 Nov 2019 at 12:43, Dilip Kumar wrote:
> >
> > On Tue, Nov 12, 2019 at 5:31 PM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, 12 Nov 2019 at 20:29, Dilip Kumar wrote:
> > > >
> > > > On Tue, Nov 12, 2019 at 4:04 PM Masahiko S
On Wed, 13 Nov 2019 at 17:57, Amit Kapila wrote:
>
> On Wed, Nov 13, 2019 at 11:39 AM Masahiko Sawada
> wrote:
> >
> > On Wed, 13 Nov 2019 at 12:43, Dilip Kumar wrote:
> > >
> > >
> > > In this function, if ParallelVacuumIsActive, we perform the parallel
> > > vacuum for all the index for which
Hi,
Trivial patch:
- remove a gcc warning (since commit 7a0574b5)
expression which evaluates to zero treated as a null pointer constant of
type 'HeapTuple' (aka 'struct HeapTupleData *')
- always use "if (newtuple == NULL)" rather than mixing !newtuple and
newtuple == NULL
Regards
Didier
di
On Wed, Nov 13, 2019 at 3:55 PM Masahiko Sawada
wrote:
>
> On Wed, 13 Nov 2019 at 17:57, Amit Kapila wrote:
> >
> > On Wed, Nov 13, 2019 at 11:39 AM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, 13 Nov 2019 at 12:43, Dilip Kumar wrote:
> > > >
> > > >
> > > > In this function, if ParallelVacuu
(moved to -hackers)
On Tue, Nov 12, 2019 at 9:55 PM Andres Freund wrote:
>
> This last point is more oriented towards other PG developers: I wonder
> if we ought to display buffer statistics for plan time, for EXPLAIN
> (BUFFERS). That'd surely make it easier to discern cases where we
> e.g. acce
On Tue, Nov 12, 2019 at 5:41 AM imai.yoshik...@fujitsu.com
wrote:
>
> On Sat, Nov 9, 2019 at 1:36 PM, Julien Rouhaud wrote:
> >
> > I attach v3 patches implementing those counters.
>
> Thanks for updating the patch! Now I can see min/max/mean/stddev plan time.
>
>
> > Note that to avoid duplicatin
st 13. 11. 2019 v 11:39 odesílatel Julien Rouhaud
napsal:
> (moved to -hackers)
>
> On Tue, Nov 12, 2019 at 9:55 PM Andres Freund wrote:
> >
> > This last point is more oriented towards other PG developers: I wonder
> > if we ought to display buffer statistics for plan time, for EXPLAIN
> > (BUF
On Wed, 13 Nov 2019 at 18:49, Dilip Kumar wrote:
>
> On Wed, Nov 13, 2019 at 11:39 AM Masahiko Sawada
> wrote:
> >
> > On Wed, 13 Nov 2019 at 12:43, Dilip Kumar wrote:
> > >
> > > On Tue, Nov 12, 2019 at 5:31 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Tue, 12 Nov 2019 at 20:29, Dilip Ku
Thomas Munro writes:
> Hello hackers,
>
> From the advanced bikeshedding department: I'd like my psql
> transcripts to have the usual alignment, but be easier to copy and
> paste later without having weird prompt stuff in the middle. How
> about a prompt format directive %w that means "whitespac
On Wed, Nov 13, 2019 at 4:15 AM Bruce Momjian wrote:
>
> On Mon, Nov 11, 2019 at 05:37:30PM +0900, Michael Paquier wrote:
> > On Wed, Sep 11, 2019 at 06:30:22PM +0200, Julien Rouhaud wrote:
> > > The thing is that pg_stat_statements assigns a 0 queryid in the
> > > post_parse_analyze_hook to recog
On Mon, Nov 11, 2019 at 10:03:14AM +0100, Antonin Houska wrote:
> This looks good to me.
Actually, no, this is not good. I have been studying more the patch,
and after stressing more this code path with a cluster having
checksums enabled and shared_buffers at 1MB, I have been able to make
a coupl
On Thu, Oct 3, 2019 at 1:18 PM Dilip Kumar wrote:
>
As mentioned by me a few days back that the first patch in this series
is ready to go [1] (I am hoping Tomas will pick it up), so I have
started the review of other patches
Review/Questions on 0002-Immediately-WAL-log-assignments.patch
On Sat, Nov 2, 2019 at 8:00 PM Andres Freund wrote:
> I think we really ought to remove the difference behind macros. That is,
> for types that could be either, provide macros that fetch function
> arguments into local memory, independent of whether the argument is a
> byval or byref type. I.e. i
On Tue, Nov 12, 2019 at 09:51:33PM -0500, Bruce Momjian wrote:
> On Sun, Nov 10, 2019 at 01:01:17PM -0600, Magnus Hagander wrote:
> > On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian wrote:
> > We had this
> > discussion in relation to archive_command years ago, and decided on a
> > shel
On Wed, 13 Nov 2019 at 13:08, Bruce Momjian wrote:
> On Tue, Nov 12, 2019 at 09:51:33PM -0500, Bruce Momjian wrote:
> > On Sun, Nov 10, 2019 at 01:01:17PM -0600, Magnus Hagander wrote:
> > > On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian wrote:
>
> > > One of the main reasons there being to be eas
В письме от среда, 13 ноября 2019 г. 16:05:20 MSK пользователь Michael Paquier
написал:
Guys! Sorry for being away for so long. I did not have much opportunities to
pay my attention to postgres recently.
Thank you for introducing build_reloptions function. It is approximately the
direction I w
В письме от среда, 13 ноября 2019 г. 16:30:29 MSK пользователь Michael Paquier
написал:
> On Tue, Nov 12, 2019 at 01:50:03PM +0900, Michael Paquier wrote:
> > We have been through great length to have build_reloptions, so
> > wouldn't it be better to also have this code path do so? Sure you
> > n
Andres Freund writes:
> On 2019-11-12 18:20:56 -0500, Tom Lane wrote:
>> Ah, right. Probably because we need to insist on every column of an
>> execution-time tupdesc having a valid atttypid ... although I wonder,
>> is that really necessary?
> Yea, the stated reasoning is ExecTypeFromTL():
> [
so it sure looks like a gcc upgrade caused the failure. But it's not
clear wheter it's a compiler bug, or some undefined behaviour that
triggers the bug.
Fabien, any chance to either bisect or get a bit more information on
the backtrace?
There is a promising "keep_error_builds" option in bui
st 13. 11. 2019 v 7:13 odesílatel Pavel Stehule
napsal:
>
>
> st 13. 11. 2019 v 7:12 odesílatel Amit Kapila
> napsal:
>
>> On Tue, Nov 12, 2019 at 11:17 AM Amit Kapila
>> wrote:
>> >
>> > I am planning to commit this patch tomorrow unless I see more comments
>> > or interest from someone else t
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Thomas Munro writes:
>> From the advanced bikeshedding department: I'd like my psql
>> transcripts to have the usual alignment, but be easier to copy and
>> paste later without having weird prompt stuff in the middle. How
>>
Hi,
here's an updated patch, with some minor tweaks based on the review and
added tests (I ended up reworking those a bit, to make them more like
the existing ones).
There's also a new piece, dealing with functional dependencies. Until
now we did the same thing as for MCV lists - we picketd the
Hi all,
So after some thoughts I did the minimal patch (for now).
I corrected documentation for the following tools so that now, using
connection string for Postgres client applications is documented in
Postgres:
- clusterdb
- pgbench
- pg_dump
- pg_restore
- reindexdb
- vacuumdb
You'll find it e
Hi,
Surely that "s->nChildXids > 0", protects s->childXids to be NULL!
But, when we exchange the test (s->nChildXids > 0) by (s->childXids != NULL), I
believe we have the same protection, because, if "s->childXids" is not NULL,
"s->nChildXids" is > 0, naturally.
That way we can improve the funct
On 2019-Nov-12, Andres Freund wrote:
> > Anyway, I still like the idea of merging the void keyword in with
> > that.
>
> Hm. Any other opinions?
Although it feels very strange to me at first glance, one only has to
learn the trick once. My initial inclination was not to do it, but I'm
kinda +0.
Hi,
On 2019-11-13 16:18:46 +, Ranier Vilela wrote:
> Surely that "s->nChildXids > 0", protects s->childXids to be NULL!
> But, when we exchange the test (s->nChildXids > 0) by (s->childXids != NULL),
> I believe we have the same protection, because, if "s->childXids" is not
> NULL, "s->nChil
On Tue, Oct 30, 2018 at 1:17 AM Andres Freund wrote:
> The patch definitely is in a prototype stage. At the very least it needs
> a high-level comment somewhere, and some of the lower-level code needs
> to be cleaned up.
>
> One thing I wasn't happy about is how checksum internals have to absorb
>
"Why is this an improvement? And what setting are we removing? You mean
that we reset nChildXids, even if it's already 0? Hard to see how that
matters."
The orginal function, ever set ChildXidsm, nChildXidsa and maxChildXids.
See at lines 1594, 1595, 1596, even if it's already 0!
The test (nChild
On Wed, Nov 13, 2019 at 09:47:01AM -0500, Tom Lane wrote:
> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> > Thomas Munro writes:
> >> From the advanced bikeshedding department: I'd like my psql
> >> transcripts to have the usual alignment, but be easier to copy and
> >> p
Hi,
On this list we quote inline, and trim quoted messages to the relevant
parts...
On 2019-11-13 17:40:27 +, Ranier Vilela wrote:
> "Why is this an improvement? And what setting are we removing? You mean
> that we reset nChildXids, even if it's already 0? Hard to see how that
> matters."
>
On 11/13/19 12:49 PM, David Fetter wrote:
>> Or just define %w as meaning "whitespace of the same width as
>> PROMPT1". You couldn't use it *in* PROMPT1, then, but I see
>> no use-case for that anyway.
>
> +1 for doing it this way. Would it make more sense to error out if
> somebody tried to set
On 11/13/19 7:28 AM, Tomas Vondra wrote:
Hi,
here's an updated patch, with some minor tweaks based on the review and
added tests (I ended up reworking those a bit, to make them more like
the existing ones).
Thanks, Tomas, for the new patch set!
Attached are my review comments so far, in the
On 2019-Nov-13, David Fetter wrote:
> On Wed, Nov 13, 2019 at 09:47:01AM -0500, Tom Lane wrote:
> > > How about a circumfix directive (like the existing %[ ... %])
> > > that replaces everything inside with whitespace, but keeps the width?
> >
> > Or just define %w as meaning "whitespace of the
On Wed, Nov 13, 2019 at 03:06:08PM -0300, Alvaro Herrera wrote:
> On 2019-Nov-13, David Fetter wrote:
>
> > On Wed, Nov 13, 2019 at 09:47:01AM -0500, Tom Lane wrote:
>
> > > > How about a circumfix directive (like the existing %[ ... %])
> > > > that replaces everything inside with whitespace, bu
On 2019-Oct-25, Tomas Vondra wrote:
> The attached patch trivially fixes that by adding a memory context
> tracking all the temporary data, and then just deletes it as a whole at
> the end of the function. This significantly reduces the memory usage for
> me, not sure it's 100% correct.
FWIW we a
On 2019-Nov-13, David Fetter wrote:
> On Wed, Nov 13, 2019 at 03:06:08PM -0300, Alvaro Herrera wrote:
> > On 2019-Nov-13, David Fetter wrote:
> >
> > > On Wed, Nov 13, 2019 at 09:47:01AM -0500, Tom Lane wrote:
> >
> > > > > How about a circumfix directive (like the existing %[ ... %])
> > > > >
On Mon, Nov 11, 2019 at 2:12 PM Andres Freund wrote:
> Hm. I feel like there's plenty reasons to get a snapshot in extensions -
> there's plenty APIs one cannot really call without doing so?
Sure, I don't disagree with that.
> What I'm
> worried about is not primarily that GetSnapshotData() is b
On Mon, Oct 28, 2019 at 7:21 PM Andres Freund wrote:
> Because that's the normal way to represent something non-existing for
> formats like json? There's a lot of information we show always for !text
> format, even if not really applicable to the context (e.g. Triggers for
> select statements). I
Alvaro Herrera writes:
> On 2019-Oct-25, Tomas Vondra wrote:
>> The attached patch trivially fixes that by adding a memory context
>> tracking all the temporary data, and then just deletes it as a whole at
>> the end of the function. This significantly reduces the memory usage for
>> me, not sure
On Tue, Nov 12, 2019 at 6:22 PM Peter Geoghegan wrote:
> * Disabled deduplication in system catalog indexes by deeming it
> generally unsafe.
I (continue to) think that deduplication is a terrible name, because
you're not getting rid of the duplicates. You are using a compressed
representation of
Hi,
On 2019-11-13 12:26:34 -0500, Robert Haas wrote:
> TL;DR: I'm not sure that we need 0001; I propose to commit 0002; and I
> have some concerns about 0003 and am interested in working further on
> it.
Thanks for looking at the patch!
> 0001 changes the StartBackgroundWorker so that the SIGIN
On 11/13/19 8:08 AM, Bruce Momjian wrote:
>
>>
>> Also, why was this patch posted without any discussion of these issues?
>> Shouldn't we ideally discuss the API first?
This is a very tiny patch. I don't think it's unusual to post such
things without prior discussion. I would agree with your po
On Wed, Nov 13, 2019 at 11:33 AM Robert Haas wrote:
> On Tue, Nov 12, 2019 at 6:22 PM Peter Geoghegan wrote:
> > * Disabled deduplication in system catalog indexes by deeming it
> > generally unsafe.
>
> I (continue to) think that deduplication is a terrible name, because
> you're not getting rid
didier writes:
> Trivial patch:
> - remove a gcc warning (since commit 7a0574b5)
> expression which evaluates to zero treated as a null pointer constant of
> type 'HeapTuple' (aka 'struct HeapTupleData *')
Hmm, the initializations "HeapTuple newtuple = false" are certainly
bogus-looking and
On Wed, Nov 13, 2019 at 03:58:38PM -0300, Alvaro Herrera wrote:
> On 2019-Nov-13, David Fetter wrote:
>
> > On Wed, Nov 13, 2019 at 03:06:08PM -0300, Alvaro Herrera wrote:
> > > On 2019-Nov-13, David Fetter wrote:
> > >
> > > > On Wed, Nov 13, 2019 at 09:47:01AM -0500, Tom Lane wrote:
> > >
> >
On 2019-Nov-13, Tom Lane wrote:
> (BTW, a different question one could ask is exactly why
> RelationBuildPartitionDesc is so profligate of leaked memory.)
The original partitioning code (f0e44751d717) decided that it didn't
want to bother with adding a "free" routine for PartitionBoundInfo
struct
Hi,
On 2019-11-13 14:29:07 -0500, Robert Haas wrote:
> On Mon, Oct 28, 2019 at 7:21 PM Andres Freund wrote:
> > Because that's the normal way to represent something non-existing for
> > formats like json? There's a lot of information we show always for !text
> > format, even if not really applica
On Wed, Nov 13, 2019 at 01:20:43PM +, Simon Riggs wrote:
On Wed, 13 Nov 2019 at 13:08, Bruce Momjian wrote:
On Tue, Nov 12, 2019 at 09:51:33PM -0500, Bruce Momjian wrote:
> On Sun, Nov 10, 2019 at 01:01:17PM -0600, Magnus Hagander wrote:
> > On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian wr
On Wed, Nov 13, 2019 at 02:48:01PM -0500, Andrew Dunstan wrote:
On 11/13/19 8:08 AM, Bruce Momjian wrote:
Also, why was this patch posted without any discussion of these issues?
Shouldn't we ideally discuss the API first?
This is a very tiny patch. I don't think it's unusual to post such
Hi,
On Wed, Nov 13, 2019 at 8:52 PM Tom Lane wrote:
>
> didier writes:
> > Trivial patch:
> > - remove a gcc warning (since commit 7a0574b5)
> > expression which evaluates to zero treated as a null pointer constant of
> > type 'HeapTuple' (aka 'struct HeapTupleData *')
>
> Hmm, the initiali
didier writes:
> clang -E output before 7a0574b5
> HeapTuple newtuple = 0;
> with 7a0574b5
> HeapTuple newtuple = ((bool) 0);
Hm, did you re-run configure after 7a0574b5? If you didn't, it would
have gone through the not-stdbool.h path in c.h, which might account
for this. It's a good catch tho
On Mon, Oct 28, 2019 at 11:11 AM Anastasia Lubennikova
wrote:
> At first I implemented bitwise as default, because it is more common .
> Though, I agree that it's essential to avoid false positives here.
> The new version of the patch is attached. I also updated pg_dump.
>
> A few more open questi
I realized only today that if role A is a member of role B,
A can ALTER and DROP objects owned by B.
I don't have a problem with that, but the documentation seems to
suggest otherwise. For example, for DROP TABLE:
Only the table owner, the schema owner, and superuser can drop a table.
Should
On 2019-Nov-13, Alvaro Herrera wrote:
> On 2019-Nov-13, Tom Lane wrote:
>
> > (BTW, a different question one could ask is exactly why
> > RelationBuildPartitionDesc is so profligate of leaked memory.)
>
> The original partitioning code (f0e44751d717) decided that it didn't
> want to bother with
Laurenz Albe writes:
> I realized only today that if role A is a member of role B,
> A can ALTER and DROP objects owned by B.
> I don't have a problem with that, but the documentation seems to
> suggest otherwise. For example, for DROP TABLE:
>Only the table owner, the schema owner, and supe
On 11/11/19 1:41 PM, Tom Lane wrote:
I happened to notice that find_expr_references_walker has not
been taught anything about TableFunc nodes, which means it will
miss the type and collation OIDs embedded in such a node.
This can be demonstrated to be a problem by the attached script,
which w
Hi,
On 2019-10-25 12:37:38 +0100, Peter Geoghegan wrote:
> On Thu, Oct 24, 2019 at 10:10 PM Andres Freund wrote:
> > Here's a first stab at getting the coverage of tuplesort.c to a
> > satisfying level. There's still bits uncovered, but that's largely
> > either a) trace_sort related b) hopefull
On Wed, Nov 13, 2019 at 03:00:03PM -0800, Mark Dilger wrote:
On 11/11/19 1:41 PM, Tom Lane wrote:
I happened to notice that find_expr_references_walker has not
been taught anything about TableFunc nodes, which means it will
miss the type and collation OIDs embedded in such a node.
This can be
Hi
>From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru]
>>> From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru]
>>>
>>> New version of builtin connection pooler fixing handling messages of
>>> extended protocol.
>>>
>> 2. When proxy_port is a bit large (perhaps more than 2^15), c
On 11/13/19 4:46 PM, Tomas Vondra wrote:
On Wed, Nov 13, 2019 at 03:00:03PM -0800, Mark Dilger wrote:
On 11/11/19 1:41 PM, Tom Lane wrote:
I happened to notice that find_expr_references_walker has not
been taught anything about TableFunc nodes, which means it will
miss the type and collatio
Mark Dilger writes:
> On 11/11/19 1:41 PM, Tom Lane wrote:
>> I happened to notice that find_expr_references_walker has not
>> been taught anything about TableFunc nodes, which means it will
>> miss the type and collation OIDs embedded in such a node.
> I can consistently generate errors like the
Hi,
On 2019-11-13 15:58:28 +0900, Michael Paquier wrote:
> On Tue, Nov 12, 2019 at 10:33:16AM -0800, Andres Freund wrote:
> > On 2019-11-12 16:25:06 +0100, Daniel Gustafsson wrote:
> >> On 11 Nov 2019, at 09:32, Michael Paquier wrote:
> >>
> >>> This part has resulted in 75c1921, and we could ju
On Wed, Nov 13, 2019 at 09:17:03PM +0900, Michael Paquier wrote:
> Actually, no, this is not good. I have been studying more the patch,
> and after stressing more this code path with a cluster having
> checksums enabled and shared_buffers at 1MB, I have been able to make
> a couple of page's LSNs
On Wed, Nov 13, 2019 at 05:02:24PM +0300, Nikolay Shaplov wrote:
> I did not read that thread yet, when I sent v3 patch.
> build_reloptions is a good stuff and we should use it for sure.
>
> I've looked at yours v4 version of the patch, it is exactly what we need
> here.
> Can we commit it as it
On Wed, Nov 13, 2019 at 5:55 PM Amit Kapila wrote:
>
> On Thu, Oct 3, 2019 at 1:18 PM Dilip Kumar wrote:
> >
>
> As mentioned by me a few days back that the first patch in this series
> is ready to go [1] (I am hoping Tomas will pick it up), so I have
> started the review of other patches
>
> Rev
On Wed, Nov 13, 2019 at 9:51 AM Dilip Kumar wrote:
>
> + /*
> + * Since parallel workers cannot access data in temporary tables, parallel
> + * vacuum is not allowed for temporary relation.
> + */
> + if (RelationUsesLocalBuffers(onerel) && params->nworkers >= 0)
> + {
> + ereport(WARNING,
> + (er
On Wed, Nov 13, 2019 at 04:05:20PM +0900, Michael Paquier wrote:
> On Wed, Nov 13, 2019 at 02:29:49PM +0900, Amit Langote wrote:
> > On Wed, Nov 13, 2019 at 2:18 PM Michael Paquier wrote:
> >> There could be an argument for keeping
> >> GET_STRING_RELOPTION actually which is still useful to get a
st 13. 11. 2019 v 15:34 odesílatel Pavel Stehule
napsal:
>
>
> st 13. 11. 2019 v 7:13 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> st 13. 11. 2019 v 7:12 odesílatel Amit Kapila
>> napsal:
>>
>>> On Tue, Nov 12, 2019 at 11:17 AM Amit Kapila
>>> wrote:
>>> >
>>> > I am planning to commit this p
At Wed, 13 Nov 2019 20:57:04 +0100, David Fetter wrote in
> On Wed, Nov 13, 2019 at 03:58:38PM -0300, Alvaro Herrera wrote:
> > On 2019-Nov-13, David Fetter wrote:
> >
> > > On Wed, Nov 13, 2019 at 03:06:08PM -0300, Alvaro Herrera wrote:
> > > > On 2019-Nov-13, David Fetter wrote:
> > > >
> > >
On Thu, Nov 14, 2019 at 9:37 AM Dilip Kumar wrote:
>
> On Wed, Nov 13, 2019 at 5:55 PM Amit Kapila wrote:
> >
> > On Thu, Oct 3, 2019 at 1:18 PM Dilip Kumar wrote:
> > >
> >
> > As mentioned by me a few days back that the first patch in this series
> > is ready to go [1] (I am hoping Tomas will
On Thu, Nov 14, 2019 at 11:43 AM Pavel Stehule wrote:
>
> st 13. 11. 2019 v 15:34 odesílatel Pavel Stehule
> napsal:
>>
>>
>> here it is. It's based on Filip Rembialkowski's patch if I remember correctly
>
>
> have I this patch assign to next commitfest or you process it in this
> commitfest?
>
On Thu, Nov 14, 2019 at 12:14 PM Amit Kapila wrote:
>
> On Thu, Nov 14, 2019 at 11:43 AM Pavel Stehule
> wrote:
> >
> > st 13. 11. 2019 v 15:34 odesílatel Pavel Stehule
> > napsal:
> >>
> >>
> >> here it is. It's based on Filip Rembialkowski's patch if I remember
> >> correctly
> >
> >
> > ha
čt 14. 11. 2019 v 7:44 odesílatel Amit Kapila
napsal:
> On Thu, Nov 14, 2019 at 11:43 AM Pavel Stehule
> wrote:
> >
> > st 13. 11. 2019 v 15:34 odesílatel Pavel Stehule <
> pavel.steh...@gmail.com> napsal:
> >>
> >>
> >> here it is. It's based on Filip Rembialkowski's patch if I remember
> corre
For now I replay for the above. Oh sorry, I was wrong about the condition.
The error occurred under following condition.
- port = 32768
- proxy_port = 6543
- $ psql postgres -p 6543
$ bin/pg_ctl start -D data
waiting for server to start
LOG: starting PostgreSQL 13devel on x86_64-pc-linux
On Wed, Nov 13, 2019 at 04:26:53PM +0300, Nikolay Shaplov wrote:
> I've changed the patch to use build_reloptions function and again propose it
> to the commitfest.
Thanks for the new patch. I have not reviewed the patch in details,
but I have a small comment.
> +#define SpGistGetFillFactor(rel
85 matches
Mail list logo
