On 2020/06/25 12:57, Alvaro Herrera wrote:
On 2020-Jun-25, Fujii Masao wrote:
/*
* Find the oldest extant segment file. We get 1 until checkpoint
removes
* the first WAL segment file since startup, which causes the status
being
* wrong under certain
Hello Tom,
INSERT INTO t() VALUES ();
I'm still unclear why it would be forbidden though, it seems logical to
try that, whereas the working one is quite away from the usual syntax.
It's forbidden because the SQL standard forbids it.
Ok, that is definitely a reason. I'm not sure it is
On Wed, Jun 24, 2020 at 10:50:39PM -0400, Tom Lane wrote:
> Can we do something comparable to the backend's HINT protocol, where
> we add on a comment that's only mostly-likely to be right?
OpenSSL publishes its error codes as of openssl/sslerr.h, and it looks
like the two error codes we would
On 2020-Jun-25, Fujii Masao wrote:
> /*
>* Find the oldest extant segment file. We get 1 until checkpoint
> removes
>* the first WAL segment file since startup, which causes the status
> being
>* wrong under certain abnormal conditions but that doesn't actually
>
On 2020/06/25 3:27, Alvaro Herrera wrote:
Thanks for those corrections.
I have pushed this. I think all problems Masao-san reported have been
dealt with, so we're done here.
Sorry for my late to reply here...
Thanks for committing the patch and improving the feature!
/*
Michael Paquier writes:
> On Thu, Jun 25, 2020 at 12:30:03AM +0200, Daniel Gustafsson wrote:
>> As mentioned elsewhere in the thread, maybe this is also something which can
>> be
>> done more easily if we improve the error reporting? Right now it's fairly
>> cryptic IMO.
> This part may be
On 2020/06/24 23:58, Alvaro Herrera wrote:
On 2020-Jun-24, Fujii Masao wrote:
I think the errcode is a bit bogus considering the new case.
IMO ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE is more appropriate.
Agreed. So I updated the patch so this errcode is used instead.
Patch attached.
On Wed, Jun 24, 2020 at 12:55:22PM -0400, Tom Lane wrote:
> Yeah, I'm sure there are a few inconsistencies. We previously made a
> pass to get rid of pg_strcasecmp for anything that had been through
> the parser's downcasing (commit fb8697b31) but I wouldn't be surprised
> if that missed a few
Back in [1] I experimented with a patch to coax compilers to build all
elog/ereport calls that were >= ERROR into a cold path away from the
function rasing the error. At the time, I really just wanted to test
how much of a speedup we could get by doing this and ended up just
writing up a patch
On Thu, Jun 25, 2020 at 12:30:03AM +0200, Daniel Gustafsson wrote:
> I don't think anyone argues against safe defaults for communication between
> upgraded clients and upgraded servers. That being said; out of the box, an
> upgraded client *will* use TLSv1.2 when connecting to a upgraded server
On Tue, Jun 23, 2020 at 4:45 PM Tomas Vondra
wrote:
>
> >>
> >> Anyway if you would like to make this view more user-friendly, I can add
> >> that. Just ping me.
> >
> >I felt we could add pg_size_pretty to make the view more user friendly.
> >
>
> Please no. That'd make processing of the data
On Tue, Jun 23, 2020 at 10:06 AM Andres Freund wrote:
> Hi,
>
> On 2020-06-23 09:23:57 -0700, Melanie Plageman wrote:
> > On Mon, Jun 22, 2020 at 9:02 PM Andres Freund
> wrote:
> > > It's not this patch's fault, but none, really none, of this stuff
> should
> > > be in the executor.
> > >
> > >
On Wed, Jun 24, 2020 at 07:18:10PM -0400, Bruce Momjian wrote:
> On Wed, Jun 24, 2020 at 12:19:00PM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2020-06-24 13:12:03 -0400, Bruce Momjian wrote:
> > > Well, my point is that merge join works that way, and no one has needed
> > > a knob to avoid
On Wed, Jun 24, 2020 at 12:19:00PM -0700, Andres Freund wrote:
> Hi,
>
> On 2020-06-24 13:12:03 -0400, Bruce Momjian wrote:
> > Well, my point is that merge join works that way, and no one has needed
> > a knob to avoid mergejoin if it is going to spill to disk. If they are
> > adjusting
On Wed, Jun 24, 2020 at 11:02:10PM +0200, Tomas Vondra wrote:
> > Indeed. And then perhaps we could eventually add some reporting /
> > monitoring infrastructure for the cases where plan time and execution
> > time memory estimate/usage widely differs.
> >
>
> I wouldn't mind something like that
On Wed, Jun 24, 2020 at 3:31 PM Dagfinn Ilmari Mannsåker
wrote:
> FWIW, MySQL (and MariaDB) only support INSERT INTO t () VALUES (), not
> DEFAULT VALUES.
We have added syntax for MySQL compatibility in the
> past, e.g. the CONCAT() function.
>
I don't see the similarities. IIUC there isn't
Tom Lane writes:
> Fabien COELHO writes:
INSERT INTO t() VALUES ();
>
>> I'm still unclear why it would be forbidden though, it seems logical to
>> try that, whereas the working one is quite away from the usual syntax.
>
> It's forbidden because the SQL standard forbids it.
>
> We allow
> On 24 Jun 2020, at 19:57, Peter Eisentraut
> wrote:
>
> On 2020-06-24 10:33, Daniel Gustafsson wrote:
>>> In PG13, we raised the server-side default of ssl_min_protocol_version to
>>> TLSv1.2. We also added a connection setting named ssl_min_protocol_version
>>> to libpq. But AFAICT, the
Hi hackers,
While working with Chris Hajas on merging Postgres 12 with Greenplum
Database we stumbled upon the following strange behavior in the geometry
type polygon:
-- >8
CREATE TEMP TABLE foo (p point);
CREATE INDEX ON foo USING gist(p);
INSERT INTO foo VALUES ('0,0'),
On 2020-Jun-24, Peter Eisentraut wrote:
> I was checking some loose ends in SQL conformance, when I noticed: We
> support GRANT role ... GRANTED BY CURRENT_USER, but we don't support
> CURRENT_ROLE in that place, even though in PostgreSQL they are equivalent.
> Here is a trivial patch to add
On Wed, Jun 24, 2020 at 12:36:24PM -0700, Andres Freund wrote:
Hi,
On 2020-06-24 15:28:47 -0400, Robert Haas wrote:
On Wed, Jun 24, 2020 at 3:14 PM Andres Freund wrote:
> FWIW, my gut feeling is that we'll end up have to separate the
> "execution time" spilling from using plain work mem,
On Wed, Jun 24, 2020 at 10:21 AM Robert Haas wrote:
> Sorry, I'm so far behind on my email. Argh.
That's okay.
> I think, especially on the blog post you linked, that we should aim to
> have INDEX_CLEANUP OFF mode do the minimum possible amount of work
> while still keeping us safe against
Fabien COELHO writes:
>>> INSERT INTO t() VALUES ();
> I'm still unclear why it would be forbidden though, it seems logical to
> try that, whereas the working one is quite away from the usual syntax.
It's forbidden because the SQL standard forbids it.
We allow zero-column syntaxes in some
Hi,
On 2020-06-24 15:41:14 -0400, Alvaro Herrera wrote:
> On 2020-Jun-24, Robert Haas wrote:
>
> > So really I think this turns on #1: is it plausible
> > that people are using this feature, however inadvertent it may be, and
> > is it potentially useful? I don't see that anybody's made an
On Wed, 24 Jun 2020 at 15:41, Alvaro Herrera
wrote:
> On 2020-Jun-24, Robert Haas wrote:
>
> > So really I think this turns on #1: is it plausible
> > that people are using this feature, however inadvertent it may be, and
> > is it potentially useful? I don't see that anybody's made an argument
On 2020-Jun-24, Robert Haas wrote:
> So really I think this turns on #1: is it plausible
> that people are using this feature, however inadvertent it may be, and
> is it potentially useful? I don't see that anybody's made an argument
> against either of those things. Unless someone can do so, I
Hi,
On 2020-06-24 15:28:47 -0400, Robert Haas wrote:
> On Wed, Jun 24, 2020 at 3:14 PM Andres Freund wrote:
> > FWIW, my gut feeling is that we'll end up have to separate the
> > "execution time" spilling from using plain work mem, because it'll
> > trigger spilling too often. E.g. if the plan
Hallo Thomas,
INSERT INTO t() VALUES ();
This is forbidden by postgres, and also sqlite.
Is there any good reason why this should be the case?
Maybe because
insert into t default values;
exists (and is standard SQL if I'm not mistaken)
That's a nice alternative I did not notice.
Hi,
On 2020-06-24 14:40:50 -0400, Tom Lane wrote:
> Tomas Vondra writes:
> > On Wed, Jun 24, 2020 at 01:29:56PM -0400, Tom Lane wrote:
> >> If we feel we need something to let people have the v12 behavior
> >> back, let's have
> >> (1) enable_hashagg on/off --- controls planner, same as it ever
On Wed, Jun 24, 2020 at 3:14 PM Andres Freund wrote:
> FWIW, my gut feeling is that we'll end up have to separate the
> "execution time" spilling from using plain work mem, because it'll
> trigger spilling too often. E.g. if the plan isn't expected to spill,
> only spill at 10 x work_mem or
On Wed, Jun 24, 2020 at 1:06 PM Alvaro Herrera wrote:
> On 2020-Jun-24, Stephen Frost wrote:
> > Doesn't mean it makes sense or that we should be supporting that. What
> > we should have is a way to allow administrators to configure a system
> > for exactly what they want to allow, and it
Hi,
On 2020-06-24 13:12:03 -0400, Bruce Momjian wrote:
> Well, my point is that merge join works that way, and no one has needed
> a knob to avoid mergejoin if it is going to spill to disk. If they are
> adjusting work_mem to prevent spill of merge join, they can do the same
> for hash agg. We
Hi,
On 2020-06-24 14:11:57 +1200, David Rowley wrote:
> 1. Statistics underestimation can cause hashagg to be selected. The
> executor will spill to disk in PG13. Users may find performance
> suffers as previously the query may have just overshot work_mem
> without causing any OOM issues. Their
Tomas Vondra writes:
> On Wed, Jun 24, 2020 at 01:29:56PM -0400, Tom Lane wrote:
>> If we feel we need something to let people have the v12 behavior
>> back, let's have
>> (1) enable_hashagg on/off --- controls planner, same as it ever was
>> (2) enable_hashagg_spill on/off --- controls executor
On Wed, Jun 24, 2020 at 01:29:56PM -0400, Tom Lane wrote:
Justin Pryzby writes:
On Wed, Jun 24, 2020 at 05:06:28AM -0400, Bruce Momjian wrote:
It would seem merge join has almost the same complexities as the new
hash join code, since it can spill to disk doing sorts for merge joins,
and
Thanks for those corrections.
I have pushed this. I think all problems Masao-san reported have been
dealt with, so we're done here.
Thanks!
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020-06-24 10:12, Vik Fearing wrote:
On 6/24/20 8:35 AM, Peter Eisentraut wrote:
I was checking some loose ends in SQL conformance, when I noticed: We
support GRANT role ... GRANTED BY CURRENT_USER, but we don't support
CURRENT_ROLE in that place, even though in PostgreSQL they are
On Wed, Jun 24, 2020 at 07:57:31PM +0200, Peter Eisentraut wrote:
> On 2020-06-24 10:33, Daniel Gustafsson wrote:
> > > In PG13, we raised the server-side default of ssl_min_protocol_version to
> > > TLSv1.2. We also added a connection setting named
> > > ssl_min_protocol_version to libpq. But
On 2020-06-24 10:33, Daniel Gustafsson wrote:
In PG13, we raised the server-side default of ssl_min_protocol_version to
TLSv1.2. We also added a connection setting named ssl_min_protocol_version to
libpq. But AFAICT, the default value of the libpq setting is empty, so any
protocol version
On Fri, Jun 19, 2020 at 12:04 AM Justin Pryzby wrote:
>
> On Tue, Apr 07, 2020 at 08:40:30AM -0400, James Coleman wrote:
> > On Tue, Apr 7, 2020 at 12:25 AM Justin Pryzby wrote:
> > > On Mon, Apr 06, 2020 at 09:57:22PM +0200, Tomas Vondra wrote:
> > > > I've pushed the fist part of this patch
Justin Pryzby writes:
> On Wed, Jun 24, 2020 at 05:06:28AM -0400, Bruce Momjian wrote:
>> It would seem merge join has almost the same complexities as the new
>> hash join code, since it can spill to disk doing sorts for merge joins,
>> and adjusting work_mem is the only way to control that spill
On Fri, May 22, 2020 at 4:40 PM Peter Geoghegan wrote:
> On Mon, May 18, 2020 at 7:32 PM Masahiko Sawada
> wrote:
> > I've attached WIP patch for HEAD. With this patch, the core pass
> > index_cleanup to bulkdelete and vacuumcleanup callbacks so that they
> > can make decision whether run vacuum
On Thu, Jun 25, 2020 at 12:24:29AM +1200, David Rowley wrote:
> On Wed, 24 Jun 2020 at 21:06, Bruce Momjian wrote:
> > I
> > don't remember anyone complaining about spills to disk during merge
> > join, so I am unclear why we would need a such control for hash join.
>
> Hash aggregate, you mean?
On Wed, Jun 24, 2020 at 07:38:43AM -0500, Justin Pryzby wrote:
> On Wed, Jun 24, 2020 at 05:06:28AM -0400, Bruce Momjian wrote:
> > It would seem merge join has almost the same complexities as the new
> > hash join code, since it can spill to disk doing sorts for merge joins,
> > and adjusting
On 2020-Jun-24, Stephen Frost wrote:
> Doesn't mean it makes sense or that we should be supporting that. What
> we should have is a way to allow administrators to configure a system
> for exactly what they want to allow, and it doesn't seem like we're
> doing that today and therefore we should
Robert Haas writes:
> On Wed, Jun 24, 2020 at 10:27 AM Tom Lane wrote:
>> More generally, though, why would we want to change this policy only
>> here? I believe we're reasonably consistent about letting the parser
>> do any required down-casing and then just checking keyword matches
>> with
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Jun 24, 2020 at 09:05:30AM +, ROS Didier wrote:
> > I would like to use a Foreign Data Wrapper (FDW) to connect to a HADOOP
> > cluster
> > which uses KERBEROS authentication.
Sadly, not really.
> > is it possible to achieve
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2020-Jun-24, Kyotaro Horiguchi wrote:
>
> > In logical replication, a replication role is intended to be
> > accessible only to the GRANTed databases. On the other hand the same
> > role can create a dead copy of the whole
On Wed, Jun 24, 2020 at 10:27 AM Tom Lane wrote:
> More generally, though, why would we want to change this policy only
> here? I believe we're reasonably consistent about letting the parser
> do any required down-casing and then just checking keyword matches
> with strcmp.
I've had the feeling
Hi Tomas,
On Tue, Jun 23, 2020 at 3:24 PM Tomas Vondra wrote:
>
> Now, a couple comments / questions about the code.
>
>
> nodeHash.c
> --
>
>
> 1) MultiExecPrivateHash says this
>
>/*
> * Not subject to skew optimization, so either insert normally
> * or save to batch file if
On Sun, Jun 14, 2020 at 3:15 AM Fabien COELHO wrote:
> > so instead I'd like to have a better way to do it.
>
> > Attached is v1 of a patch to refactor things so that parts of the
> > BASE_BACKUP and CREATE_REPLICATION_SLOT are replaced with a flexible
> > options syntax.
>
> Patch applies
On Wed, Jun 24, 2020 at 6:09 PM ROS Didier wrote:
> Hi Bruce
>
> In the following link :
> https://www.enterprisedb.com/blog/connecting-hadoop-and-edb-postgres-shrink-big-data-challenges
> We can see :
> "Support for various authentication methods (i.e. Kerberos, NOSASL, etc.)"
>
> So
On 2020-Jun-24, Fujii Masao wrote:
> On 2020/06/24 8:39, Alvaro Herrera wrote:
> > I think we should publish the value from wal_keep_segments separately
> > from max_slot_wal_keep_size. ISTM that the user might decide to change
> > or remove wal_keep_segments and be suddenly at risk of losing
On 2020-Jun-24, movead...@highgo.ca wrote:
> >Maybe a better answer is to have a new switch in postmaster that creates
> >any needed files (incl. producing associated WAL etc); so you'd run
> >pg_resetwal -x some-value
> >postmaster --create-special-stuff
> >then start your server and off you go.
On 2020-Jun-24, Fujii Masao wrote:
> > I think the errcode is a bit bogus considering the new case.
> > IMO ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE is more appropriate.
>
> Agreed. So I updated the patch so this errcode is used instead.
> Patch attached.
LGTM.
--
Álvaro Herrera
On 2020-Jun-24, Kyotaro Horiguchi wrote:
> In logical replication, a replication role is intended to be
> accessible only to the GRANTed databases. On the other hand the same
> role can create a dead copy of the whole cluster, including
> non-granted databases.
In other words -- essentially, if
Bharath Rupireddy writes:
> COPY command's FORMAT option allows only all lowercase csv, text or
> binary, this is true because strcmp is being used while parsing these
> values.
This is nonsense, actually:
regression=# create table foo (f1 int);
CREATE TABLE
regression=# copy foo from stdin
On Wed, Jun 24, 2020 at 2:37 PM Fujii Masao wrote:
>
> On 2020/06/23 15:27, Amit Kapila wrote:
> >
> > Having a separate function for this seems like a good idea but can we
> > consider displaying it in a view like pg_stat_replication_slots as we
> > are discussing a nearby thread to have such a
Hi Bruce
In the following link :
https://www.enterprisedb.com/blog/connecting-hadoop-and-edb-postgres-shrink-big-data-challenges
We can see :
"Support for various authentication methods (i.e. Kerberos, NOSASL, etc.)"
So HDFS_FDW support kerberos authentication . how to be sure of that
On Wed, Jun 24, 2020 at 05:06:28AM -0400, Bruce Momjian wrote:
> On Wed, Jun 24, 2020 at 02:11:57PM +1200, David Rowley wrote:
> > On Tue, 23 Jun 2020 at 08:24, Jeff Davis wrote:
> > > Another way of looking at it is that the weird behavior is already
> > > there in v12, so there are already
On Wed, 24 Jun 2020 at 21:06, Bruce Momjian wrote:
> I
> don't remember anyone complaining about spills to disk during merge
> join, so I am unclear why we would need a such control for hash join.
Hash aggregate, you mean? The reason is that upgrading to PG13 can
cause a performance regression
Fabien COELHO schrieb am 24.06.2020 um 14:18:
> I would like to create an "all defaults" row, i.e. a row composed of the
> default values for all attributes, so I wrote:
>
> INSERT INTO t() VALUES ();
>
> This is forbidden by postgres, and also sqlite.
>
> Is there any good reason why this
Hello devs,
I would like to create an "all defaults" row, i.e. a row composed of the
default values for all attributes, so I wrote:
INSERT INTO t() VALUES ();
This is forbidden by postgres, and also sqlite.
Is there any good reason why this should be the case?
--
Fabien.
On Tue, Jun 23, 2020 at 4:00 PM Andres Freund wrote:
> https://postgr.es/m/20130621000900.GA12425%40alap2.anarazel.de is a
> thread with more information / patches further along.
>
> I confused this patch with the approach in
>
On Wed, Jun 24, 2020 at 4:27 PM Dilip Kumar wrote:
>
> iOn Wed, Jun 24, 2020 at 4:04 PM Amit Kapila wrote:
> >
> > On Tue, Jun 23, 2020 at 7:00 PM Dilip Kumar wrote:
> > >
> > > Here is the POC patch to discuss the idea of a cleanup of shared
> > > fileset on proc exit. As discussed offlist,
iOn Wed, Jun 24, 2020 at 4:04 PM Amit Kapila wrote:
>
> On Tue, Jun 23, 2020 at 7:00 PM Dilip Kumar wrote:
> >
> > Here is the POC patch to discuss the idea of a cleanup of shared
> > fileset on proc exit. As discussed offlist, here I am maintaining
> > the list of shared fileset. First time
On Mon, Jun 22, 2020 at 11:56 AM Dilip Kumar wrote:
>
> On Tue, Jun 16, 2020 at 2:37 PM Amit Kapila wrote:
> >
>
> > 8.
> > + /*
> > + * Start a transaction on stream start, this transaction will be committed
> > + * on the stream stop. We need the transaction for handling the buffile,
> > + *
On Tue, Jun 23, 2020 at 7:00 PM Dilip Kumar wrote:
>
> Here is the POC patch to discuss the idea of a cleanup of shared
> fileset on proc exit. As discussed offlist, here I am maintaining
> the list of shared fileset. First time when the list is NULL I am
> registering the cleanup function
Hi,
COPY command's FORMAT option allows only all lowercase csv, text or
binary, this is true because strcmp is being used while parsing these
values.
It would be nice if the uppercase or combination of lower and upper
case format options such as CSV, TEXT, BINARY, Csv, Text, Binary so
on. is
On 2020/06/24 11:56, Kyotaro Horiguchi wrote:
At Tue, 23 Jun 2020 10:51:40 +0900, Michael Paquier wrote
in
On Sun, Jun 21, 2020 at 01:02:34PM -0700, Andres Freund wrote:
I still maintain that adding restrictions here is a bad idea. Even
disregarding the discussion of running normal
On Tue, Jun 23, 2020 at 12:55 AM Maciek Sakrejda wrote:
>
> Hello,
>
> I had some questions about the behavior of some accounting in parallel
> EXPLAIN plans. Take the following plan:
>
>
..
>
> The Nested Loop here aggregates data for metrics like `buffers read`
> from its workers, and to
On 2020/06/24 9:38, Alvaro Herrera wrote:
On 2020-Jun-23, Fujii Masao wrote:
If restart_lsn of logical replication slot gets behind more than
max_slot_wal_keep_size from the current LSN, the logical replication
slot would be invalidated and its restart_lsn is reset to an invalid LSN.
If this
On Wed, Jun 24, 2020 at 09:05:30AM +, ROS Didier wrote:
> Hi
>
> I would like to use a Foreign Data Wrapper (FDW) to connect to a HADOOP
> cluster
> which uses KERBEROS authentication.
>
> is it possible to achieve this ? which FDW should be used ?
Well, I would use the Hadoop FDW:
On 2020/06/24 8:39, Alvaro Herrera wrote:
On 2020-Jun-23, Kyotaro Horiguchi wrote:
At Tue, 23 Jun 2020 11:50:34 +0530, Amit Kapila wrote
in
On Mon, Jun 22, 2020 at 6:32 PM Fujii Masao wrote:
We should expose the LSN calculated from
"the current WAL LSN - max(wal_keep_segments * 16MB,
On Wed, Jun 24, 2020 at 12:41 PM Maciek Sakrejda wrote:
>
> On Tue, Jun 23, 2020 at 7:55 PM Amit Kapila wrote:
> > > I don't see any other reason for
> > > looping over the NL node itself in this plan. The Gather itself
> > > doesn't do any real looping, right?
> >
> > It is right that Gather
On 2020/06/23 15:27, Amit Kapila wrote:
On Tue, Jun 23, 2020 at 7:47 AM Fujii Masao wrote:
On 2020/06/23 10:10, Kyotaro Horiguchi wrote:
At Mon, 22 Jun 2020 22:02:51 +0900, Fujii Masao
wrote in
I feel such a function is good to have but I am not sure if there is a
need to tie it with
Hi
I would like to use a Foreign Data Wrapper (FDW) to connect to a HADOOP cluster
which uses KERBEROS authentication.
is it possible to achieve this ? which FDW should be used ?
Thanks in advance
Best Regards
Didier ROS
EDF
Ce message et toutes les pièces jointes (ci-après le 'Message')
On Wed, Jun 24, 2020 at 02:11:57PM +1200, David Rowley wrote:
> On Tue, 23 Jun 2020 at 08:24, Jeff Davis wrote:
> > Another way of looking at it is that the weird behavior is already
> > there in v12, so there are already users relying on this weird behavior
> > as a crutch for some other planner
> On 24 Jun 2020, at 10:46, Magnus Hagander wrote:
> It might also be worth noting that it's not really "any protocol version", it
> means it will be "whatever the openssl configuration says", I think? For
> example, debian buster sets:
>
> [system_default_sect]
> MinProtocol = TLSv1.2
>
>
Hi Inoue-san,
On Wed, Jun 24, 2020 at 05:20:42PM +0900, Inoue, Hiroshi wrote:
> Where do you test, on Windows or on *nix?
> How do you test there?
I have been testing the driver on macos only, with various backend
versions, from 11 to 14.
Thanks,
--
Michael
signature.asc
Description: PGP
>Yeah, the normal workaround is to create the necessary file manually in
>order to let the system start after such an operation; they are
>sometimes necessary to enable testing weird cases with wraparound and
>such. So a total rejection to work for these cases would be unhelpful
>precisely for
On Wed, Jun 24, 2020 at 10:33 AM Daniel Gustafsson wrote:
> > On 24 Jun 2020, at 08:39, Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
> >
> > In PG13, we raised the server-side default of ssl_min_protocol_version
> to TLSv1.2. We also added a connection setting named
>
Hi,
It looks like the parsing of newly introduced "PARALLEL" option for
COPY FROM command has an issue(in the
0002-Framework-for-leader-worker-in-parallel-copy.patch),
Mentioning PARALLEL '4ar2eteid'); would pass with 4 workers since
atoi() is being used for converting string to integer which
> On 24 Jun 2020, at 08:39, Peter Eisentraut
> wrote:
>
> In PG13, we raised the server-side default of ssl_min_protocol_version to
> TLSv1.2. We also added a connection setting named ssl_min_protocol_version
> to libpq. But AFAICT, the default value of the libpq setting is empty, so
> any
On 6/22/20 11:59 AM, Amul Sul wrote:
2. Now skipping the startup checkpoint if the system is read-only mode, as
discussed [2].
I am not able to perform pg_checksums o/p after shutting down my server
in read only mode .
Steps -
1.initdb (./initdb -k -D data)
2.start the server(./pg_ctl -D
Hi Michael,
Where do you test, on Windows or on *nix?
How do you test there?
regards,
Hiroshi Inoue
On 2020/06/24 11:11, Michael Paquier wrote:
On Tue, Jun 23, 2020 at 02:02:33PM +0900, Michael Paquier wrote:
Actually, while reviewing the code, the only code path where we use
currtid2()
On 6/24/20 8:35 AM, Peter Eisentraut wrote:
> I was checking some loose ends in SQL conformance, when I noticed: We
> support GRANT role ... GRANTED BY CURRENT_USER, but we don't support
> CURRENT_ROLE in that place, even though in PostgreSQL they are
> equivalent. Here is a trivial patch to add
Here is another stab at this subject.
This is a much simplified variant: When encountering a parameter change
in the WAL that is higher than the standby's current setting, we log a
warning (instead of an error until now) and pause recovery. If you
resume (unpause) recovery, the instance
Dear hackers,
I update my non-volatile WAL buffer's patchset to v3. Now we can use it in
streaming replication mode.
Updates from v2:
- walreceiver supports non-volatile WAL buffer
Now walreceiver stores received records directly to non-volatile WAL buffer if
applicable.
- pg_basebackup
On Tue, Jun 23, 2020 at 7:55 PM Amit Kapila wrote:
> > I don't see any other reason for
> > looping over the NL node itself in this plan. The Gather itself
> > doesn't do any real looping, right?
>
> It is right that Gather doesn't do looping but Parallel Seq Scan node does so.
Sorry, I still
In PG13, we raised the server-side default of ssl_min_protocol_version
to TLSv1.2. We also added a connection setting named
ssl_min_protocol_version to libpq. But AFAICT, the default value of the
libpq setting is empty, so any protocol version will be accepted. Is
this what we wanted?
I was checking some loose ends in SQL conformance, when I noticed: We
support GRANT role ... GRANTED BY CURRENT_USER, but we don't support
CURRENT_ROLE in that place, even though in PostgreSQL they are
equivalent. Here is a trivial patch to add that.
--
Peter Eisentraut
On Tue, Jun 23, 2020 at 02:31:05PM +0900, Michael Paquier wrote:
> Looks right to me, good catch. I'll apply that tomorrow my time
> except if there are any objections in-between.
And done.
--
Michael
signature.asc
Description: PGP signature
93 matches
Mail list logo
