On Wed, Apr 24, 2019 at 1:58 PM Amit Kapila wrote:
> The two improvements in this code which are discussed in this thread
> and can be done independently to this patch are:
> a. use one bit to represent each block in the map. This gives us the
> flexibility to use the map for the different
On Wed, Apr 24, 2019 at 9:49 PM Andres Freund wrote:
> On 2019-04-24 11:28:32 +0530, Amit Kapila wrote:
> > On Tue, Apr 23, 2019 at 10:59 PM Andres Freund wrote:
> > > > > On 2019-04-22 18:49:44 +0530, Amit Kapila wrote:
> > > > I think we should first try to see in this new scheme (a) when to
On Wed, Apr 24, 2019 at 10:36 PM Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Apr-24, Paul Guo wrote:
> >> On Wed, Apr 24, 2019 at 12:49 PM Andres Freund
> wrote:
> >>> This seems like a bad idea to me. IMO we want to support using a pipe
> >>> etc here. If the admin creates a fifo
On 2019/04/25 8:27, Tom Lane wrote:
> Amit Langote writes:
>> 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.
>
> After thinking about it more, it seems like a bad
On Thu, Apr 25, 2019 at 9:53 AM alex lock wrote:
>
>
> that's something I want to change, as I said at the beginning. include
> avoid some memory release (like the EState and so on), snapshot release.
>
>
I check my original statement, I found "snapshot release" was missed, that
obviously
On Wed, Apr 24, 2019 at 11:30 PM Tom Lane wrote:
> alex lock writes:
> > The cursor means something like declare c cursor for select * from t;
> > The holdable cursor means declare c cursor WITH HOLD for select * from t;
>
> > Holdable cursor is good at transaction, user can still access it
On 2019/04/25 0:55, Amit Langote wrote:
> On Thu, Apr 25, 2019 at 12:39 AM Amit Langote wrote:
>> On Thu, Apr 25, 2019 at 12:38 AM Amit Langote
>> wrote:
>>> On Thu, Apr 25, 2019 at 12:35 AM Alvaro Herrera
>>> wrote:
On 2019-Apr-25, Amit Langote wrote:
> It seems that
On Sun, Apr 14, 2019 at 05:51:47PM +0200, Laurenz Albe wrote:
> test=> INSERT INTO ser (id) VALUES (DEFAULT);
> ERROR: more than one owned sequence found
Yes this should never be user-triggerable, so it seems that we need to
fix and back-patch something if possible.
> I propose that we check if
Peter Geoghegan writes:
> ... I'm not
> seeing why the context that the PrepareTempTablespaces() catalog
> access occurs in actually matters.
The point there is that a catalog access might leak some amount of
memory. Probably not enough to be a big deal, but ...
On Wed, Apr 24, 2019 at 12:17 PM Tom Lane wrote:
> After a bit more thought it seemed like another answer would be to
> make all three of those functions assert that the caller did the
> right thing, as per attached. This addresses the layering-violation
> complaint, but might be more of a pain
On Wed, Apr 24, 2019 at 05:18:08PM -0700, Andres Freund wrote:
> Just so it's guaranteed that it'll never happen? :)
Items get done, from time to time... b0eaa4c is one rare example :p
/me runs and hides.
--
Michael
signature.asc
Description: PGP signature
On Wed, Apr 24, 2019 at 10:36:03AM -0400, Tom Lane wrote:
> Nah, I don't buy that one either. Nobody has any business creating any
> non-Postgres files in the stats directory ... and if somebody does want
> to stick a FIFO in there, perhaps for debug purposes, why should we stop
> them?
I have
On 2019-04-25 09:16:50 +0900, Michael Paquier wrote:
> Perhaps you should add a TODO item for that?
Just so it's guaranteed that it'll never happen? :)
On Wed, Apr 24, 2019 at 04:09:56PM -0700, Andres Freund wrote:
> I think we should change dbsize.c to call
> RelationGetNumberOfBlocksInFork() for relkinds != TABLE/TOAST/MATVIEW,
> and a new AM callback for those. Probably with the aforementioned
> additional logic of closing smgr references if
Amit Langote writes:
> 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.
After thinking about it more, it seems like a bad idea to put the check
in CheckIndexCompatible;
Hi,
To me it seems like a noticable layering violation for dbsize.c to
directly stat() files in the filesystem, without going through
smgr.c. And now tableam.
This means there's code knowing about file segments outside of md.c -
which imo shouldn't be the case. We also stat a lot more than
On Wed, Apr 24, 2019 at 3:04 PM Tom Lane wrote:
> > It is disabled by default, in the sense that the trace_sort GUC
> > defaults to off. I believe that the overhead of building in the
> > instrumentation without enabling it is indistinguishable from zero.
>
> It would probably be useful to
On 2019-Apr-23, Alvaro Herrera wrote:
> I'm not sure yet that 100% of the patch is gone, but yes much of it
> would go away thankfully.
Of course, the part that fixes the bug that indexes move tablespace when
recreated by a rewriting ALTER TABLE is still necessary. Included in
the attached
Peter Geoghegan writes:
> On Wed, Apr 24, 2019 at 2:15 PM Joe Conway wrote:
>> Has anyone ever (or recently) measured the impact on performance to have
>> this enabled? Is it that generically useful for debugging of production
>> instances of Postgres that we really want it always enabled
On Wed, Apr 24, 2019 at 2:29 PM Alvaro Herrera wrote:
> This is a really strange argument. You're saying that somebody thought
> about it: "Hmm, well, I can remove this preprocessor symbol but then
> trace_sort would no longer resemble a developer option. So I'm going to
> leave the symbol
On 2019-Apr-24, Peter Geoghegan wrote:
> I suspect that the reason that this hasn't happened already is because
> it leaves trace_sort/TRACE_SORT in the slightly awkward position of no
> longer quite meeting the traditional definition of a "developer
> option".
This is a really strange argument.
On Wed, Apr 24, 2019 at 2:15 PM Joe Conway wrote:
> Has anyone ever (or recently) measured the impact on performance to have
> this enabled? Is it that generically useful for debugging of production
> instances of Postgres that we really want it always enabled despite the
> performance impact?
On 4/24/19 5:10 PM, Peter Geoghegan wrote:
> On Wed, Apr 24, 2019 at 2:07 PM Joe Conway wrote:
>> I just noticed that TRACE_SORT is defined by default (since 2005
>> apparently). It seems odd since it is the only debugging code enabled by
>> default.
>
> I think that we should get rid of the
On Wed, Apr 24, 2019 at 2:07 PM Joe Conway wrote:
> I just noticed that TRACE_SORT is defined by default (since 2005
> apparently). It seems odd since it is the only debugging code enabled by
> default.
I think that we should get rid of the #ifdef stuff, so that it isn't
possible to disable the
I just noticed that TRACE_SORT is defined by default (since 2005
apparently). It seems odd since it is the only debugging code enabled by
default.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
Alexander Korotkov writes:
> On Wed, Apr 24, 2019 at 9:31 PM Tom Lane wrote:
>> Why is this so bad? It's not like the gist regression test isn't
>> ridiculously expensive already; I'd have expected it to provide
>> darn near 100% coverage for what it's costing in runtime.
> I don't think there
On Tue, Apr 16, 2019 at 9:15 AM Tomas Vondra
wrote:
>
> I'm not sure it's that clear cut, actually. Sure, it's not the usual
> (block,item) pair so it's not possible to jump to the exact location, so
> it's not the raw physical identifier as regular TID. But the data are
> organized in a btree,
I wrote:
> Here's a draft patch for that.
>
> It's slightly ugly that this adds a dependency on commands/tablespace
> to fd.c, which is a pretty low-level module. I think wanting to avoid
> that layering violation might've been the reason for doing things the
> way they are. However, this gets
On Tue, Apr 23, 2019 at 1:06 PM Tom Lane wrote:
> There are three functions in fd.c that have a dependency on the
> temp tablespace info having been set up:
> OpenTemporaryFile
> GetTempTablespaces
> GetNextTempTableSpace
> This patch makes the first of those
So, while testing this I noticed that pg_restore fails with deadlocks if
you do a parallel restore if the --load-via-partition-root switch was
given to pg_dump. Is that a known bug?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
As a user, I am interested in the optimizer changes for sure, and I
actually had wished they were highlighted more in previous releases.
> I think planner smarts are arguably one of our weakest areas when
> compared to the big commercial databases. The more we can throw in
> there about this sort
On Wed, Apr 24, 2019 at 9:31 PM Tom Lane wrote:
> This tells a pretty scary story:
>
> https://coverage.postgresql.org/src/backend/access/gist/index.html
>
> In particular, gistbuildbuffers.c is not entered *at all*, and
> gistbuild.c is only 21% covered.
>
> I noticed this after adding an
This tells a pretty scary story:
https://coverage.postgresql.org/src/backend/access/gist/index.html
In particular, gistbuildbuffers.c is not entered *at all*, and
gistbuild.c is only 21% covered.
I noticed this after adding an assertion that I expected
gistInitBuildBuffers to fail on, and
On Mon, Apr 22, 2019 at 1:39 AM Tom Lane wrote:
> Alexander Korotkov writes:
> >> On Wed, Apr 17, 2019 at 8:43 PM Tom Lane wrote:
> >>> Yeah, I'd noticed that one too :-(. I think the whole jsonpath patch
> >>> needs a sweep to bring its error messages into line with our style
> >>>
On Wed, Apr 24, 2019 at 10:43 AM Peter Geoghegan wrote:
> The hard part is how to do varwidth encoding for space-efficient
> partition numbers while continuing to use IndexTuple fields for heap
> TID on the leaf level, *and* also having a
> BTreeTupleGetHeapTID()-style macro to get partition
On Wed, Apr 24, 2019 at 10:10 AM Tomas Vondra
wrote:
> >I'm still interested in the answer to this question, but I don't see a
> >reply that specifically concerns it. Apologies if I have missed one.
>
> I don't think prefetching WAL blocks is all that important. The WAL
> segment was probably
On Wed, Apr 24, 2019 at 5:22 AM Robert Haas wrote:
> If you drop or detach a partition, you can either (a) perform, as part
> of that operation, a scan of every global index to remove all
> references to the former partition, or (b) tell each global indexes
> that all references to that partition
Andres Freund writes:
> On 2019-04-24 10:13:09 -0400, Tom Lane wrote:
>> I can't say that I like 0001 at all. It adds a bunch of complication and
>> new failure modes (e.g., having to panic on chdir failure) in order to do
>> what exactly? I've not been following the thread closely, but the
>>
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Apr 24, 2019 at 9:28 AM Stephen Frost wrote:
> > At least in part then it seems like we're viewing the level of effort
> > around what I'm talking about quite differently, and I feel like that's
> > largely because every time I
On Wed, Apr 24, 2019 at 9:25 AM Andres Freund wrote:
> The inability
> to reasonably test master/standby setups on a single machine is pretty
> jarring (yes, one can use basebackup tablespace maps - but that doesn't
> work well for new tablespaces).
+1 agree. Feature which can't be easily
Hi,
On 2019-04-24 17:02:28 +0900, Kyotaro HORIGUCHI wrote:
> +/*
> + * Check if the path is in the data directory strictly.
> + */
> +static bool
> +is_in_data_directory(const char *path)
> +{
> + char cwd[MAXPGPATH];
> + char abspath[MAXPGPATH];
> + char absdatadir[MAXPGPATH];
> +
>
Hi,
On 2019-04-24 10:13:09 -0400, Tom Lane wrote:
> Kyotaro HORIGUCHI writes:
> > At Wed, 24 Apr 2019 13:23:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> > wrote in
> > <20190424.132304.40676137.horiguchi.kyot...@lab.ntt.co.jp>
> >> We need to adjust relative path between PGDATA-based
Hi,
On 2019-04-24 11:28:32 +0530, Amit Kapila wrote:
> On Tue, Apr 23, 2019 at 10:59 PM Andres Freund wrote:
> > > > On 2019-04-22 18:49:44 +0530, Amit Kapila wrote:
> > > I think we should first try to see in this new scheme (a) when to set
> > > the map, (b) when to clear it, (c) how to use.
On Wed, Apr 24, 2019 at 9:28 AM Stephen Frost wrote:
> Looking at it from what I'm sitting, I brought up two ways that we
> could extend the protocol to "request from the server only those blocks
> where LSN >= threshold_value" with one being the modification to
> BASE_BACKUP and the other being
On Thu, Apr 25, 2019 at 12:39 AM Amit Langote wrote:
> On Thu, Apr 25, 2019 at 12:38 AM Amit Langote wrote:
> > On Thu, Apr 25, 2019 at 12:35 AM Alvaro Herrera
> > wrote:
> > > On 2019-Apr-25, Amit Langote wrote:
> > >
> > > > It seems that DefineIndex() is forgetting to update_relispartition()
On Thu, Apr 25, 2019 at 12:38 AM Amit Langote wrote:
> On Thu, Apr 25, 2019 at 12:35 AM Alvaro Herrera
> wrote:
> > On 2019-Apr-25, Amit Langote wrote:
> >
> > > It seems that DefineIndex() is forgetting to update_relispartition()
> > > on a partition's index when it's attached to an index being
On Thu, Apr 25, 2019 at 12:35 AM Alvaro Herrera
wrote:
> On 2019-Apr-25, Amit Langote wrote:
>
> > It seems that DefineIndex() is forgetting to update_relispartition()
> > on a partition's index when it's attached to an index being added to
> > the parent. That results in unexpected behavior
On 2019-Apr-25, Amit Langote wrote:
> It seems that DefineIndex() is forgetting to update_relispartition()
> on a partition's index when it's attached to an index being added to
> the parent. That results in unexpected behavior when adding a foreign
> key referencing the parent.
BTW, maybe
On 2019-Apr-25, Amit Langote wrote:
> It seems that DefineIndex() is forgetting to update_relispartition()
> on a partition's index when it's attached to an index being added to
> the parent. That results in unexpected behavior when adding a foreign
> key referencing the parent.
Ah, thanks for
Hi,
It seems that DefineIndex() is forgetting to update_relispartition()
on a partition's index when it's attached to an index being added to
the parent. That results in unexpected behavior when adding a foreign
key referencing the parent.
create table foo (a int) partition by list (a);
create
alex lock writes:
> The cursor means something like declare c cursor for select * from t;
> The holdable cursor means declare c cursor WITH HOLD for select * from t;
> Holdable cursor is good at transaction, user can still access it after the
> transaction is commit. But it is bad at it have
On Sun, 2019-04-14 at 20:15 +0200, I wrote:
> I wrote:
> > Identity columns don't work if they own more than one sequence.
>
> Alternatively, maybe getOwnedSequence should only consider sequences
> with an "internal" dependency on the column. That would avoid the problem
> without forbidding
On Wed, Apr 24, 2019 at 11:12 AM Matsumura, Ryo
wrote:
>
> 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
Alvaro Herrera writes:
> On 2019-Apr-24, Paul Guo wrote:
>> On Wed, Apr 24, 2019 at 12:49 PM Andres Freund wrote:
>>> This seems like a bad idea to me. IMO we want to support using a pipe
>>> etc here. If the admin creates a fifo like this without attaching a
>>> program it seems like it's their
Kyotaro HORIGUCHI writes:
> At Wed, 24 Apr 2019 13:23:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
> <20190424.132304.40676137.horiguchi.kyot...@lab.ntt.co.jp>
>> We need to adjust relative path between PGDATA-based and
>> pg_tblspc based. The attached first patch does that.
>
On Wed, Apr 24, 2019 at 09:25:12AM -0400, Robert Haas wrote:
On Mon, Apr 22, 2019 at 9:51 PM Robert Haas wrote:
For this particular use case, wouldn't you want to read the WAL itself
and use that to issue prefetch requests? Because if you use the
.modblock files, the data file blocks will end
On Wed, 2019-04-24 at 14:25 +0100, Simon Riggs wrote:
> On Wed, 24 Apr 2019 at 12:55, Etsuro Fujita
> wrote:
>
> > > My point is that this should not be necessary.
> >
> > In my opinion, I think this is necessary...
>
> Could we decide by looking at what FDWs are known to exist?
> I hope we
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Apr 22, 2019 at 2:26 PM Stephen Frost wrote:
> > There was basically zero discussion about what things would look like at
> > a protocol level (I went back and skimmed over the thread before sending
> > my last email to
The cursor means something like declare c cursor for select * from t;
The holdable cursor means declare c cursor WITH HOLD for select * from t;
Holdable cursor is good at transaction, user can still access it after the
transaction is commit. But it is bad at it have to save all the record to
On Mon, Apr 22, 2019 at 9:51 PM Robert Haas wrote:
> For this particular use case, wouldn't you want to read the WAL itself
> and use that to issue prefetch requests? Because if you use the
> .modblock files, the data file blocks will end up in memory but the
> WAL blocks won't, and you'll still
On Wed, 24 Apr 2019 at 12:55, Etsuro Fujita
wrote:
> > My point is that this should not be necessary.
>
> In my opinion, I think this is necessary...
>
Could we decide by looking at what FDWs are known to exist? I hope we are
trying to avoid breakage in the smallest number of FDWs.
--
Simon
On Wed, 2019-04-24 at 20:54 +0900, Etsuro Fujita wrote:
> How about adding to the documentation for BeginForeignInsert a mention
> that if an FDW doesn't support COPY FROM and/or routable foreign tables,
> it must throw an error in BeginForeignInsert accordingly.
Sure, some more documentation
On 2019-Apr-24, Paul Guo wrote:
> On Wed, Apr 24, 2019 at 12:49 PM Andres Freund wrote:
> > This seems like a bad idea to me. IMO we want to support using a pipe
> > etc here. If the admin creates a fifo like this without attaching a
> > program it seems like it's their fault.
>
> Oh, I never
On Tue, 23 Apr 2019 at 04:54, Bruce Momjian wrote:
>
> We had a discussion in October about adding more optimizer items to the
> release notes:
>
>
> https://www.postgresql.org/message-id/flat/20181010220601.GA7807%40momjian.us#11d805ea0b0fcd0552dfa99251417cc1
>
> There was no agreement
On Mon, Apr 22, 2019 at 1:16 PM Peter Geoghegan wrote:
> Yes, though that should probably work by reusing what we already do
> with heap TID (use standard IndexTuple fields on the leaf level for
> heap TID), plus an additional identifier for the partition number that
> is located at the physical
On Tue, Apr 23, 2019 at 6:55 PM Tom Lane wrote:
> 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,
(2019/04/23 4:37), Laurenz Albe wrote:
On Mon, 2019-04-22 at 21:45 +0900, Etsuro Fujita wrote:
(2019/04/20 20:53), Laurenz Albe wrote:
On Fri, 2018-04-06 at 23:24 +, Robert Haas wrote:
Allow insert and update tuple routing and COPY for foreign tables.
Also enable this for postgres_fdw.
On 4/22/19 6:54 PM, Bruce Momjian wrote:
We had a discussion in October about adding more optimizer items to the
release notes:
https://www.postgresql.org/message-id/flat/20181010220601.GA7807%40momjian.us#11d805ea0b0fcd0552dfa99251417cc1
There was no agreement on a change, but if
Mmm. I posted to wrong thread. Sorry.
At Tue, 23 Apr 2019 16:39:49 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190423.163949.36763221.horiguchi.kyot...@lab.ntt.co.jp>
> At Tue, 23 Apr 2019 13:31:58 +0800, Paul Guo wrote in
>
> > Hi Kyotaro, ignoring the MakePGDirectory()
Fujita-san,
On 2019/04/24 18:55, Etsuro Fujita wrote:
> (2019/04/23 10:03), Amit Langote wrote:
>> Thanks for adding me as an author, but I think the latest
>> patch is mostly your work, so I'm happy to be listed as just a reviewer. :)
>
> You found this bug, analyzed it, and wrote the first
(2019/04/23 10:03), Amit Langote wrote:
So, it seems to OK to keep this commit this as one patch.
I read your commit message and it seems to sufficiently explain the issues
being fixed.
Cool!
Thanks for adding me as an author, but I think the latest
patch is mostly your work, so I'm happy
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 persistence column
should be shown as is?
Temporariness added, but not raw.
Ok, it
Hello.
At Wed, 24 Apr 2019 13:23:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190424.132304.40676137.horiguchi.kyot...@lab.ntt.co.jp>
> > > with a check that forces relative paths to be outside of PGDATA (baring
> > > symlinks). As far as I can tell
On Wed, 24 Apr 2019 at 14:53, Amit Langote
wrote:
>
> On 2019/04/24 10:19, David Rowley wrote:
> > ERROR: invalid input syntax for type integer: "One"
> > LINE 1: INSERT INTO public.listp1 VALUES ('One', 1);
> >
> > That settles the debate on the other thread...
>
> +1 to fixing this, although
Hi,
Finally, I find this crash is caused by shmget_osm, which does not support
SmartOS (maybe,
I am not sure). When I install Oracle Instant Client 12.2.0.1.0, it works.
https://github.com/laurenz/oracle_fdw/issues/313
On 4/23/19 3:09 PM, Laurenz Albe wrote:
On Tue, 2019-04-23 at 04:26
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
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'. */
> >
77 matches
Mail list logo
