On Tue, May 07, 2019 at 12:39:13PM +0900, Michael Paquier wrote:
> Okay, point taken. I'll go apply that to the back-branches as well.
And done.
--
Michael
signature.asc
Description: PGP signature
Hi
Commit cc8d4151 [*] introduced a dependency between some functions in
libpgcommon and libpgfeutils, which is not reflected in the linker options
provided when building an external program using PGXS, e.g. attempting to
build the attached (trivial) example results in:
$
On Tue, May 7, 2019 at 3:15 PM Tomas Vondra
wrote:
> On Tue, May 07, 2019 at 01:48:40PM +1200, Thomas Munro wrote:
> >Seems expensive for large numbers of slices -- you need to join the
> >outer batch against each inner slice.
>
> Nope, that's not how it works. It's the array of batches that gets
On Tue, Apr 30, 2019 at 1:20 AM Alexander Korotkov
wrote:
> On Mon, Apr 29, 2019 at 6:11 PM Tom Lane wrote:
> > Alexander Korotkov writes:
> > > [ jsonpath-errors-improve-3.patch ]
> >
> > This is getting better, but IMO it's still a bit too willing to use
> > a boilerplate primary error
On Fri, May 03, 2019 at 08:14:35AM +0200, Laurenz Albe wrote:
> On Thu, 2019-05-02 at 22:43 +0200, Peter Eisentraut wrote:
>> I think the proper way to address this would be to create some kind of
>> dependency between the sequence and the default.
>
> That is certainly true. But that's hard to
On Mon, May 06, 2019 at 01:56:47PM -0400, Bruce Momjian wrote:
> Is there a reason pg_checksums is plural and not singular, i.e.,
> pg_checksum? I know it is being renamed for PG 12. It might have
> needed to be plural when it was pg_verify_checksums.
Because it applies to checksums to many
Hello.
At Mon, 29 Apr 2019 00:28:31 -0300, Avinash Kumar
wrote in
> Hi Team,
>
> Let us say we have a Master (M1) and a Slave (S1) in replication using
> Streaming Replication.
>
> I stopped all my writes from Application and i switched a WAL and made sure
> it is replicated to Slave.
> I
On Mon, May 06, 2019 at 11:24:31PM -0400, Tom Lane wrote:
> It's reasonable to doubt that this is the only problem the affected
> applications would have with such a server, too. I don't see a lot
> of point in "fixing" this code unless somebody actually tests that.
Okay, point taken. I'll go
On Wed, May 1, 2019 at 9:29 AM Amit Kapila wrote:
>
> On Wed, May 1, 2019 at 6:02 AM Robert Haas wrote:
> >
> > Replying to myself to resend to the list, since my previous attempt
> > seems to have been eaten by a grue.
> >
> > On Tue, Apr 30, 2019 at 11:14 AM Robert Haas wrote:
> > >
> > > On
On Tue, May 07, 2019 at 12:07:56PM +0900, Michael Paquier wrote:
> Now, what do we do about the potential deadlock issues in
> WaitForOlderSnapshots? The attached is an isolation test able to
> reproduce the deadlock within WaitForOlderSnapshots() with two
> parallel REINDEX CONCURRENTLY. I'd
Michael Paquier writes:
> On Mon, May 06, 2019 at 10:23:07PM -0400, Tom Lane wrote:
>> The originally-complained-of breakage exists in all active branches,
>> so is it really OK to commit this only in HEAD?
> I did not think that it would be that critical for back-branches, but
> I don't mind
Tomas Vondra writes:
> Do we actually check how many duplicates are there during planning?
Certainly that's part of the planner's cost estimates ... but it's
only as good as the planner's statistical knowledge.
regards, tom lane
On Mon, May 06, 2019 at 10:23:07PM -0400, Tom Lane wrote:
> The originally-complained-of breakage exists in all active branches,
> so is it really OK to commit this only in HEAD?
I did not think that it would be that critical for back-branches, but
I don't mind going ahead and remove the code
On Tue, May 07, 2019 at 01:48:40PM +1200, Thomas Munro wrote:
On Tue, May 7, 2019 at 9:58 AM Melanie Plageman
wrote:
On Fri, May 3, 2019 at 5:34 PM Tomas Vondra
wrote:
The second patch tries to enforce work_mem more strictly. That would be
impossible if we were to keep all the BufFile
On Mon, May 6, 2019 at 8:33 PM Tom Lane wrote:
>
> Andres Freund writes:
> > On 2019-05-05 18:55:30 +0530, Amit Kapila wrote:
> >> I understand that we have to take a call here shortly, but as there is
> >> a weekend so I would like to wait for another day to see if anyone
> >> else wants to
On Tue, May 7, 2019 at 2:45 PM Andres Freund wrote:
> I just hit this bad a couple times during some testing. Under load, with
> 2500 segments to recycle, it took well over a minute.
I wonder if this played a part in the wal_recycle=off-for-ZFS thing.
--
Thomas Munro
https://enterprisedb.com
On Sat, May 04, 2019 at 09:59:20PM +0900, Michael Paquier wrote:
> The result should be no deadlocks happening in the two sessions
> running the reindex. I can see the deadlock easily with three psql
> sessions, running manually the queries.
+* If the OID isn't valid, it means the index
On Mon, May 06, 2019 at 08:00:23PM -0700, Andres Freund wrote:
> Michael's email had a proposed patch. I think there's a few small
> changes needed, but otherwise it looks like the right direction to me.
I would not mind seeing this stuff fixed and back-patched.
--
Michael
signature.asc
Hi,
On 2019-05-06 22:54:43 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I think we ought to backpatch a version of this fix.
>
> Uh ... what fix are you talking about?
Michael's email had a proposed patch. I think there's a few small
changes needed, but otherwise it looks like the right
Andres Freund writes:
> I think we ought to backpatch a version of this fix.
Uh ... what fix are you talking about?
regards, tom lane
Hi,
I just hit this bad a couple times during some testing. Under load, with
2500 segments to recycle, it took well over a minute.
I think we ought to backpatch a version of this fix. Yes, there've not
been many complaints, but there's no messages during log levels one can
enable without beeing
On Tue, May 07, 2019 at 11:05:32AM +0900, Kyotaro HORIGUCHI wrote:
> Hi.
>
> At Sun, 28 Apr 2019 17:07:16 +0200, David Fetter wrote in
> <20190428150716.gp28...@fetter.org>
> > Our test coverage needs all the help it can get.
> >
> > This patch, extracted from another by Fabian Coelho, helps
Michael Paquier writes:
> On Mon, May 06, 2019 at 05:39:18PM +0200, Julien Rouhaud wrote:
>> I'm definitely done for today.
> Looks good to me, so committed.
The originally-complained-of breakage exists in all active branches,
so is it really OK to commit this only in HEAD?
Hi.
At Sun, 28 Apr 2019 17:07:16 +0200, David Fetter wrote in
<20190428150716.gp28...@fetter.org>
> Our test coverage needs all the help it can get.
>
> This patch, extracted from another by Fabian Coelho, helps move things
> in that direction.
>
> I'd like to argue that it's not a new
On Tue, May 07, 2019 at 10:16:54AM +0900, Kyotaro HORIGUCHI wrote:
> The fake symlinks need correction after the data directory and
> tablespsce directory are moved. Maybe needs to call
> CorrectSymlink() or something at startup... Or relative
> tablespaces should be rejected on Windows?
It took
On Tue, May 7, 2019 at 9:58 AM Melanie Plageman
wrote:
> On Fri, May 3, 2019 at 5:34 PM Tomas Vondra
> wrote:
>> The second patch tries to enforce work_mem more strictly. That would be
>> impossible if we were to keep all the BufFile structs in memory, so
>> instead it slices the batches into
At Sat, 27 Apr 2019 09:35:19 +0900, Michael Paquier wrote
in <20190427003519.gc2...@paquier.xyz>
> On Fri, Apr 26, 2019 at 11:21:48AM -0400, Tom Lane wrote:
> > I don't think feature freeze precludes adding new test cases.
>
> I think as well that adding this stuff into v12 would be fine. Now
Meskes-san
> This look very reasonable to me. I'm completely fine with this
> restriction being placed on PREPARE FROM.
Thank you. I start making a new patch.
Regards
Ryo Matsumura
Hello.
At Fri, 26 Apr 2019 12:25:10 -0700, Andres Freund wrote in
<20190426192510.dndtaxslneoh4...@alap3.anarazel.de>
> On 2019-04-26 17:29:56 +0900, Kyotaro HORIGUCHI wrote:
> > Win32 implement cannot have symbolic link feature as Linux-like
> > OSes for some restrictions. (Windows 7 and 10
On Mon, May 06, 2019 at 05:39:18PM +0200, Julien Rouhaud wrote:
> I'm definitely done for today.
Looks good to me, so committed.
--
Michael
signature.asc
Description: PGP signature
On Mon, May 6, 2019 at 5:15 PM Peter Geoghegan wrote:
> VACUUM asserts P_FIRSTDATAKEY(opaque) > PageGetMaxOffsetNumber(page)
> within _bt_mark_page_halfdead(), but doesn't test that condition in
> release builds. This means that the earliest modifications of the
> right page, before the high key
On Mon, May 6, 2019 at 4:11 PM Peter Geoghegan wrote:
> The important question is how VACUUM will recognize it. It's clearly
> not as bad as something that causes "failed to re-find parent key"
> errors, but I think that VACUUM might not be reclaiming it for the FSM
> (haven't checked). Note that
I suspect that if you build it, the will come, "they" being anyone who
has to schedule coverage, check usage of a resource over time, etc. Is
this something you want help with at some level? Coding, testing,
promoting...
You might be right. :-) Most of this is done already, since it was
On Mon, May 6, 2019 at 3:29 PM Tom Lane wrote:
> Yeah, as _bt_split is currently coded, _bt_truncate has to be a "no
> errors" function, which it isn't. The pfree for its result is being
> done in an ill-chosen place, too.
I am tempted to move the call to _bt_truncate() out of _bt_split()
Peter Geoghegan writes:
> Commit 8fa30f906be reduced the elevel of a number of "can't happen"
> errors from PANIC to ERROR. These were all critical-section-adjacent
> errors involved in nbtree page splits, and nbtree page deletion. It
> also established the following convention within
On Mon, May 06, 2019 at 11:19:27AM -0700, Paul Jungwirth wrote:
> On 5/3/19 6:41 PM, David Fetter wrote:
> > This suggests two different ways to extend ranges over aggregation:
> > one which is a union of (in general) disjoint intervals, two others
> > are a union of intervals, each of which has a
On Fri, May 3, 2019 at 5:34 PM Tomas Vondra
wrote:
>
> The second patch tries to enforce work_mem more strictly. That would be
> impossible if we were to keep all the BufFile structs in memory, so
> instead it slices the batches into chunks that fit into work_mem, and
> then uses a single
On Mon, May 6, 2019 at 12:48 PM Peter Geoghegan wrote:
> On the other other hand, it seems to me that the PageGetTempPage()
> thing might have been okay, because it happens before the high key is
> inserted on the new right buffer page. The same cannot be said for the
> way we generate a new high
On Mon, May 6, 2019 at 7:14 AM Andres Freund wrote:
>
> Hi,
>
> On May 6, 2019 3:40:55 AM PDT, Rafia Sabih wrote:
> >I was trying the toyam patch and on make check it failed with
> >segmentation fault at
> >
> >static void
> >toyam_relation_set_new_filenode(Relation rel,
> > char persistence,
>
On Mon, May 6, 2019 at 2:21 PM Alvaro Herrera wrote:
> On 2019-May-06, Robert Haas wrote:
> > On Thu, May 2, 2019 at 12:18 PM Antonin Houska wrote:
> > > The next version of the patch is attached.
> >
> > I don't think any of this looks acceptable:
>
> I agree. I inteded to suggest upthread to
Commit 8fa30f906be reduced the elevel of a number of "can't happen"
errors from PANIC to ERROR. These were all critical-section-adjacent
errors involved in nbtree page splits, and nbtree page deletion. It
also established the following convention within _bt_split(), which
allowed Tom to keep the
On 2019-May-06, Robert Haas wrote:
> On Thu, May 2, 2019 at 12:18 PM Antonin Houska wrote:
> > The next version of the patch is attached.
>
> I don't think any of this looks acceptable:
I agree. I inteded to suggest upthread to pass an additional argument
to XLogRead, which is a function that
On 5/3/19 6:41 PM, David Fetter wrote:
This suggests two different ways to extend ranges over aggregation:
one which is a union of (in general) disjoint intervals, two others
are a union of intervals, each of which has a weight.
. . .
I think the cases above, or at least the first two of them,
On 5/4/19 3:11 PM, Corey Huinker wrote:
One question is how to aggregate ranges that would leave gaps and/or
overlaps. So in my extension there is a one-param version that forbids
gaps & overlaps, but I let you permit them by passing extra parameters,
so the signature is:
On Mon, May 6, 2019 at 1:58 PM Tom Lane wrote:
> Robert Haas writes:
> > Right. That's why I favor applying the change to move DSM cleanup to
> > the end for now, and seeing how that goes. It could be that we'll
> > eventually discover that doing it before all of the AtEOXact_BLAH
> >
On Thu, May 2, 2019 at 12:18 PM Antonin Houska wrote:
> The next version of the patch is attached.
I don't think any of this looks acceptable:
+#ifndef FRONTEND
+/*
+ * Backend should have wal_segment_size variable initialized, segsize is not
+ * used.
+ */
+#define XLogFileNameCommon(tli, num,
Robert Haas writes:
> Right. That's why I favor applying the change to move DSM cleanup to
> the end for now, and seeing how that goes. It could be that we'll
> eventually discover that doing it before all of the AtEOXact_BLAH
> functions have had a short at doing their thing is still too
Is there a reason pg_checksums is plural and not singular, i.e.,
pg_checksum? I know it is being renamed for PG 12. It might have
needed to be plural when it was pg_verify_checksums.
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Mon, May 6, 2019 at 12:26 PM Andres Freund wrote:
> I'm not convinced by that. I've certainly many a time wrote queries
> against pg_class to figure out which relation a toast table belongs
> to. E.g. after looking at the largest relations in the system, looking
> at pg_stat_*_tables, after
On Mon, May 6, 2019 at 12:18 PM Andres Freund wrote:
> > None of that addresses the question of the distributed cost of sending
> > more sinval messages. If you have a million little tiny relations and
> > VACUUM goes through and clears one tuple out of each one, it will be
> > spewing sinval
On Mon, May 6, 2019 at 1:32 PM Tom Lane wrote:
> Robert Haas writes:
> > I have a thought about this. It seems to me that when it comes to
> > backend-private memory, we release it even later: aborting the
> > transaction does nothing, and we do it only later when we clean up the
> >
Robert Haas writes:
> I have a thought about this. It seems to me that when it comes to
> backend-private memory, we release it even later: aborting the
> transaction does nothing, and we do it only later when we clean up the
> transaction. So I wonder whether we're going to find that we
On 5/5/19 12:24 AM, Thomas Munro wrote:
> On Sun, May 5, 2019 at 2:35 PM Jonathan S. Katz wrote:
>> On 5/3/19 6:29 PM, Tom Lane wrote:
>>> See
>>>
>>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8b3bce2017b15e05f000c3c5947653a3e2c5a29f
>>>
>>> Please send any corrections by
On 2019-May-06, Justin Pryzby wrote:
> Perhaps ... but TOAST is an implementation detail, and I think it should
> rarely
> be important to know the toast table for a given table.
I'm with Andres -- while it's admittedly a rare need, it is a real one.
Sometimes I wish for \d++ which would
Hi,
On 2019-05-06 11:58:18 -0400, Tom Lane wrote:
> Not sure though --- generally, if you're looking at a specific
> toast table, you already know which table is its parent. But
> maybe confirmation is a good thing.
I'm not convinced by that. I've certainly many a time wrote queries
against
On Mon, May 06, 2019 at 09:13:52AM +0200, Rafia Sabih wrote:
> On Fri, 3 May 2019 at 16:27, Justin Pryzby wrote:
> >
> > On Fri, May 03, 2019 at 02:55:47PM +0200, Rafia Sabih wrote:
> > > On Mon, 22 Apr 2019 at 17:49, Justin Pryzby wrote:
> > > >
> > > > It's deliberate that \dt doesn't show
Hi,
On 2019-05-06 11:52:12 -0400, Robert Haas wrote:
> On Mon, May 6, 2019 at 11:27 AM Andres Freund wrote:
> > > I think it's legitimate to question whether sending additional
> > > invalidation messages as part of the design of this feature is a good
> > > idea. If it happens frequently, it
On Mon, May 6, 2019 at 12:05 PM Tom Lane wrote:
> Robert Haas writes:
> > ... I guess you could incur the overhead repeatedly if the relation starts
> > out at 1 block, grows to 4, is vacuumed back down to 1, lather, rinse,
> > repeat, but is that actually realistic?
>
> While I've not studied
On Thu, May 2, 2019 at 10:15 AM Tom Lane wrote:
> Thomas Munro writes:
> > A while back I posted a patch[1] to change the order of resowner
> > cleanup so that DSM handles are released last. That's useful for the
> > error cleanup path on Windows, when a SharedFileSet is cleaned up (a
> >
On 2019-May-06, Rushabh Lathia wrote:
> Found another scenario where check constraint is not getting
> dump for the child table.
You're right, the patched code is bogus; I'm reverting it all for
today's minors. Thanks for reporting.
--
Álvaro Herrera
Robert Haas writes:
> ... I guess you could incur the overhead repeatedly if the relation starts
> out at 1 block, grows to 4, is vacuumed back down to 1, lather, rinse,
> repeat, but is that actually realistic?
While I've not studied the patch, I assumed that once a relation has an
FSM it won't
Rafia Sabih writes:
> On Fri, 3 May 2019 at 16:27, Justin Pryzby wrote:
>> Thanks - what about also showing the associated non-toast table ?
> IMHO, what makes more sense is to show the name of associated toast
> table in the \dt+ of the normal table.
I'm not for that: it's useless information
On Mon, May 6, 2019 at 11:27 AM Andres Freund wrote:
> > I think it's legitimate to question whether sending additional
> > invalidation messages as part of the design of this feature is a good
> > idea. If it happens frequently, it could trigger expensive sinval
> > resets more often. I don't
On Mon, May 6, 2019 at 5:34 PM Tom Lane wrote:
>
> Julien Rouhaud writes:
> > WFM. Updated patch attached, I also removed another similar chunk in
> > the same file while at it.
>
> Uh, that looks backwards:
Argh, sorry :(
I'm definitely done for today.
fix_appendQualifiedRelation-v4.diff
Julien Rouhaud writes:
> WFM. Updated patch attached, I also removed another similar chunk in
> the same file while at it.
Uh, that looks backwards:
@@ -146,10 +146,6 @@ connectDatabase(const char *dbname, const char *pghost,
exit(1);
}
- if
On Mon, May 6, 2019 at 3:49 PM Tom Lane wrote:
>
> Michael Paquier writes:
> > On Mon, May 06, 2019 at 08:32:44AM -0400, Andrew Dunstan wrote:
> >> Why do we even have code referring to pre-7.3 servers? Wouldn't it be
> >> simpler just to remove that code?
>
> > Even for pg_dump, we only support
On Mon, May 6, 2019 at 8:13 AM Dilip Kumar wrote:
> > In general, I find the code for updating transaction headers to be
> > really hard to understand. I'm not sure exactly what can be done
> > about that. Like, why is UndoRecordPrepareTransInfo unpacking undo?
>
> It's only unpacking header.
Hi,
On 2019-05-06 11:10:15 -0400, Robert Haas wrote:
> I'm really surprised that the original design of this patch involved
> storing state in global variables. That seems like a pretty poor
> decision. This is properly per-relation information, and any approach
> like that isn't going to work
On Sun, May 5, 2019 at 9:25 AM Amit Kapila wrote:
> I understand that we have to take a call here shortly, but as there is
> a weekend so I would like to wait for another day to see if anyone
> else wants to share his opinion.
I haven't looked deeply into the issues with this patch, but it seems
Andres Freund writes:
> On 2019-05-05 18:55:30 +0530, Amit Kapila wrote:
>> I understand that we have to take a call here shortly, but as there is
>> a weekend so I would like to wait for another day to see if anyone
>> else wants to share his opinion.
> I still think that's the right course.
Robert Haas wrote:
> On Thu, Apr 25, 2019 at 12:36 PM Oleksii Kliukin wrote:
>> - Fallbacks to autovacuum parameters in another scope. Right now in the
>> absence of the per-table and per-tablespace autovacuum parameters the code
>> uses the ones from the global scope. However, if only some of
Hi,
On 2019-05-05 18:55:30 +0530, Amit Kapila wrote:
> On Sat, May 4, 2019 at 2:55 PM Amit Kapila wrote:
> > On Fri, May 3, 2019 at 2:14 PM Amit Kapila wrote:
> > I am fine going with option (a), that's why I have prepared a revert
> > patch, but I have a slight fear that the other option might
Hi,
On May 6, 2019 3:40:55 AM PDT, Rafia Sabih wrote:
>On Tue, 9 Apr 2019 at 15:17, Heikki Linnakangas
>wrote:
>>
>> On 08/04/2019 20:37, Andres Freund wrote:
>> > On 2019-04-08 15:34:46 +0300, Heikki Linnakangas wrote:
>> >> There's a little bug in index-only scan executor node, where it
Michael Paquier writes:
> On Mon, May 06, 2019 at 08:32:44AM -0400, Andrew Dunstan wrote:
>> Why do we even have code referring to pre-7.3 servers? Wouldn't it be
>> simpler just to remove that code?
> Even for pg_dump, we only support servers down to 8.0. Let's nuke
> this code.
+1. I think
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Mon, May 06, 2019 at 08:32:44AM -0400, Andrew Dunstan wrote:
> > Why do we even have code referring to pre-7.3 servers? Wouldn't it be
> > simpler just to remove that code?
>
> Even for pg_dump, we only support servers down to 8.0.
Hi Matsumura-san,
> I defined the following specifications. Please review it.
>
> * ECPG can accept any valid PREPARE AS statement.
> * A char-type host variable can be used as the statement name of
> PREPARE AS,
> but its value is constrained by the specification of PREPARE AS.
> (e.g. the
On Mon, May 06, 2019 at 08:32:44AM -0400, Andrew Dunstan wrote:
> Why do we even have code referring to pre-7.3 servers? Wouldn't it be
> simpler just to remove that code?
Even for pg_dump, we only support servers down to 8.0. Let's nuke
this code.
--
Michael
signature.asc
Description: PGP
On 5/6/19 4:17 AM, Julien Rouhaud wrote:
> On Mon, May 6, 2019 at 10:04 AM Julien Rouhaud wrote:
>> Hi,
>>
>> It seems that 582edc369cd caused $subject.
>>
>> Trivial fix attached, though I obviously didn't actually test it
>> against such server.
> Ahem, correct fix attached. I'm going to get
On Mon, May 6, 2019 at 4:41 PM Thomas Munro wrote:
>
> On Mon, May 6, 2019 at 9:26 PM Amit Kapila wrote:
>
> > If so, I am getting it both before and after your patch.
>
> Huh. I thought the only problem here was the phenomenon demonstrated
> by [1]. I'm a bit stumped... if we've closed all
On Mon, May 6, 2019 at 9:26 PM Amit Kapila wrote:
> On Mon, May 6, 2019 at 3:43 AM Thomas Munro wrote:
> > Here's a way to produce an error which might produce the log message
> > on Windows. Does anyone want to try it?
>
> I can give it a try.
Thanks!
> > If it does produce the log message,
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-05-03 23:08:44 -0400, Stephen Frost wrote:
> > As mentioned though, it's likely to be a
> > quite rare thing to run into, so you'd have to be extra unlucky to even
> > hit this case and perhaps the extra code complication just isn't
On Tue, 9 Apr 2019 at 15:17, Heikki Linnakangas wrote:
>
> On 08/04/2019 20:37, Andres Freund wrote:
> > On 2019-04-08 15:34:46 +0300, Heikki Linnakangas wrote:
> >> There's a little bug in index-only scan executor node, where it mixes up
> >> the
> >> slots to hold a tuple from the index, and
On Mon, May 6, 2019 at 3:43 AM Thomas Munro wrote:
>
> On Fri, May 3, 2019 at 2:15 AM Tom Lane wrote:
> > Thomas Munro writes:
> > > A while back I posted a patch[1] to change the order of resowner
> > > cleanup so that DSM handles are released last. That's useful for the
> > > error cleanup
Found another scenario where check constraint is not getting
dump for the child table.
Testcase:
create table test ( c1 serial, c2 int not null, c3 integer CHECK (c3 > 0))
partition by list (c2);
create table test_p1 partition of test for values in ( 1);
create table test_p2 partition of test
On Mon, May 6, 2019 at 10:04 AM Julien Rouhaud wrote:
>
> Hi,
>
> It seems that 582edc369cd caused $subject.
>
> Trivial fix attached, though I obviously didn't actually test it
> against such server.
Ahem, correct fix attached. I'm going to get a coffee and hide for
the rest of the day.
Hi,
It seems that 582edc369cd caused $subject.
Trivial fix attached, though I obviously didn't actually test it
against such server.
fix_appendQualifiedRelation-v1.diff
Description: Binary data
On Fri, 3 May 2019 at 16:27, Justin Pryzby wrote:
>
> On Fri, May 03, 2019 at 02:55:47PM +0200, Rafia Sabih wrote:
> > On Mon, 22 Apr 2019 at 17:49, Justin Pryzby wrote:
> > >
> > > It's deliberate that \dt doesn't show toast tables.
> > > \d shows them, but doesn't show their indices.
> > >
> >
On 2019-05-06 00:00:04 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On May 5, 2019 8:56:58 PM PDT, Tom Lane wrote:
> >> On this coast, "tonight" is running into "tomorrow" ... you planning
> >> to do that soon?
>
> > I'd planned to finish cooking and eating, and then doing it. Seems like
Hi,
On 2019-05-03 23:08:44 -0400, Stephen Frost wrote:
> This makes me think we should both order it and combine it into one
> message... but that'd then be pretty difficult to deal with,
> potentially, from a translation standpoint and just from a "wow, that's
> a huge log message", which is
89 matches
Mail list logo
