Hello
Correct index lookup is a difficult task. I tried to implement this
previously...
But the answer in SO is a bit incomplete for recent postgresql releases.
Seqscan is not the only possible way to set not null in pg12+. My patch was
commited ( https://commitfest.postgresql.org/22/1389/ ) a
On Thu, May 28, 2020 at 05:55:59PM -0700, Andres Freund wrote:
> And there only for very old servers (< 8.2), according to Hiroshi
> Inoue. Found that out post 12 freeze. I was planning to drop them for
> 13, but I unfortunately didn't get around to do so :(
[... digging ...]
Ah, I think I see you
On Fri, 2020-05-29 at 00:16 +0200, Daniel Gustafsson wrote:
> Since OpenSSL is now releasing 3.0.0-alpha versions, I took a look at using it
> with postgres to see what awaits us. As it is now shipping in releases (with
> GA planned for Q4), users will probably soon start to test against it so I
>
On Thu, May 28, 2020 at 05:15:17PM +0200, Daniel Gustafsson wrote:
> The comment in be-secure-openssl.c didn't get the memo that the hardcoded DH
> parameters moved in 573bd08b99e277026e87bb55ae69c489fab321b8. The attached
> updates the wording, keeping it generic enough that we wont need to updat
On Fri, May 29, 2020 at 5:59 AM Mark Dilger
wrote:
>
> > On May 21, 2020, at 12:12 AM, John Naylor
> > wrote:
> > very picky in general. As a test, it also successfully finds a
> > function for the OS "words" file, the "D" sets of codepoints, and for
> > sets of the first n built-in OIDs, where
There's the age-old problem of SET NOT NULL being impossible on large actively
used tables, because it needs to lock the table and do a table scan to check if
there are any existing NULL values. I currently have a table that's not
particularly huge but a scan takes 70 seconds, which causes unacc
At Thu, 28 May 2020 09:08:19 -0400, Dave Cramer
wrote in
> On Thu, 28 May 2020 at 05:11, Kyotaro Horiguchi
> wrote:
> > Mmm. It is not the proper way to use physical replication and it's
> > totally accidental that that worked (or even it might be a bug). The
> > documentation is saying as the
Hi,
On 2020-05-20 10:32:18 +0300, Konstantin Knizhnik wrote:
> On 20.05.2020 08:10, Andres Freund wrote:
> > On May 19, 2020 8:05:00 PM PDT, Noah Misch wrote:
> > > On Tue, May 19, 2020 at 04:07:29PM +0300, Konstantin Knizhnik wrote:
> > > > Definition of pg_atomic_compare_exchange_u64 requires a
Thanks all of you for your feedback.
On Fri, May 29, 2020 at 9:04 AM Tom Lane wrote:
> Tomas Vondra writes:
> > On Wed, May 27, 2020 at 09:58:04PM +0800, Andy Fan wrote:
> >> so we need to optimize the cost model for such case, the method is the
> >> patch I mentioned above.
>
> > Making the pl
On Thu, 2020-05-28 at 20:57 +0200, Tomas Vondra wrote:
> Attached is a patch adding CP_SMALL_TLIST to create_agg_plan and
> create_groupingsets_plan.
Looks good, except one question:
Why would aggstrategy ever be MIXED when in create_agg_path? Wouldn't
that only happen in create_groupingsets_path
Andres Freund writes:
> On 2020-04-05 12:51:56 -0400, Tom Lane wrote:
>> I think it might be a good idea to make relations-without-storage
>> set up rd_tableam as a vector of dummy functions that will throw
>> some suitable complaint about "relation lacks storage". NULL is
>> a horrible default f
> >so we need to optimize the cost model for such case, the method is the
> >patch I mentioned above.
>
> Making the planner more robust w.r.t. to estimation errors is nice, but
> I wouldn't go as far saying we should optimize for such cases. The stats
> can be arbitrarily off, so should we expect
Hi,
On 2020-04-05 12:51:56 -0400, Tom Lane wrote:
> (2) The proximate cause of the crash is that rd_tableam is zero,
> so that the interface functions in tableam.h just crash hard.
> This seems like a pretty bad thing; does anyone want to promise
> that there are no other oversights of the same il
Tomas Vondra writes:
> On Wed, May 27, 2020 at 09:58:04PM +0800, Andy Fan wrote:
>> so we need to optimize the cost model for such case, the method is the
>> patch I mentioned above.
> Making the planner more robust w.r.t. to estimation errors is nice, but
> I wouldn't go as far saying we should
Hi,
On 2020-05-22 19:32:57 -0400, Alvaro Herrera wrote:
> On 2020-Apr-09, Michael Paquier wrote:
>
> > Playing more with this stuff, it happens that we have zero code
> > coverage for currtid() and currtid2(), and the main user of those
> > functions I can find around is the ODBC driver:
> > http
On Tue, 2020-05-26 at 17:40 -0700, Jeff Davis wrote:
> On Tue, 2020-05-26 at 21:15 +0200, Tomas Vondra wrote:
> > Yeah. I agree prefetching is definitely out of v13 scope. It might
> > be
> > interesting to try how useful would it be, if you're willing to
> > spend
> > some time on a prototype.
>
On Wed, May 27, 2020 at 09:58:04PM +0800, Andy Fan wrote:
On Wed, May 27, 2020 at 8:01 PM Ashutosh Bapat <
ashutosh.ba...@2ndquadrant.com> wrote:
On Wed, 27 May 2020 at 04:43, Andy Fan wrote:
You can use the attached sql to reproduce this issue, but I'm not sure
you can
get the above resul
Hi,
On 2020-05-27 07:49:45 -0700, Jesse Zhang wrote:
> On the mensiversary of the last response, what can I do to help move
> this along (aside from heeding the advice "don't use LLVM HEAD")?
Sorry, I had looked at it at point with the intent to commit it, and hit
some stupid small snags (*). And
Since OpenSSL is now releasing 3.0.0-alpha versions, I took a look at using it
with postgres to see what awaits us. As it is now shipping in releases (with
GA planned for Q4), users will probably soon start to test against it so I
wanted to be prepared.
Regarding the deprecations, we can either s
> On 28.05.2020, at 23:43, Tom Lane wrote:
>
> Markus Winand writes:
>> However, if the conflict happens in a subquery, it doesn’t anymore:
>
>>WITH data (c, posix) AS (
>>values ('a' COLLATE "C", 'b' COLLATE "POSIX")
>>)
>>SELECT *
>> FROM (S
On 2020-05-28 17:07:46 +0900, Michael Paquier wrote:
> Please note that I would still wait for their next GA release to plug
> in any extra holes at the same time. @Jesse: or is this change
> actually part of the upcoming 10.0.1?
Why? I plan to just commit this change now.
> On May 21, 2020, at 12:12 AM, John Naylor wrote:
>
> Hi,
>
> Attached is a patch to use perfect hashing to speed up Unicode
> normalization quick check.
>
> 0001 changes the set of multipliers attempted when generating the hash
> function. The set in HEAD works for the current set of NFC c
Markus Winand writes:
> However, if the conflict happens in a subquery, it doesn’t anymore:
> WITH data (c, posix) AS (
> values ('a' COLLATE "C", 'b' COLLATE "POSIX")
> )
> SELECT *
> FROM (SELECT *, c || posix AS none FROM data) data
>
> On May 20, 2020, at 12:03 AM, Michael Paquier wrote:
>
> On Tue, May 19, 2020 at 09:32:15AM -0400, Tom Lane wrote:
>> Hm, I'm pretty certain that data_directory does not need this because
>> canonicalization is done elsewhere; the most that you could accomplish
>> there is to cause problems.
Hi!
I think I’ve found a bug related to the strength of collations. Attached is a
WIP patch, that address some other issues too.
In this this example, the conflict of implicit collations propagates correctly:
WITH data (c, posix) AS (
values ('a' COLLATE "C", 'b' COLLATE
Thomas Munro escribió:
> @@ -1094,8 +1103,16 @@ WALRead(XLogReaderState *state,
> XLByteToSeg(recptr, nextSegNo,
> state->segcxt.ws_segsize);
> state->routine.segment_open(state, nextSegNo, &tli);
>
> - /* This shouldn't happen --
On Thu, May 21, 2020 at 3:17 AM Alexander Korotkov
wrote:
>
> On Thu, May 21, 2020 at 12:37 AM Peter Geoghegan wrote:
> > Commit 911e7020770 added a variety of new support routines to index
> > AMs. For example, it added a support function 5 to btree (see
> > BTOPTIONS_PROC), but didn't document
> On Mar 2, 2020, at 5:29 PM, Peter Geoghegan wrote:
>
> On Sun, Mar 1, 2020 at 12:15 PM Floris Van Nee
> wrote:
>> Minor conflict with that patch indeed. Attached is rebased version. I'm
>> running some tests now - will post the results here when finished.
>
> Thanks.
>
> We're going to
On Wed, May 27, 2020 at 11:07:04AM +0200, Tomas Vondra wrote:
On Tue, May 26, 2020 at 06:42:50PM -0700, Melanie Plageman wrote:
On Tue, May 26, 2020 at 5:40 PM Jeff Davis wrote:
On Tue, 2020-05-26 at 21:15 +0200, Tomas Vondra wrote:
As for the tlist fix, I think that's mostly ready too - th
On Thu, May 28, 2020 at 1:07 AM Michael Paquier wrote:
> Please note that I would still wait for their next GA release to plug
> in any extra holes at the same time. @Jesse: or is this change
> actually part of the upcoming 10.0.1?
No a refactoring like this was not in the back branches (nor is
On 5/27/20 3:29 AM, Michael Paquier wrote:
>> I think that each of those tests should have a separate unlikely() marker,
>> since the whole point here is that we don't expect either of those tests
>> to yield true in the huge majority of CHECK_FOR_INTERRUPTS executions.
>
> +1. I am not sure that
On Thu, May 28, 2020 at 10:01 AM Stephen Frost wrote:
> as if we don't know what columns are
Amen to that!
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
The comment in be-secure-openssl.c didn't get the memo that the hardcoded DH
parameters moved in 573bd08b99e277026e87bb55ae69c489fab321b8. The attached
updates the wording, keeping it generic enough that we wont need to update it
should the parameters move again.
cheers ./daniel
openssl_dh_com
On Thu, May 28, 2020 at 7:52 AM Tom Lane wrote:
> (BTW, adding an option for auto-rollback wouldn't change my opinion
> about that. Not all side-effects of a query can be rolled back. Thus,
> if there is an auto-rollback option, it mustn't be GUC-adjustable
> either.)
>
Yeah, I've worked mysel
"David G. Johnston" writes:
> The ANALYZE option should not be part of the GUC setup.
Yeah. While I'm generally not in favor of putting GUCs into the mix
here, the only one that seriously scares me is a GUC that would affect
whether the EXPLAIN'd query executes or not. A GUC that causes buffer
Noah Misch writes:
> On Wed, Feb 19, 2020 at 08:42:36PM +0100, Peter Eisentraut wrote:
>> I think there should just
>> be an option "plpython is: {2|3|don't build it at all}". Then packagers can
>> match this to what their plan for /usr/bin/python* is -- which appears to be
>> different everywher
On Thu, May 28, 2020 at 6:42 AM Robert Haas wrote:
> On Wed, May 27, 2020 at 9:33 PM David G. Johnston
> wrote:
> > I'm not seeing enough similarity with the reasons for, and specific
> behaviors, of those previous GUCs to dismiss this proposal on that basis
> alone. These are "crap we messed t
On Wed, May 27, 2020 at 6:51 PM Amit Langote wrote:
>
> So in Rajkumar's example, the cursor is declared as:
>
> CURSOR IS SELECT * FROM tbl WHERE c1< 5 FOR UPDATE;
>
> and the WHERE CURRENT OF query is this:
>
> UPDATE tbl SET c2='aa' WHERE CURRENT OF cur;
Thanks for the clarification. So it l
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, May 28, 2020 at 8:53 AM Peter Eisentraut
> wrote:
> > More along these lines: We could also remove the ENCRYPTED and
> > UNENCRYPTED keywords from CREATE and ALTER ROLE. AFAICT, these have
> > never been emitted by pg_dump or psql
On Thu, May 28, 2020 at 8:53 AM Peter Eisentraut
wrote:
> More along these lines: We could also remove the ENCRYPTED and
> UNENCRYPTED keywords from CREATE and ALTER ROLE. AFAICT, these have
> never been emitted by pg_dump or psql, so there are no concerns from
> that end. Thoughts?
I have a qu
On Wed, May 27, 2020 at 9:33 PM David G. Johnston
wrote:
> I'm not seeing enough similarity with the reasons for, and specific
> behaviors, of those previous GUCs to dismiss this proposal on that basis
> alone. These are "crap we messed things up" switches that alter a query
> behind the scene
On 5/28/20 8:10 AM, Peter Eisentraut wrote:
> On 2020-05-27 15:25, Jonathan S. Katz wrote:
>> $ initdb -D data --auth-local=scram-sha-256 --auth-host=md5
>>
>> Got an error message:
>>
>> "initdb: error: must specify a password for the superuser to enable md5
>> authentication"
>>
>> For the last t
On Wed, May 27, 2020 at 4:00 PM Peter Eisentraut
wrote:
> First, consider that git has over 170 subcommands. PostgreSQL currently
> has 36, and we're probably not going to add dozens more any time soon.
> So the issue is not of the same scope. It also seems to me that the way
> git is organized
On Thu, 28 May 2020 at 05:11, Kyotaro Horiguchi
wrote:
> Hello, Vladimir.
>
> At Thu, 28 May 2020 11:57:23 +0300, Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote in
> > Kyotaro>It seems to me that that crash means Pgjdbc is initiating a
> logical
> > Kyotaro>replication connection to sta
On 2020-05-27 15:59, Stephen Frost wrote:
Agreed- let's remove the legacy options. As I've mentioned elsewhere,
distros may manage the issue for us, and if we want to get into it, we
could consider adding support to pg_upgrade to complain if it comes
across a legacy setting that isn't valid. I'
On 2020-05-27 15:25, Jonathan S. Katz wrote:
$ initdb -D data --auth-local=scram-sha-256 --auth-host=md5
Got an error message:
"initdb: error: must specify a password for the superuser to enable md5
authentication"
For the last two, that behavior is to be expected (after all, you've set
the tw
On Wed, May 27, 2020 at 8:22 PM Dilip Kumar wrote:
>
> On Tue, May 26, 2020 at 7:45 AM Dilip Kumar wrote:
> >
> >
> > Okay, sending again.
>
> While reviewing/testing I have found a couple of problems in 0005 and
> 0006 which I have fixed in the attached version.
>
I haven't reviewed the new fix
Hi all,
While working on some monitoring tasks I realised that the pg_monitor
role doesn't have access to the pg_replication_origin_status.
Are there any strong thoughts on not giving pg_monitor access to this
view, or is it just something that nobody asked for yet? I can't find
any reason for pg
On Thu, May 28, 2020 at 3:06 PM Amit Langote
wrote:
> On Thu, May 28, 2020 at 1:36 PM amul sul wrote:
> > On Wed, May 27, 2020 at 12:53 PM Amit Langote
> wrote:
> >> Actually, if you declare the cursor without FOR SHARE/UPDATE, the case
> >> would fail even with traditional inheritance:
> >>
>
On Sun, May 3, 2020 at 3:12 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> I've finally performed couple of tests involving more IO. The
> not-that-big dataset of 1.5 GB for the replica with the memory allowing
> fitting ~ 1/6 of it, default prefetching parameters and an update
> workload with u
On Thu, May 28, 2020 at 1:36 PM amul sul wrote:
> On Wed, May 27, 2020 at 12:53 PM Amit Langote wrote:
>> I guess the workaround is to declare the cursor such that no
>> partitions/children are pruned/excluded.
>
> Disabling pruning as well -- at-least for the statement or function.
Now *that* i
On Thu, May 28, 2020 at 2:41 PM Amit Kapila wrote:
>
> On Thu, May 28, 2020 at 12:46 PM Dilip Kumar wrote:
> >
> > On Tue, May 26, 2020 at 12:00 PM Amit Kapila
> > wrote:
> > >
> > > Isn't this problem only for subxact file as we anyway create changes
> > > file as part of start stream message
On Thu, May 28, 2020 at 3:15 PM Amit Kapila wrote:
>
> On Thu, May 28, 2020 at 12:57 PM Dilip Kumar wrote:
> >
> > On Tue, May 26, 2020 at 3:04 PM Amit Kapila wrote:
> > >
> > > Why we need memory-related to subxacts till the worker is alive? As
> > > we have now, after reading subxact info (su
On Thu, May 28, 2020 at 12:57 PM Dilip Kumar wrote:
>
> On Tue, May 26, 2020 at 3:04 PM Amit Kapila wrote:
> >
> > Why we need memory-related to subxacts till the worker is alive? As
> > we have now, after reading subxact info (subxact_info_read), we need
> > to ensure that it is freed after its
On Thu, May 28, 2020 at 1:36 PM amul sul wrote:
> On Wed, May 27, 2020 at 12:53 PM Amit Langote wrote:
>> Actually, if you declare the cursor without FOR SHARE/UPDATE, the case
>> would fail even with traditional inheritance:
>>
>> drop table if exists p cascade;
>> create table p (a int);
>> cre
On Thu, May 28, 2020 at 12:46 PM Dilip Kumar wrote:
>
> On Tue, May 26, 2020 at 12:00 PM Amit Kapila wrote:
> >
> > Isn't this problem only for subxact file as we anyway create changes
> > file as part of start stream message which should have come after
> > abort? If so, can't we detect whether
Hello, Vladimir.
At Thu, 28 May 2020 11:57:23 +0300, Vladimir Sitnikov
wrote in
> Kyotaro>It seems to me that that crash means Pgjdbc is initiating a logical
> Kyotaro>replication connection to start physical replication.
>
> Well, it used to work previously, so it might be a breaking change f
Hi
st 27. 5. 2020 v 13:31 odesílatel Amit Khandekar
napsal:
> On Tue, 26 May 2020 at 09:06, Amit Khandekar
> wrote:
> >
> > On Sat, 23 May 2020 at 23:24, Pavel Stehule
> wrote:
> > >
> > >FOR counter IN 1..180 LOOP
> > > id = 0; id = 0; id1 = 0;
> > > id2 = 0; id3 = 0; id1
Kyotaro>It seems to me that that crash means Pgjdbc is initiating a logical
Kyotaro>replication connection to start physical replication.
Well, it used to work previously, so it might be a breaking change from the
client/application point of view.
Vladimir
At Thu, 28 May 2020 15:44:26 +0900, Michael Paquier wrote
in
> On Wed, May 27, 2020 at 04:35:51PM +0900, Michael Paquier wrote:
> > On Wed, May 27, 2020 at 04:21:59PM +0900, Kyotaro Horiguchi wrote:
> > > I don't oppose to full-spelling. How about the attached?
> >
> > No problem from me.
>
>
On Wed, May 27, 2020 at 07:49:45AM -0700, Jesse Zhang wrote:
> For bystanders: Andres and I argued for "fixing this sooner and
> backpatch" and Michael suggested "wait longer and whack all moles". We
> have waited, and there seems to be only one mole (finding all dead
> unbroken "include"s was left
At Thu, 28 May 2020 09:07:04 +0300, Vladimir Sitnikov
wrote in
> Pgjdbc test suite identified a SIGSEGV in the recent HEAD builds of
> PostgreSQL, Ubuntu 14.04.5 LTS
>
> Here's a call stack:
> https://travis-ci.org/github/pgjdbc/pgjdbc/jobs/691794110#L7484
> The crash is consistent, and it repr
On Wed, Feb 19, 2020 at 08:42:36PM +0100, Peter Eisentraut wrote:
> I think there should just
> be an option "plpython is: {2|3|don't build it at all}". Then packagers can
> match this to what their plan for /usr/bin/python* is -- which appears to be
> different everywhere.
Today, we do not give
On Thu, May 28, 2020 at 04:32:22PM +0900, Kyotaro Horiguchi wrote:
> I think that's not the case. I think I cause this crash with the
> HEAD. I'll post a fix soon.
>
> Pgjdbc seems initiating physical replication on a logical replication
> session.
Let me see... Indeed:
$ psql "replication=dat
On Tue, May 26, 2020 at 08:49:44AM +0900, Michael Paquier wrote:
> NB: I found some incorrect comments as per the attached:
> s/open_segment/segment_open/
> s/close_segment/segment_close/
And fixed this one with f93bb0c.
--
Michael
signature.asc
Description: PGP signature
At Thu, 28 May 2020 16:22:33 +0900, Michael Paquier wrote
in
> On Thu, May 28, 2020 at 09:07:04AM +0300, Vladimir Sitnikov wrote:
> > The CI history shows that HEAD was good at 11 May 13:27 UTC, and it became
> > bad by 19 May 14:00 UTC,
> > so the regression was introduced somewhere in-between.
On Tue, May 26, 2020 at 3:04 PM Amit Kapila wrote:
>
> On Mon, May 25, 2020 at 8:07 PM Dilip Kumar wrote:
> >
> > On Fri, May 22, 2020 at 11:54 AM Amit Kapila
> > wrote:
> > >
> > > 4.
> > > + * XXX Do we need to allocate it in TopMemoryContext?
> > > + */
> > > +static void
> > > +subxact_info
On Thu, May 28, 2020 at 09:07:04AM +0300, Vladimir Sitnikov wrote:
> The CI history shows that HEAD was good at 11 May 13:27 UTC, and it became
> bad by 19 May 14:00 UTC,
> so the regression was introduced somewhere in-between.
>
> Does that ring any bells?
It does, thanks! This would map with 1
On Tue, May 26, 2020 at 12:00 PM Amit Kapila wrote:
>
> On Fri, May 22, 2020 at 6:22 PM Dilip Kumar wrote:
> >
> > On Mon, May 18, 2020 at 4:10 PM Amit Kapila wrote:
> > >
> > > On Sun, May 17, 2020 at 12:41 PM Dilip Kumar
> > > wrote:
> > > >
> > > > On Fri, May 15, 2020 at 4:04 PM Amit Kapil
On Wed, May 27, 2020 at 11:59:59AM -0400, Alvaro Herrera wrote:
> In the discussion that led to 811b6e36a9e2 I did suggest to use "read
> only M of N" instead, but there wasn't enough discussion on that fine
> point so we settled on what you now call prevalent without a lot of
> support specificall
70 matches
Mail list logo
