Hi all,
I want to support canceling for a plpython query which may be a busy loop.
I found some discussions on pgsql-hackers 2 years ago. Below is the link.
https://www.postgresql.org/message-id/cafywgj3+xg7ecl2nu-mxx6p+o6c895pm3myz-b+9n9dffeh...@mail.gmail.com
Mario wrote a patch to fix this p
On 10 May 2018 at 05:33, David Rowley wrote:
> On 10 May 2018 at 16:13, Amit Langote wrote:
>> The patch to ExecInsert looks good, but I think we also need to do the
>> same thing in CopyFrom.
>
> I think so too.
>
> Updated patch attached.
Patch is good.
The cause of this oversight is the lack
Hello,
I recently investigated a problem where a standby is promoted to be the new
master. The promoted standby crashes shortly thereafter for whatever
reason. Upon running the crash recovery, the promoted standby (now master)
PANICs with message such as:
PANIC,XX000,"WAL contains references to i
On 2018/05/10 13:33, David Rowley wrote:
> On 10 May 2018 at 16:13, Amit Langote wrote:
>> The patch to ExecInsert looks good, but I think we also need to do the
>> same thing in CopyFrom.
>
> I think so too.
>
> Updated patch attached.
Thanks, looks good.
Regards,
Amit
On 10 May 2018 at 16:13, Amit Langote wrote:
> The patch to ExecInsert looks good, but I think we also need to do the
> same thing in CopyFrom.
I think so too.
Updated patch attached.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training
On 2018/05/10 12:55, David Rowley wrote:
> Hi,
>
> Scanning ExecInsert, it looks like there's a needless additional
> partition constraint check against the tuple. This should only be
> required if there's a before row INSERT trigger. The code block up
> one from the additional check tries to dis
On Wed, May 9, 2018 at 5:20 PM, Etsuro Fujita
wrote:
>
> (2018/04/25 18:51), Ashutosh Bapat wrote:
>> Actually I noticed that ConvertRowtypeExpr are used to cast a child's
>> whole row reference expression (not just a Var node) into that of its
>> parent and not. For example a cast like NULL::chil
Hi,
Scanning ExecInsert, it looks like there's a needless additional
partition constraint check against the tuple. This should only be
required if there's a before row INSERT trigger. The code block up
one from the additional check tries to disable the check, but it goes
ahead regardless, providi
On 2018/05/10 10:02, Michael Paquier wrote:
> Something
> that I find confusing on HEAD though is that DefineIndex calls itself
> around line 1006 and cascades through each children but there is no
> context about the error.
>
> For example if I have this partition layer:
> CREATE TABLE measuremen
On 2018/05/10 10:37, Michael Paquier wrote:
> On Thu, May 10, 2018 at 10:15:05AM +0900, Amit Langote wrote:
>> While I agree with this, let me point out that we do allow inherited check
>> constraints on foreign tables that are not actually enforced locally.
>>
>> create table p (a int) partition b
David Rowley wrote:
> On 10 May 2018 at 14:01, Alvaro Herrera wrote:
> > I'm thinking something a bit more radical. First, since partition
> > pruning is the future and constraint exclusion is soon to be a thing of
> > the past, we should describe pruning first, and then describe exclusion
> > in
On 10 May 2018 at 14:01, Alvaro Herrera wrote:
> I'm thinking something a bit more radical. First, since partition
> pruning is the future and constraint exclusion is soon to be a thing of
> the past, we should describe pruning first, and then describe exclusion
> in terms of pruning.
But... tha
David Rowley wrote:
> Thanks for reviewing again.
Hi,
I'm thinking something a bit more radical. First, since partition
pruning is the future and constraint exclusion is soon to be a thing of
the past, we should describe pruning first, and then describe exclusion
in terms of pruning. Second, I'
On 10 May 2018 at 06:55, Andres Freund wrote:
> Do you have a patchset including that? I didn't find anything after a
> quick search...
There was an earlier rev on the other thread but without msync checks.
I've added panic for msync in the attached, and tidied the comments a bit.
I didn't ad
On Thu, May 10, 2018 at 10:15:05AM +0900, Amit Langote wrote:
> While I agree with this, let me point out that we do allow inherited check
> constraints on foreign tables that are not actually enforced locally.
>
> create table p (a int) partition by range (a);
> create table p1 partition of p for
On 2018/05/09 23:57, Robert Haas wrote:
> For right now, I think the options are (1) throw an ERROR if we
> encounter a foreign table or (2) silently skip the foreign table. I
> think (2) is defensible for non-UNIQUE indexes, because the index is
> just a performance optimization.
Along with othe
On Wed, May 09, 2018 at 11:10:43AM -0400, Tom Lane wrote:
> Agreed about unique indexes. I suggest that we throw an error for both
> cases, because (1) having unique and non-unique indexes behave differently
> for this purpose seems pretty weird; (2) throwing an error now preserves
> our options t
On 2018/05/09 22:43, Alvaro Herrera wrote:
> Amit Langote wrote:
>> On 2018/05/09 11:31, David Rowley wrote:
>>> On 9 May 2018 at 14:29, Amit Langote wrote:
On 2018/05/09 11:20, Michael Paquier wrote:
> While looking at this code, is there any reason to not make
> gen_partprune_steps
On 2018-05-01 09:38:03 +0800, Craig Ringer wrote:
> On 1 May 2018 at 00:09, Andres Freund wrote:
>
> > It's not. Only SYNC_FILE_RANGE_WAIT_{BEFORE,AFTER} eat errors. Which
> > seems sensible, because they could be considered data integrity
> > operations.
>
> Ah, I misread that. Thankyou.
>
> >
On Wed, May 09, 2018 at 10:39:07AM -0300, Alvaro Herrera wrote:
> Michael Paquier wrote:
>> This removes a useless default clause in partprune.c and it got
>> forgotten in the crowd. Just attaching it again here, and it can just
>> be applied on top of the rest.
>
> Done, thanks for insisting.
T
On Wed, May 9, 2018 at 2:04 PM, Michael Paquier wrote:
> On Wed, May 09, 2018 at 02:28:50PM -0300, Alvaro Herrera wrote:
>> I pushed some fixes produced here. Attached is the remainder of the
>> patch you submitted. I notice now that we haven't actually fixed
>> Peter's source of complaint, thou
On Wed, May 09, 2018 at 02:28:50PM -0300, Alvaro Herrera wrote:
> I pushed some fixes produced here. Attached is the remainder of the
> patch you submitted. I notice now that we haven't actually fixed
> Peter's source of complaint, though. AFAICS your patch just adds test
> cases, and upthread d
On Tue, May 8, 2018 at 11:21 PM, Amit Kapila wrote:
> On Tue, May 8, 2018 at 5:27 PM, Robert Haas wrote:
>> On Mon, May 7, 2018 at 11:34 PM, Amit Kapila wrote:
>>> I think we can cover InitPlan and Subplans that can be parallelized in
>>> a separate section "Parallel Subplans" or some other head
On Thu, May 3, 2018 at 5:16 PM, Peter Geoghegan wrote:
> On Thu, May 3, 2018 at 12:37 PM, Robert Haas wrote:
>> On Wed, May 2, 2018 at 3:06 PM, Vladimir Sitnikov
>> wrote:
>>> Sample output can be seen here:
>>> https://github.com/vlsi/pgsqlstat/tree/pgsqlio#pgsqlio
>>
>> Neat. Not sure what ge
On Tue, May 8, 2018 at 5:05 PM, Thomas Munro
wrote:
> +scanning them more than once would preduce duplicate results. Plans that
>
> s/preduce/produce/
Fixed, thanks.
> +Append or MergeAppend plan node.
> vs.
> +Append of regular Index Scan plans; each
>
> I think we should standardi
On Wed, May 9, 2018 at 1:37 PM, Merlin Moncure wrote:
> On Wed, May 9, 2018 at 11:00 AM Robert Haas wrote:
>> Independently of that, it would be probably also useful to avoid
>> bumping the reference count multiple times when a buffer is accessed
>> by the same backend several times in quick succ
On Wed, May 9, 2018 at 11:00 AM Robert Haas wrote:
> Independently of that, it would be probably also useful to avoid
> bumping the reference count multiple times when a buffer is accessed
> by the same backend several times in quick succession. Perhaps this
> could even be as simple as maintain
Michael Paquier wrote:
> On Wed, May 02, 2018 at 01:38:22PM +0900, Amit Langote wrote:
> > Perhaps, I'm just repeating what's already been said, but I think it might
> > be better to have the word "partitioned" in the message.
>
> That's what Peter is pointing to upthread and what the v1 of upthre
On Tue, May 8, 2018 at 10:22 AM, Юрий Соколов wrote:
> "just prior to the point" means we have to have machinery for information
> expiration without eviction. For example, same "clock hand" should walk
> over all buffers continiously, and decrement "usage count", but without
> eviction performed.
Alvaro Herrera writes:
> Tom Lane wrote:
>> Robert Haas writes:
>>> Who says we need a portable way? If we had something that worked on
>>> Linux and macOS, it would cover most developer environments. I wonder
>>> if readlink("/etc/localtime", buf, sz) might be a viable approach.
>> I wondered
Simon Riggs writes:
> Indexes on foreign tables cause an ERROR, so yes, we already just
> don't create them.
>
> You're suggesting silently skipping the ERROR. I can't see a reason for that.
Truly, I was inaccurate. I mean that index propagation is a nice feature,
and making it available for mi
On Wed, May 9, 2018 at 11:39 AM, Alvaro Herrera
wrote:
> In Debian systems, it's a symlink. Apparently in RHEL6 and older it's a
> copy or hardlink, and the file /etc/sysconfig/clock contains a ZONE
> variable that points to the right zone. Maybe if we add enough
> platform-dependent hacks, we w
Tom Lane wrote:
> Robert Haas writes:
> > On Tue, May 8, 2018 at 4:48 PM, Tom Lane wrote:
> >> Really the only thing here that jumps out as being unduly expensive for
> >> what it's doing is select_default_timezone. That is, and always has been,
> >> a brute-force algorithm; I wonder if there's
On Wed, May 9, 2018 at 11:12 AM, Simon Riggs wrote:
> If we can assume an index exists on a foreign table, why can we not
> just assume a unique index exists?? Why the difference?
We can't assume either of those things, and I didn't say that we should.
--
Robert Haas
EnterpriseDB: http://www.en
On Wed, May 9, 2018 at 11:20 AM, Simon Riggs wrote:
> On 9 May 2018 at 16:15, Robert Haas wrote:
>> On Wed, May 9, 2018 at 11:14 AM, Simon Riggs wrote:
>>> On 9 May 2018 at 16:10, Tom Lane wrote:
Robert Haas writes:
> On Wed, May 9, 2018 at 9:08 AM, Simon Riggs wrote:
>> Shouldn'
On 9 May 2018 at 16:15, Robert Haas wrote:
> On Wed, May 9, 2018 at 11:14 AM, Simon Riggs wrote:
>> On 9 May 2018 at 16:10, Tom Lane wrote:
>>> Robert Haas writes:
On Wed, May 9, 2018 at 9:08 AM, Simon Riggs wrote:
> Shouldn't the fix be to allow creation of indexes on foreign tables?
Robert Haas writes:
> On Tue, May 8, 2018 at 4:48 PM, Tom Lane wrote:
>> Really the only thing here that jumps out as being unduly expensive for
>> what it's doing is select_default_timezone. That is, and always has been,
>> a brute-force algorithm; I wonder if there's a way to do better?
> Who
On Wed, May 9, 2018 at 11:14 AM, Simon Riggs wrote:
> On 9 May 2018 at 16:10, Tom Lane wrote:
>> Robert Haas writes:
>>> On Wed, May 9, 2018 at 9:08 AM, Simon Riggs wrote:
Shouldn't the fix be to allow creation of indexes on foreign tables?
(Maybe they would be virtual or foreign inde
On 9 May 2018 at 16:10, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, May 9, 2018 at 9:08 AM, Simon Riggs wrote:
>>> Shouldn't the fix be to allow creation of indexes on foreign tables?
>>> (Maybe they would be virtual or foreign indexes??)
>
>> It might be useful to invent the concept of a f
On 9 May 2018 at 15:57, Robert Haas wrote:
> For right now, I think the options are (1) throw an ERROR if we
> encounter a foreign table or (2) silently skip the foreign table. I
> think (2) is defensible for non-UNIQUE indexes, because the index is
> just a performance optimization. However, fo
Robert Haas writes:
> On Wed, May 9, 2018 at 9:08 AM, Simon Riggs wrote:
>> Shouldn't the fix be to allow creation of indexes on foreign tables?
>> (Maybe they would be virtual or foreign indexes??)
> It might be useful to invent the concept of a foreign index, but not
> for v11 a month after fe
On Tue, May 8, 2018 at 4:48 PM, Tom Lane wrote:
> Really the only thing here that jumps out as being unduly expensive for
> what it's doing is select_default_timezone. That is, and always has been,
> a brute-force algorithm; I wonder if there's a way to do better? We can
> probably guess that ev
On Wed, May 9, 2018 at 9:08 AM, Simon Riggs wrote:
> How much sense is it to have a partitioned table with a mix of local
> and foreign tables?
Fair question, but we put some effort into making it work, so I think
it should keep working.
> Shouldn't the fix be to allow creation of indexes on for
On Tue, May 8, 2018 at 4:51 PM, Stas Kelvich wrote:
>> On 7 May 2018, at 20:04, Robert Haas wrote:
>> But what happens if a transaction starts on node A at time T0 but
>> first touches node B at a much later time T1, such that T1 - T0 >
>> global_snapshot_defer_time?
>
> Such transaction will get
On 9 May 2018 at 15:26, Arseny Sher wrote:
>
> Simon Riggs writes:
>
>> How much sense is it to have a partitioned table with a mix of local
>> and foreign tables?
>
> Well, as much sense as fdw-based sharding has, for instance. It is
> arguable, but it exists.
>
>> Shouldn't the fix be to allow
Marina Polyakova wrote:
> Hello everyone in this thread!
> I got a similar server crash as in [1] on the master branch since the commit
> 9fdb675fc5d2de825414e05939727de8b120ae81 when the assertion fails because
> the second argument ScalarArrayOpExpr is not a Const or an ArrayExpr, but is
> an Ar
Simon Riggs writes:
> How much sense is it to have a partitioned table with a mix of local
> and foreign tables?
Well, as much sense as fdw-based sharding has, for instance. It is
arguable, but it exists.
> Shouldn't the fix be to allow creation of indexes on foreign tables?
> (Maybe they woul
Amit Langote wrote:
> On 2018/05/09 11:31, David Rowley wrote:
> > On 9 May 2018 at 14:29, Amit Langote wrote:
> >> On 2018/05/09 11:20, Michael Paquier wrote:
> >>> While looking at this code, is there any reason to not make
> >>> gen_partprune_steps static? This is only used in partprune.c for
Michael Paquier wrote:
> Alvaro, could it be possible to consider as well the patch I posted
> here?
> https://www.postgresql.org/message-id/20180424012042.gd1...@paquier.xyz
>
> This removes a useless default clause in partprune.c and it got
> forgotten in the crowd. Just attaching it again her
On 9 May 2018 at 12:50, Arseny Sher wrote:
> Hi,
>
> 8b08f7d4 added propagation of indexes on partitioned tables to
> partitions, which is very cool. However, index creation also recurses
> down to foreign tables. I doubt this is intentional, as such indexes are
> forbidden as not making much sens
On Wed, May 9, 2018 at 5:20 PM, Arseny Sher wrote:
> Hi,
>
> 8b08f7d4 added propagation of indexes on partitioned tables to
> partitions, which is very cool. However, index creation also recurses
> down to foreign tables. I doubt this is intentional, as such indexes are
> forbidden as not making m
(2018/05/08 16:20), Ashutosh Bapat wrote:
On Tue, May 1, 2018 at 5:00 PM, Etsuro Fujita
wrote:
Here are my review comments on patch
0003-postgres_fdw-child-join-with-ConvertRowtypeExprs-cau.patch:
* This assertion in deparseConvertRowtypeExpr wouldn't always be true
because of cases like ALTE
Hi,
8b08f7d4 added propagation of indexes on partitioned tables to
partitions, which is very cool. However, index creation also recurses
down to foreign tables. I doubt this is intentional, as such indexes are
forbidden as not making much sense; attempt to create index on
partitioned table with fo
On Wed, May 9, 2018 at 1:58 AM, Craig Ringer wrote:
> >
> > It would be much more convenient to just set the environment variable
> when
> > running the script and let it affect the whole process and its children.
> >
> > Would a patch be welcome?
>
> I can't really comment on that part, but:
>
>
On 2018/05/09 13:14, Amit Langote wrote:
> Hi David.
>
> Thanks for addressing my comments.
>
> On 2018/05/07 15:00, David Rowley wrote:
>> v2 patch is attached.
>
> Looks good to me.
Sorry, I should've seen noticed v3 before sending my email.
v3 looks good too, but when going through it, I no
55 matches
Mail list logo
