On Sat, Jan 04, 2020 at 09:38:24PM +0300, Alexey Kondratov wrote:
> Finally, I have also merged and unified all your and Masahiko's proposals
> with my recent changes: ereport corrections, tab-completion, docs update,
> copy/equalfuncs update, etc. New version is attached. Have it come any
> closer
On Fri, Dec 27, 2019 at 4:26 AM Tom Lane wrote:
> Fujii Masao writes:
> > My customer reported me that the queries through a partitioned table
> > ignore each partition's SELECT, INSERT, UPDATE, and DELETE privileges,
> > on the other hand, only TRUNCATE privilege specified for each partition
> >
On Mon, Jan 06, 2020 at 01:36:23PM +0100, Fabien COELHO wrote:
>> I think that I would just remove the "debug" variable defined in
>> pgbench.c all together, and switch the messages for the duration and the
>> one in executeMetaCommand to use info-level logging..
>
> Ok, done.
Thanks. The output
Bonjour Michaël,
I think that I would just remove the "debug" variable defined in
pgbench.c all together, and switch the messages for the duration and the
one in executeMetaCommand to use info-level logging..
Ok, done.
Thanks. The output then gets kind of inconsistent when using --debug:
p
Hello.
Isn't this patch somehow broken?
At Mon, 28 Oct 2019 16:36:09 +0100, Vik Fearing
wrote in
> On 28/10/2019 13:48, Surafel Temesgen wrote:
> >
> >
> > On Fri, Oct 25, 2019 at 10:45 PM Vik Fearing
> > mailto:vik.fear...@2ndquadrant.com>> wrote:
> >
> > >
> > > I don't understan
On Sat, 4 Jan 2020 at 18:12, Dean Rasheed wrote:
>
> On Sat, 4 Jan 2020 at 17:13, Tom Lane wrote:
> >
> > Dean Rasheed writes:
> > > That included a change to rewriteTargetListIU() to prevent it from
> > > adding dummy targetlist entries for unassigned-to attributes for
> > > auto-updatable view
On 1/6/20 8:37 PM, Tomas Vondra wrote:
> Hi,
>
> This patch is currently in "needs review" state, but the last message is
> from August 29, and my understanding is that there have been a couple of
> objections / disagreements about the architecture, difficulties with
> producing the set of syscall
Do we actually need the smallint versions of these functions?
I would have thought that automatic casting would take care of any
cases that need smallints, and I can't believe that there's any
performance benefit to be had that's worth maintaining the extra code.
Regards,
Dean
Hi,
I am getting a server crash on publication server on HEAD for the below
test case.
Commit: b9c130a1fdf16cd99afb390c186d19acaea7d132
Data setup:
Publication server:
wal_level = logical
max_wal_senders = 10
max_replication_slots = 15
wal_log_hints = on
hot_standby_feedback = on
wal_receiver_sta
Dean Rasheed writes:
> Do we actually need the smallint versions of these functions?
Doubt it. It'd be fairly hard even to call those, since e.g. "42"
is an int not a smallint.
regards, tom lane
On Tue, Jan 07, 2020 at 06:02:14AM -0500, Joe Conway wrote:
On 1/6/20 8:37 PM, Tomas Vondra wrote:
Hi,
This patch is currently in "needs review" state, but the last message is
from August 29, and my understanding is that there have been a couple of
objections / disagreements about the architect
On 02/01/2020 01:15, John Naylor wrote:
I wrote:
Currently, we include the function name string in each FmgrBuiltin
struct, whose size is 24 bytes on 64 bit platforms. As far as I can
tell, the name is usually unused, so the attached (WIP, untested)
patch stores it separately, reducing this str
On Tue, 7 Jan 2020 at 06:02, Amit Langote wrote:
> Rebased and updated to address your comments.
>
+
+ Partitioned tables are not considered when FOR ALL TABLES
+ is specified.
+
+
What is the reason for above, I mean not for the comment but not
including partitioned tables in for all tab
On Mon, Jan 6, 2020 at 7:22 PM Michael Paquier wrote:
> Okay for the first one, printing the OID sounds like a good idea.
> Like Tom, I would prefer keeping the relation name with "(null)" for
> the schema name. Or even better, could we just print the OID all the
> time? What's preventing us fro
2020年1月7日(火) 16:03 Michael Paquier :
>
> On Mon, Jan 06, 2020 at 04:32:39PM -0500, Stephen Frost wrote:
> > RESTRICT, yes. I don't know about ONLY being sensible as we don't
> > really deal with inheritance and foreign tables very cleanly today, as I
> > said up-thread, so I'm not sure if we reall
On Tue, Aug 06, 2019 at 09:03:08PM +0300, Alexander Korotkov wrote:
...
Unfortunately, it seems that none of such strategies would fit all the
cases.
Basically, we have two option for renaming a file. * MoveFileEx() –
safest possible option, less likely loose files, but takes a lock on
target
On Tue, Jan 7, 2020 at 7:59 AM Tomas Vondra
wrote:
> Barring objections, I'll mark it as rejected.
I think that's right. Since I just caught up on this thread, I'd like
to offer a few belated comments:
1. I don't think it would kill us to add a few hooks that would allow
this feature to be added
Hello, I wanted some guidance/suggestions about creating an spgist
extension. For context, i am a grad student doing research that involves
comparing the performance of different indexes for spatial data. We've
built a system that uses Postgres and one of the data structures we want to
use is a loo
Kyotaro Horiguchi writes:
> At Tue, 26 Nov 2019 10:49:11 -0500, Tom Lane wrote in
>> Hmm, interesting. IMO, that *should* have thrown an error, but of
>> course not that one. The ADD COLUMN operations are all processed
>> in parallel, so it's not okay for one of them to have a GENERATED
>> exp
On Mon, Jan 6, 2020 at 6:56 PM Stephen Frost wrote:
> The first is this- ANYONE can create an extension in the system today,
> if it's marked as superuser=false. If anything, it seems like that's
> probably too loose- certainly based on your contention that ONLY
> superusers should wield such a p
On Sun, Jan 5, 2020 at 11:01 PM Michael Paquier wrote:
> Sounds like an agreement then. The original patch documents the range
> in postgresql.conf.sample, which is fine by me as this is done for
> some parameters, and skips the part about doc/, which also matches
> with the surrounding effort fo
I wrote:
> So I believe that the real problem here is that the executor is
> evaluating GENERATED expressions at the wrong time. It's evaluating
> them against the pre-conversion tuples when it should be evaluating
> them against the post-conversion tuples. We need to go fix that,
> rather than i
On Tue, Jan 07, 2020 at 11:33:07AM -0500, Robert Haas wrote:
On Tue, Jan 7, 2020 at 7:59 AM Tomas Vondra
wrote:
Barring objections, I'll mark it as rejected.
I think that's right.
Done.
Since I just caught up on this thread, I'd like to offer a few belated
comments:
1. I don't think it w
On Fri, Jan 3, 2020 at 2:35 PM Stephen Frost wrote:
> > Well, I don't know how to make you happy here.
>
> I suppose I should admit that, first off, I don't feel you're required
> to make me happy, and I don't think it's necessary to make me happy to
> get this feature into PG.
Fair enough. That
Hi,
This patch is currently in "needs review" state, but that seems quite
wrong - there's been a lot of discussions about how we might improve
behavior for append-only-tables, but IMO there's no clear consensus nor
a patch that we might review.
So I think this should be either "waiting on author
Robert Haas writes:
> On Mon, Jan 6, 2020 at 7:22 PM Michael Paquier wrote:
>> For the second one, I would really wish that we keep the restriction
>> put in place by a052f6c until we actually figure out how to make the
>> operation safe in the ways we want it to work because this puts
>> the cat
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jan 6, 2020 at 6:56 PM Stephen Frost wrote:
> > The first is this- ANYONE can create an extension in the system today,
> > if it's marked as superuser=false. If anything, it seems like that's
> > probably too loose- certainly base
Hi!
On Tue, Jan 7, 2020 at 7:16 PM Tomas Vondra
wrote:
> I don't have access to a Windows machine and my developer experience
> with that platform is pretty much nil, but I think this patch makes
> sense. It's not an ideal solution, but it's not clear such solution
> exists, and an improvement is
Alexander Korotkov writes:
> On Tue, Jan 7, 2020 at 7:16 PM Tomas Vondra
> wrote:
>> I don't have access to a Windows machine and my developer experience
>> with that platform is pretty much nil, but I think this patch makes
>> sense. It's not an ideal solution, but it's not clear such solution
>
On Tue, Jan 7, 2020 at 9:40 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Tue, Jan 7, 2020 at 7:16 PM Tomas Vondra
> > wrote:
> >> I don't have access to a Windows machine and my developer experience
> >> with that platform is pretty much nil, but I think this patch makes
> >> sense. It
On Tue, Jan 7, 2020 at 1:17 PM Stephen Frost wrote:
> Why would it be trusted if it's $SCARY_EXTENSION ...? Why are we trying
> to punt on solving for that question by installing a much more
> complicated system here than is really necessary, just to avoid having
> to make that decision?
I'm not
On Tue, Jan 7, 2020 at 12:56 PM Tomas Vondra
wrote:
> I think the "hook issue" is that the actual code is somewhere else. On
> the one hand that minimizes the dev/testing/maintenance burden for us,
> on the other hand it means we're not really testing the hooks. Meh.
I don't care about the testin
On Wed, Dec 18, 2019 at 11:37 AM Robert Haas wrote:
> If nobody has further comments or objections, I plan to commit these
> in early January.
Done.
Which, I think, wraps up the work I felt needed to be done here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreS
Alexander Korotkov writes:
> I'm not sure issue we faced is really about single platform. TBH, the
> assumptions we place to rename function is very strict. We assume
> rename works atomically on system crash. And we indirectly assume it
> can work concurrently as least with file readers. The
Hi
po 6. 1. 2020 v 22:34 odesílatel Andrew Dunstan <
andrew.duns...@2ndquadrant.com> napsal:
> On Thu, Nov 28, 2019 at 2:15 PM Andrew Dunstan
> wrote:
> >
> >
> > On 11/27/19 9:35 PM, Michael Paquier wrote:
> > > On Fri, Nov 15, 2019 at 09:45:59PM +0100, Pavel Stehule wrote:
> > >> Maybe ERRCODE
On 2019-Dec-29, Tomas Vondra wrote:
> On Fri, Dec 27, 2019 at 04:46:18PM -0300, Alvaro Herrera wrote:
> >
> > This patch changes xact.c to avoid updating transaction start timestamps
> > for walsenders (maybe more commentary is desirable). I think logical
> > decoding is just a special form of w
Greetings!
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jan 7, 2020 at 1:17 PM Stephen Frost wrote:
> > Why would it be trusted if it's $SCARY_EXTENSION ...? Why are we trying
> > to punt on solving for that question by installing a much more
> > complicated system here than is really
I wrote:
> I installed libedit_3.1-20150325.orig.tar.gz from source here, and it
> passes our current regression test and seems to behave just fine in
> light manual testing. (I did not apply any of the Debian-specific
> patches at [1], but they don't look like they'd explain much.)
> So I'm a bit
On Tue, Jan 07, 2020 at 11:33:31AM -0500, Peter Griggs wrote:
Hello, I wanted some guidance/suggestions about creating an spgist
extension. For context, i am a grad student doing research that involves
comparing the performance of different indexes for spatial data. We've
built a system that uses
Alvaro Herrera writes:
> OK, I pushed my patch to branches 10 - master.
> (See https://postgr.es/m/20200107211624.GA18974@alvherre.pgsql )
The buildfarm seems less than happy with this.
regards, tom lane
> "Surafel" == Surafel Temesgen writes:
Surafel> Unlike most other executor node limit node has implementation
Surafel> for handling backward scan that support cursor operation but
Surafel> your approach didn't do this inherently because it outsource
Surafel> limitNode functionality to wi
I wrote:
> The buildfarm seems less than happy with this.
... and, having now looked at the patch, I'm not surprised.
Breaking stmtStartTimestamp, which is what you did, seems like
an awfully side-effect-filled route to the goal. If you want
to prevent monitoring from showing this, why didn't you
I just wanted to address a question we got about making scanCols
instead of using RelOptInfo->attr_needed.
David Rowley had asked:
> For planning, isn't this information already available via either
> targetlists or from the RelOptInfo->attr_needed array combined with
> min_attr and max_attr?
at
On Tue, Jan 7, 2020 at 4:36 PM Stephen Frost wrote:
> Here's the thing though.. creating the extension isn't *really* (in our
> permissions model anyway) what lets you create outbound connections-
> it's creating a 'SERVER', and to be able to do that you need to have
> USAGE rights on the FDW, wh
On 2020-Jan-07, Tom Lane wrote:
> I wrote:
> > The buildfarm seems less than happy with this.
>
> ... and, having now looked at the patch, I'm not surprised.
> Breaking stmtStartTimestamp, which is what you did, seems like
> an awfully side-effect-filled route to the goal. If you want
> to preve
On Mon, Dec 30, 2019 at 4:34 PM Melanie Plageman
wrote:
> So, I finally have a prototype to share of parallel hashloop fallback.
Hi Melanie,
Thanks for all your continued work on this! I started looking at it
today; it's a difficult project and I think it'll take me a while to
grok. I do have
Mark Lorenz writes:
>> Why not? These format codes are specified as
>> Dday of the week, Sunday (1) to Saturday (7)
>> WW week number of year (1–53) (the first week starts on the first day
>> of the year)
> I don't want to create any connection here. The day is calculated
> correctly. But
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jan 7, 2020 at 4:36 PM Stephen Frost wrote:
> > Here's the thing though.. creating the extension isn't *really* (in our
> > permissions model anyway) what lets you create outbound connections-
> > it's creating a 'SERVER', and to
Alvaro Herrera writes:
> On 2020-Jan-07, Tom Lane wrote:
>> ... and, having now looked at the patch, I'm not surprised.
>> Breaking stmtStartTimestamp, which is what you did, seems like
>> an awfully side-effect-filled route to the goal. If you want
>> to prevent monitoring from showing this, why
On Tue, Jan 07, 2020 at 01:06:08PM -0500, Tom Lane wrote:
> I still agree with Robert that a052f6c is a bad idea. It's not the case
> that that's blocking "any connected user" from causing an issue. The
> temp schemas are always owned by the bootstrap superuser, so only a
> superuser could delete
Michael Paquier writes:
> Okay, I am running out of arguments then, so attached is a patch to
> address things. I would also prefer if we keep the relation name in
> the log even if the namespace is missing.
A couple of thoughts:
* Please revert a052f6c as a separate commit specifically doing t
At Wed, 1 Jan 2020 23:46:02 -0800, Noah Misch wrote in
> On Wed, Dec 25, 2019 at 10:39:32AM +0900, Kyotaro Horiguchi wrote:
> > I'm not sure which is better. If we say we know that
> > repalloc(AllocSetRealloc) doesn't free memory at all, there's no point
> > in calling repalloc for shrinking and
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 3, 2020 at 2:35 PM Stephen Frost wrote:
> > > Well, I don't know how to make you happy here.
> >
> > I suppose I should admit that, first off, I don't feel you're required
> > to make me happy, and I don't think it's necessary
On Sun, Dec 29, 2019 at 8:02 PM Noah Misch wrote:
> ==00:00:00:28.322 1527557== Source and destination overlap in
> memcpy(0x1000104, 0x1000104, 4)
> ==00:00:00:28.322 1527557==at 0x4C2E74D: memcpy@@GLIBC_2.14
> (vg_replace_strmem.c:1035)
> ==00:00:00:28.322 1527557==by 0xA9A57B: qunique
On Tue, Jan 07, 2020 at 07:55:17PM -0500, Tom Lane wrote:
> * Please revert a052f6c as a separate commit specifically doing that,
> so that when it comes time to make the release notes, it's clear that
> a052f6c doesn't require documentation.
Okay. Committed the revert first then.
> * I think th
On Tue, Jan 07, 2020 at 12:21:26PM -0500, Robert Haas wrote:
> Done. I didn't commit the postgresql.conf.sample change because:
>
> (1) I think Bruce voted against it.
>
> (2) It makes the line a little wide, and I'd rather not do that.
Thanks!
--
Michael
signature.asc
Description: PGP signatu
From: David Fetter
> > But I see two problems with the proposed approach: (1) initdb
> > doesn't support setting up SSL, so the only thing you can achieve
> > here is to reject all TCP/IP connections, until you have set up SSL.
>
> I don't believe any special setup is needed to require TLS for th
On Mon, Jan 6, 2020 at 4:26 PM Christoph Berg wrote:
>
> Re: Tom Lane 2020-01-05 <25771.1578249...@sss.pgh.pa.us>
>
> Ubuntu bionic fails elsewhere:
>
> 07:19:51 t/001_stream_rep.pl .. ok
> 07:19:53 t/002_archiving.pl ... ok
> 07:19:59 t/003_recovery_targets.pl
On Sun, Jan 5, 2020 at 8:00 AM Noah Misch wrote:
>
> On Sat, Jan 04, 2020 at 06:56:48AM +0530, Amit Kapila wrote:
> > In the latter case, we either want to
> > (a) tweak the test to raise the value of max_files_per_process, (b)
> > remove the test entirely.
>
> I generally favor keeping the test,
Hello.
At Tue, 31 Dec 2019 13:16:49 +0300, Maxim Orlov wrote
in
> Now we decided to drop many tables, let's say 1000 or 1 not in a
> single transaction, but each table in a separate one. So, due to
> "plain" shared_buffers memory we have to do for loop for every
> relation which leads to la
On Wed, Jan 8, 2020 at 5:20 PM Kyotaro Horiguchi
wrote:
> Relfilenode can be reused right after commit. There can be a case
> where readers of the resued relfilenode see the pages from already
> removed files left on shared buffers. On the other hand newly
> allocated buffers for the reused relfil
On Mon, 6 Jan 2020 at 15:27, Masahiko Sawada
wrote:
>
> On Sun, 5 Jan 2020 at 23:28, Amit Kapila wrote:
> >
> > On Sun, Jan 5, 2020 at 7:38 PM Masahiko Sawada
> > wrote:
> > >
> > > On Sun, 5 Jan 2020 at 22:39, Tomas Vondra
> > > wrote:
> > > >
> > > >
> > > > So if we think we need an option
On Wed, Jan 8, 2020 at 11:31 AM Masahiko Sawada
wrote:
>
> On Mon, 6 Jan 2020 at 15:27, Masahiko Sawada
> wrote:
> >
> > I just felt it's not intuitive that specifying parallel degree to 0
> > means to disable parallel vacuum. But since majority of hackers seem
> > to agree with this syntax I'm n
On Wed, Jan 8, 2020 at 7:08 AM Pavel Stehule wrote:
>
> Hi
>
> po 6. 1. 2020 v 22:34 odesílatel Andrew Dunstan
> napsal:
>>
>>
>> Updated version including docco and better error message.
>>
>> cheers
>>
>> andrew
>
>
> I think so my objections are solved. I have small objection
>
> + errdetail(
> 2020年1月6日 下午8:17，Dean Rasheed 写道：
>
> On Mon, 6 Jan 2020 at 11:01, Tomas Vondra
> wrote:
>>
>> On Mon, Jan 06, 2020 at 01:04:15PM +0800, 曾文旌(义从) wrote:
>>
>>> 2 We feel that gtt needs to maintain statistics, but there is no
>>> agreement on what it will be done.
>>>
>>
>> I certainly ag
Hi, Jeff
I tried to use the logical tape APIs for hash agg spilling, based on
your 1220 version.
Turns out it doesn't make much of performance difference with the
default 8K block size (might be my patch's problem), but the disk space
(not I/O) would be saved a lot because I force the respilling
On Sun, Dec 1, 2019 at 10:03 AM Michael Paquier wrote:
> On Thu, Nov 28, 2019 at 07:07:22PM +0800, Pengzhou Tang wrote:
> > Richard pointed out that he get incorrect results with the patch I
> > attached, there are bugs somewhere,
> > I fixed them now and attached the newest version, please refer
At Mon, 30 Dec 2019 13:52:50 -0500, Robert Haas wrote
in
> On Wed, Dec 18, 2019 at 9:53 PM Kyotaro Horiguchi
> wrote:
> > The doc is saying that "size" is "Size of the allocation" and
> > "allocated_size" is "size including padding". It seems somewhat
> > confusing to me. I'm not sure what word
On Wed, 8 Jan 2020 at 15:31, Amit Kapila wrote:
>
> On Wed, Jan 8, 2020 at 11:31 AM Masahiko Sawada
> wrote:
> >
> > On Mon, 6 Jan 2020 at 15:27, Masahiko Sawada
> > wrote:
> > >
> > > I just felt it's not intuitive that specifying parallel degree to 0
> > > means to disable parallel vacuum. But
On Mon, Jan 6, 2020 at 4:44 PM Dilip Kumar wrote:
>
> On Mon, Jan 6, 2020 at 4:36 PM Amit Kapila wrote:
> >
> > On Mon, Jan 6, 2020 at 3:56 PM Dilip Kumar wrote:
> > >
> > > On Mon, Jan 6, 2020 at 2:11 PM Amit Kapila
> > > wrote:
> > > >
> > > > 3.
> > > > +static void
> > > > +ReorderBufferSt
70 matches
Mail list logo
