On Thu, Apr 19, 2018 at 6:20 PM, Andres Freund wrote:
> On April 18, 2018 8:05:50 PM PDT, Thomas Munro
> wrote:
>>By the way, these patches only use the death signal to make
>>PostmasterIsAlive() fast, for use by busy loops like recovery. The
>>postmaster pipe is still used for IO/timeout loops
On 2018/04/18 21:55, Etsuro Fujita wrote:
> (2018/04/18 14:44), Amit Langote wrote:
>> Oh, I didn't really consider this part carefully. That the resultRelInfo
>> received by BeginForeignInsert (when called by ExecInitRoutingInfo) could
>> be a reused UPDATE result relation. It might be possible
About CMake:
We can use 3.9 version very well, it has all features for us, at least for
my postgres_cmake branch and I have the experience to introduce features to
cmake special for postgres build.
Also, cmake very easily build even for Solaris or AIX (on my webpage I have
examples to build postgre
Thank you, pushed
Peter Geoghegan wrote:
On Wed, Apr 18, 2018 at 10:47 PM, Teodor Sigaev wrote:
Thank you, pushed.
Thanks.
I saw another preexisting issue, this time one that has been around
since 2007. Commit bc292937 forgot to remove a comment above
_bt_insertonpg() (the 'afteritem' stuff
On 2018/04/18 19:27, Amit Langote wrote:
> Please find attached an updated version of your patch. I think we'll need
> to make some documentation changes and think about a way to back-patch
> this to PG10.
Added documentation changes. Also, noticed that there was no need to
change the production
Hi,
Encountered the following behavior with initdb on one of our test
builds while using latest master head:
initdb -D $DATADIR
The program "postgres" was found by "/Users/nikhils/install/bin/initdb"
but was not the same version as initdb.
Check your installation.
Intrigued, on digging down fur
>
> The above is all about getting the build system to work at all. If that
> isn't a showstopper there's a subsequent discussion to be had about older
> platforms where one could get the build system to work but convenient
> packages are missing. For example not even RHEL7 has any Python3 packages
On 4/18/18, Tom Lane wrote:
> John Naylor writes:
>> and dug through a bit to find cases where 'catalog' is clearly a
>> better term. Most of these are in the pg_*.h/.dat file boilerplate
>> comments, which would be easy enough to change with a script. If we're
>> going to do that, the word order
On 2018/04/18 5:18, Alvaro Herrera wrote:
> Amit Langote wrote:
>
>> 0001-Make-copying-of-cached-partitioning-info-more-con.patch
>> 0002-Cache-all-partitioning-info-under-one-memory-cont.patch
>> 0003-Cache-partsupfunc-separately-from-PartitionKey.patch
>
> I'd rather not do these patches now, u
At Tue, 17 Apr 2018 16:41:31 +0900, Etsuro Fujita
wrote in <5ad5a52b.7050...@lab.ntt.co.jp>
> (2018/04/17 16:10), Amit Langote wrote:
> > On 2018/04/17 11:13, Kyotaro HORIGUCHI wrote:
> >> If I'm reading this correctly, ExecInitParititionInfo calls
> >> ExecInitRoutingInfo so currently CheckValid
Hi.
On 2018/04/19 6:45, Alvaro Herrera wrote:
> Amit Langote wrote:
>> On Thu, Apr 19, 2018 at 12:01 AM, Alvaro Herrera
>> wrote:
>
>>> Makes sense. Still, I was expecting that pruning of hash partitioning
>>> would also work for pseudotypes, yet it doesn't.
>>
>> It does?
>
> Aha, so it does.
Various comments in GetOldestXmin mention the possibility of the oldest
xmin going backward, and assert that this is actually safe. It's not.
Consider:
A table has a toastable column. A row is updated in a way that changes
the toasted value. There are now two row versions pointing to different
to
On 2018/04/19 13:32, Ashutosh Bapat wrote:
> On Thu, Apr 19, 2018 at 2:54 AM, David Rowley
>> The more I think about this the more undecided I am as to whether we
>> need to add a GUC for this at all, so I'm keen to hear more people
>> voice their opinion about this. If bugs are the only true reas
Thanks for reviewing.
At Wed, 18 Apr 2018 19:27:16 +0900, Amit Langote
wrote in
<7ac6b44e-4638-3320-1512-f6c03a28d...@lab.ntt.co.jp>
> Horiguchi-san,
>
> Thank you for updating the patch.
>
> On 2018/04/16 16:17, Kyotaro HORIGUCHI wrote:
> > the attached v6 patch differs only in gram.y since
06.04.2018 09:19, Alexander Lakhin wrote:
To avoid overheating of this pretty hot discussion, I would like just
to propose "a more elaborated fix" (for REL_10_STABLE and master).
In fact, when we perform "make installcheck" it not only requires us
to build ecpg, but it also rebuilds libpostgres,
(2018/04/19 16:43), Amit Langote wrote:
On 2018/04/18 21:55, Etsuro Fujita wrote:
(2018/04/18 14:44), Amit Langote wrote:
That the resultRelInfo
received by BeginForeignInsert (when called by ExecInitRoutingInfo) could
be a reused UPDATE result relation.
2. This is UPDATE and the resultRelIn
(2018/04/19 19:03), Kyotaro HORIGUCHI wrote:
At Tue, 17 Apr 2018 16:41:31 +0900, Etsuro Fujita wrote
in<5ad5a52b.7050...@lab.ntt.co.jp>
(2018/04/17 16:10), Amit Langote wrote:
On 2018/04/17 11:13, Kyotaro HORIGUCHI wrote:
If I'm reading this correctly, ExecInitParititionInfo calls
ExecInitRo
On Thu, Apr 19, 2018 at 5:02 PM, Amit Langote
wrote:
> On 2018/04/19 13:32, Ashutosh Bapat wrote:
>> On Thu, Apr 19, 2018 at 2:54 AM, David Rowley
>>> The more I think about this the more undecided I am as to whether we
>>> need to add a GUC for this at all, so I'm keen to hear more people
>>> voi
On 19.04.2018 07:46, Tsunakawa, Takayuki wrote:
From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru]
Oracle, for example, you can create dedicated and non-dedicated backends.
I wonder why we do not want to have something similar in Postgres.
Yes, I want it, too. In addition to dedica
Nikhil Sontakke wrote:
> Intrigued, on digging down further, this is happening because we are
> not using a long enough buffer to accept the output of "postgres -V"
> in the find_other_exec() function. In our case, we had used
> --with-extra-version option with configure which caused the output of
On Thu, Apr 19, 2018 at 7:19 AM, Michael Paquier wrote:
> On Wed, Apr 18, 2018 at 10:52:51AM -0400, Robert Haas wrote:
>> I would just document the risks. If the documentation says that you
>> can't rely on the value until after the next checkpoint, or whatever
>> the rule is, then I think we're
=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?= writes:
>> The above is all about getting the build system to work at all. If that
>> isn't a showstopper there's a subsequent discussion to be had about older
>> platforms where one could get the build system to work but convenient
>> packages a
On Thu, Apr 19, 2018, 9:24 AM Konstantin Knizhnik, <
k.knizh...@postgrespro.ru> wrote:
>
>
> On 19.04.2018 07:46, Tsunakawa, Takayuki wrote:
> > From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru]
> > Oracle, for example, you can create dedicated and non-dedicated backends.
> >> I wonder
Amit Langote wrote:
> On 2018/04/19 6:45, Alvaro Herrera wrote:
> > Please give this version another look. I also rewrote a couple of
> > comments.
>
> Thanks, your rewritten version looks much better.
Thanks! Pushed now.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
Postgre
I'll take a look tomorrow.
Interesting, contrib/amcheck doesn't find any error in index. Seems, it's
subject for further improvement.
Nevertheless, seems, I found. In _bt_mark_page_halfdead() we use truncated high
key IndexTuple as a storage of blocknumber of top parent to remove. And sets
Amit Langote wrote:
> Yeah, I too have wondered in the past what it would take to make
> equalTupDescs() return true for parent and partitions. Maybe we can make
> it work by looking a bit harder than I did then.
How about simply relaxing the tdtypeid test from equalTupleDescs? I
haven't looked
On 2018-04-18 06:36:38 -0400, Heikki Linnakangas wrote:
> On 18/04/18 06:10, Konstantin Knizhnik wrote:
> > But there are still use cases which can not be covered y external
> > connection pooler.
>
> Can you name some? I understand that the existing external connection
> poolers all have their li
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2018-04-18 06:36:38 -0400, Heikki Linnakangas wrote:
> > On 18/04/18 06:10, Konstantin Knizhnik wrote:
> > > But there are still use cases which can not be covered y external
> > > connection pooler.
> >
> > Can you name some? I understa
On Thu, Apr 19, 2018 at 9:42 AM, Teodor Sigaev wrote:
> Interesting, contrib/amcheck doesn't find any error in index. Seems, it's
> subject for further improvement.
I think that you're right that this should be detectable by
bt_index_parent_check(). I have an idea about how we can make this
happe
On Wed, Apr 18, 2018 at 7:06 PM, Alvaro Herrera
wrote:
>
>
> IMO the cause is the totally_frozen variable, which starts life in a
> bogus state (true) and the different code paths can set it to the right
> state, or by inaction end up deciding that the initial bogus state was
> correct in the fir
I would like to go and implement this check now, and if all goes well
I may propose that you commit it to the master branch for v11. I don't
see this as a new feature. I see it as essential testing
infrastructure. What do you think about adding this new check soon?
Agree. Hope, nobody found a way
On Thu, Apr 19, 2018 at 1:20 PM, Alvaro Herrera wrote:
> Amit Langote wrote:
>> Yeah, I too have wondered in the past what it would take to make
>> equalTupDescs() return true for parent and partitions. Maybe we can make
>> it work by looking a bit harder than I did then.
>
> How about simply rel
Stephen Frost writes:
> Greetings,
> * Andres Freund (and...@anarazel.de) wrote:
>> On 2018-04-18 06:36:38 -0400, Heikki Linnakangas wrote:
>>> However, I suspect that dealing with *all* of the issues is going to be hard
>>> and tedious. And if there are any significant gaps, things that don't wor
On 19/04/18 09:38, Alvaro Herrera wrote:
Nikhil Sontakke wrote:
Intrigued, on digging down further, this is happening because we are
not using a long enough buffer to accept the output of "postgres -V"
in the find_other_exec() function. In our case, we had used
--with-extra-version option with
On Thu, Apr 19, 2018 at 12:00 PM, Robert Haas wrote:
> On Thu, Apr 19, 2018 at 1:20 PM, Alvaro Herrera
> wrote:
>> How about simply relaxing the tdtypeid test from equalTupleDescs? I
>> haven't looked deeply but I think just checking whether or not both are
>> RECORDOID might be sufficient, for
Alvaro Herrera wrote:
> Amit Langote wrote:
>
> > Yeah, I too have wondered in the past what it would take to make
> > equalTupDescs() return true for parent and partitions. Maybe we can make
> > it work by looking a bit harder than I did then.
>
> How about simply relaxing the tdtypeid test fro
I also think that we could have better conventional regression test
coverage here.
I tried to minimize Michael's test case and add it to patch.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
diff --git a/src/backen
On Thu, 19 Apr 2018 at 10:27, Dave Cramer wrote:
> It would be useful to test with the JDBC driver
> We run into issues with many pool implementations due to our opinionated
nature
Absolutely.
And Java developers frequently have a further opinionated nature on this...
A bunch of Java framework
Michael Paquier wrote:
> Then, let's consider the beginning of the first commit fest of v12 as
> judgement. Implementing radix tree for shared buffers is a long-term
> project, which has no guarantee to get merged, while a visibly-simple
> reloptions which helps in some cases...
In the scenario
Heikki Linnakangas wrote:
> Nitpick: using MAXPGPATH seems for the buffer size seems to wrong to me.
> We're not storing a path here. MAXPGPATH is 1024 by default, which seems
> fine, but I would've spelled it out directly as "line[1000]".
Hmm ... yeah, kinda. Do you care about it strongly enoug
2018-04-19 21:56 GMT+02:00 Alvaro Herrera :
> Michael Paquier wrote:
>
> > Then, let's consider the beginning of the first commit fest of v12 as
> > judgement. Implementing radix tree for shared buffers is a long-term
> > project, which has no guarantee to get merged, while a visibly-simple
> > r
On 2018-04-19 16:56:59 -0300, Alvaro Herrera wrote:
> Michael Paquier wrote:
>
> > Then, let's consider the beginning of the first commit fest of v12 as
> > judgement. Implementing radix tree for shared buffers is a long-term
> > project, which has no guarantee to get merged, while a visibly-simp
Andres Freund wrote:
> On 2018-04-19 16:56:59 -0300, Alvaro Herrera wrote:
> > Michael Paquier wrote:
> >
> > > Then, let's consider the beginning of the first commit fest of v12 as
> > > judgement. Implementing radix tree for shared buffers is a long-term
> > > project, which has no guarantee to
Tom Lane wrote:
> The test case that's failing, in identity.sql, has been there since
> early February; the lack of any crashes till more recently suggests
> that something committed in mid-to-late March broke it.
>
> I have no idea what's going on there, but I think this is clearly
> something w
On 2018-04-19 15:01:24 -0400, Tom Lane wrote:
> Only after you can say "there's nothing wrong with this that isn't
> directly connected to its not being in-core" does it make sense to try
> to push the logic into core.
I think there's plenty things that don't really make sense solving
outside of p
On Thu, Apr 19, 2018 at 10:47 PM, Teodor Sigaev wrote:
> I also think that we could have better conventional regression test
>> coverage here.
>>
>
> I tried to minimize Michael's test case and add it to patch.
- if (ItemPointerIsValid(leafhikey))
+ if (ItemPointerGetBlockNumberNoCheck(leafhike
John Naylor writes:
> I've attached a patch that mostly touches boilerplate comments in the
> headers and data files. I couldn't resist editing some comments for
> clarity and consistency.
Pushed, along with a little bit of extra tweaking to fix random
discrepancies in the header comments.
> Not
Alvaro Herrera writes:
> Of the machines you listed, conchuela has gdb installed, which gives us
> a nice backtrace of the crash, pasted below, which seems to blame event
> triggers. Of the tests in the same parallel group as identity, the test
> fast_default seems to be the only one with an even
I wrote:
> I'm inclined to say that whether or not there's a bug here (and there
> well may be, it doesn't seem like a crash is a good thing), this is
> bad test design and we need to change it.
So my suspicion was aroused by the fact that, unlike almost every
other function in event_trigger.c, Ev
> "Alvaro" == Alvaro Herrera writes:
Alvaro> I can't look further into this now -- maybe next week if nobody
Alvaro> has beaten me into it. My guess is that the identity stuff is
Alvaro> not setting state like event triggers expect.
I think this is unrelated to the identity stuff. I suspe
Tom Lane wrote:
> Hence, two questions:
>
> * Should EventTriggerTableRewrite do
>
> if (!currentEventTriggerState ||
> currentEventTriggerState->commandCollectionInhibited)
> return;
>
> like most of the other functions, or should it just check for null
> currentEventTrigge
On Wed, Apr 18, 2018 at 2:22 AM, Michael Paquier wrote:
> I was thinking about this problem, and it looks that one approach for
> double-writes would be to introduce it as a secondary WAL stream
> independent from the main one:
> - Once a buffer is evicted from shared buffers and is dirty, write i
> I think there's plenty things that don't really make sense solving
> outside of postgres:
> - additional added hop / context switches due to external pooler
This is only applied to external process type pooler (like Pgpool-II).
> - temporary tables
> - prepared statements
> - GUCs and other ses
On Wed, Apr 18, 2018 at 11:40:51AM +0200, Fabien COELHO wrote:
>> - double-write buffers use a pre-decided numbers of pages (32 for the
>> checkpointer, 128 divided into 4 buckets for the backends), which are
>> synced into disk once each batch is full.
>
>> - The double-write file of the checkpoi
On Thu, Apr 19, 2018 at 06:28:01PM -0400, Robert Haas wrote:
> On Wed, Apr 18, 2018 at 2:22 AM, Michael Paquier wrote:
>> I was thinking about this problem, and it looks that one approach for
>> double-writes would be to introduce it as a secondary WAL stream
>> independent from the main one:
>> -
On Fri, Apr 20, 2018 at 07:58:00AM +0900, Tatsuo Ishii wrote:
> Yeah. Since SCRAM auth is implemented, some connection poolers
> including Pgpool-II are struggling to adopt it.
Er, well. pgpool is also taking advantage of MD5 weaknesses... While
SCRAM fixes this class of problems, and channel bi
On Thu, Apr 19, 2018 at 04:59:44PM -0300, Alvaro Herrera wrote:
> Heikki Linnakangas wrote:
>> Nitpick: using MAXPGPATH seems for the buffer size seems to wrong to me.
>> We're not storing a path here. MAXPGPATH is 1024 by default, which seems
>> fine, but I would've spelled it out directly as "lin
> On Fri, Apr 20, 2018 at 07:58:00AM +0900, Tatsuo Ishii wrote:
>> Yeah. Since SCRAM auth is implemented, some connection poolers
>> including Pgpool-II are struggling to adopt it.
>
> Er, well. pgpool is also taking advantage of MD5 weaknesses... While
> SCRAM fixes this class of problems, and
>
> My gut reaction to Catalin's list is that requiring C+11 is a pretty
> darn high bar to clear for older platforms.
>
It's only for latest version and we can support version 3.9 with C++98 I
think at least 5 years.
3.9.6 was realease in November 10, 2017 .
That's a pretty big shift from the pr
On Thu, Apr 19, 2018 at 03:10:42PM +0900, Michael Paquier wrote:
> You are right. I can easily see the leak if I use for example a
> background worker which connects to a database, and launches many
> transactions in a row. The laziest reproducer I have is to patch one of
> my bgworkers to launch
Fujita-san,
Thanks for the updated patch.
On 2018/04/19 21:42, Etsuro Fujita wrote:
> (2018/04/19 16:43), Amit Langote wrote:
>> Would it be a good idea to explain *why* we need to replace the RTE in the
>> first place? Afaics, it's for deparseColumnRef() to find the correct
>> relation when it
On Thu, Apr 19, 2018 at 2:00 PM, Alexander Korotkov
wrote:
> - if (ItemPointerIsValid(leafhikey))
> + if (ItemPointerGetBlockNumberNoCheck(leafhikey) != InvalidBlockNumber)
>
> Should we use BTreeInnerTupleGetDownLink() as soon as we use
> BTreeInnerTupleSetDownLink() for setting this?
> Or even i
On Thu, Apr 19, 2018 at 07:11:43PM +0530, Amit Kapila wrote:
> On Thu, Apr 19, 2018 at 7:19 AM, Michael Paquier wrote:
>> And, er, actually, I was thinking again about the case where a user
>> wants to disable full_page_writes temporarily to do some bulk load and
>> then re-enable it. With the pa
On 2018/04/20 4:40, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> Amit Langote wrote:
>>
>>> Yeah, I too have wondered in the past what it would take to make
>>> equalTupDescs() return true for parent and partitions. Maybe we can make
>>> it work by looking a bit harder than I did then.
>>
>> H
On Thu, Apr 19, 2018 at 11:59 AM, Teodor Sigaev wrote:
> Agree. Hope, nobody found a way how to use amcheck module in production to
> serve user requests. But, it should be implemented before BETA stage, in
> opposite case we will get a lot of objections.
It shouldn't take that long to get a patc
On Thu, Apr 19, 2018 at 10:47:02PM +0300, Teodor Sigaev wrote:
> I tried to minimize Michael's test case and add it to patch.
I cannot comment on the actual fix as I lack background in the area, but
having a test case and even more having pg_upgrade do some work on those
pages are good things. Th
what about just free _SPI_stack in AtEOXact_SPI? if the transaction end was
initiated by SPI , AtEOXact_SPI will do nothing.
for example:
@@ -283,6 +295,8 @@ AtEOXact_SPI(bool isCommit)
errmsg("transaction left non-empty SPI stack"),
On 2018/04/19 21:50, Ashutosh Bapat wrote:
> On Thu, Apr 19, 2018 at 5:02 PM, Amit Langote
>> I can imagine having a enable_partition_pruning which defaults to true, if
>> only to avoid the performance overhead of pruning code when a user knows
>> for sure that it won't help for some queries. Alth
On 20 April 2018 at 14:07, Amit Langote wrote:
> To clarify: if we're going to add a new parameter *for partitioned tables*
> to configure whether or not pruning occurs, even if UPDATE and DELETE now
> rely on constraint exclusion for pruning, we should ignore the setting of
> constraint_exclusion
Hi.
On 2018/04/20 11:18, David Rowley wrote:
> On 20 April 2018 at 14:07, Amit Langote wrote:
>> To clarify: if we're going to add a new parameter *for partitioned tables*
>> to configure whether or not pruning occurs, even if UPDATE and DELETE now
>> rely on constraint exclusion for pruning, we
(2018/04/20 9:48), Amit Langote wrote:
On 2018/04/19 21:42, Etsuro Fujita wrote:
(2018/04/19 16:43), Amit Langote wrote:
Would it be a good idea to explain *why* we need to replace the RTE in the
first place? Afaics, it's for deparseColumnRef() to find the correct
relation when it uses planner
On 20 April 2018 at 14:33, Amit Langote wrote:
> On 2018/04/20 11:18, David Rowley wrote:
>> 4. Replace test doing (constraint_exclusion ==
>> CONSTRAINT_EXCLUSION_PARTITION) with (enable_partition_pruning).
>> 5. Get rid of CONSTRAINT_EXCLUSION_PARTITION.
>
> About 4 & 5:
>
> Perhaps we should le
On Fri, Apr 20, 2018 at 10:00:38AM +0800, jian.l...@i-soft.com.cn wrote:
> what about just free _SPI_stack in AtEOXact_SPI? if the transaction
> end was initiated by SPI , AtEOXact_SPI will do nothing. For example:
> @@ -283,6 +295,8 @@ AtEOXact_SPI(bool isCommit)
>
On Wed, Apr 18, 2018 at 11:43 AM, Jonathan Rudenberg
wrote:
> On Tue, Apr 17, 2018, at 19:31, Thomas Munro wrote:
>> On Wed, Apr 18, 2018 at 11:01 AM, Jonathan Rudenberg
>> wrote:
>> > Yep, I think I know approximately what it looked like, I've attached a
>> > lightly redacted plan. All of the h
On 20 April 2018 at 14:07, Amit Langote wrote:
> To clarify: if we're going to add a new parameter *for partitioned tables*
> to configure whether or not pruning occurs, even if UPDATE and DELETE now
> rely on constraint exclusion for pruning, we should ignore the setting of
> constraint_exclusion
On Fri, Apr 20, 2018 at 7:37 AM, Amit Langote
wrote:
> On 2018/04/19 21:50, Ashutosh Bapat wrote:
>> On Thu, Apr 19, 2018 at 5:02 PM, Amit Langote
>>> I can imagine having a enable_partition_pruning which defaults to true, if
>>> only to avoid the performance overhead of pruning code when a user k
By the way, I think I found a bug of FPW.
The following steps yields INSERT record that doesn't have a FPI
after a checkpoint.
(Start server with full_page_writes = off)
CREATE TABLE t (a int);
CHECKPOINT;
INSERT INTO t VALUES (1);
ALTER SYSTEM SET full_page_writes TO on;
SELECT pg_reload_conf();
I tried to minimize Michael's test case and add it to patch.
-if (ItemPointerIsValid(leafhikey))
+if (ItemPointerGetBlockNumberNoCheck(leafhikey) != InvalidBlockNumber)
Should we use BTreeInnerTupleGetDownLink() as soon as we use
BTreeInnerTupleSetDownLink() for setting this?
Or even invent
heard of people using bt_index_parent_check() in production, but only
when they already knew that their database was corrupt, and wanted to
isolate the problem. I imagine that people that use
bt_index_parent_check() in production do so because they want as much
information as possible, and are wil
Christopher>One of the things that they find likable is that by having the
connection
pool live
Christopher>in the framework alongside the application is that this makes
it easy to
attach
Christopher>hooks so that the pool can do intelligent things based on
application-aware
logic.
I'm afraid I do
80 matches
Mail list logo
