On Wed, Jul 18, 2018 at 12:15:25PM +0530, Ashutosh Bapat wrote:
> On Wed, Jul 18, 2018 at 11:52 AM, Michael Paquier wrote:
>> On Wed, Jul 18, 2018 at 02:35:23PM +0900, Masahiko Sawada wrote:
>>> Hi,
>>>
>>> While debugging planner I realized that print_path() function is not
>>> aware of both Gath
On Wed, Jul 18, 2018 at 11:52 AM, Michael Paquier wrote:
> On Wed, Jul 18, 2018 at 02:35:23PM +0900, Masahiko Sawada wrote:
>> Hi,
>>
>> While debugging planner I realized that print_path() function is not
>> aware of both GatherMerge path and CustomScan path. Attached small
>> patch fixes it.
>
>
On Wed, Jul 18, 2018 at 06:09:57AM +, Tsunakawa, Takayuki wrote:
> From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
>> I reviewed patch and it works as per the subject, but I am not able to verify
>> the actual
>> bug that is reported in the upthread. The moving of setErrorMode() call
>>
On Wed, Jul 18, 2018 at 02:35:23PM +0900, Masahiko Sawada wrote:
> Hi,
>
> While debugging planner I realized that print_path() function is not
> aware of both GatherMerge path and CustomScan path. Attached small
> patch fixes it.
Good catch. Those should be backpatched. While I am looking at t
From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
> I reviewed patch and it works as per the subject, but I am not able to verify
> the actual
> bug that is reported in the upthread. The moving of setErrorMode() call
> to the start
> of the main function can handle all the cases that can lead
On Wed, Jul 18, 2018 at 5:41 PM, Andrey Borodin wrote:
>> I think we'd want pg_upgrade tests showing an example of each SLRU
>> growing past one segment, and then being upgraded, and then being
>> accessed in various different pages and segment files, so that we can
>> see that we're able to shift
On 17 July 2018 at 23:10, Tom Lane wrote:
> Peter Geoghegan writes:
>> I've done plenty of research into the history of this hack. It was
>> your work, but it does actually make sense in the context of today's
>> nbtree code. It is essential with scankey-wise duplicates, since
>> groveling throug
Hi, Tomas!
>
> I think we'd want pg_upgrade tests showing an example of each SLRU
> growing past one segment, and then being upgraded, and then being
> accessed in various different pages and segment files, so that we can
> see that we're able to shift the data to the right place successfully.
>
Hi,
While debugging planner I realized that print_path() function is not
aware of both GatherMerge path and CustomScan path. Attached small
patch fixes it.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
fix_print_path.patch
Description: B
Hi, Tomas!
> 15 июля 2018 г., в 1:20, Tomas Vondra
> написал(а):
>
> So I doubt it's this, but I've tweaked the scripts to also set this GUC
> and restarted the tests on both machines. Let's see what that does.
Do you observe any different results?
Thanks!
Best regards, Andrey Borodin.
Hi all,
While looking at the source code for more consistency work with error
messages, I have bumped into a couple of messages which could be
simplified, as those include in the name of the file manipulated
basically the same information as the context added.
I have finished with the attached.
On Tue, Jul 17, 2018 at 08:34:17AM -0400, Fabien COELHO wrote:
>
> Hello David,
>
> A few comments about this v2.
>
> ISTM that there is quite strong opposition to having "warn" as a default, so
> probably you should set if "off"?
Done.
> >>I do not really understand the sort order of this arr
At Wed, 18 Jul 2018 11:12:06 +0800, Craig Ringer wrote
in
> On 26 February 2018 at 12:06, Tsunakawa, Takayuki <
> tsunakawa.ta...@jp.fujitsu.com> wrote:
>
> > From: Craig Ringer [mailto:cr...@2ndquadrant.com]
> > > The patch proposed here means that early crashes will invoke WER. If
> > we're
>
On 17 July 2018 at 03:29, Robert Haas wrote:
> On Mon, Jul 16, 2018 at 2:36 AM, Amit Khandekar
> wrote:
>> 0001 patch contains the main fix. In this patch I have used some
>> naming conventions and some comments that you used in your patch,
>> plus, I used your method of lazily allocating new st
On Tue, Jul 17, 2018 at 06:03:26PM +0900, Michael Paquier wrote:
> On Tue, Jul 17, 2018 at 02:55:07PM +0700, John Naylor wrote:
>> I didn't dig deeper, since TOAST and the large object facility are
>> mutually exclusive so there shouldn't be a toast table here anyway.
>> Hope this helps.
>
> [...
Hello. I confirmed that this patch fixes the crash.
At Tue, 17 Jul 2018 20:01:05 -0400, Tom Lane wrote in
<14892.1531872...@sss.pgh.pa.us>
> I wrote:
> >> So I said I didn't want to do extra work on this, but I am looking into
> >> fixing it by having these aux process types run a ResourceOwner
On 26 February 2018 at 12:06, Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Craig Ringer [mailto:cr...@2ndquadrant.com]
> > The patch proposed here means that early crashes will invoke WER. If
> we're
> > going to allow WER we should probably just do so unconditionally.
> >
On Tue, Jul 17, 2018 at 5:45 PM, Robert Haas wrote:
> Yes, that's a good point. Also, and I think pretty importantly, this
> seems essential if we want to allow retail index tuple deletion, which
> has its own set of advantages.
Retail index tuple deletion is clearly something we should have in
On Tue, Jul 17, 2018 at 02:28:14PM +0100, Dean Rasheed wrote:
> From what I understand from here [1], some parts of OpenSSL call
> RAND_poll() once on initialisation, and that's enough to get the PRNG
> going. It's not obvious that calling it multiple times would have any
> benefit.
>
> They also
On Sat, Jul 14, 2018 at 5:34 AM, Heikki Linnakangas wrote:
> On 18/04/18 09:55, Thomas Munro wrote:
>> Here's a draft patch that does that. One contentious question is:
>> should you have to opt *in* to auto-exit-on-postmaster death? Andres
>> opined that you should. I actually think it's not s
On Tue, Jul 17, 2018 at 01:31:01PM -0400, Robert Haas wrote:
> On Tue, Jul 17, 2018 at 1:27 PM, Alvaro Herrera
> wrote:
>> On 2018-Jul-17, Robert Haas wrote:
>>> On Tue, Jul 17, 2018 at 8:33 AM, Dean Rasheed
>>> wrote:
if (RAND_status() == 0)
RAND_poll();
>>>
>>> Looks like a reci
Robert Haas writes:
> On Tue, Jul 17, 2018 at 8:55 PM, Tom Lane wrote:
>> Uh, what? There are only a few callers of those, and they'd all have
>> crashed already if they were somehow dealing with an invalid buffer.
> Sorry, I meant Assert(owner != NULL).
Oh, gotcha: so that if an external deve
On Tue, Jul 17, 2018 at 3:12 PM, Peter Eisentraut
wrote:
> The actual implementation could use another round of consideration. I
> wonder how this should interact with min_wal_size. Wouldn't
> min_wal_size = 0 already do what we need (if you could set it to 0,
> which is currently not possible)?
On Tue, Jul 17, 2018 at 8:55 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jul 17, 2018 at 8:01 PM, Tom Lane wrote:
>>> Any objections? Anyone want to do further review?
>
>> LGTM. I think this is an improvement. However, it seems like it
>> might be a good idea for ResourceOwnerRememb
Robert Haas writes:
> On Tue, Jul 17, 2018 at 8:01 PM, Tom Lane wrote:
>> Any objections? Anyone want to do further review?
> LGTM. I think this is an improvement. However, it seems like it
> might be a good idea for ResourceOwnerRememberBuffer and
> ResourceOwnerForgetBuffer to Assert(buffer
On Tue, Jul 17, 2018 at 8:01 PM, Tom Lane wrote:
> Any objections? Anyone want to do further review?
LGTM. I think this is an improvement. However, it seems like it
might be a good idea for ResourceOwnerRememberBuffer and
ResourceOwnerForgetBuffer to Assert(buffer != NULL), so that if
somebody
On Tue, Jul 17, 2018 at 5:16 PM, Peter Geoghegan wrote:
> There is actually a flipside to that downside, though (i.e. the
> downside is also an upside): While not filling up leaf pages that have
> free space on them is bad, it's only bad when it doesn't leave the
> pages completely empty. Leaving
On Tue, Jul 17, 2018 at 03:02:32PM -0400, Tom Lane wrote:
> Cute idea, but it seems not to work with older versions of prove:
>
> $ which prove
> /usr/local/perl5.8.3/bin/prove
> $ prove --state=save
> Unknown option: s
I didn't know this one, and that's actually nice, but I cannot get
easily a w
I wrote:
>> So I said I didn't want to do extra work on this, but I am looking into
>> fixing it by having these aux process types run a ResourceOwner that can
>> be told to clean up any open buffer pins at exit.
> That turned out to be a larger can of worms than I'd anticipated, as it
> soon emer
On 07/18/2018 12:41 AM, Konstantin Knizhnik wrote:
> ...
>
> Teodor Sigaev has proposed an alternative approach for calculating
> selectivity of multicolumn join or compound index search.
> Usually DBA creates compound indexes which can be used by optimizer to
> build efficient query execution
On Tue, Jul 17, 2018 at 3:10 PM, Tom Lane wrote:
> Well, the actual problem was O(N^2) behavior:
>
> https://www.postgresql.org/message-id/2378.967216388%40sss.pgh.pa.us
>
> https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=40549e9cb5abd2986603883e4ab567dab34723c6
Oh, yeah. We st
On Mon, Jul 16, 2018 at 04:04:12PM -0400, Alvaro Herrera wrote:
> No objection here -- incremental progress is better than none.
Thanks. I have pushed 0001 now. I have found some more work which
could be done, for which I'll spawn a new thread.
--
Michael
signature.asc
Description: PGP signatu
Hello Heikki,
[...] Let's keep it that way. I think the only change we need to make in
the logic is to check at the end, if *any* progress reports at all have
been printed, and print one if not.
Ok, this simplifies the condition.
And do that only when the -P option is smaller than the -T op
On 16.07.2018 23:55, Tomas Vondra wrote:
On 07/16/2018 02:54 PM, Dean Rasheed wrote:
On 16 July 2018 at 13:23, Tomas Vondra wrote:
The top-level clauses allow us to make such deductions, with deeper
clauses it's much more difficult (perhaps impossible). Because for
example with (a=1 AND b=
Peter Geoghegan writes:
> I've done plenty of research into the history of this hack. It was
> your work, but it does actually make sense in the context of today's
> nbtree code. It is essential with scankey-wise duplicates, since
> groveling through hundreds or even thousands of pages full of
> d
On 17 July 2018 at 19:47, Robert Haas wrote:
> On Mon, Jul 9, 2018 at 6:00 AM, Simon Riggs wrote:
>> Proposal would be to add a new lock mode "ShareUpdate", which does not
>> conflict with itself and yet conflicts with "ShareUpdateExclusive" or
>> higher. (Hence, it is a strong lock type). DDL wo
On Tue, Jul 17, 2018 at 1:29 PM, Tom Lane wrote:
> Yeah ... if memory serves, there were specific usage patterns where
> that hack made things way better than they'd been before. (I do not
> recall if the hack itself was mine, but I think I can be blamed for
> the "getting tired" comment ...) I'
On Tue, Jul 17, 2018 at 1:12 PM, Robert Haas wrote:
> This seems like really interesting and important work. I wouldn't
> have foreseen that the "getting tired" code would have led to this
> kind of bloat (even if I had known about it at all).
Thanks!
I'm glad that I can come up with concrete,
On 07/17/2018 09:12 PM, Peter Eisentraut wrote:
> On 17.07.18 00:04, Jerry Jelinek wrote:
>> There have been quite a few comments since last week, so at this point I
>> am uncertain how to proceed with this change. I don't think I saw
>> anything concrete in the recent emails that I can act upon.
>
Robert Haas writes:
> On Sun, Jul 8, 2018 at 7:59 PM, Peter Geoghegan wrote:
>> The whole "getting tired" thing is the root of the problem here, which
>> is why the pending v3 of my patch will remove that code completely
>> (_bt_findinsertloc() is streamlined).
> This seems like really interesti
On Sun, Jul 8, 2018 at 7:59 PM, Peter Geoghegan wrote:
> The whole "getting tired" thing is the root of the problem here, which
> is why the pending v3 of my patch will remove that code completely
> (_bt_findinsertloc() is streamlined).
Peter,
This seems like really interesting and important wor
On 17.07.18 00:04, Jerry Jelinek wrote:
> There have been quite a few comments since last week, so at this point I
> am uncertain how to proceed with this change. I don't think I saw
> anything concrete in the recent emails that I can act upon.
The outcome of this could be multiple orthogonal patc
Peter Eisentraut writes:
> How about something like this:
> -PG_PROVE_FLAGS = -I $(top_srcdir)/src/test/perl/ -I $(srcdir)
> +PG_PROVE_FLAGS = -I $(top_srcdir)/src/test/perl/ -I $(srcdir) --state=save
Cute idea, but it seems not to work with older versions of prove:
$ which prove
/usr/local/per
On 17.07.18 07:20, Craig Ringer wrote:
> A user has raised the point that our refusal to GRANT rights to
> untrusted PLs is counterproductive and inconsistent with how we behave
> elsewhere.
Previous discussion:
https://www.postgresql.org/message-id/flat/1357905627.24219.6.camel%40vanquo.pezone.ne
On Mon, Jul 9, 2018 at 6:00 AM, Simon Riggs wrote:
> Proposal would be to add a new lock mode "ShareUpdate", which does not
> conflict with itself and yet conflicts with "ShareUpdateExclusive" or
> higher. (Hence, it is a strong lock type). DDL would take a
> ShareUpdateLock on the table, then dur
On 16.07.18 19:13, Tom Lane wrote:
> But a TAP test failure leaves nothing behind that git will consider
> unusual. I've repeatedly had to run check-world with no parallelism
> (wasting many minutes) in order to locate which test actually failed.
How about something like this:
diff --git a/src/M
Hi!
> 16 июля 2018 г., в 21:24, Andrey Borodin написал(а):
>
I was checking WAL replay of new scheme to log page deletes and found a bug
there (incorrect value of deleted downlink in WAL record). Here's fixed patch
v10.
Also I've added support to WAL identification for new record, done some
On Mon, Jul 16, 2018 at 3:25 PM, Tomas Vondra
wrote:
> Oh, right, I forgot the patch also adds the leader into the group, for
> some reason (I agree it's unclear why that would be necessary, as you
> pointed out later).
>
> But all this is happening while holding the partition lock (in exclusive
>
> On 17 Jul 2018, at 19:11, Andrew Dunstan
> wrote:
>
> On 07/17/2018 12:04 PM, Daniel Gustafsson wrote:
>> Since DEBUG is not a defined loglevel, it seems superfluous to include it
>> here.
>> It’s also omitted from the documentation so it should probably be omitted
>> from
>> here.
>>
>> +
On 2018-Jul-16, David Rowley wrote:
> On 16 July 2018 at 12:55, David Rowley wrote:
> > Thinking about this some more, I don't quite see any reason that the
> > partitioned_rels for a single hierarchy couldn't just be a Bitmapset
> > instead of an IntList.
>
> Of course, this is not possible sin
On Tue, Jul 17, 2018 at 1:27 PM, Alvaro Herrera
wrote:
> On 2018-Jul-17, Robert Haas wrote:
>
>> On Tue, Jul 17, 2018 at 8:33 AM, Dean Rasheed
>> wrote:
>> > if (RAND_status() == 0)
>> > RAND_poll();
>>
>> Looks like a recipe for an infinite loop. At least, I think we ought
>> to have a CHE
On Fri, Apr 6, 2018 at 4:25 PM, Claudio Freire wrote:
>> True all that. My point is that the multi-segmented array isn't all that
>> simple and proven, compared to an also straightforward B-tree. It's pretty
>> similar to a B-tree, actually, except that it has exactly two levels, and
>> the node (
On 2018-Jul-17, Robert Haas wrote:
> On Tue, Jul 17, 2018 at 8:33 AM, Dean Rasheed
> wrote:
> > if (RAND_status() == 0)
> > RAND_poll();
>
> Looks like a recipe for an infinite loop. At least, I think we ought
> to have a CHECK_FOR_INTERRUPTS() in that loop.
What loop?
--
Álvaro Herrera
On 01/03/18 05:35, Peter Eisentraut wrote:
The SQL standard offers the "chained transactions" feature to address
this. The new command variants COMMIT AND CHAIN and ROLLBACK AND CHAIN
immediately start a new transaction with the characteristics (isolation
level, read/write, deferrable) of the pr
On Tue, Jul 17, 2018 at 8:33 AM, Dean Rasheed wrote:
> if (RAND_status() == 0)
> RAND_poll();
Looks like a recipe for an infinite loop. At least, I think we ought
to have a CHECK_FOR_INTERRUPTS() in that loop.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreS
On 07/17/2018 12:04 PM, Daniel Gustafsson wrote:
On 4 Jul 2018, at 15:34, Andrew Dunstan wrote:
On Wed, Jun 20, 2018 at 2:06 PM, Daniel Gustafsson wrote:
On 27 Apr 2018, at 04:24, Andres Freund wrote:
On 2018-04-27 11:52:18 +0930, Tom Dunstan wrote:
I'd argue this should contain the non
> On 4 Jul 2018, at 15:34, Andrew Dunstan
> wrote:
>
> On Wed, Jun 20, 2018 at 2:06 PM, Daniel Gustafsson wrote:
>>> On 27 Apr 2018, at 04:24, Andres Freund wrote:
>>>
>>> On 2018-04-27 11:52:18 +0930, Tom Dunstan wrote:
> I'd argue this should contain the non-error cases. It's just as
>>
On 2018-Jul-17, Grigory Smolkin wrote:
> Hello, hackers!
>
> Recently I was investigating the case of 'stuck in wraparaound' problem.
> PostgreSQL instance(9.6.9) in question reached 'million-before-wraparound'
> threshold and switched to read-only mode.
> Running vacuum in single-mode gives not
Hello, hackers!
Recently I was investigating the case of 'stuck in wraparaound' problem.
PostgreSQL instance(9.6.9) in question reached
'million-before-wraparound' threshold and switched to read-only mode.
Running vacuum in single-mode gives not results, datfrozenxid was not
advancing:
backen
On 27/06/18 21:57, Daniel Gustafsson wrote:
On 27 Jun 2018, at 14:32, Daniel Gustafsson wrote:
Attached is an updated patch for supporting the native macOS Secure Transport
library, rebased on top of current master.
Courtesy of the ever-present Murphy I managed to forget some testcode in
sr
On 17 July 2018 at 14:04, Michael Paquier wrote:
> On Tue, Jul 17, 2018 at 01:33:11PM +0100, Dean Rasheed wrote:
>> Looking for precedents elsewhere, I found [2] which does exactly that,
>> although I'm slightly dubious about the need for the for-loop there. I
>> also found a thread [3], which rec
On Thu, Mar 1, 2018 at 4:14 PM Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Tsunakawa, Takayuki [mailto:tsunakawa.ta...@jp.fujitsu.com]
> > Another idea to add to the current patch is to move the call to
> SetErrorMode()
> > to the below function, which is called first in m
On Tue, Jul 17, 2018 at 01:33:11PM +0100, Dean Rasheed wrote:
> Looking for precedents elsewhere, I found [2] which does exactly that,
> although I'm slightly dubious about the need for the for-loop there. I
> also found a thread [3], which recommends simply doing
>
> if (RAND_status() == 0)
>
On 07/17/2018 11:09 AM, Dean Rasheed wrote:
On 16 July 2018 at 21:55, Tomas Vondra wrote:
...
>>
So, how would the proposed algorithm work? Let's start with "a=1":
sel(a=1) = 0.1508
I don't see much point in applying the two "b" clauses independently (or
how would it be done, as it's e
On Mon, Jul 16, 2018 at 11:35 PM Andres Freund wrote:
> On 2018-07-04 20:11:21 +1000, Haribabu Kommi wrote:
> > On Tue, Jul 3, 2018 at 5:06 PM Andres Freund wrote:
>
> > > The most fundamental issues I had with Haribabu's last version from [2]
> > > are the following:
> > >
> > > - The use of Ta
> Понедельник, 16 июля 2018, 22:19 +03:00 от Andrey Borodin
> :
>
>Hi!
>
>> 16 июля 2018 г., в 22:58, Andrey Klychkov < aaklych...@mail.ru > написал(а):
>> Dear hackers!
>>
>> I have an idea to facilitate work with index rebuilding.
>>
>> "ALTER INDEX ... RENAME CONCURRENTLY TO ..."
>
>The i
Hello David,
A few comments about this v2.
ISTM that there is quite strong opposition to having "warn" as a default,
so probably you should set if "off"?
transform_null_equals_options[] = { [...]
I do not really understand the sort order of this array. Maybe it could be
alphabetical, or
Last week I upgraded 15 servers from various pre-10 versions to 10.4.
At first everything looked OK, but then (around 4 days later) one of
them failed with this in the logs:
2018-07-14 01:53:35.840 BST LOG: could not generate random cancel key
2018-07-14 01:53:37.233 BST LOG: could not generat
On 07/16/2018 08:01 PM, Michael Paquier wrote:
I doubt as well that we'd be able to catch all the holes as well as the
conditions where the optimization could be run safely are rather
basically impossible to catch beforehand. I'd like to vote for getting
rid of this optimization for COPY, t
On Tue, Jul 17, 2018 at 12:42 AM Laurenz Albe
wrote:
> Haribabu Kommi wrote:
> > > On Wed, Jul 4, 2018 at 11:14 PM Laurenz Albe
> wrote:
> > > > Haribabu Kommi wrote:
> > > >
> > > > - I think the construction with "read_write_host_index" makes the
> code even more
> > > > complicated than it
Hello,
Yeah, I was wondering about that too. But Fabien brought up a completely new
use-case for this: people learning SQL.
Indeed.
This year, about 30% of my students wrote "= NULL" in a query at least
once. Probably I or a colleague were called to the rescue for help.
So this warning w
>Понедельник, 16 июля 2018, 22:40 +03:00 от Victor Yegorov :
>
>пн, 16 июл. 2018 г. в 21:58, Andrey Klychkov < aaklych...@mail.ru >:
>>I made a patch to solve this issue (see the attachment).
>>It allows to avoid locks by a query like this:
>>“alter index rename CONCURRENTLY to ”.
>
>Please, ha
Attached 7th version of the patches:
* renamed recheck fields and variables
* fixed formatting of the one if-statement
On 15.07.2018 14:54, Andrey Borodin wrote:
14.07.2018, 1:31, Nikita Glukhov wrote:
Attached 6th version of the patches.
...
2. The patch leaves contribs intact. Do extens
On Tue, Jul 17, 2018 at 2:21 AM, Michael Paquier wrote:
> For this part, it seems to me that we can do better than what is in
> HEAD:
> - Call RangeVarGetRelidExtended without lock.
I haven't been following this work closely, but I just want to point
out that the reason why RangeVarGetRelidExtend
On Tue, Jul 17, 2018 at 12:19 AM, Michael Paquier wrote:
> And the patch previously sent removes them, but perhaps I am missing
> your point?
I was just confused. Sorry for the noise.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Jul 17, 2018 at 12:13 PM, Kaye Ann Ignacio
wrote:
> Hi,
>
> I have a foreign table created with postgres_fdw and with that, I tried to
> create a local table to reference the foreign table in order to set a
> foreign key constraint in my local table but I get an error message saying
> that
On 17.07.18 08:58, Michael Paquier wrote:
> Hm... I am wondering if we actually want the "auto" mode where we make
> the option smarter automatically. I am afraid of users trying to use it
> and being surprised that there is no gain while they expected some. I
> would rather switch that to an on
## ramsiddu007 (ramsiddu...@gmail.com):
> If i remove first character it's run. That first
> character is invisible, I have checked that *ascii* value, it is *65279*.
That's not an ASCII-value, ASCII has 8 bits at most.
What you've got there is a UTF-16 Byte Order Mark: 65279 is 0xfeff
(one of t
Hello.
At Tue, 17 Jul 2018 13:37:59 +0900, Masahiko Sawada
wrote in
> >> The usage of XLogSegNoOffsetToRecPtr is wrong. Since we specify the
> >> destination at 4th argument the wal_segment_size will be changed in
> >> the above expression. The regression tests by PostgreSQL Patch Tester
> >
>
Hi,
I have a foreign table created with postgres_fdw and with that, I tried to
create a local table to reference the foreign table in order to set a
foreign key constraint in my local table but I get an error message saying
that the referenced table is not a table. Is there a way I can reference a
Hi all,
Today i got one problem what i have saved more that one procedures in
a folder. After i have concatenate those files into single file through
shell script. After am trying to run that single file in my server, it was
showing syntax error. If i remove first character it's run. That fir
Hello.
At Mon, 16 Jul 2018 16:14:09 -0400, Alvaro Herrera
wrote in <20180716201409.2qfcneo4qkdwjvpv@alvherre.pgsql>
> On 2018-Jul-12, Heikki Linnakangas wrote:
>
> > > > Thanks for the pointer. My tap test has been covering two out of
> > > > the three scenarios you have in your script. I hav
On 16 July 2018 at 21:55, Tomas Vondra wrote:
>
>
> On 07/16/2018 02:54 PM, Dean Rasheed wrote:
>> On 16 July 2018 at 13:23, Tomas Vondra wrote:
> The top-level clauses allow us to make such deductions, with deeper
> clauses it's much more difficult (perhaps impossible). Because for
>
On Tue, Jul 17, 2018 at 02:55:07PM +0700, John Naylor wrote:
> I didn't dig deeper, since TOAST and the large object facility are
> mutually exclusive so there shouldn't be a toast table here anyway.
> Hope this helps.
[... digging ...]
This comes from get_rel_infos where large objects are treated
On 7/17/18, Michael Paquier wrote:
> I was just having a second look at this patch, and did a bit more tests
> with pg_upgrade which passed.
>
> +-- 2. pg_largeobject and pg_largeobject_metadata, to avoid problems
> +-- with pg_upgrade
> John, what's actually the failure that was seen here? It wo
On Mon, Jul 16, 2018 at 01:13:36PM -0400, Tom Lane wrote:
> Since "make check-world" is rather chatty, if you get a failure while
> running it under high parallelism, the location of the failure has often
> scrolled off the terminal window by the time all the other subjobs
> exit.
Yes, I have pest
86 matches
Mail list logo
