On Wed, Dec 25, 2019 at 10:39:32AM +0900, Kyotaro Horiguchi wrote:
> At Tue, 24 Dec 2019 11:57:39 -0800, Noah Misch wrote in
> > On Mon, Dec 23, 2019 at 07:41:49PM +0900, Kyotaro Horiguchi wrote:
> > > If we regard repalloc as far faster than FileOpen/FileClose or we care
> > > about only
2020年1月2日(木) 12:16 Alvaro Herrera :
>
> On 2020-Jan-01, Kohei KaiGai wrote:
>
> > Hello,
> >
> > The attached patch adds TRUNCATE support on foreign table.
> >
> > This patch adds an optional callback ExecForeignTruncate(Relation rel)
> > to FdwRoutine.
> > It is invoked during
On Mon, Dec 30, 2019 at 3:43 PM Amit Kapila wrote:
>
> On Sun, Dec 29, 2019 at 1:34 PM Dilip Kumar wrote:
> >
> > I have observed some more issues
> >
> > 1. Currently, In ReorderBufferCommit, it is always expected that
> > whenever we get REORDER_BUFFER_CHANGE_INTERNAL_SPEC_CONFIRM, we must
> >
Bruce Momjian writes:
> Does the next decade start on 2020-01-01 or 2021-01-01?
I see Randall Munroe has weighed in on this topic:
https://xkcd.com/2249/
regards, tom lane
On Thu, Jan 2, 2020 at 8:29 AM Masahiko Sawada
wrote:
>
> On Tue, 31 Dec 2019 at 12:39, Amit Kapila wrote:
> >
> > On Mon, Dec 30, 2019 at 6:46 PM Tomas Vondra
> > wrote:
> > >
> > > On Mon, Dec 30, 2019 at 08:25:28AM +0530, Amit Kapila wrote:
> > > >On Mon, Dec 30, 2019 at 2:53 AM Tomas Vondra
On 2020-Jan-01, Kohei KaiGai wrote:
> Hello,
>
> The attached patch adds TRUNCATE support on foreign table.
>
> This patch adds an optional callback ExecForeignTruncate(Relation rel)
> to FdwRoutine.
> It is invoked during ExecuteTruncateGuts, then FDW driver hands over
> the jobs related to
On Tue, 31 Dec 2019 at 12:39, Amit Kapila wrote:
>
> On Mon, Dec 30, 2019 at 6:46 PM Tomas Vondra
> wrote:
> >
> > On Mon, Dec 30, 2019 at 08:25:28AM +0530, Amit Kapila wrote:
> > >On Mon, Dec 30, 2019 at 2:53 AM Tomas Vondra
> > > wrote:
> > >> I think there's another question we need to ask -
Robert Haas writes:
> AFAICS, the only options to make that work with JSON are (1) introduce
> a new hand-coded JSON parser designed for frontend operation, (2) add
> a dependency on an external JSON parser that we can use from frontend
> code, or (3) adapt the existing JSON parser used in the
On Wed, Jan 1, 2020 at 7:46 PM Tom Lane wrote:
> David Fetter writes:
> > On Wed, Jan 01, 2020 at 01:43:40PM -0500, Robert Haas wrote:
> >> So, if someone can suggest to me how I could read JSON from a tool in
> >> src/bin without writing a lot of code, I'm all ears.
>
> > Maybe I'm missing
David Fetter writes:
> On Wed, Jan 01, 2020 at 01:43:40PM -0500, Robert Haas wrote:
>> So, if someone can suggest to me how I could read JSON from a tool in
>> src/bin without writing a lot of code, I'm all ears.
> Maybe I'm missing something obvious, but wouldn't combining
> pg_read_file() with
I wrote:
> Currently, we include the function name string in each FmgrBuiltin
> struct, whose size is 24 bytes on 64 bit platforms. As far as I can
> tell, the name is usually unused, so the attached (WIP, untested)
> patch stores it separately, reducing this struct to 16 bytes.
>
> We can go one
Hello Peter,
The patch seems pretty straightforward, but this
+/*
+ * Convenient shorcuts
+ */
+#define fatal pg_log_fatal
+#define error pg_log_error
+#define warning pg_log_warning
+#define info pg_log_info
+#define debug pg_log_debug
seems counterproductive. Let's just use the normal
Bonjour Michaël, et excellente année 2020 !
Hmm. Wouldn't it make sense to output the log generated as
information from the test using pg_log_info() instead of using
fprintf(stderr) (the logs of the initial data load, progress report)?
For the progress report, the reason I decided against
On 01/01/2020 11:50, Surafel Temesgen wrote:
>
>
> Hi,
> Attached is a complete patch and also contain a fix for your comments
>
This does not compile against current head (0ce38730ac).
gram.y: error: shift/reduce conflicts: 6 found, 0 expected
--
Vik Fearing
The RelationNeedsWAL() code block within _bt_delitems_delete() has had
the following comment for many years now:
/*
* We need the target-offsets array whether or not we store the whole
* buffer, to allow us to find the latestRemovedXid on a standby
* server.
*/
XLogRegisterData((char *)
On Wed, Jan 01, 2020 at 01:43:40PM -0500, Robert Haas wrote:
> On Tue, Dec 31, 2019 at 9:16 PM David Steele wrote:
> > > That said, I agree that there's no reason to come up with a bespoke
> > > format and parser when JSON is already available in every PostgreSQL
> > > installation. Imposing a
On Tue, Dec 31, 2019 at 9:16 PM David Steele wrote:
> > That said, I agree that there's no reason to come up with a bespoke
> > format and parser when JSON is already available in every PostgreSQL
> > installation. Imposing a structure atop that includes a version
> > number, as you suggest,
st 1. 1. 2020 v 16:50 odesílatel Ashutosh Sharma
napsal:
> Hi All,
>
> When a ROW variable having NULL value is assigned to a RECORD
> variable, it gives no structure to the RECORD type variable. Let's
> consider the following example.
>
> create table t1(a int, b text);
>
> insert into t1
Hi All,
When a ROW variable having NULL value is assigned to a RECORD
variable, it gives no structure to the RECORD type variable. Let's
consider the following example.
create table t1(a int, b text);
insert into t1 values(1, 'str1');
create or replace function f1() returns void as
$$
declare
Hello hackers,
Based on ideas from earlier discussions[1][2], here is an experimental
WIP patch to improve recovery speed by prefetching blocks. If you set
wal_prefetch_distance to a positive distance, measured in bytes, then
the recovery loop will look ahead in the WAL and call PrefetchBuffer()
Hi,
Attached is a complete patch and also contain a fix for your comments
regards
Surafel
From 0a1e51b6fcce03014e3ee355d42443add4da7a28 Mon Sep 17 00:00:00 2001
From: Surafel Temesgen
Date: Wed, 1 Jan 2020 13:27:25 +0300
Subject: [PATCH] system versioned temporal table
---
21 matches
Mail list logo
