On Tue, 18 Jun 2019 at 22:34, Tomas Vondra wrote:
>
> One slightly inconvenient thing I realized while playing with the
> address data set is that it's somewhat difficult to set the desired size
> of the multi-column MCV list.
>
> At the moment, we simply use the maximum statistic target for attri
A patch fixing this bug
https://www.postgresql.org/message-id/flat/15738-21723084f3009ceb%40postgresql.org
From 0144733c9f128108670f3654605f274928d83096 Mon Sep 17 00:00:00 2001
From: RekGRpth
Date: Fri, 26 Apr 2019 15:35:30 +0500
Subject: Disconnect from SPI manager on error
diff --git a/src/pl
The discussion in bug #15631 revealed that serial/identity sequences of
temporary tables should really also be temporary (easy), and that
serial/identity sequences of unlogged tables should also be unlogged.
But there is no support for unlogged sequences, so I looked into that.
If you copy the ini
Hi hackers,
Thank you for your many questions and feedbacks at PGCon 2019.
Attached is the patch rebased for the current master branch.
Regards,
Yugo Nagata
On Tue, 14 May 2019 15:46:48 +0900
Yugo Nagata wrote:
> On Mon, 1 Apr 2019 12:11:22 +0900
> Yugo Nagata wrote:
>
> > On Thu, 27 Dec 201
On Wed, Jun 19, 2019 at 11:35 PM Robert Haas wrote:
>
> On Tue, Jun 18, 2019 at 2:07 PM Robert Haas wrote:
> > On Tue, Jun 18, 2019 at 7:31 AM Amit Kapila wrote:
> > > [ new patches ]
> >
> > I tried writing some code [ to use these patches ].
>
> I spent some more time experimenting with this p
I am yet to work on Andres's latest detailed review comments, but I
thought before that, I should submit a patch for the below reported
issue because I was almost ready with the fix. Now I will start to
work on Andres's comments, for which I will reply separately.
On Fri, 1 Mar 2019 at 13:33, tush
On Thu, Jun 20, 2019 at 2:24 PM Dilip Kumar wrote:
>
> On Wed, Jun 19, 2019 at 11:35 PM Robert Haas wrote:
> >
> > On Tue, Jun 18, 2019 at 2:07 PM Robert Haas wrote:
> > > On Tue, Jun 18, 2019 at 7:31 AM Amit Kapila
> > > wrote:
> > > > [ new patches ]
> > >
> > > I tried writing some code [ t
On Wed, Jun 19, 2019 at 11:35 PM Robert Haas wrote:
>
> On Tue, Jun 18, 2019 at 2:07 PM Robert Haas wrote:
> > On Tue, Jun 18, 2019 at 7:31 AM Amit Kapila wrote:
> > > [ new patches ]
> >
> > I tried writing some code [ to use these patches ].
>
>
> for (;;)
> {
> UnpackedUndoRecord *uur = U
On Tue, Jun 18, 2019 at 5:07 PM shawn wang wrote:
>
> Masahiko Sawada 于2019年6月17日周一 下午8:30写道：
>>
>> On Fri, Jun 14, 2019 at 7:41 AM Tomas Vondra
>> wrote:
>> > I personally find the idea of encrypting tablespaces rather strange.
>> > Tablespaces are meant to define hysical location for objects,
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Also on the topic of process: 48 hours before a wrap deadline is
> *particularly* not the time to play fast and loose with this sort of
> thing. It'd have been better to wait till after this week's releases,
> so there'd at least be time to reco
Hi,
On 6/19/19 9:57 AM, Dmitry Dolgov wrote:
Here is what I was talking about, POC for an integration with index scan. About
using of create_skipscan_unique_path and suggested planner improvements, I hope
together with Jesper we can come up with something soon.
I made some minor changes, but
Hello,
I ran into someone with a system where big queries scanning 8GB+ of
all-in-cache data took consistently ~2.5x longer on a primary server
than on a replica. Both servers had concurrent activity on them but
plenty of spare capacity and similar specs. After some investigation
it turned out t
On 2019-06-12 13:16, Peter Eisentraut wrote:
> I haven't figured out the time zone issue yet, but I guess the solution
> might involve moving some of the code from check_recovery_target_time()
> to assign_recovery_target_time().
I think that won't work either. What we need to do is postpone the
i
On 6/20/19 8:34 AM, Masahiko Sawada wrote:
> I think even if we provide the per table encryption we can have
> encryption keys per tablepaces. That is, all tables on the same
> tablespace encryption use the same encryption keys but user can
> control encrypted objects per tables.
>
>> Will we add
On Thu, Jun 20, 2019 at 2:42 AM Amit Kapila wrote:
> Okay, one reason that comes to mind is we don't want to choke the
> system as applying undo can consume CPU and generate a lot of I/O. Is
> that you have in mind or something else?
Yeah, mainly that, but also things like log spam, and even pre
I decided to do some experiments with how we use Flex. The main
takeaway is that backtracking, which we removed in 2005, doesn't seem
to matter anymore for the core scanner. Also, state table size is of
marginal importance.
Using the information_schema Flex+Bison microbenchmark from Tom [1], I
tes
On Thu, Jun 20, 2019 at 6:48 AM Amit Kapila wrote:
> > for (;;)
> > {
> > UnpackedUndoRecord *uur = UndoFetchRecord(urp);
> > if (i like this one)
> > break;
> > urp = uur->uur_blkprev; // should be renamed, since zedstore +
> > probably others will have tuple chains not block
John Naylor writes:
> I decided to do some experiments with how we use Flex. The main
> takeaway is that backtracking, which we removed in 2005, doesn't seem
> to matter anymore for the core scanner. Also, state table size is of
> marginal importance.
Huh. That's really interesting, because remo
> Looking at the discussion where the feature was added, I think changing the
> EXPLAIN just wasn't considered.
I think this is an oversight. It is very useful to have this on
EXPLAIN.
> The attached patch adds "avoided" to "exact" and "lossy" as a category
> under "Heap Blocks".
It took me a w
On Thu, Jun 20, 2019 at 6:44 AM Amit Kapila wrote:
> BTW, while looking at the code of UndoFetchRecord, I see some problem.
> There is a coding pattern like
> if()
> {
> }
> else
> {
>LWLockAcquire()
> ..
> ..
> }
>
> LWLockRelease().
>
> I think this is not correct.
Independently of that
RekGRpth writes:
> A patch fixing this bug
> https://www.postgresql.org/message-id/flat/15738-21723084f3009ceb%40postgresql.org
I do not think this code change is necessary or appropriate.
It is not plpgsql's job to clean up after other backend subsystems
during a transaction abort. Maybe if plp
On Thu, Jun 20, 2019 at 8:01 PM Robert Haas wrote:
>
> On Thu, Jun 20, 2019 at 2:42 AM Amit Kapila wrote:
> > Okay, one reason that comes to mind is we don't want to choke the
> > system as applying undo can consume CPU and generate a lot of I/O. Is
> > that you have in mind or something else?
>
Hi,
On 2019-06-20 10:52:54 -0400, Tom Lane wrote:
> John Naylor writes:
> > It would be nice to have confirmation to make sure I didn't err
> > somewhere, and to try a more real-world benchmark.
>
> I don't see much wrong with using information_schema.sql as a parser/lexer
> benchmark case. We
On Thu, Jun 20, 2019 at 8:52 AM Stephen Frost wrote:
> I don't want to come across as implying that I'm saying what was done
> was 'fine', or that we shouldn't be having this conversation, I'm just
> trying to figure out how we can frame it in a way that we learn from it
> and work to improve on i
Hi,
On 2019-06-20 15:42:14 +0200, Peter Eisentraut wrote:
> On 2019-06-12 13:16, Peter Eisentraut wrote:
> > I haven't figured out the time zone issue yet, but I guess the solution
> > might involve moving some of the code from check_recovery_target_time()
> > to assign_recovery_target_time().
>
Hi,
On 2019-06-20 12:02:30 -0400, Robert Haas wrote:
> On Thu, Jun 20, 2019 at 8:52 AM Stephen Frost wrote:
> > I don't want to come across as implying that I'm saying what was done
> > was 'fine', or that we shouldn't be having this conversation, I'm just
> > trying to figure out how we can fram
On Thu, Jun 20, 2019 at 11:35 AM Amit Kapila wrote:
> This delay is for *not* choking the system by constantly performing
> undo requests that consume a lot of CPU and I/O as discussed in above
> point. For holding off the same error request to be re-tried, we need
> next_retry_time type of metho
Hi,
Right now using -w for shutting down clusters with a bit bigger shared
buffers will very frequently fail, because the shutdown checkpoint takes
much longer than 60s. Obviously that can be addressed by manually
setting PGCTLTIMEOUT to something higher, but forcing many users to do
that doesn't
Hi
Searching subject for "Specify thread msgid" field doesn't work. It returns
empty result set every time.
Regards
Pavel
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-06-20 12:02:30 -0400, Robert Haas wrote:
> > On Thu, Jun 20, 2019 at 8:52 AM Stephen Frost wrote:
> > > I don't want to come across as implying that I'm saying what was done
> > > was 'fine', or that we shouldn't be having this conv
On 2019-Jun-20, Andres Freund wrote:
> On 2019-06-20 12:02:30 -0400, Robert Haas wrote:
> > I agree that it's a difficult situation. I do kind of wonder whether
> > we were altogether overreacting. If we had shipped it as it was,
> > what's the worst thing that would have happened?
>
> I think
On Thu, Jun 20, 2019 at 1:28 PM Alvaro Herrera wrote:
> I suppose we could have a moratorium on commits starting from (say) EOB
> Wednesday of the week prior to the release; patches can only be
> committed after that if they have ample support (where "ample support"
> might be defined as having +1
On Tue, Jun 18, 2019 at 9:08 PM Thomas Munro wrote:
> It's currently set to 4, but I now think that was too cautious. It
> tries to avoid fragmentation by ramping up slowly (that is, memory
> allocated and in some cases committed by the operating system that we
> don't turn out to need), but it's
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jun 20, 2019 at 1:28 PM Alvaro Herrera
> wrote:
> > I suppose we could have a moratorium on commits starting from (say) EOB
> > Wednesday of the week prior to the release; patches can only be
> > committed after that if they have
Greetings,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> Searching subject for "Specify thread msgid" field doesn't work. It returns
> empty result set every time.
Is this still not working? I was chatting with Magnus and it seems
possible this was broken and then fixed already.
Thanks,
S
I wrote:
> Nosing around in tab-complete.c, I notice a fair number of other
> places where we're doing COMPLETE_WITH() with just a single possible
> completion. Knowing what we know now, in each one of those places
> libreadline will suppose that that completion is the only syntactically
> legal c
Hi,
On 2019-06-20 14:20:27 -0400, Robert Haas wrote:
> On Tue, Jun 18, 2019 at 9:08 PM Thomas Munro wrote:
> > Perhaps also the number of slots per backend should be dynamic, so
> > that you have the option to increase it from the current hard-coded
> > value of 2 if you don't want to increase ma
čt 20. 6. 2019 v 20:27 odesílatel Stephen Frost napsal:
> Greetings,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
> > Searching subject for "Specify thread msgid" field doesn't work. It
> returns
> > empty result set every time.
>
> Is this still not working? I was chatting with Magnus a
> "Stephen" == Stephen Frost writes:
Stephen> In the situation that started this discussion, a change had
Stephen> already been made and it was only later realized that it
Stephen> caused a regression.
Just to keep the facts straight:
The regression was introduced by importing tzdb 2019a
Greetings,
* Andrew Gierth (and...@tao11.riddles.org.uk) wrote:
> > "Stephen" == Stephen Frost writes:
>
> Stephen> In the situation that started this discussion, a change had
> Stephen> already been made and it was only later realized that it
> Stephen> caused a regression.
>
> Just to
Stephen Frost writes:
> * Andrew Gierth (and...@tao11.riddles.org.uk) wrote:
> "Stephen" == Stephen Frost writes:
>> Stephen> Piling on to that, the regression was entwined with other
>> Stephen> important changes that we wanted to include in the release.
>>
>> I'm not sure what you're referring
> "Tom" == Tom Lane writes:
>> I was referring to the fact that the regression was introduced by a,
>> presumably important, tzdb update (2019a, as mentioned above). At
>> least, I made the assumption that the commit of the import of 2019a
>> had more than just the change that introduced
On Thu, Jun 20, 2019 at 02:20:27PM -0400, Robert Haas wrote:
> On Tue, Jun 18, 2019 at 9:08 PM Thomas Munro wrote:
> > It's currently set to 4, but I now think that was too cautious. It
> > tries to avoid fragmentation by ramping up slowly (that is, memory
> > allocated and in some cases committe
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Keep in mind that dealing with whatever tzdb chooses to ship is
> Tom> not optional from our standpoint. Even if we'd refused to import
> Tom> 2019a, every installation using --with-system-tzdata (which, I
> Tom> sincerely hope, include
Andrew Gierth writes:
> Tom's "fix" of backpatching 23bd3cec6 (which happened on Friday 14th)
> addressed only a subset of cases, as far as I know working only on Linux
> (the historical convention has always been for /etc/localtime to be a
> copy of a zonefile, not a symlink to one). I only decid
On Thu, Jun 20, 2019 at 08:08:44AM +0100, Dean Rasheed wrote:
On Tue, 18 Jun 2019 at 22:34, Tomas Vondra wrote:
One slightly inconvenient thing I realized while playing with the
address data set is that it's somewhat difficult to set the desired size
of the multi-column MCV list.
At the momen
On Thu, Jun 20, 2019 at 06:55:41AM +0100, Dean Rasheed wrote:
On Tue, 18 Jun 2019 at 21:59, Tomas Vondra wrote:
The current implementation of multi-column MCV lists (added in this
cycle) uses a fairly simple algorithm to pick combinations to include in
the MCV list. We just compute a minimum n
On 2019-May-20, Paul A Jungwirth wrote:
> On Mon, May 20, 2019 at 9:44 PM Amit Langote
> wrote:
> > This sounds more like an open item to me [1], not something that have to
> > be postponed until the next CF.
> >
> > [1] https://wiki.postgresql.org/wiki/PostgreSQL_12_Open_Items
>
> Oh sorry, I a
This patch was applied as f73293aba4d4. Thanks, Paul and Michael.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Jun 20, 2019 at 09:30:34AM +0200, Peter Eisentraut wrote:
> The discussion in bug #15631 revealed that serial/identity sequences of
> temporary tables should really also be temporary (easy), and that
> serial/identity sequences of unlogged tables should also be unlogged.
> But there is no s
On Thu, Jun 20, 2019 at 07:34:10PM -0400, Alvaro Herrera wrote:
> This patch was applied as f73293aba4d4. Thanks, Paul and Michael.
Thanks for the thread update, Alvaro. I completely forgot to mention
the commit on this thread.
--
Michael
signature.asc
Description: PGP signature
On Thu, Apr 25, 2019 at 4:01 AM Alvaro Herrera wrote:
> So, while testing this I noticed that pg_restore fails with deadlocks if
> you do a parallel restore if the --load-via-partition-root switch was
> given to pg_dump. Is that a known bug?
Was investigating --load-via-partition-root with a cow
52 matches
Mail list logo
