On Thu, Sep 19, 2019 at 12:14 AM Pavel Stehule wrote:
>
> Hi
>
> I am sending updated version - the changes against last patch are two. I use
> pg_terminate_backed for killing other terminates like Tom proposed. I am not
> sure if it is 100% practical - on second hand the necessary right to
This certainly looks like a good addition to me that can be
implemented on both client and server side. It is always good to have
a common location where the list of all the certificates from various
CA's can be placed for validation.
--
With Regards,
Ashutosh Sharma
The behavior is not actually changed, but I had to move fillfactor away
because it cannot be declared on partitioned tables, it must be declared
on partitions only. Once there is a function to handle that it is pretty
easy to add the test.
I can remove it but franckly there are only benefits:
v12:
- fixes NULL vs NULL
- works correctly with a partitioned table without partitions attached
- generates an error if the partition method is unknown
- adds an assert
You seem to have attached some previous version (v2) of this patch. I
could see old issues in the patch which we
On Thu, Aug 29, 2019 at 3:15 PM Richard Guo wrote:
>
>
> Attached is a patch as an attempt to address this issue. The idea is
> quite straightforward. When building partition info for joinrel, we
> generate any possible EC-derived joinclauses of form 'outer_em =
> inner_em', which will be used
On Thu, Sep 19, 2019 at 05:40:15PM -0700, Jeff Davis wrote:
> On Tue, 2019-09-17 at 16:04 +0900, Michael Paquier wrote:
>> What do you think? There is no need to save down the connection
>> parameter value into fe_scram_state.
>
> I'm not sure I understand this comment, but I removed the extra
On Fri, Sep 13, 2019 at 1:01 AM Alvaro Herrera wrote:
>
> This v6 is just Fabien's v5, rebased over a very minor conflict, and
> pgindented. No further changes. I've marked this Ready for Committer.
>
Should we add function header for the below function to maintain the
common standard of this
On Fri, Sep 20, 2019 at 12:41 AM Fabien COELHO wrote:
>
>
> Hello Amit,
>
> > [...] 'ps' itself won't be NULL in that case, the value it contains is
> > NULL. I have debugged this case as well. 'ps' itself can be NULL only
> > when you pass wrong column number or something like that to
On Fri, Sep 20, 2019 at 5:48 AM Taylor Vesely wrote:
>
> > When doing update operation, for each tuple being modified,
> > *tuplebuffers_insert()* says that there is no entry for the relation
> > being modified in the hash table although it was already added when
> > the first tuple in the table
On Thu, Sep 19, 2019 at 11:41 PM Pavel Stehule wrote:
>
>
>
> čt 19. 9. 2019 v 13:52 odesílatel vignesh C napsal:
>>
>> On Thu, Sep 19, 2019 at 12:14 AM Pavel Stehule
>> wrote:
>> >
>> > Hi
>> >
>> > I am sending updated version - the changes against last patch are two. I
>> > use
On 9/19/19 11:00 AM, Robert Haas wrote:
On Thu, Sep 19, 2019 at 9:51 AM Robert Haas wrote:
I intend that we should be able to support incremental backups based
either on a previous full backup or based on a previous incremental
backup. I am not aware of a technical reason why we need to
Hi Robert,
On 9/19/19 9:51 AM, Robert Haas wrote:
On Wed, Sep 18, 2019 at 9:11 PM David Steele wrote:
Also consider adding the timestamp.
Sounds reasonable, even if only for the benefit of humans who might
look at the file. We can decide later whether to use it for anything
else (and
On Fri, Sep 20, 2019 at 12:41 AM Fabien COELHO wrote:
>
> This case now generates a fail.
>
> v12:
> - fixes NULL vs NULL
> - works correctly with a partitioned table without partitions attached
> - generates an error if the partition method is unknown
> - adds an assert
>
You seem to
On Thu, Sep 19, 2019 at 08:22:04AM +0530, Amit Kapila wrote:
> Thanks. I was about to have a look today, but anyway I checked the
> committed patch and it looks fine.
Thanks Amit for double-checking.
--
Michael
signature.asc
Description: PGP signature
On Thu, Sep 19, 2019 at 05:40:41PM +0300, Alexey Kondratov wrote:
> On 19.09.2019 16:21, Robert Haas wrote:
>> So, earlier in this thread, I suggested making this part of ALTER
>> TABLE, and several people seemed to like that idea. Did we have a
>> reason for dropping that approach?
Personally, I
On Fri, Sep 20, 2019 at 10:38:31AM +0900, Michael Paquier wrote:
> Hi all,
>
> This is a new thread related to the bug analyzed here:
> https://www.postgresql.org/message-id/20190919083203.gc21...@paquier.xyz
>
> And in short, if you attempt to do an ALTER TABLE with a custom
> reloptions the
On Thu, Sep 19, 2019 at 05:14:20PM -0700, Ashwin Agrawal wrote:
> I didn't try as waiting to see if for emacs as well shows up :-) Do we want
> to get these in src/tools/editors?
A full complex plugin may be hard to justify, especially as I suspect
that there are very few hackers able to create
Hi all,
This is a new thread related to the bug analyzed here:
https://www.postgresql.org/message-id/20190919083203.gc21...@paquier.xyz
And in short, if you attempt to do an ALTER TABLE with a custom
reloptions the command burns itself, like that for example this
sequence:
create extension
On Thu, Sep 19, 2019 at 05:20:15PM +0530, Kuntal Ghosh wrote:
> While subscription 3 is created, it eventually reaches to a consistent
> snapshot point and prints the WAL location corresponding to it. It
> seems sub1/sub2 immediately fails to serialize the snapshot to the
> .snap file having the
On Tue, 2019-09-17 at 16:04 +0900, Michael Paquier wrote:
> basically maps into checking after FE_SCRAM_FINISHED. Instead of
> those two flags, wouldn't it be cleaner to add an extra routine to
> fe-auth-scram.c which does the same sanity checks, say
> pg_fe_scram_check_state()? This needs to be
> When doing update operation, for each tuple being modified,
> *tuplebuffers_insert()* says that there is no entry for the relation
> being modified in the hash table although it was already added when
> the first tuple in the table was updated. Why is it so?
Currently, when doing an update, it
On Thu, Sep 19, 2019 at 02:13:23PM +0300, Nikolay Shaplov wrote:
> What a good catch! dummy_index already proved to be useful ;-)
Yes, the testing around custom reloptions is rather poor now, so this
module has value. I still don't like much its shape though, so I
began hacking on it for
Chapman Flack writes:
> Sure, against *every* non-spec feature we have or ever will have, someone
> /could/ raise a generic "what if SQL committee might add something pretty
> similar in future".
> But what we have in this case are specific non-spec features (array, map,
> and sequence
Chapman Flack writes:
> But is that even the point? It's already noted in [1] that the standard
> calls for one style of regexps and we're providing another.
> It's relatively uncomplicated now to add some kind of distinguishing
> syntax for our posix flavor of like_regex. Yes, it would be a
On 9/19/19 6:18 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> On 9/19/19 3:48 PM, Tom Lane wrote:
>>> Seems like
>>> the error handling in jsonpath_gram.y could use some cleanup too
>>> ... although I don't think it's a task to tackle while we're
>>> rushing to get v12 shippable.
>
>> IIRC
"Jonathan S. Katz" writes:
> On 9/19/19 3:48 PM, Tom Lane wrote:
>> Seems like
>> the error handling in jsonpath_gram.y could use some cleanup too
>> ... although I don't think it's a task to tackle while we're
>> rushing to get v12 shippable.
> IIRC if we want to change the contents of an error
On 9/19/19 3:48 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> I looked at the patch, but did not test it. From what I can see, it
>> looks good, but perhaps we add a test in it to show that single-quoted
>> literals are unsupported?
>
> I thought about that, but it seems like it'd be
On 19.09.2019 22:14, Alexander Korotkov wrote:
Pushed.
Attached patch fixes premature xs_orderbynulls[] assignment. The old value of
NULL flag, not the new, should be checked before pfree()ing the old value.
--
Nikita Glukhov
Postgres Professional: http://www.postgrespro.com
The Russian
"Jonathan S. Katz" writes:
> I looked at the patch, but did not test it. From what I can see, it
> looks good, but perhaps we add a test in it to show that single-quoted
> literals are unsupported?
I thought about that, but it seems like it'd be memorializing some
other weird behavior:
On Mon, Sep 16, 2019 at 10:30 PM Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Mon, Sep 16, 2019 at 3:47 PM Nikita Glukhov
> wrote:
> > On 13.09.2019 20:17, Alexander Korotkov wrote:
> >
> > On Fri, Sep 13, 2019 at 5:23 PM Nikita Glukhov
> wrote:
> >
> > I have moved handling of
Hello Amit,
[...] 'ps' itself won't be NULL in that case, the value it contains is
NULL. I have debugged this case as well. 'ps' itself can be NULL only
when you pass wrong column number or something like that to PQgetvalue.
Argh, you are right! I mixed up C NULL and SQL NULL:-(
If we
On Wed, 2019-09-18 at 13:50 -0700, Soumyadeep Chakraborty wrote:
> Hi Jeff,
Hi Soumyadeep and Melanie,
Thank you for the review!
> max_stack_depth max level lazy (ms) eager (ms) (eage
> r/lazy)
> 2MB 82 302.715 427.554 1.4123978
> 3MB 3474567.829 896.143
Hi people,
I have written language plugins for .spec files used in isolation tests. They
are available for Vim and Visual Studio Code. I hope they will make reading the
tests easier for you. If you find a problem, please open an issue!
If we're going to open this up, can we add an option to say "this key is
allowed to log in to this account", SSH style?
I like the idea of using keys rather than .pgpass, but I like the
~/.ssh/authorized_keys model and don't like the "set up an entire
certificate infrastructure" approach.
On
Hi,
currently, libpq does SSL cerificate validation only against the defined
`PGSSLROOTCERT` file.
Is there any specific reason, why the system truststore ( at least under
unixoid systems) is not considered for the validation?
We would like to contribute a patch to allow certificate
Hello
Thank you for review!
> - This parameter can only be set at server start.
> + This parameter can only be set in the postgresql.conf
> + file or on the server command line.
>
> I'm not sure it's good to change the context of this
> description. This was mentioning that changing of this
On 19.09.2019 16:21, Robert Haas wrote:
On Thu, Sep 19, 2019 at 12:43 AM Michael Paquier wrote:
It seems to me that it would be good to keep the patch as simple as
possible for its first version, and split it into two if you would
like to add this new option instead of bundling both together.
On Thu, Sep 19, 2019 at 12:43 AM Michael Paquier wrote:
> It seems to me that it would be good to keep the patch as simple as
> possible for its first version, and split it into two if you would
> like to add this new option instead of bundling both together. This
> makes the review of one and
I've updated the patch series following the suggestions. Thanks.
>
>
v6-0001-Extact-common-functions-from-pg_basebackup-into-s.patch
Description: Binary data
v6-0003-Ensure-target-clean-shutdown-at-the-beginning-of-.patch
Description: Binary data
Hi Tom,
In the attached patch i include the comments given
regards
Surafel
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c
index 82d8140ba2..692d6492bd 100644
--- a/contrib/postgres_fdw/postgres_fdw.c
+++ b/contrib/postgres_fdw/postgres_fdw.c
@@ -3035,7
On Thu, Aug 22, 2019 at 6:44 PM Paul Guo wrote:
>
> Thanks. I updated the patch to v5. It passes install-check testing and
recovery testing.
>
This patch contains one more bug, in addition to what Anastasia has found.
If the test case in the patch is tweaked slightly, as follows, the standby
On Thu, Sep 19, 2019 at 12:14 AM Pavel Stehule wrote:
>
> Hi
>
> I am sending updated version - the changes against last patch are two. I use
> pg_terminate_backed for killing other terminates like Tom proposed. I am not
> sure if it is 100% practical - on second hand the necessary right to
Hello hackers,
It seems there is a pattern how the error is occurring in different
systems. Following are the relevant log snippets:
nightjar:
sub3 LOG: received replication command: CREATE_REPLICATION_SLOT
"sub3_16414_sync_16394" TEMPORARY LOGICAL pgoutput USE_SNAPSHOT
sub3 LOG: logical
Hi Michael,
Thank you for your comments.
On 19.09.2019 7:43, Michael Paquier wrote:
On Wed, Sep 18, 2019 at 03:46:20PM +0300, Alexey Kondratov wrote:
Currently in Postgres SET TABLESPACE always comes with [ NOWAIT ] option, so
I hope it worth adding this option here for convenience. Added in
On Thu, Sep 19, 2019 at 11:35 AM Ashutosh Sharma wrote:
>
> On Thu, Sep 19, 2019 at 8:10 AM Alexandra Wang wrote:
> >
> > On Tue, Sep 17, 2019 at 4:15 AM Ashutosh Sharma
> > wrote:
> >>
> >> create table t1(a int, b int) using zedstore;
> >> insert into t1 select i, i+10 from
В письме от четверг, 19 сентября 2019 г. 17:32:03 MSK пользователь Michael
Paquier написал:
> > src/test/modules/dummy_index_am directory check" I see a similar
> > failure with "ERROR: unrecognized lock mode: 2139062143". I changed
>
> > that to a PANIC and got a core file containing this
On Thu, Sep 19, 2019 at 11:47 AM Amit Kapila wrote:
>
> On Thu, Sep 19, 2019 at 10:25 AM Fabien COELHO wrote:
> > Hello Amit,
> >
> > >> Yes, on -i it will fail because the syntax will not be recognized.
> > >
> > > Maybe we should be checking the server version, which would allow to
> > >
On Thu, Sep 19, 2019 at 3:08 PM vignesh C wrote:
>
> On Mon, Jul 15, 2019 at 6:09 PM Luis Carril wrote:
> >
> > On 15.07.19 12:06, Daniel Gustafsson wrote:
> >
> Few comments:
>
> As you have specified required_argument in above:
> + {"include-foreign-data", required_argument, NULL, 11},
>
> The
On Mon, Jul 15, 2019 at 6:09 PM Luis Carril wrote:
>
> On 15.07.19 12:06, Daniel Gustafsson wrote:
>
Few comments:
As you have specified required_argument in above:
+ {"include-foreign-data", required_argument, NULL, 11},
The below check may not be required:
+ if (strcmp(optarg, "") == 0)
+ {
+
On Wed, Sep 18, 2019 at 10:25 AM Amit Kapila wrote:
>
> On Tue, Sep 17, 2019 at 5:48 PM James Coleman wrote:
> >
> > On Tue, Sep 17, 2019 at 2:21 AM Amit Kapila wrote:
> > >
> > >
> > > Let me know what you think of attached? I think we can back-patch
> > > this patch. What do you think?
On Thu, Sep 19, 2019 at 2:15 PM Amit Kapila wrote:
>
> On Thu, Sep 19, 2019 at 1:40 PM Filip Rembiałkowski
> wrote:
> >
> > There is a small but eye catching glitch in the v12 (and master) docs
> > for "CREATE TABLE AS".
> >
> > https://www.postgresql.org/docs/12/sql-createtableas.html
> >
> >
Hello. I looked this and have some comments.
At Wed, 28 Aug 2019 12:49:46 +0300, Sergei Kornilov wrote in
<34084371566985...@sas1-0a6c2e2b59d7.qloud-c.yandex.net>
sk> Hello
sk>
sk> Updated patch attached. (also I merged into one file)
sk>
sk> > +
sk> > + WAL receiver will be restarted after
On Thu, Sep 19, 2019 at 1:40 PM Filip Rembiałkowski
wrote:
>
> There is a small but eye catching glitch in the v12 (and master) docs
> for "CREATE TABLE AS".
>
> https://www.postgresql.org/docs/12/sql-createtableas.html
>
> index b5c4ce6959..56d06838f1 100644
> ---
Hi Fabien,
On Thu, Sep 19, 2019 at 1:55 PM Fabien COELHO wrote:
> Hello Amit,
>
> >> Yes, on -i it will fail because the syntax will not be recognized.
> >
> > Maybe we should be checking the server version, which would allow to
> > produce more useful error messages when these options are used
On Thu, Sep 19, 2019 at 10:51:09AM +1200, Thomas Munro wrote:
> Let's see if I can see this on my Mac... yep, with "make -C
> src/test/modules/dummy_index_am directory check" I see a similar
> failure with "ERROR: unrecognized lock mode: 2139062143". I changed
> that to a PANIC and got a core
There is a small but eye catching glitch in the v12 (and master) docs
for "CREATE TABLE AS".
https://www.postgresql.org/docs/12/sql-createtableas.html
index b5c4ce6959..56d06838f1 100644
--- a/doc/src/sgml/ref/create_table_as.sgml
+++ b/doc/src/sgml/ref/create_table_as.sgml
@@ -146,7 +146,6 @@
Hello
Thank you for review!
> ISTM that you need to update the above parts in postgresql.conf.sample.
Good catch, I forgot about conf sample.
> ISTM that you need to update the above comment in walreceiver.c.
Changed
> If primary_conninfo is set to an empty string, walreceiver just shuts
On 2019-09-16 15:41, Tom Lane wrote:
> Peter Eisentraut writes:
>> The ecpglib major version (SO_MAJOR_VERSION) was changed in
>> bd7c95f0c1a38becffceb3ea7234d57167f6d4bf (Add DECLARE STATEMENT support
>> to ECPG.), but I don't see anything in that patch that would warrant
>> that. I think we
On Thu, Sep 19, 2019 at 10:25 AM Fabien COELHO wrote:
> Hello Amit,
>
> >> Yes, on -i it will fail because the syntax will not be recognized.
> >
> > Maybe we should be checking the server version, which would allow to
> > produce more useful error messages when these options are used against
> >
On Wed, Sep 18, 2019 at 10:33 PM Fabien COELHO wrote:
>
>
> Hello Amit,
>
> >> - use search_path to find at most one pgbench_accounts
> >> It still uses left join because I still think that it is appropriate.
> >> I added a lateral to avoid repeating the array_position call
> >> to
60 matches
Mail list logo
