Rebased over b663a4136 --- no substantive changes, just keeping
the cfbot happy.
regards, tom lane
diff --git a/contrib/postgres_fdw/deparse.c b/contrib/postgres_fdw/deparse.c
index 6faf499f9a..c38e2419d5 100644
--- a/contrib/postgres_fdw/deparse.c
+++ b/contrib/postgres_f
On Thu, Jan 21, 2021 at 11:12:56AM +0800, Julien Rouhaud wrote:
>
> There was a conflict with a3dc926009be8 (Refactor option handling of
> CLUSTER, REINDEX and VACUUM), so rebased version attached. No other
> changes included yet.
New conflict, v3 attached.
>From 63afe51453d4413ad7e73c66268e6ff1
Hi Hackers,
When using psql I found there's no tab completion for upper character inputs.
It's really inconvenient sometimes so I try to fix this problem in the attached
patch.
Here is the examples to show what this patch can do.
Action:
1. connect the db using psql
2. input SQL command
3. en
On Sat, Feb 6, 2021 at 7:40 PM Andres Freund wrote:
> Looks like a mistake on my part... Probably a rename regex that somehow
> went wrong - I went back and forth on those names way too many
> times. Want me to push the fix?
Yes, please do. I could do it myself, but better that you do it
yourself
Hi,
On 2021-02-06 12:27:30 -0800, Peter Geoghegan wrote:
> Why is GlobalVisIsRemovableFullXid() not named
> GlobalVisCheckRemovableFullXid() instead? ISTM that that name makes
> much more sense, since it is what I'd expect for a function that is
> the "Full XID equivalent" of GlobalVisCheckRemovab
On Sat, Feb 6, 2021 at 2:10 AM Petr Jelinek
wrote:
>
> Hi,
>
> Some minor comments about code:
>
> > + else if (res->status == WALRCV_ERROR && missing_ok)
> > + {
> > + /* WARNING. Error, but missing_ok = true. */
> > + ereport(WARNIN
On Fri, Feb 5, 2021 at 11:01 PM Fujii Masao wrote:
>
>
>
> On 2021/02/05 16:52, Kasahara Tatsuhito wrote:
> > Hi,
> >
> > The following is written in the comments of PQputCopyEnd().
> >
> > (snip)
> > * Returns 1 if successful, 0 if data could not be sent (only possible
> > * in nonblock mod
On Sat, Feb 06, 2021 at 10:39:53PM +0100, Tomas Vondra wrote:
> Copying this info in index_concurrently_swap seems a bit strange - we're
> copying other stuff there, but this is modifying something we've already
> copied before. I understand why we do it there to make this backpatchable,
> but mayb
After poking around a bit more, I notice that the hasRecursive flag
really ought to get propagated as well, since that's also an attribute
of the CTE list. That omission doesn't seem to have any ill effect
today, since nothing in planning or execution looks at that flag, but
someday it might. So
Greg Nancarrow writes:
> I found a bug in the query rewriter. If a query that has a modifying
> CTE is re-written, the hasModifyingCTE flag is not getting set in the
> re-written query.
Ugh.
> I've attached the patch with the suggested fix (reviewed by Amit Langote).
I think either the bit abou
Hi Hackers,
I found a bug in the query rewriter. If a query that has a modifying
CTE is re-written, the hasModifyingCTE flag is not getting set in the
re-written query. This bug can result in the query being allowed to
execute in parallel-mode, which results in an error.
I originally found the pr
Heikki Linnakangas writes:
> I just noticed that if you load a file using psql:
> it sends every line as a separate FE/BE protocol CopyData packet.
> ...
> I'll add this to the next commitfest. There's similar inefficiency in
> the server side in COPY TO, but I'll leave that for another patch.
T
Hi,
I just noticed that if you load a file using psql:
\copy from
it sends every line as a separate FE/BE protocol CopyData packet. That's
pretty wasteful if the lines are narrow. The overhead of each CopyData
packet is 5 bytes.
To demonstrate, I generated a simple test file with the stri
On 2/5/21 8:43 AM, Michael Paquier wrote:
On Fri, Feb 05, 2021 at 08:22:17AM +0100, Ronan Dunklau wrote:
I'm not surprised by this answer, the good news is it's being back-patched.
Yes, I have no problem with that. Until this gets fixed, the damage
can be limited with an extra ALTER INDEX, th
Why is GlobalVisIsRemovableFullXid() not named
GlobalVisCheckRemovableFullXid() instead? ISTM that that name makes
much more sense, since it is what I'd expect for a function that is
the "Full XID equivalent" of GlobalVisCheckRemovableXid().
Note also that GlobalVisIsRemovableFullXid() is the only
Hi,
For v7-0002-Implement-CLUSTER-of-partitioned-table.patch:
+* We have to build the list in a different memory context so it
will
+* survive the cross-transaction processing
+*/
+ old_context = MemoryContextSwitchTo(cluster_context);
cluster_context is not modified
Hi,
+ if (strcmp(defel->defname, "truncatable") == 0)
+ server_truncatable = defGetBoolean(defel);
Looks like we can break out of the loop when the condition is met.
+ /* ExecForeignTruncate() is invoked for each server */
The method name in the comment
On Mon, Jan 18, 2021 at 12:34:59PM -0600, Justin Pryzby wrote:
> On Sat, Nov 28, 2020 at 08:03:02PM -0600, Justin Pryzby wrote:
> > On Sun, Nov 15, 2020 at 07:53:35PM -0600, Justin Pryzby wrote:
> > > On Wed, Nov 04, 2020 at 08:23:56PM -0600, Justin Pryzby wrote:
> > > > On Tue, Oct 27, 2020 at 07:
On 2/5/21 2:50 PM, Heikki Linnakangas wrote:
> On 05/02/2021 21:16, Andrew Dunstan wrote:
>>
>> On 2/5/21 10:54 AM, Stephen Frost wrote:
>>> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
I ran it for about 2 h on my laptop with the patch I was working on
[2]. It
didn't find any cra
Hello,
The attached patch is for supporting "TRUNCATE" on foreign tables.
This patch includes:
* Adding "ExecForeignTruncate" function into FdwRoutine.
* Enabling "postgres_fdw" to use TRUNCATE.
This patch was proposed by Kaigai-san in March 2020,
but it was returned because it can't be applied
On Sat, Feb 6, 2021 at 3:26 PM Petr Jelinek wrote:
>
> On 06/02/2021 07:29, Amit Kapila wrote:
> > On Fri, Feb 5, 2021 at 6:45 PM Euler Taveira wrote:
> >> - replorigin_drop(roident, true);
> >> + replorigin_drop_by_name(name, false /* missing_ok */ , true /* nowait */
> >> );
> >>
> >> A modern
On 06/02/2021 07:29, Amit Kapila wrote:
On Fri, Feb 5, 2021 at 6:45 PM Euler Taveira wrote:
On Fri, Feb 5, 2021, at 4:01 AM, Amit Kapila wrote:
I am not completely whether we should retire replorigin_drop or just
keep it for backward compatibility? What do you think? Anybody else
has any opini
On 06/02/2021 06:07, Amit Kapila wrote:
On Sat, Feb 6, 2021 at 6:22 AM Peter Smith wrote:
On Sat, Feb 6, 2021 at 2:10 AM Petr Jelinek
wrote:
+ReplicationSlotNameForTablesync(Oid suboid, Oid relid, char
syncslotname[NAMEDATALEN])
+{
+ if (syncslotname)
+ sprintf(syncslotname
23 matches
Mail list logo
