On Tue, Apr 23, 2019 at 07:03:58AM +0200, Fabien COELHO wrote:
>
> Hello David,
>
> > I noticed that there wasn't a bulk way to see table logged-ness in psql,
> > so I made it part of \dt+.
>
> Applies, compiles, works for me.
>
> ISTM That temporary-ness is not shown either. Maybe the persiste
On Tue, Apr 23, 2019 at 10:59 PM Andres Freund wrote:
> > > On 2019-04-22 18:49:44 +0530, Amit Kapila wrote:
> > > > /*
> > > > @@ -1132,9 +1110,6 @@ fsm_local_set(Relation rel, BlockNumber
> > > > cur_nblocks)
> > > > /* Set the status of the cached target block to 'unavailable'. */
> > >
On Wed, Apr 24, 2019 at 12:49 PM Andres Freund wrote:
> Hi,
>
> On 2019-04-24 12:46:15 +0800, Paul Guo wrote:
> > This is, in theory, not a 100% bug, but it is probably not unusual to see
> > conflicts of files between postgresql sqls and other applications on the
> > same node so I think the fix
Hi,
On 2019-04-24 12:46:15 +0800, Paul Guo wrote:
> This is, in theory, not a 100% bug, but it is probably not unusual to see
> conflicts of files between postgresql sqls and other applications on the
> same node so I think the fix is needed. I checked all code that calls
> AllocateFile() and wrot
Hello, Postgres hackers.
I happened to see a hang issue when running a simple copy query. The root
cause and repro way are quite simple.
mkfifo /tmp/a
run sql:
copy (select generate_series(1, 10)) to '/tmp/a';
It hangs at AllocateFile()->fopen() because that file was previously
created as a fif
Sorry, I was in haste.
At Wed, 24 Apr 2019 13:18:45 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190424.131845.116224815.horiguchi.kyot...@lab.ntt.co.jp>
> At Tue, 23 Apr 2019 10:05:03 -0700, Andres Freund wrote
> in <20190423170503.uw5jxrujqlozg...@alap3.anarazel.de>
> > Hi,
>
At Tue, 23 Apr 2019 10:05:03 -0700, Andres Freund wrote in
<20190423170503.uw5jxrujqlozg...@alap3.anarazel.de>
> Hi,
>
> On 2019-04-23 16:08:18 +0900, Michael Paquier wrote:
> > On Mon, Apr 22, 2019 at 11:00:03PM -0700, Andres Freund wrote:
> > > FWIW, I think the right fix for this is to simply
On 2019/04/24 10:19, David Rowley wrote:
> On Wed, 24 Apr 2019 at 06:50, Alvaro Herrera wrote:
>> Per my comment at https://postgr.es/m/2019045129.GA6126@alvherre.pgsql
>> I think that pg_dump can possibly cause bogus partition definitions,
>> when the users explicitly decide to join tables as
Hi Fabien,
I review your patch.
> Add a few tests for the new feature.
+++ b/src/test/regress/expected/psql.out
@@ -4729,3 +4729,46 @@ drop schema testpart;
set search_path to default;
set role to default;
drop role testrole_partitioning;
+--
There is space (+--' '). Please delete it. It is
On Tue. Apr. 23, 2019 at 02:59 AM Masao, Fujii
wrote:
Thank you for the comment.
> So I think that the patch should fix also the description for those
> replication functions. Thought?
I think so too.
I attach a new patch.
Regards
Ryo Matsumura
replication_functions_doc.patch
Description: re
On 2019/04/23 20:03, David Rowley wrote:
> On Tue, 23 Apr 2019 at 18:18, Amit Langote
> wrote:
>>
>> If partitions needed a
>> map in the old database, this patch means that they will *continue* to
>> need it in the new database.
>
> That's incorrect.
Not completely though, because...
> My poin
Thanks for looking at this.
On 2019/04/24 7:03, Tom Lane wrote:
> ISTM we could work around the problem with the attached, which I think
> is a good change independently of anything else.
Agreed.
> There is still an issue, which manifests in both 11 and HEAD, namely
> that the code also propagat
On Wed, 24 Apr 2019 at 06:50, Alvaro Herrera wrote:
> Per my comment at https://postgr.es/m/2019045129.GA6126@alvherre.pgsql
> I think that pg_dump can possibly cause bogus partition definitions,
> when the users explicitly decide to join tables as partitions that have
> different column order
On 2019-Apr-24, David Rowley wrote:
> On Wed, 24 Apr 2019 at 10:26, Alvaro Herrera wrote:
> > If creating a partition, there is the additional rule that parent's
> > tablespace overrides default_tablespace:
> >
> > a2. if there's a TABLESPACE clause, use that.
> > b2. otherwise, if the parent h
On Tue, Apr 23, 2019 at 07:54:52PM -0400, Tom Lane wrote:
> That seems like pretty much of a hack :-(, in particular I'm not
> convinced that we'd not end up with a missing index entry afterwards.
> Maybe it's the only way, but I think first we need to trace down
> exactly why this broke. I rememb
I wrote:
> It also seems quite odd that it doesn't fail every time; surely it's
> not conditional whether we'll try to insert a new pg_class tuple or not?
> We need to understand that, too.
Oh! One gets you ten it "works" as long as the pg_class update is a
HOT update, so that we don't actually e
Michael Paquier writes:
> On Tue, Apr 23, 2019 at 04:47:19PM -0400, Tom Lane wrote:
>> Is there some precondition you're not mentioning?
> Hm. In my own init scripts, I create a new database just after
> starting the instance.
Ah, there we go:
regression=# create database d1;
CREATE DATABASE
r
On Tue, 23 Apr 2019 at 01:12, David Rowley wrote:
> I started working on this today and I've attached what I have so far.
I've added this to the July commitfest so that I don't forget about it.
https://commitfest.postgresql.org/23/2102/
--
David Rowley http://www.2ndQuadrant
On Tue, Apr 23, 2019 at 04:47:19PM -0400, Tom Lane wrote:
> regression=# reindex index pg_class_relname_nsp_index;
> REINDEX
> regression=# reindex index pg_class_oid_index;
> REINDEX
> regression=# reindex index pg_class_tblspc_relfilenode_index;
> REINDEX
> regression=# reindex table pg_class;
On Wed, 24 Apr 2019 at 10:26, Alvaro Herrera wrote:
> If creating a partition, there is the additional rule that parent's
> tablespace overrides default_tablespace:
>
> a2. if there's a TABLESPACE clause, use that.
> b2. otherwise, if the parent has a tablespace, use that.
> c2. otherwise, if t
Andres Freund writes:
> ... I think none of these are critical issues for tableam, but we should fix
> them.
> I'm not sure about doing so for v12 though. 1) and 3) are fairly
> trivial, but 2) would involve changing the FDW interface, by changing
> the AnalyzeForeignTable, AcquireSampleRowsFunc
Hi,
On 2019-04-08 15:34:46 +0300, Heikki Linnakangas wrote:
> index_update_stats() calls RelationGetNumberOfBlocks(). If the AM
> doesn't use normal data files, that won't work. I bumped into that with my
> toy implementation, which wouldn't need to create any data files, if it
> wasn't for this.
Thanks for taking the time to think through this.
On 2019-Apr-22, Robert Haas wrote:
> If we know what the feature is supposed to do, then it should be
> possible to look at each relevant piece of code and decides whether it
> implements the specification correctly or not. But if we don't have a
On Tue, 23 Apr 2019 at 20:23, Peter Eisentraut
wrote:
> The attached patch is based on your sketch. It's clearly better in the
> long term not to rely on heap tuples here. But in testing this change
> seems to make it slightly slower, certainly not a speedup as you were
> apparently hoping for.
Andrew Dunstan writes:
> Test above works as expected with the patch, see attached. This is from
> jacana.
Great, thanks for checking!
> LMK if you want more tests run before I blow the test instance away
Can't think of anything else.
It'd be nice if we could cover stuff like this in the regr
On 4/21/19 10:21 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 4/21/19 12:28 AM, Tom Lane wrote:
>>> I don't have any way to test this on Windows, so could somebody
>>> do that? Manually running the Turkish test cases ought to be enough.
>> How does one do that? Just set a Turkish locale?
>
ISTM we could work around the problem with the attached, which I think
is a good change independently of anything else.
There is still an issue, which manifests in both 11 and HEAD, namely
that the code also propagates the parent index's comment to any child
indexes. You can see that with this ex
On 2019-Apr-18, Michael Paquier wrote:
> Fujii-san has sent me a report offline about REINDEX. And since 9.6,
> trying to REINDEX directly an index of pg_class fails lamentably on an
> assertion failure (mbsync failure if bypassing the assert):
Hmm, yeah, I ran into this crash too, more than a y
Michael Paquier writes:
> Fujii-san has sent me a report offline about REINDEX. And since 9.6,
> trying to REINDEX directly an index of pg_class fails lamentably on an
> assertion failure (mbsync failure if bypassing the assert):
So ... I can't reproduce this on HEAD. Nor the back branches.
re
On Wed, Apr 24, 2019 at 1:15 AM Tom Lane wrote:
> Ibrar Ahmed writes:
> > I am working on an FDW where the database does not support any operator
> > other than "=" in JOIN condition. Some queries are genrating the plan
> with
> > JOIN having "<" operator. How and at what stage I can stop FDW to
Ibrar Ahmed writes:
> I am working on an FDW where the database does not support any operator
> other than "=" in JOIN condition. Some queries are genrating the plan with
> JOIN having "<" operator. How and at what stage I can stop FDW to not make
> such a plan. Here is my sample query.
What exac
Keep in mind that a large part of the reason why the \cset patch got
bounced was exactly that its detection of \; was impossibly ugly
and broken. Don't expect another patch using the same logic to
get looked on more favorably.
Looking at the end of the discussion about \cset, it seems what
y
I wrote:
> Peter Geoghegan writes:
>> That doesn't seem like a particularly good or complete answer, though.
>> Perhaps it should simply be called within BufFileCreateTemp(). The
>> BufFile/fd.c layering is confusing in a number of ways IMV.
> I don't actually see why BufFileCreateTemp should do
Hi,
I am working on an FDW where the database does not support any operator
other than "=" in JOIN condition. Some queries are genrating the plan with
JOIN having "<" operator. How and at what stage I can stop FDW to not make
such a plan. Here is my sample query.
tpch=# select
l_orderkey,
I hope it's alright to throw in my $0.02 as a user. I've been following
this (and the other thread on reading WAL to find modified blocks,
prefaulting, whatever else) since the start with great excitement and would
love to see the built-in backup capabilities in Postgres greatly improved.
I know th
In pursuit of the problem with standby servers sometimes not responding
to fast shutdowns [1], I spent awhile staring at the postmaster's
state-machine logic. I have not found a cause for that problem,
but I have identified some other things that seem like bugs:
1. sigusr1_handler ignores PMSIGN
Tom Lane wrote:
> Keep in mind that a large part of the reason why the \cset patch got
> bounced was exactly that its detection of \; was impossibly ugly
> and broken. Don't expect another patch using the same logic to
> get looked on more favorably.
Looking at the end of the discussion
Per my comment at https://postgr.es/m/2019045129.GA6126@alvherre.pgsql
I think that pg_dump can possibly cause bogus partition definitions,
when the users explicitly decide to join tables as partitions that have
different column ordering than the parent table. Any COPY or INSERT
command withou
Hello All,
Please find attached a patch that explains Log-Shipping standby server
major upgrades.
We agreed to do this in
https://www.postgresql.org/message-id/CAA4eK1%2Bo6ErVAh484VtE91wow1-uOysohSvb0TS52Ei76PzOKg%40mail.gmail.com
Thanks,
Konstantin Evteev
diff --git a/doc/src/sgml/ref/pgupgrade.
On Tue, Apr 23, 2019 at 10:09:39AM -0700, Andres Freund wrote:
Hi,
On 2019-04-23 19:01:29 +0200, Tomas Vondra wrote:
On Tue, Apr 23, 2019 at 09:34:54AM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-04-23 18:07:40 +0200, Tomas Vondra wrote:
> > Well, the thing is that for prefetching to be possi
On Fri, Apr 19, 2019 at 6:34 PM Peter Geoghegan wrote:
> Attached revision does it that way, specifically by adding a new field
> to the insertion scankey struct (BTScanInsertData).
Pushed.
--
Peter Geoghegan
Hi,
On 2019-04-23 13:31:25 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-04-23 15:46:17 +0530, Amit Kapila wrote:
> >> If we invalidate it only when there's no space on the page, then when
> >> should we set it back to available, because if we don't do that, then
> >> we might miss t
Andres Freund writes:
> On 2019-04-23 15:46:17 +0530, Amit Kapila wrote:
>> If we invalidate it only when there's no space on the page, then when
>> should we set it back to available, because if we don't do that, then
>> we might miss the space due to concurrent deletes.
> Well, deletes don't tr
Hello Tom,
Keep in mind that a large part of the reason why the \cset patch got
bounced was exactly that its detection of \; was impossibly ugly
and broken. Don't expect another patch using the same logic to
get looked on more favorably.
Although I do not claim that my implementation was ve
Hi,
On 2019-04-23 15:46:17 +0530, Amit Kapila wrote:
> On Mon, Apr 22, 2019 at 10:34 PM Andres Freund wrote:
> > On 2019-04-22 18:49:44 +0530, Amit Kapila wrote:
> > > /*
> > > @@ -1132,9 +1110,6 @@ fsm_local_set(Relation rel, BlockNumber cur_nblocks)
> > > BlockNumber blkno,
> > >
Alvaro Herrera writes:
> On 2019-Apr-23, Laurenz Albe wrote:
>> Maybe you should open an oracle_fdw issue, but I don't know how
>> much I can help you, since this is the first time I have heard
>> of SmartOS.
> SmartOS is just the continuation of OpenSolaris, AFAIU.
Yeah. You can see these same
On 2019-Apr-23, Laurenz Albe wrote:
> Maybe you should open an oracle_fdw issue, but I don't know how
> much I can help you, since this is the first time I have heard
> of SmartOS.
SmartOS is just the continuation of OpenSolaris, AFAIU.
--
Álvaro Herrerahttps://www.2ndQuadrant.c
Hi,
On 2019-04-23 19:01:29 +0200, Tomas Vondra wrote:
> On Tue, Apr 23, 2019 at 09:34:54AM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2019-04-23 18:07:40 +0200, Tomas Vondra wrote:
> > > Well, the thing is that for prefetching to be possible you actually have
> > > to be a bit behind. Otherwi
Hi,
On 2019-04-23 16:08:18 +0900, Michael Paquier wrote:
> On Mon, Apr 22, 2019 at 11:00:03PM -0700, Andres Freund wrote:
> > FWIW, I think the right fix for this is to simply drop the requirement
> > that tablespace paths need to be absolute. It's not buying us anything,
> > it's just making thin
On Tue, Apr 23, 2019 at 09:34:54AM -0700, Andres Freund wrote:
Hi,
On 2019-04-23 18:07:40 +0200, Tomas Vondra wrote:
Well, the thing is that for prefetching to be possible you actually have
to be a bit behind. Otherwise you can't really look forward which blocks
will be needed, right?
IMHO the
Hi,
On 2019-04-23 18:07:40 +0200, Tomas Vondra wrote:
> Well, the thing is that for prefetching to be possible you actually have
> to be a bit behind. Otherwise you can't really look forward which blocks
> will be needed, right?
>
> IMHO the main use case for prefetching is when there's a spike o
On Tue, Apr 23, 2019 at 11:43:05AM -0400, Stephen Frost wrote:
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
On Tue, Apr 23, 2019 at 10:22:46AM -0400, Stephen Frost wrote:
>* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
>>On Sat, Apr 20, 2019 at 04:21:52PM -0400, Robert
On Sun, Apr 14, 2019 at 02:49:57AM -0400, Chapman Flack wrote:
> Hi,
>
> Both tables in $subject (in datatype.sgml and xfunc.sgml, respectively)
> contain similar information (though the xfunc one mentions C structs and
> header files, and the datatype one does not, but has a description column)
>
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Tue, Apr 23, 2019 at 10:22:46AM -0400, Stephen Frost wrote:
> >* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> >>On Sat, Apr 20, 2019 at 04:21:52PM -0400, Robert Haas wrote:
> >>>On Sat, Apr 20, 2019 at 12:42 AM Stephen Fr
On Tue, Apr 23, 2019 at 10:22:46AM -0400, Stephen Frost wrote:
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
On Sat, Apr 20, 2019 at 04:21:52PM -0400, Robert Haas wrote:
>On Sat, Apr 20, 2019 at 12:42 AM Stephen Frost wrote:
>>> Oh. Well, I already explained my algorithm for
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Sat, Apr 20, 2019 at 04:21:52PM -0400, Robert Haas wrote:
> >On Sat, Apr 20, 2019 at 12:42 AM Stephen Frost wrote:
> >>> Oh. Well, I already explained my algorithm for doing that upthread,
> >>> which I believe would be quite c
"Daniel Verite" writes:
> Fabien COELHO wrote:
>> I added some stuff to extract embedded "\;" for pgbench "\cset", which has
>> been removed though, but it is easy to add back a detection of "\;", and
>> also to detect select. If the position of the last select is known, the
>> cursor can
On Thu, Apr 18, 2019 at 3:12 PM Masahiko Sawada wrote:
>
> On Thu, Apr 18, 2019 at 4:20 AM Peter Geoghegan wrote:
> >
> > On Wed, Apr 17, 2019 at 10:46 AM Tom Lane wrote:
> > > Yeah, if we wanted to expose these complications more directly, we
> > > could think about adding or changing the main
22.04.2019 2:02, Robert Haas wrote:
I think we're getting closer to a meeting of the minds here, but I
don't think it's intrinsically necessary to rewrite the whole method
of operation of pg_basebackup to implement incremental backup in a
sensible way. One could instead just do a straightforward
On Tue, 23 Apr 2019 at 18:18, Amit Langote
wrote:
>
> If partitions needed a
> map in the old database, this patch means that they will *continue* to
> need it in the new database.
That's incorrect. My point was about dropped columns being removed
after a dump / reload. Only binary upgrade mode
At Tue, 23 Apr 2019 19:00:54 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190423.190054.262966274.horiguchi.kyot...@lab.ntt.co.jp>
> > For TAP tests, we can point generated temporary directory by
> > "../../".
Wrong. A generating tmpdir (how?) in "../" (that is, in the node
direco
On Mon, Apr 22, 2019 at 10:34 PM Andres Freund wrote:
> On 2019-04-22 18:49:44 +0530, Amit Kapila wrote:
> > /*
> > @@ -1132,9 +1110,6 @@ fsm_local_set(Relation rel, BlockNumber cur_nblocks)
> > BlockNumber blkno,
> > cached_target_block;
> >
> > - /* The l
At Tue, 23 Apr 2019 17:44:18 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190423.174418.262292011.horiguchi.kyot...@lab.ntt.co.jp>
> At Tue, 23 Apr 2019 16:08:18 +0900, Michael Paquier
> wrote in <20190423070818.gm2...@paquier.xyz>
> > On Mon, Apr 22, 2019 at 11:00:03PM -0700, An
Fabien COELHO wrote:
> I added some stuff to extract embedded "\;" for pgbench "\cset", which has
> been removed though, but it is easy to add back a detection of "\;", and
> also to detect select. If the position of the last select is known, the
> cursor can be declared in the right pl
At Tue, 23 Apr 2019 16:08:18 +0900, Michael Paquier wrote
in <20190423070818.gm2...@paquier.xyz>
> On Mon, Apr 22, 2019 at 11:00:03PM -0700, Andres Freund wrote:
> > FWIW, I think the right fix for this is to simply drop the requirement
> > that tablespace paths need to be absolute. It's not buyi
At Tue, 23 Apr 2019 14:53:28 +0900, Michael Paquier wrote
in <20190423055328.gk2...@paquier.xyz>
> On Tue, Apr 23, 2019 at 01:33:39PM +0900, Kyotaro HORIGUCHI wrote:
> > I think this is rahter a testing or debugging feature. This can
> > be apply to all paths, so the variable might be "path_prefi
On 2019-04-01 11:23, Peter Eisentraut wrote:
> On 2019-03-31 04:57, Andres Freund wrote:
>> while rebasing the remaining tableam patches (luckily a pretty small set
>> now!), I had a few conflicts with ExecComputeStoredGenerated(). While
>> resolving I noticed:
>
> The core of that code was writte
Hi Aya-san,
I tested your v3 patch and it seemed to work on my Linux environment.
However, the CF Patch Tester detected a build failure (probably on Windows).
Refer to: http://commitfest.cputube.org/
Docs:
It would be better to have reference to the documentations of
Frontend/Backend Protocol's
Hello.
At Tue, 23 Apr 2019 13:31:58 +0800, Paul Guo wrote in
> Hi Kyotaro, ignoring the MakePGDirectory() failure will fix this database
> create redo error, but I suspect some other kind of redo, which depends on
> the files under the directory (they are not copied since the directory is
> not
On 2019/04/22 21:45, Etsuro Fujita wrote:
> (2019/04/20 20:53), Laurenz Albe wrote:
>> I propose that PostgreSQL only allows COPY FROM on a foreign table if
>> the FDW
>> implements BeginForeignInsert. The attached patch implements that.
>
> I don't think that is a good idea, because there might
On Tue, 2019-04-23 at 04:26 +, Li Japin wrote:
> Yes, those errors does not impact the postgresql, but when
> I use oracle_fdw extension, I couldn't startup the postgresql,
> and I find that the dlopen throw an error which lead postmaster
> exit, and there is not more information.
That may wal
On Mon, Apr 22, 2019 at 11:00:03PM -0700, Andres Freund wrote:
> FWIW, I think the right fix for this is to simply drop the requirement
> that tablespace paths need to be absolute. It's not buying us anything,
> it's just making things more complicated. We should just do a simple
> check against th
On Mon, 2019-04-22 at 14:07 -0700, Andres Freund wrote:
> How about just applying the patch from v12 on?
> > Then it is a behavior change in a major release, which is acceptable.
> > It requires the imaginary FDW above to add an empty BeginForeignInsert
> > callback function, but will unbreak FDW t
73 matches
Mail list logo
