On Fri, Nov 22, 2019 at 02:21:41PM +0900, Amit Langote wrote:
> Thanks for working on this. I guess this is a follow up to:
> https://www.postgresql.org/message-id/20191102052001.GB1614%40paquier.xyz
Exactly. I got that in my mind for a couple of days, so I gave it a
shot and the result was
On Fri, Nov 22, 2019 at 11:01:54AM +0900, Amit Langote wrote:
> The latest patch looks good to me, except, maybe the comment of
> StdRdOptions should be updated:
>
> * StdRdOptions
> * Standard contents of rd_options for heaps and generic indexes.
>
> IIUC, StdRdOptions no longer applies
On Thu, Nov 21, 2019 at 09:39:53PM +0300, Nikolay Shaplov wrote:
> BRIN_AM_OID and friends are defined in catalog/pg_am_d.h so for core indexes
> we can do relation->rd_rel->relam == BRIN_AM_OID check. But for contrib
> indexes we can't do such a thing.
> Bloom index does not need such check as
On 22.11.2019 10:08, Pavel Stehule wrote:
I test it, and there is a problem already. We doesn't raise a
exception, but the result is wrong
create table foo(a int);
create or replace function f1(int)
returns void as $$
begin
insert into foo values($1);
end;
$$ language plpgsql;
create
Michael Paquier wrote:
> On Thu, Nov 21, 2019 at 05:05:50PM +0900, Michael Paquier wrote:
> > And with WAL segments at 1MB, I was seeing quite a slowdown with the
> > patch... Then I have done an extra test with pg_waldump with the
> > segments generated previously with the output redirected to
On Fri, Nov 22, 2019 at 12:49:33AM -0300, Alvaro Herrera wrote:
> Yes :-) hopefully next week. Thanks for reviewing.
Thanks, I am switching the entry as ready for committer then. Please
note that the latest patch series have a conflict at the top of
walsender.c easy enough to resolve, and that
pá 22. 11. 2019 v 7:33 odesílatel Kyotaro Horiguchi
napsal:
> At Fri, 22 Nov 2019 06:15:25 +0100, Pavel Stehule
> wrote in
> > čt 21. 11. 2019 v 20:44 odesílatel Tom Lane napsal:
> >
> > > Pavel Stehule writes:
> > > > čt 21. 11. 2019 v 10:31 odesílatel Konstantin Knizhnik <
> > > >
At Fri, 22 Nov 2019 06:15:25 +0100, Pavel Stehule
wrote in
> čt 21. 11. 2019 v 20:44 odesílatel Tom Lane napsal:
>
> > Pavel Stehule writes:
> > > čt 21. 11. 2019 v 10:31 odesílatel Konstantin Knizhnik <
> > > k.knizh...@postgrespro.ru> napsal:
> > >> With contain_mutable_functions the patch
Attached is the latest patch to add support for Incremental
Materialized View Maintenance (IVM). IVM allows to reflect
modifications made on base tables immediately to the target
materialized views.
Up to now, IVM supports materialized views using:
- Inner joins
- Some aggregate functions
Hi Peter,
On Wed, Nov 20, 2019 at 4:55 PM Peter Eisentraut
wrote:
> On 2019-11-18 09:53, Amit Langote wrote:
> > I have spent some time hacking on this. With the attached updated
> > patch, adding a partitioned table to publication results in publishing
> > the inserts, updates, deletes of the
On Fri, 22 Nov 2019 at 09:08, Amit Kapila wrote:
> Have you tried before that fix , if not, can you once try by
> temporarily reverting that fix in your environment and share the
> output of each step? After you get the error due to EOF, check that
> you have .spill files in pg_replslot// and
Hi Michael,
Thanks for working on this. I guess this is a follow up to:
https://www.postgresql.org/message-id/20191102052001.GB1614%40paquier.xyz
On Thu, Nov 21, 2019 at 1:26 PM Michael Paquier wrote:
>
> Hi all,
>
> After working on dc816e58, I have noticed that what we are doing with
>
čt 21. 11. 2019 v 21:15 odesílatel Paul Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On 11/21/19 1:06 AM, Pavel Stehule wrote:
> > 2. I don't like introduction "safe" operators - now the basic operators
> > are doubled, and nobody without documentation will use @* operators.
> >
> > It is
On Fri, 15 Nov 2019 at 00:34, Andrew Dunstan
wrote:
>
> On 11/14/19 11:07 AM, Bruce Momjian wrote:
> > On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
> >> On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra <
> tomas.von...@2ndquadrant.com>
> >> I think it would be beneficial to
On Thu, 21 Nov 2019 at 09:07, Justin Pryzby wrote:
> On Tue, Nov 19, 2019 at 07:22:26PM -0600, Justin Pryzby wrote:
> > I was trying to reproduce what was happening:
> > set -x; psql postgres -txc "DROP TABLE IF EXISTS t" -c "CREATE TABLE t(i
> int unique); INSERT INTO t SELECT
čt 21. 11. 2019 v 20:44 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > čt 21. 11. 2019 v 10:31 odesílatel Konstantin Knizhnik <
> > k.knizh...@postgrespro.ru> napsal:
> >> With contain_mutable_functions the patch becomes trivial.
>
> > Stable functions doesn't need own snapshot too, so
pá 22. 11. 2019 v 1:13 odesílatel Michael Paquier
napsal:
> On Thu, Nov 21, 2019 at 08:19:56PM -0300, Euler Taveira wrote:
> > Em qui., 21 de nov. de 2019 às 15:59, Pavel Stehule
> > escreveu:
> >>
> >> isn't src/tutorial/func.c obsolete? There is not any benefit for users.
> >
> > version-0
At Thu, 21 Nov 2019 10:35:25 -0500, Tom Lane wrote in
> > If we don't intend what Peter pointed (arrangement of low-OIDs at
> > feature freeze), it can be done by moving OIDs to lower values at
> > commit. (I don't mean commiters should do that, it may be bothersome.)
>
> Yes, that's exactly
Hello, Lief, Peter.
At Thu, 21 Nov 2019 12:50:18 +, "Leif Gunnar Erlandsen"
wrote in
> Adding another patch which is not only for recovery_target_time but also for
> xid, name and lsn.
>
> > After studying this a bit more, I think the current behavior is totally
> > bogus and needs a
On Thu, Nov 21, 2019 at 2:11 PM Amit Kapila wrote:
>
> On Sat, Nov 16, 2019 at 7:01 AM vignesh C wrote:
> >
> > On Tue, Nov 12, 2019 at 11:19 AM Amit Kapila
> > wrote:
> > >
> > > On Tue, Nov 12, 2019 at 6:33 AM vignesh C wrote:
> > > >
> > > >
> > > > Thanks Amit for your comments. Please
Mark Dilger writes:
> I have winnowed down the test a bit further. The attached
> smaller patch still triggers the same assertion as the prior
> patch did.
FWIW, I can reproduce the assertion failure with your first test,
but not with this simplified one.
I also confirm that it only happens in
On 2019-Nov-22, Michael Paquier wrote:
> Alvaro, you are marked as a committer of this CF entry. Are you
> planning to look at it again? Sorry for the delay from my side.
Yes :-) hopefully next week. Thanks for reviewing.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
On Thu, Nov 21, 2019 at 8:32 PM Juan José Santamaría Flecha
wrote:
>
> On Thu, Nov 21, 2019 at 5:02 AM Amit Kapila wrote:
>>
>> On Wed, Nov 20, 2019 at 5:41 PM Juan José Santamaría Flecha
>> wrote:
>> >
>> > On Wed, Nov 20, 2019 at 9:48 AM Amit Khandekar
>> > wrote:
>> >>
>> >> On Wed, 20 Nov
On Thu, 21 Nov 2019 10:40:36 +0100
Peter Eisentraut wrote:
> On 2019-11-21 02:42, TAKATSUKA Haruka wrote:
> > FATAL: could not access status of transaction ..
> > DETAIL: Could not read from file (pg_clog/ or pg_xact/) ...:
> > Success.
> >
> > This error has caused the server to
On 11/21/19 6:20 PM, Mark Dilger wrote:
Hackers,
I stumbled upon an assertion while testing master for possible
bugs. I am reporting it here in the hope that this report will
be useful. The attached small regression test patch consistently
triggers an assert in predicate.c:
TRAP:
Hackers,
I stumbled upon an assertion while testing master for possible
bugs. I am reporting it here in the hope that this report will
be useful. The attached small regression test patch consistently
triggers an assert in predicate.c:
TRAP: FailedAssertion("!isCommit ||
Hello,
On Thu, Nov 21, 2019 at 2:22 PM Michael Paquier wrote:
> Any opinions or objections to share regarding the recent
> progress done?
The latest patch looks good to me, except, maybe the comment of
StdRdOptions should be updated:
* StdRdOptions
* Standard contents of rd_options for
On Thu, Nov 21, 2019 at 05:05:50PM +0900, Michael Paquier wrote:
> And with WAL segments at 1MB, I was seeing quite a slowdown with the
> patch... Then I have done an extra test with pg_waldump with the
> segments generated previously with the output redirected to /dev/null.
> Going through 512
Michael Paquier writes:
> No objections from here, let's get rid of it. The docs actually make
> use of the V1 versions, and funcs_new.c is not even compiled (it does
> compile). Any objections to the attached? On top of moving the file,
> there is one comment to update and a sentence to
On Thu, Nov 21, 2019 at 08:19:56PM -0300, Euler Taveira wrote:
> Em qui., 21 de nov. de 2019 às 15:59, Pavel Stehule
> escreveu:
>>
>> isn't src/tutorial/func.c obsolete? There is not any benefit for users.
>
> version-0 calling conventions were removed in v10. It seems an
> oversight at commit
> On 19/11/2019, at 5:05 PM, Gareth Palmer wrote:
>>
>> Since nobody has objected to this, I'm supposing that there's general
>> consensus that that design sketch is OK, and we can move on to critiquing
>> implementation details. I took a look, and didn't like much of what I saw.
Attached is
Em qui., 21 de nov. de 2019 às 15:59, Pavel Stehule
escreveu:
>
> isn't src/tutorial/func.c obsolete? There is not any benefit for users.
>
version-0 calling conventions were removed in v10. It seems an
oversight at commit 5ded4bd2140. Tutorial needs some care (I'm not
volunteering to improve
Thomas Munro writes:
> I'd like to get rid of those IDENTIFICATION lines completely (they are
> left over from the time when the project used CVS, and that section
> had a $Header$ "ident" tag, but in the git era, those ident tags are
> no longer in fashion).
I'm not for that. Arguments about
On Sun, Nov 17, 2019 at 6:36 AM vignesh C wrote:
> I noticed that some of the source files does not include the copyright
> information. Most of the files have included it, but few files have
> not included it. I felt it should be included. The attached patch
> contains the fix for including the
On 11/21/19 1:06 AM, Pavel Stehule wrote:
2. I don't like introduction "safe" operators - now the basic operators
are doubled, and nobody without documentation will use @* operators.
It is not intuitive. I think is better to map this functionality to
basic operators +- * and implement it just
Pavel Stehule writes:
> čt 21. 11. 2019 v 10:31 odesílatel Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> napsal:
>> With contain_mutable_functions the patch becomes trivial.
> Stable functions doesn't need own snapshot too, so it is not fully correct,
> but it is on safe side.
No, I doubt
On Thu, Nov 21, 2019 at 3:35 PM Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
>
> On 11/20/19 3:40 PM, Thomas Munro wrote:
> > On Fri, Nov 8, 2019 at 3:41 AM Andrew Dunstan
> > wrote:
> >> On 11/7/19 9:12 AM, Alvaro Herrera wrote:
> The patch says:
>
> +require
Hi
isn't src/tutorial/func.c obsolete? There is not any benefit for users.
Regards
Pavel
čt 21. 11. 2019 v 10:31 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
> > I've set the CF entry to "Waiting on Author" pending a new patch
> > that does it like that.
>
> With contain_mutable_functions the patch becomes trivial.
>
Stable functions doesn't need own
čt 21. 11. 2019 v 6:33 odesílatel vignesh C napsal:
> On Mon, Nov 18, 2019 at 6:30 PM Pavel Stehule
> wrote:
> >>
> >> I'll send this test today
> >
> >
> > here is it
> >
>
> Thanks for adding the test.
> Few comments:
> This function is same as in test/recovery/t/013_crash_restart.pl, we
>
В письме от среда, 20 ноября 2019 г. 16:44:18 MSK пользователь Michael Paquier
написал:
> > It seems to me that if the plan is to have one option structure for
> > each index AM, which has actually the advantage to reduce the bloat of
> > each relcache entry currently relying on StdRdOptions,
On 2019-11-02 08:39, Peter Eisentraut wrote:
On 2019-10-31 14:36, Tom Lane wrote:
Peter Eisentraut writes:
float4 is now always pass-by-value; the pass-by-reference code path is
completely removed.
I think this is OK.
OK, here is a patch for just this part, and we can continue the
On Thu, Nov 21, 2019 at 11:57:22PM +0800, Andy Fan wrote:
On Thu, Nov 21, 2019 at 6:12 PM Tomas Vondra
wrote:
On Thu, Nov 21, 2019 at 08:30:51AM +0800, Andy Fan wrote:
>>
>>
>> Hm. That actually raises the stakes a great deal, because if that's
>> what you're expecting, it would require
čt 21. 11. 2019 v 17:31 odesílatel Nikita Glukhov
napsal:
> On 17.11.2019 13:35, Pavel Stehule wrote:
>
> Hi
>
> út 12. 11. 2019 v 22:51 odesílatel Nikita Glukhov
> napsal:
>
>> On 12.11.2019 20:54, Pavel Stehule wrote:
>>
>> > Hi
>> >
>> > please, can you rebase
On 17.11.2019 13:35, Pavel Stehule wrote:
Hi
út 12. 11. 2019 v 22:51 odesílatel Nikita Glukhov
mailto:n.glu...@postgrespro.ru>> napsal:
On 12.11.2019 20:54, Pavel Stehule wrote:
> Hi
>
> please, can you rebase 0001-SQL-JSON-functions-v40.patch. I have a
> problem with
On Thu, Nov 21, 2019 at 6:12 PM Tomas Vondra
wrote:
> On Thu, Nov 21, 2019 at 08:30:51AM +0800, Andy Fan wrote:
> >>
> >>
> >> Hm. That actually raises the stakes a great deal, because if that's
> >> what you're expecting, it would require planning out both the
> transformed
> >> and
Kyotaro Horiguchi writes:
> At Wed, 20 Nov 2019 23:45:21 -0500, Tom Lane wrote in
>> I do not think there is any easy solution that guarantees that.
>> We could imagine having some sort of pre-registration mechanism,
>> maybe, but it seems like more trouble than benefit.
> If we don't intend
On Thu, Nov 21, 2019 at 5:02 AM Amit Kapila wrote:
> On Wed, Nov 20, 2019 at 5:41 PM Juan José Santamaría Flecha
> wrote:
> >
> > On Wed, Nov 20, 2019 at 9:48 AM Amit Khandekar
> wrote:
> >>
> >> On Wed, 20 Nov 2019 at 13:10, Amit Kapila
> wrote:
> >> > See comment in pgunlink() "We need to
On 11/20/19 3:40 PM, Thomas Munro wrote:
> On Fri, Nov 8, 2019 at 3:41 AM Andrew Dunstan
> wrote:
>> On 11/7/19 9:12 AM, Alvaro Herrera wrote:
The patch says:
+require Win32::API;
+Win32::API->import;
>>> Oh, you're right, it does. I wonder why, though:
>>>
On 18.11.2019 9:42, Surafel Temesgen wrote:
On Fri, Nov 15, 2019 at 6:24 PM Alexey Kondratov
mailto:a.kondra...@postgrespro.ru>> wrote:
1) Maybe it is fine, but now I do not like this part:
+ portal = GetPortalByName("");
+ dest = CreateDestReceiver(DestRemote);
+
Adding another patch which is not only for recovery_target_time but also for
xid, name and lsn.
> After studying this a bit more, I think the current behavior is totally bogus
> and needs a serious
> rethink.
>
> If you specify a recovery target and it is reached, recovery pauses
> (depending
After studying this a bit more, I think the current behavior is totally
bogus and needs a serious rethink.
If you specify a recovery target and it is reached, recovery pauses
(depending on recovery_target_action).
If you specify a recovery target and it is not reached when the end of
the
On Tue, Nov 19, 2019 at 3:39 PM k.jami...@fujitsu.com
wrote:
>
> On Wed, Nov 13, 2019 5:34PM (GMT+9), Fujii Masao wrote:
> > On Wed, Nov 13, 2019 at 3:57 PM k.jami...@fujitsu.com
> >
> > wrote:
> > >
> > > On Wed, Oct. 2, 2019 5:40 PM, Fujii Masao wrote:
> > > > On Tue, Jul 10, 2018 at 3:04 PM
On Wed, Nov 20, 2019 at 1:11 PM btkimurayuzk
wrote:
>
> > Barring any objection, I'm thinking to commit this patch.
> >
> > Regards,
>
> Build and All Test has passed .
> Looks good to me .
Thanks for reviewing the patch!
I committed the following two patches.
- Allow ALTER VIEW command to
At Thu, 21 Nov 2019 16:01:07 +0900 (JST), Kyotaro Horiguchi
wrote in
> > For deleting relfilenodes, smgrDoPendingDeletes() collects a list for
> > smgrdounlinkall() to pass to DropRelFileNodesAllBuffers(), which is
> > sophisticated about optimizing the shared buffers scan. Commit 279628a
> >
On 2019-11-08 05:00, Grigory Smolkin wrote:
Attached new patch revision, now end of available WAL is defined as the
fact of missing required WAL.
In case of standby, the end of WAL is defined as 2 consecutive switches
of WAL source, that didn`t provided requested record.
In case of streaming
On Tue, Nov 19, 2019 at 5:25 PM Amit Kapila wrote:
>
> On Sat, Nov 16, 2019 at 6:44 PM Amit Kapila wrote:
> >
> > On Thu, Nov 7, 2019 at 5:13 PM Amit Kapila wrote:
> > >
> > > Some notes before commit:
> > > --
> > > 1.
> > > Commit message need to be changed
On 2019-11-08 17:59, Robert Haas wrote:
OK. Could you see what you think of the attached patches? 0001 does
some refactoring of toast_fetch_datum() and toast_fetch_datum_slice()
to make them look more like each other and clean up a bunch of stuff
that I thought was annoying, and 0002 then pulls
On Thu, Nov 21, 2019 at 3:25 PM Dilip Kumar wrote:
>
> On Thu, 21 Nov 2019, 14:15 Masahiko Sawada,
> wrote:
>>
>> On Thu, 21 Nov 2019 at 14:32, Dilip Kumar wrote:
>> >
>> >
>> > In v33-0001-Add-index-AM-field-and-callback-for-parallel-ind patch, I
>> > am a bit doubtful about this kind of
On Thu, Nov 21, 2019 at 08:30:51AM +0800, Andy Fan wrote:
Hm. That actually raises the stakes a great deal, because if that's
what you're expecting, it would require planning out both the transformed
and untransformed versions of the query before you could make a cost
comparison.
I don't
On Thu, 21 Nov 2019, 14:15 Masahiko Sawada,
wrote:
> On Thu, 21 Nov 2019 at 14:32, Dilip Kumar wrote:
> >
> > On Thu, Nov 21, 2019 at 10:46 AM Dilip Kumar
> wrote:
> > >
> > > On Wed, Nov 20, 2019 at 11:01 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Mon, 18 Nov 2019 at 15:38, Masahiko
Thanks for the review.
On Thu, Nov 21, 2019 at 6:34 AM Tom Lane wrote:
>
> Amit Langote writes:
> > [ v6-0001-Use-root-parent-s-permissions-when-reading-child-.patch ]
>
> I started to review this, and discovered that the new regression test
> passes just fine without applying any of the rest
On 2019-11-21 02:42, TAKATSUKA Haruka wrote:
FATAL: could not access status of transaction ..
DETAIL: Could not read from file (pg_clog/ or pg_xact/) ...: Success.
This error has caused the server to fail to start with recovery.
I got a report that it happend repeatedly at the newly
I've set the CF entry to "Waiting on Author" pending a new patch
that does it like that.
With contain_mutable_functions the patch becomes trivial.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/pl/plpgsql/src/pl_exec.c
On Wed, Nov 20, 2019 at 11:05 AM Suraj Kharage <
suraj.khar...@enterprisedb.com> wrote:
> Hi,
>
> Since now we are generating the backup manifest file with each backup, it
> provides us an option to validate the given backup.
> Let's say, we have taken a backup and after a few days, we want to
On Thu, 21 Nov 2019, 13:52 Masahiko Sawada,
wrote:
> On Thu, 21 Nov 2019 at 14:16, Dilip Kumar wrote:
> >
> > On Wed, Nov 20, 2019 at 11:01 AM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, 18 Nov 2019 at 15:38, Masahiko Sawada
> > > wrote:
> > > >
> > > > On Mon, 18 Nov 2019 at 15:34, Amit
st 20. 11. 2019 v 20:32 odesílatel Paul A Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On Tue, Nov 19, 2019 at 9:49 PM Paul A Jungwirth
> wrote:
> >
> > On Tue, Nov 19, 2019 at 1:17 AM Pavel Stehule
> wrote:
> > > Hi
> > > I tested last patches. I found some issues
> >
> > Thank you for
On Tue, Nov 19, 2019 at 3:30 PM Rushabh Lathia
wrote:
>
>
> My colleague Suraj did testing and noticed the performance impact
> with the checksums. On further testing, he found that specifically with
> sha its more of performance impact.
>
> Please find below statistics:
>
> no of tables
On Fri, Nov 15, 2019 at 11:30:02AM +0300, Grigory Smolkin wrote:
> On 11/9/19 5:26 AM, Michael Paquier wrote:
>> Another question I have: do we need to care more about other extra
>> ACLs applied to other object types? For example a subset of columns
>> on a table with a column being renamed
On Thu, 21 Nov 2019 at 14:32, Dilip Kumar wrote:
>
> On Thu, Nov 21, 2019 at 10:46 AM Dilip Kumar wrote:
> >
> > On Wed, Nov 20, 2019 at 11:01 AM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, 18 Nov 2019 at 15:38, Masahiko Sawada
> > > wrote:
> > > >
> > > > On Mon, 18 Nov 2019 at 15:34, Amit
On Sat, Nov 16, 2019 at 7:01 AM vignesh C wrote:
>
> On Tue, Nov 12, 2019 at 11:19 AM Amit Kapila wrote:
> >
> > On Tue, Nov 12, 2019 at 6:33 AM vignesh C wrote:
> > >
> > >
> > > Thanks Amit for your comments. Please find the updated patch which
> > > does not include the changes mentioned
I think your first thought was good.
How high ? I think it's a matter of convention, certainly more than default
100.
czw., 21 lis 2019 o 02:05 Andy Fan napisał(a):
>
>
> On Thu, Oct 31, 2019 at 11:07 PM Tom Lane wrote:
>
>>
>>
>> Possibly this could be finessed by only trying to find
On Thu, 21 Nov 2019 at 14:16, Dilip Kumar wrote:
>
> On Wed, Nov 20, 2019 at 11:01 AM Masahiko Sawada
> wrote:
> >
> > On Mon, 18 Nov 2019 at 15:38, Masahiko Sawada
> > wrote:
> > >
> > > On Mon, 18 Nov 2019 at 15:34, Amit Kapila wrote:
> > > >
> > > > On Mon, Nov 18, 2019 at 11:37 AM Masahiko
On Wed, Nov 20, 2019 at 03:50:29PM +0100, Antonin Houska wrote:
> Thus the use of pg_pread() makes the code quite a bit simpler, so I
> re-introduced it. If you decide that an explicit lseek() should be used yet,
> just let me know.
Skimming through the code, it looks like in a good state. The
74 matches
Mail list logo
