On Sat, Jul 18, 2020 at 7:36 PM Tom Lane wrote:
> I wonder whether skink's failure today is due to this change:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2020-07-18%2018%3A01%3A10
That seems extremely likely. I think that I need to do something like
what you see in the
Peter Geoghegan writes:
> On Thu, Jul 16, 2020 at 10:24 AM Anastasia Lubennikova
> wrote:
>> Other than that, patches look good to me, so move them to "Ready For
>> Committer".
> Pushed the first patch just now, and intend to push the other one soon.
> Thanks!
I wonder whether skink's failure
I wrote:
> In all branches back to v10, initdb marks pg_subscription.subslotname
> as NOT NULL: ...
> Nonetheless, CREATE/ALTER SUBSCRIPTION blithely set it to null
> when slot_name = NONE is specified.
> What would we like to do about this? Removing the NOT NULL
> marking wouldn't be too hard in
Jeff Davis writes:
> What is your opinion about pessimizing the HashAgg disk costs (not
> affecting HashAgg plans expected to stay in memory)? Tomas Vondra
> presented some evidence that Sort had some better IO patterns in some
> cases that weren't easily reflected in a principled way in the cost
Hi,
On 2020-07-18 20:15:52 -0400, Tom Lane wrote:
> As best I can tell, the reason it's so slow is that somebody decided they
> ought to have a completionist approach to discovering whether the compiler
> has "C++11 features". The test program embedded in configure for this
> is a good 220 lines
Peter Eisentraut writes:
> On 2020-07-16 18:17, Tom Lane wrote:
>> Yeah. Because we'd want to rip out those hacks, it's not quite as simple
>> as "regenerate configure with this other autoconf version"; somebody will
>> have to do some preliminary investigation and produce a patch for the
>> auto
On Sat, 2020-07-18 at 14:30 -0400, Tom Lane wrote:
> You'e being optimistic about it being possible to remove a GUC once
> we ship it. That seems to be a hard sell most of the time.
If nothing else, a repeat of this thread in a year or two to discuss
removing a GUC doesn't seem appealing.
> I th
I wrote:
> Dean Rasheed writes:
>> if (isinf(base) && isinf(offset))
>> {
>> if ((base > 0 && sub) || (base < 0 && !sub))
>> PG_RETURN_BOOL(true);
>> }
> Yeah, I'd experimented with more-or-less that logic before arriving at
> my v2 patch. I didn't like the outcom
On Sat, Jul 18, 2020 at 11:30 AM Tom Lane wrote:
> Jeff Davis writes:
> > Yes, I think we should have that GUC (hashagg_avoid_disk_plan) for at
> > least one release.
>
> You'e being optimistic about it being possible to remove a GUC once
> we ship it. That seems to be a hard sell most of the ti
On Tue, Jul 14, 2020 at 10:08:39PM -0500, Justin Pryzby wrote:
> I'm still missing feedback from committers about the foundation of this
> approach.
Now rebased on top of fix for my own bug report (1d09fb1f).
I also changed argument handling for pg_ls_dir_recurse().
Passing '.' gave an initial p
Em sáb., 18 de jul. de 2020 às 15:19, Tom Lane escreveu:
> Ranier Vilela writes:
> > Em sáb., 18 de jul. de 2020 às 14:21, Tom Lane
> escreveu:
> >> No, there's just something wrong with Coverity's analysis.
> >> I've grown a bit disillusioned with that tool; of late it's
> >> been giving many
Andres Freund writes:
> On 2020-07-17 16:09:14 -0400, Tom Lane wrote:
>> headerscheck and cpluspluscheck are both unhappy about this:
>> ./src/include/replication/worker_internal.h:49:2: error: unknown type name
>> 'slock_t'
>> slock_t relmutex;
>> ^~~
> I think including spin.h i
Jeff Davis writes:
> On Fri, 2020-07-17 at 18:38 -0700, Peter Geoghegan wrote:
>> There is also the separate question of what to do about the
>> hashagg_avoid_disk_plan GUC (this is a separate open item that
>> requires a separate resolution). Tom leans slightly towards removing
>> it now. Is your
Ranier Vilela writes:
> Em sáb., 18 de jul. de 2020 às 14:21, Tom Lane escreveu:
>> No, there's just something wrong with Coverity's analysis.
>> I've grown a bit disillusioned with that tool; of late it's
>> been giving many more false positives than useful reports.
> It could be, differences i
On Fri, 2020-07-17 at 18:38 -0700, Peter Geoghegan wrote:
> There is also the separate question of what to do about the
> hashagg_avoid_disk_plan GUC (this is a separate open item that
> requires a separate resolution). Tom leans slightly towards removing
> it now. Is your position about the same a
In all branches back to v10, initdb marks pg_subscription.subslotname
as NOT NULL:
# \d pg_subscription
Table "pg_catalog.pg_subscription"
Column | Type | Collation | Nullable | Default
-+-+---+--+-
oid | oid
Em sáb., 18 de jul. de 2020 às 14:21, Tom Lane escreveu:
> Ranier Vilela writes:
> > Can you take a look?
> > Per Coverity.
> > There is something wrong with the definition of QUEUE_PAGESIZE on async.c
>
> No, there's just something wrong with Coverity's analysis.
> I've grown a bit disillusione
Ranier Vilela writes:
> Can you take a look?
> Per Coverity.
> There is something wrong with the definition of QUEUE_PAGESIZE on async.c
No, there's just something wrong with Coverity's analysis.
I've grown a bit disillusioned with that tool; of late it's
been giving many more false positives tha
I've pushed this patch, with a number of adjustments, some cosmetic
and some not so much (no pg_dump support!?). We're not quite
done though ...
Dave Cramer writes:
> So looking at how to confirm that the subscriber has receive functions for
> all of the types.
> AFAICT we don't have that inform
Hi, thanks for working on this. I had planned to work on it and I’m looking
forward to this natively in Postgres.
The patch builds with the following warnings:
plancat.c:2368:18: warning: variable 'name' is used uninitialized whenever
'for' loop exits because its condition is false [-Wsometimes
Thanks for the feedback,
> There is one warning present in the changes:
> copy.c: In function ‘ProcessCopyOptions’:
> copy.c:1208:5: warning: ISO C90 forbids mixed declarations and code
> [-Wdeclaration-after-statement]
> char*sval = defGetString(defel);
>
Weirdly this is not caught by c
Hi Tom,
Can you take a look?
Per Coverity.
There is something wrong with the definition of QUEUE_PAGESIZE on async.c
1. #define QUEUE_PAGESIZE BLCKSZ
2. BLCKSZ is 8192
3..sizeof(AsyncQueueControl) is 8080, according to Coverity (Windows 64
bits)
4. (Line 1508)qe.length = QUEUE_PAGESIZE - o
Dean Rasheed writes:
> if (isinf(base) && isinf(offset))
> {
> if ((base > 0 && sub) || (base < 0 && !sub))
> PG_RETURN_BOOL(true);
> }
Yeah, I'd experimented with more-or-less that logic before arriving at
my v2 patch. I didn't like the outcome that "inf both inf
On Fri, Jul 17, 2020 at 02:03:18PM +0900, Michael Paquier wrote:
> It would be better to get all that fixed and backpatched. Is somebody
> already looking into that?
I have been through this set, and applied the changes as of 045d03f &
friends. There was an extra URL broken in 9.5 and 9.6 relate
On 7/17/20 4:26 PM, Nikita Glukhov wrote:
>
>>> Patch #5 implements functions for new JSON type that is expected to appear
>>> in
>>> the upcoming SQL/JSON standard:
>>>
>>> - JSON() is for constructing JSON typed values from JSON text.
>>>It is almost equivalent to text::json[b] cast, exce
On 7/18/20 5:46 AM, Amit Kapila wrote:
>
>> I don't have an especially easy way to experiment on Windows; I can push
>> experiments to the CI service and wait a bit to see what they do, but
>> I figured I'd ask here first.
>>
> I have tried and 'pg_ctl stuff seems to be working for a privileged
>
On 07/18/20 05:46, Amit Kapila wrote:
> I don't think so. I think you can use 'pg_ctl start' to achieve that.
> I think the JOBS stuff is primarily required when we use 'register'
> operation (aka runs server via service). For example, if you see one
> of the Job options "JOB_OBJECT_LIMIT_DIE_ON_U
On Fri, Jul 17, 2020 at 10:18 PM Rémi Lapeyre wrote:
>
> >
> > I don't know how to do that with git-send-email, but you can certainly do
> > it easy with git-format-patch and just attach them using your regular MUA.
> >
> > (and while the cfbot and the archives have no problems dealing with the
On Sat, Jul 18, 2020 at 4:36 PM Michael Paquier wrote:
>
> On Sat, Jul 18, 2020 at 04:12:02PM +0530, vignesh C wrote:
> > Can we specify Insert/Update or delete with copy?
> > When I tried few scenarios I was getting the following error:
> > ERROR: COPY query must have a RETURNING clause
> >
> >
Hi,
One of the comments needs correction "sorting all tuples in the the
dataset" should have been "sorting all tuples in the dataset".
The Attached patch has the changes for the same.
Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com
From cac50bde06ba4493f278b3a79d15d2591f45344b Mon Sep
On Sat, Jul 18, 2020 at 04:12:02PM +0530, vignesh C wrote:
> Can we specify Insert/Update or delete with copy?
> When I tried few scenarios I was getting the following error:
> ERROR: COPY query must have a RETURNING clause
>
> I might be missing some scenarios, just wanted to confirm if this is
On Fri, Jul 17, 2020 at 8:38 AM Masahiko Sawada
wrote:
>
> On Thu, 16 Jul 2020 at 13:53, tsunakawa.ta...@fujitsu.com
> wrote:
> >
> > Hi Sawada san,
> >
> >
> > I'm reviewing this patch series, and let me give some initial comments and
> > questions. I'm looking at this with a hope that this wi
On Sat, Jul 18, 2020 at 8:08 AM Michael Paquier wrote:
>
> On Fri, Jul 17, 2020 at 05:28:51PM +0530, vignesh C wrote:
> > On Fri, Jul 17, 2020 at 11:15 AM Michael Paquier
> > wrote:
> >> Not completely actually. The page of psql for \copy does not mention
> >> the optional where clause, and I t
On Sat, Jul 18, 2020 at 5:33 AM Chapman Flack wrote:
>
> But there's a NOTE! in the comment for CreateRestrictedProcess: "Job object
> will only work when running as a service, because it's automatically
> destroyed when pg_ctl exits."
>
> I haven't been able to find any documentation of what that
On Fri, Jul 17, 2020 at 8:59 PM Dave Cramer wrote:
>
> On Fri, 17 Jul 2020 at 11:17, David G. Johnston
> wrote:
>>
>> On Fri, Jul 17, 2020 at 8:10 AM Dave Cramer wrote:
>>>
>>> This started out with just fixing
>>>
>>> "One option do deal" to " One option to deal"
>>>
>>> But after reading the
On Fri, 17 Jul 2020 at 01:59, Tom Lane wrote:
>
> Dean Rasheed writes:
> > On Thu, 16 Jul 2020, 22:50 Tom Lane, wrote:
> >> Actually, after staring at those results awhile longer, I decided
> >> they were wrong. The results shown here seem actually sane ---
> >> for instance, -Infinity shouldn'
On Sat, Jul 11, 2020 at 1:14 AM Mark Dilger
wrote:
>
> > Tom and Álvaro discussed upthread:
> >
> >> Would it make sense (and possible) to have a keyword category that is
> >> not disjoint wrt. the others? Maybe that ends up being easier than
> >> a solution that ends up with six or seven categor
37 matches
Mail list logo
