On Thu, Jul 5, 2018 at 6:44 AM, Robert Haas wrote:
>
> Well, as far as I know, it's up to me which parts of your emails I want to
> quote in my reply. I did read this part. It did not change my opinion. My
> fundamental objection to your proposal is that I think it is too wordy. I
> think users
On 2018-07-04 13:15:19 -0400, Alvaro Herrera wrote:
> On 2018-Jun-30, Tom Lane wrote:
>
> > Alvaro Herrera writes:
> > > Fix crash when ALTER TABLE recreates indexes on partitions
> >
> > So ... buildfarm member skink has been reporting a valgrind failure
> > during initdb since this patch went
On Thu, Jul 05, 2018 at 03:10:33AM +0900, Fujii Masao wrote:
> On Tue, Jul 3, 2018 at 11:28 AM, Michael Paquier wrote:
> Thanks for the review! So, committed.
Thanks.
>> (please indent!).
>
> Hmm.. I failed to find indent issue in my patch... But anyway
> future execution of pgindent will fix
On Wed, Jul 04, 2018 at 09:57:31AM -0400, Alvaro Herrera wrote:
> None from me.
Thanks Alvaro. For now the patch uses the following error message:
+SELECT pg_replication_slot_advance('regression_slot3', '0/1'); -- error
+ERROR: cannot move slot with non-reserved restart_lsn
Mentioning directly
On Wed, Jul 4, 2018 at 7:53 PM, Michael Paquier wrote:
> On Wed, Jul 04, 2018 at 06:54:05PM -0700, Peter Geoghegan wrote:
>> I don't know about any of that, but something has to give. How much
>> more time has to pass before we admit defeat? At a certain point, that
>> is the responsible thing to
Hello.
At Wed, 04 Jul 2018 17:23:51 -0400, Tom Lane wrote in
<67470.1530739...@sss.pgh.pa.us>
> Kyotaro HORIGUCHI writes:
> > At Mon, 2 Jul 2018 14:25:58 -0400, Robert Haas
> > wrote in
> >
> >> Copying the whole hash table kinds of sucks, partly because of the
> >> time it will take to
On Wed, Jul 04, 2018 at 06:54:05PM -0700, Peter Geoghegan wrote:
> I don't know about any of that, but something has to give. How much
> more time has to pass before we admit defeat? At a certain point, that
> is the responsible thing to do.
Well, for this one it is not really complicated to
On Wed, Jul 4, 2018 at 7:09 PM, David Rowley
wrote:
> hmm. Maybe I missed any other use case. The mention of hypothetical
> indexes seems a bit lost on this thread. Andrew's proposal mentions
> that an invisible index will just not be considered by the planner.
> I'd very much assume here that
On 5 July 2018 at 13:31, Peter Geoghegan wrote:
> On Wed, Jul 4, 2018 at 6:26 PM, David Rowley
> wrote:
>> Or would it be insanely weird to just not allow setting or unsetting
>> this invisible flag if indcheckxmin is true? I can't imagine there
>> will be many people adding an index and not
On Mon, Jul 2, 2018 at 6:30 PM, Michael Paquier wrote:
> On Mon, Jul 02, 2018 at 10:30:11AM -0400, Andrew Dunstan wrote:
>> 528 1146 Fix the optimization to skip WAL-logging on table created in
>> same transaction
>
> This has been around for an astonishing amount of time... I don't
> recall all
On Mon, Jul 02, 2018 at 10:41:05PM +0900, Michael Paquier wrote:
> I am planning to finish wrapping this patch luckily on Wednesday JST
> time, or in the worst case on Thursday. I got this problem on my mind
> for a couple of days now and I could not find a case where the approach
> taken could
On Wed, Jul 04, 2018 at 08:19:48PM -0500, Larry Rosenman wrote:
> On Thu, Jul 05, 2018 at 12:56:49PM +1200, Thomas Munro wrote:
> > On Thu, Jul 5, 2018 at 12:35 PM, Larry Rosenman wrote:
> > > I agree. Is there an easy way I can add this work around to peripatus'
> > > source tree:
> > >
> > >
On Wed, Jul 4, 2018 at 6:26 PM, David Rowley
wrote:
> Or would it be insanely weird to just not allow setting or unsetting
> this invisible flag if indcheckxmin is true? I can't imagine there
> will be many people adding an index and not wanting to use it while
> it's still being created. I
On 19 June 2018 at 09:56, Andres Freund wrote:
> Be careful about that - currently it's not actually trivially possible
> to ever update pg_index rows. No, I'm not kidding
> you. pg_index.indexcheckxmin relies on the pg_index row's xmin. If you
> have ALTER do a non inplace update, you'll break
On Thu, Jul 05, 2018 at 12:56:49PM +1200, Thomas Munro wrote:
> On Thu, Jul 5, 2018 at 12:35 PM, Larry Rosenman wrote:
> > I agree. Is there an easy way I can add this work around to peripatus'
> > source tree:
> >
> > It may be that adding "LDFLAGS+= -Wl,-z,notext" (and removing LLD_UNSAFE)
>
From: Craig Ringer [mailto:cr...@2ndquadrant.com]
> I'm assuming you don't want to offer a grant that lets anyone use them for
> anything. But if you have a really broad grant to PostgreSQL, all someone
> would have to do to inherit the grant is re-use some part of PostgreSQL.
Your assumption is
On Tue, Jul 3, 2018 at 12:41 AM Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> > rhaas=# drop table foo;
> > ERROR: table "foo" does not exist
> > HINT: Try dropping a table with a different name that does exist, or
> > first create this table before trying to drop it.
>
> Again a
On Thu, Jul 5, 2018 at 12:35 PM, Larry Rosenman wrote:
> I agree. Is there an easy way I can add this work around to peripatus'
> source tree:
>
> It may be that adding "LDFLAGS+= -Wl,-z,notext" (and removing LLD_UNSAFE)
> will let the port build with lld.
Maybe something like this at the end
On 2018/07/05 9:40, Andres Freund wrote:
> On 2018-07-02 17:14:14 +0900, Amit Langote wrote:
>> I studied this a bit and found a bug that's causing the crash.
>>
>> The above mentioned commit has this hunk:
>>
>> @@ -1309,6 +1311,9 @@ hypothetical_dense_rank_final(PG_FUNCTION_ARGS)
>>
On Wed, Jul 04, 2018 at 07:35:28PM -0500, Larry Rosenman wrote:
> On Thu, Jul 05, 2018 at 12:30:37PM +1200, Thomas Munro wrote:
> > On Thu, Jul 5, 2018 at 11:43 AM, Larry Rosenman wrote:
> > > I noticed my buildfarm member peripatus hadn't been building due to me
> > > missing a perl library.
On 2018-07-02 17:14:14 +0900, Amit Langote wrote:
> I studied this a bit and found a bug that's causing the crash.
>
> The above mentioned commit has this hunk:
>
> @@ -1309,6 +1311,9 @@ hypothetical_dense_rank_final(PG_FUNCTION_ARGS)
> PG_RETURN_INT64(rank);
>
> osastate =
On Thu, Jul 05, 2018 at 12:30:37PM +1200, Thomas Munro wrote:
> On Thu, Jul 5, 2018 at 11:43 AM, Larry Rosenman wrote:
> > I noticed my buildfarm member peripatus hadn't been building due to me
> > missing a perl library. After I fixed that I get failures on:
> >
> > Buildfarm member peripatus
On Thu, Jul 5, 2018 at 11:43 AM, Larry Rosenman wrote:
> I noticed my buildfarm member peripatus hadn't been building due to me
> missing a perl library. After I fixed that I get failures on:
>
> Buildfarm member peripatus failed on REL9_3_STABLE stage Make
> Buildfarm member peripatus failed on
On Wed, May 30, 2018 at 09:59:01AM +0800, Craig Ringer wrote:
> On 30 May 2018 at 09:53, Andres Freund wrote:
> > On May 29, 2018 9:44:09 PM EDT, Craig Ringer wrote:
> > >https://blogs.msdn.microsoft.com/commandline/2017/12/19/af_unix-comes-to-windows/
> > >
> > >The latest Windows 10 update
I noticed my buildfarm member peripatus hadn't been building due to me
missing a perl library. After I fixed that I get failures on:
Buildfarm member peripatus failed on REL9_3_STABLE stage Make
Buildfarm member peripatus failed on REL9_4_STABLE stage Make
Buildfarm member peripatus failed on
Hi,
On 2018-06-27 12:16:29 -0700, Andres Freund wrote:
> I think we should backpatch those checks - it's a fairly nasty situation
> for users to not be able to even drop an index without going to single
> user mode.
Did that back to 9.4 - before that page deletion and splits worked
differently
Hello hackers,
FreeBSD's setproctitle() is a bit slow because it contains a syscall
or two, so people often run PostgreSQL with update_process_title set
to off on that OS. That makes the user experience not quite as nice
as Linux. As a weekend learn-me-some-kernel-hacking project I fixed
that
Thomas Munro writes:
> I'd like to do this to postinit.c:
> PerformAuthentication(MyProcPort);
> + AcceptInvalidationMessages();
> InitializeSessionUserId(username, useroid);
> Any objections?
That seems like a *really* ad-hoc place to put it. Why
On Wednesday, July 4, 2018, Tom Lane wrote:
>
> Also, based on other messages, it seems like what the OP wants is
> to be sure that "CREATE TABLE X" will succeed afterwards, so that
> failing to get rid of view X will not do what he needs.
>
I read and agree that what should be possible, absent
Kyotaro HORIGUCHI writes:
> At Mon, 2 Jul 2018 14:25:58 -0400, Robert Haas wrote
> in
>> Copying the whole hash table kinds of sucks, partly because of the
>> time it will take to copy it, but also because it means that memory
>> usage is still O(nbackends * ntables). Without looking at the
On 2018-Jul-04, Andres Freund wrote:
> On 2018-07-04 17:02:01 -0400, Alvaro Herrera wrote:
> > On 2018-Jul-04, Andres Freund wrote:
> >
> > > > I think the soonest this can work is to add the column in pg12 so that
> > > > it can be used to upgrade to pg13.
> > >
> > > I don't think we can
Robert Haas writes:
> Another possibility that would also seem to meet the OP's needs is to
> make it do this:
> DROP TABLE IF EXISTS X;
> NOTICE: relation "X" is not a table, skipping
> His complaint was really that it generated an ERROR, IIUC.
While that would perhaps meet the OP's desires,
On 2018-07-04 17:02:01 -0400, Alvaro Herrera wrote:
> On 2018-Jul-04, Andres Freund wrote:
>
> > > I think the soonest this can work is to add the column in pg12 so that
> > > it can be used to upgrade to pg13.
> >
> > I don't think we can easily require that everyone pg_upgrading to v13+
> >
On 2018-Jul-04, Andres Freund wrote:
> > I think the soonest this can work is to add the column in pg12 so that
> > it can be used to upgrade to pg13.
>
> I don't think we can easily require that everyone pg_upgrading to v13+
> upgrades to v12 first?
We've never done that, I don't know if we
Andrew Gierth writes:
> This installs to $(includedir_server)/$(MODULEDIR)/$MODULE/file.h
> (e.g. include/server/extension/hstore/hstore.h for an actual example),
> and errors if HEADERS_xxx is defined for anything that's not a module
> listed in MODULES or MODULE_big.
I've not studied this
Hi,
On 2018-07-04 16:43:19 -0400, Alvaro Herrera wrote:
> On 2018-Jul-04, Tom Lane wrote:
>
> > Alvaro Herrera writes:
> > > Requiring a scan of all indexes during pg_upgrade might increase the
> > > upgrade time prohibitively for some sites, so I don't think that's a
> > > good solution.
> >
On 14 May 2018 at 08:35, Simon Muller wrote:
> Okay, I've added this to the next commitfest at
> https://commitfest.postgresql.org/18/1629/.
>
> Thanks both Michael and David for the feedback so far.
>
I noticed through the patch tester link at http://commitfest.cputube.org/
that my patch
On 2018-Jul-04, Tom Lane wrote:
> Alvaro Herrera writes:
> > Requiring a scan of all indexes during pg_upgrade might increase the
> > upgrade time prohibitively for some sites, so I don't think that's a
> > good solution.
>
> Perhaps VACUUM could be taught to clean up invalid entries? That
>
On Fri, Jun 08, 2018 at 11:03:38AM -0700, Andres Freund wrote:
> On 2018-06-08 09:23:02 +0100, Simon Riggs wrote:
> > For context, AEL locks are normally removed by COMMIT or ABORT.
> > StandbyReleaseOldLocks() is just a sweeper to catch anything that
> > didn't send an abort before it died, so it
Alvaro Herrera writes:
> Requiring a scan of all indexes during pg_upgrade might increase the
> upgrade time prohibitively for some sites, so I don't think that's a
> good solution.
Perhaps VACUUM could be taught to clean up invalid entries? That
wouldn't help Andrey's unstated goal of being
On 2018-Jul-04, Andrey Borodin wrote:
> Thanks, Tom!
>
> So, I can create the script for pg_upgrade that will walk through each old
> enough[0] GiST index, scan for invalid tuples and repair them. This procedure
> seems quite trivial, but there will be more code that we have now. Does it
>
On Tue, Jul 3, 2018 at 11:28 AM, Michael Paquier wrote:
> On Tue, Jul 03, 2018 at 04:13:15AM +0900, Fujii Masao wrote:
>> OK, so what about the attached patch?
>
> I have been looking at this patch, and this looks in good shape to me
Thanks for the review! So, committed.
> (please indent!).
Prabhat Sahu writes:
> I have taken pg_dumpall in pg-master and after restoring the dump I am not
> able to see the "Access privileges" as below:
> Same is reproducible in back branches as well, is this fine ?
Yes, it is, because the privileges are the same in both states. In
one case you have
On 2018-Jun-30, Tom Lane wrote:
> Alvaro Herrera writes:
> > Fix crash when ALTER TABLE recreates indexes on partitions
>
> So ... buildfarm member skink has been reporting a valgrind failure
> during initdb since this patch went in. However, I'm unable to reproduce
> such a failure here, and
On Tue, Jul 3, 2018 at 4:34 PM, Srinivas Karthik V
wrote:
> @Peter: I was indexing the primary key of all the tables in tpc-ds. Some of
> the fact tables has multiple columns as part of the primary key. Also, most
> of them are numeric type.
Please see my mail to -hackers on suffix truncation:
I've been working on B-Tree suffix truncation, as part of a larger
effort to make all index tuples have unique keys by treating their
heap TID as a first class part of the key space, as part of an even
larger (and still ill-defined) effort to improve index vacuuming
(a.k.a. "retail index tuple
On Wed, Jul 4, 2018 at 4:47 PM, Jamison, Kirk wrote:
> Hi, Fujii-san
>
> I came across this post and I got interested in it,
> so I tried to apply/test the patch but I am not sure if I did it correctly.
> I set-up master-slave sync, 200GB shared_buffers, 2
> max_locks_per_transaction,
> 1
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
I reviewed and tested patch one more times, including check
> 4 июля 2018 г., в 19:22, Tom Lane написал(а):
>
> Andrey Borodin writes:
>> There is bunch of code in current GiST implementation checking for
>> GistTupleIsInvalid(). PostgreSQL since 9.1 do not create invalid tuples.
>> Should we support this tuples forever?
>
> The question is not
Andrey Borodin writes:
> There is bunch of code in current GiST implementation checking for
> GistTupleIsInvalid(). PostgreSQL since 9.1 do not create invalid tuples.
> Should we support this tuples forever?
The question is not whether we still create such tuples. The reason
the code is still
On Wed, Jul 4, 2018 at 5:08 AM, Pavan Deolasee wrote:
> But AFAICS get_relation_info() tries to lock every index and since REINDEX
> will be holding a AEL on the index being reindexed, get_relation_info()
> blocks. Since get_relation_info() gets into every read path, wouldn't a
> concurrent
Hi,
I got an assertion failure when I use GROUPS mode and specifies offset
without ORDER BY clause. The reproduction steps and the backtrace I
got are following.
=# create table test as select 1 as c;
=# select sum(c) over (partition by c groups between 1 preceding and
current row) from test;
On 2018-Jul-04, Michael Paquier wrote:
> At the end, are their any objections into fixing the issue and
> tightening the advancing API?
None from me.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Jun 20, 2018 at 2:06 PM, Daniel Gustafsson wrote:
>> On 27 Apr 2018, at 04:24, Andres Freund wrote:
>>
>> On 2018-04-27 11:52:18 +0930, Tom Dunstan wrote:
I'd argue this should contain the non-error cases. It's just as
reasonable to want to add this as a debug level or such.
On Tue, Jul 3, 2018 at 6:17 AM, ROS Didier wrote:
> Hi
>
>I Would like to know how to encrypt data with *physical*
> public key files. I can’t find any documentation about this subject.
>
>Thanks in advance
>
This isn't really a suitable question for
Haribabu Kommi wrote:
> On Wed, Jan 24, 2018 at 9:01 AM Jing Wang wrote:
> > Hi All,
> >
> > Recently I put a proposal to support 'prefer-read' parameter in
> > target_session_attrs in libpq. Now I updated the patch with adding content
> > in the sgml and regression test case.
> >
> > Some
On Wed, Jul 4, 2018 at 5:36 PM, Etsuro Fujita
wrote:
> (2018/07/04 19:04), Ashutosh Bapat wrote:
>>
>> On Fri, Jun 29, 2018 at 6:21 PM, Etsuro Fujita
>> wrote:
>>>
>>> (2018/06/22 22:54), Ashutosh Bapat wrote:
+ if (enable_partitionwise_join&&
The documentation [1] claims that REINDEX does not block readers on the
table.
"REINDEX is similar to a drop and recreate of the index in that the index
contents are rebuilt from scratch. However, the locking considerations are
rather different. REINDEX locks out writes but not reads of the
(2018/07/04 19:04), Ashutosh Bapat wrote:
On Fri, Jun 29, 2018 at 6:21 PM, Etsuro Fujita
wrote:
(2018/06/22 22:54), Ashutosh Bapat wrote:
+ if (enable_partitionwise_join&& rel->top_parent_is_partitioned)
+ {
+ build_childrel_tlist(root, rel, childrel, 1,);
+ }
On Wed, Jul 4, 2018 at 12:59 AM, Michael Paquier wrote:
> On Fri, Mar 30, 2018 at 10:06:46AM +0900, Kyotaro HORIGUCHI wrote:
>> Hello. I found that c203d6cf81 hit this and this is the rebased
>> version on the current master.
>
> Okay, as this is visibly the oldest item in this commit fest,
On Mon, Jul 2, 2018 at 6:42 PM Sergei Kornilov wrote:
> Hello
>
Thanks for the review.
> I found SELECT pg_stat_statements_reset(NULL,NULL,s.queryid) in tests and
> it pass tests, but i wonder how it works. Should not we check the NULL
> through PG_ARGISNULL macro before any PG_GETARG_*?
On Tue, Jul 3, 2018 at 5:06 PM Andres Freund wrote:
> Hi,
>
> As I've previously mentioned I had planned to spend some time to polish
> Haribabu's version of the pluggable storage patch and rebase it on the
> vtable based slot approach from [1]. While doing so I found more and
> more things that
(2018/07/02 18:46), Etsuro Fujita wrote:
(2018/06/22 23:58), Robert Haas wrote:
And, in general, it seems to me that we want
to produce the right outputs at the lowest possible level of the plan
tree. For instance, suppose that one of the relations being scanned
is not parallel-safe but the
On Fri, Jun 29, 2018 at 6:21 PM, Etsuro Fujita
wrote:
> (2018/06/22 22:54), Ashutosh Bapat wrote:
>>
>> I have started reviewing the patch.
>
>
> Thanks for the review!
>
>> + if (enable_partitionwise_join&& rel->top_parent_is_partitioned)
>> + {
>> +
Hi hackers,
while I tried to debug 'gcc -fstack-protector -O3' problems in [1], I noticed
that gbt_var_union() mistreats the first vector element. Patch is attached.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1544349
Pavel
>From 4e4f0fe8d2f74a85f37abdf095ab8aecf9329596 Mon Sep 17 00:00:00
On Wed, Jul 4, 2018 at 4:35 PM, Michael Paquier wrote:
> I wanted to comment on that this morning but forgot as my mind was
> driven away by another problem. What if you used the Julien-Rouhaud's
> method of a custom script with only ";" used as query and -c? This
> won't run any queries, and
On 02.07.18 10:38, Daniel Gustafsson wrote:
>> On 29 Jun 2018, at 18:44, Tom Lane wrote:
>
>> +1 for shortening it as proposed by Peter. The existing arrangement
>> made sense when it was first written, when there were only about three
>> individual options IIRC. Now it's just confusing,
Hello. This is new version fixed windows build.
At Tue, 03 Jul 2018 19:01:44 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20180703.190144.222427588.horiguchi.kyot...@lab.ntt.co.jp>
> Hello. Thanks for the comment.
>
> At Mon, 2 Jul 2018 14:25:58 -0400, Robert Haas wrote
> in
>
Hello.
At Tue, 26 Jun 2018 16:26:59 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20180626.162659.223208514.horiguchi.kyot...@lab.ntt.co.jp>
> The previous patche files doesn't have version number so I let
> the attached latest version be v2.
>
>
>
Hi, Fujii-san
I came across this post and I got interested in it,
so I tried to apply/test the patch but I am not sure if I did it correctly.
I set-up master-slave sync, 200GB shared_buffers, 2
max_locks_per_transaction,
1 DB with 500 table partitions shared evenly across 5 tablespaces.
On 02.07.18 17:11, Ashutosh Sharma wrote:
> Firstly, it would test if the ROLLBACK works as expected when used
> with the deferred constraints in plpgsql procedures. Secondly, it
> would test if the COMMIT/ROLLBACK works as expected for deferrable
> constraints which was initially immediate type
On 03.07.18 19:20, Andres Freund wrote:
> On 2018-06-29 10:19:17 -0700, Andres Freund wrote:
>> Hi,
>>
>> On 2018-06-29 13:56:12 +0200, Peter Eisentraut wrote:
>>> On 6/29/18 13:07, amul sul wrote:
This happens because of in fmgr_security_definer() function we are
changing global
>-Original Message-
>From: AJG [mailto:ay...@gera.co.nz]
>Sent: Wednesday, June 27, 2018 3:21 AM
>To: pgsql-hack...@postgresql.org
>Subject: Re: Global shared meta cache
>
>Ideriha, Takeshi wrote
>> 2) benchmarked 3 times for each conditions and got the average result
>> of TPS.
>>
Hi.
I wonder why we mention on the following page that CREATE COLLATION
requires SHARE ROW EXCLUSIVE lock
https://www.postgresql.org/docs/devel/static/explicit-locking.html
I know that's the lock taken on the pg_collation catalog, but do we need
to mention locks taken by a DDL command on the
On 2018/06/19 2:05, Tom Lane wrote:
> Amit Langote writes:
>> [ 0001-Open-partitioned-tables-during-Append-initialization.patch ]
>
> I took a look at this. While I'm in agreement with the general idea of
> holding open the partitioned relations' relcache entries throughout the
> query, I do
Hi, hackers!
When execute sql with prepared protocol, read committed transaction will hold
backend_xmin until the end of the transaction.
Is this behavior normal?
Should read committed transaction release backend_xmin immediately after SQL
executing is completed? Just like
when executing sql
76 matches
Mail list logo
