On Thu, Apr 12, 2018 at 11:46:33AM +0530, Ashutosh Bapat wrote:
> Usually there are threads associated with the open items, then there
> are patches to solve those and owners responsible in resolving them.
> We have all the infrastructure in the commitfest app to track those
> things, may be we cou
On Wed, Apr 11, 2018 at 10:33 PM, Magnus Hagander wrote:
> On Wed, Apr 11, 2018 at 6:57 PM, Andres Freund wrote:
>>
>> On 2018-04-11 13:54:34 -0300, Alvaro Herrera wrote:
>> > The other proposal was that we could have a simple web app to track open
>> > items. After all, we now know what we need
On Thu, Apr 12, 2018 at 2:31 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 4/11/18 10:53, Tom Lane wrote:
>>> It's not that much work to move the items rather than remove them,
>
>> Well, toward the end of the cycle, when the list of closed items is
>> quite long, then it does become a bit
On Thu, Apr 12, 2018 at 10:34:30AM +0900, Kyotaro HORIGUCHI wrote:
> Checkpointer never calls CreateCheckPoint while
> RecoveryInProgress() == true. In other words, checkpointer is not
> an updator of shared FPW at the time StartupXLOG calls
> CreateCheckPoint for fallback_promote.
I have been abl
On 11 April 2018 at 09:32, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Mon, Apr 9, 2018 at 2:28 PM, Alvaro Herrera
>> wrote:
>
>> >> I don't get this. The executor surely had to (and did) open all of
>> >> the relations somewhere even before this patch.
>
>> > I was worried that this codin
Hello.
At Wed, 11 Apr 2018 09:43:37 -0400, "Jonathan S. Katz"
wrote in
> case EXPR_KIND_PARTITION_BOUNDS:
> ^~
..
> 2 errors generated.
>
> The attached patch fixes the error.
Sorry for the silly mistake.
> I ran the following cas
On 2018/04/12 5:33, Alvaro Herrera wrote:
> Amit Langote wrote:
>> Hi.
>>
>> I noticed that relispartition isn't set for index's partitions.
>
> This patch should fix it.
Thanks. I saw your commit 9e9befac4a22 and changes seem fine.
Regards,
Amit
On Tue, Apr 10, 2018 at 5:45 PM, Peter Geoghegan wrote:
> I did find another problem, though. Looks like the idea to explicitly
> represent the number of attributes directly has paid off already:
>
> pg@~[3711]=# create table covering_bug (f1 int, f2 int, f3 text);
> create unique index cov_idx on
On 2018/04/11 21:35, Alvaro Herrera wrote:
> Here's an idea. Why don't we move the function/opclass creation lines
> to insert.sql, without the DROPs, and use the same functions/opclasses
> in the three tests insert.sql, alter_table.sql, hash_part.sql and
> partition_prune.sql, i.e. not recreate w
On 12 April 2018 at 09:19, Keith Fiske wrote:
> To me the current behavior is even more unintuitive. You tell it to put the
> parent table in a specific tablespace and it completely ignores the option
> and puts it in the default. Then when you go create children without
> specifying a tablespace,
Hello. Thanks to Heikkit for picking this up and thanks for the
commnet to Michael.
# The attached is changed only in a comment, and rebased.
At Thu, 12 Apr 2018 05:24:14 +0900, Michael Paquier wrote
in <20180411202414.ga32...@paquier.xyz>
> On Wed, Apr 11, 2018 at 02:09:48PM +0300, Heikki Linn
On 4/10/18 06:29, Pavan Deolasee wrote:
> One of our 2ndQuadrant support customers recently reported a sudden rush
> of TOAST errors post a crash recovery, nearly causing an outage. Most
> errors read like this:
>
> ERROR: unexpected chunk number 0 (expected 1) for toast value
While research
On Wed, Apr 11, 2018 at 10:16:24AM -0400, Tom Lane wrote:
> That works for me:
>
> $ git clean -dfx
> $ ./configure ... --with-python and other stuff ...
> $ cd src/pl/plpython
> $ make all
> make -C ../../../src/backend generated-headers
> make[1]: Entering directory `/home/postgres/pgsql/src/bac
Michael Paquier writes:
> I have not really checked this thread in details, but one thing that
> strikes me is that it would be rather easy to add a TAP test based on
> the initial script that Pavan has sent. Would that be worth testing
> cycles or not?
I doubt it --- that test is so specialized
On Wed, Apr 11, 2018 at 10:28:10PM +0100, Simon Riggs wrote:
> Requesting review so I don't cause multiple revert commits.
I have gone through the code tree with your patch applied for some time,
and it seems to me that there are no more traces of merge or any of its
infrastructure. Tests are als
On Wed, Apr 11, 2018 at 04:28:33PM -0400, Tom Lane wrote:
> I propose therefore that the right fix does not require an API change
> for GetNewOidWithIndex: we can just make it use SnapshotAny all the
> time.
I have not really checked this thread in details, but one thing that
strikes me is that it
That's the idea that I tried to express. The point is that we need to
tell the user that there is no need to worry about it, rather than
that they're wrong to ask about it. Though we should probably actually
just throw an error.
Or maybe it should be the collation of the underlying table columns
Peter Geoghegan wrote:
On Wed, Apr 11, 2018 at 2:29 PM, Peter Eisentraut
wrote:
But in this case it doesn't even do equality comparison, it just returns
the value.
That's the idea that I tried to express. The point is that we need to
tell the user that there is no need to worry about it, ra
On 4/11/18 17:38, Peter Geoghegan wrote:
> On Wed, Apr 11, 2018 at 2:29 PM, Peter Eisentraut
> wrote:
>> But in this case it doesn't even do equality comparison, it just returns
>> the value.
>
> That's the idea that I tried to express. The point is that we need to
> tell the user that there is n
On Thu, Apr 12, 2018 at 12:01:29AM +0300, Heikki Linnakangas wrote:
> Thanks for the debugging and the patch, Edmund!
Thanks for the commit, Heikki.
--
Michael
signature.asc
Description: PGP signature
> On Apr 11, 2018, at 4:58 PM, Peter Eisentraut
> wrote:
>
> On 4/11/18 10:53, Tom Lane wrote:
>> It's not that much work to move the items rather than remove them,
>
> Well, toward the end of the cycle, when the list of closed items is
> quite long, then it does become a bit of a burden to ca
On Wed, Apr 11, 2018 at 2:29 PM, Peter Eisentraut
wrote:
> But in this case it doesn't even do equality comparison, it just returns
> the value.
That's the idea that I tried to express. The point is that we need to
tell the user that there is no need to worry about it, rather than
that they're wr
On 4/11/18 17:19, Keith Fiske wrote:
> To me the current behavior is even more unintuitive. You tell it to put
> the parent table in a specific tablespace and it completely ignores the
> option and puts it in the default. Then when you go create children
> without specifying a tablespace, you don't
On 4/11/18 17:08, Peter Geoghegan wrote:
>> However, I don't see any point in defining collations here, because
>> INCLUDE attributes exist solely for index-only scans. So, index just
>> can return value of INCLUDE attribute "as is", no point to do something
>> with collation.
>>
>> So, I propose
On 4/11/18 12:06, Andres Freund wrote:
> On 2018-03-22 15:19:12 +0100, Pavel Stehule wrote:
>> attached patch should to fix it
>
> This is still broken, and has been an open item for a bit. Peter, Could
> you check whether Pavel's fix resolves the issue for you?
Yes, I will work on this.
--
Pet
On Wed, Apr 11, 2018 at 4:54 PM, Michael Paquier
wrote:
> On Wed, Apr 11, 2018 at 12:52:06PM -0400, Keith Fiske wrote:
> > Any chance of this being an inheritable property that can simply be
> > overridden if the TABLESPACE flag is set when creating a child table? If
> > it's not set, just set th
On Wed, Apr 11, 2018 at 1:58 PM, Alexander Korotkov
wrote:
> It appears that INCLUDE columns might have collation defined.
> For instance, following query is working:
>
> create index t_s1_s2_idx on t (s1) include (s2 collate "en_US.UTF-8");
>
> However, I don't see any point in defining collation
Peter Eisentraut writes:
> On 4/11/18 10:53, Tom Lane wrote:
>> It's not that much work to move the items rather than remove them,
> Well, toward the end of the cycle, when the list of closed items is
> quite long, then it does become a bit of a burden to carefully cut and
> paste the item in the
On 29/03/18 10:46, Michael Paquier wrote:
On Tue, Mar 27, 2018 at 03:47:07PM +1300, Edmund Horner wrote:
I considered whether aux processes really need those strings
(especially st_clienthostname), but decided it was more consistent
just to assume that they might. (It's an extra 3 kB... if we w
On 4/11/18 10:53, Tom Lane wrote:
> It's not that much work to move the items rather than remove them,
Well, toward the end of the cycle, when the list of closed items is
quite long, then it does become a bit of a burden to carefully cut and
paste the item in the little browser window without maki
On Wed, Apr 11, 2018 at 10:47 PM, Alvaro Herrera
wrote:
> Teodor Sigaev wrote:
>
> > Patch attached.
>
> I wonder why this is a problem in opfamilies but not collations.
> If we don't compare collations, wouldn't it make more sense to break out
> of the loop once the number of keys is reached?
>
On Thu, Apr 12, 2018 at 4:04 AM, Andres Freund wrote:
> This is an open item for v11:
>
> Tidy up es_query_dsa and possibly ParallelWorkerContext?
> Original commit: e13029a5ce353574516c64fd1ec9c50201e705fd (principal
> author: Thomas Munro; owner: Robert Haas)
> Bug fix: fd7
On Wed, Apr 11, 2018 at 12:52:06PM -0400, Keith Fiske wrote:
> Any chance of this being an inheritable property that can simply be
> overridden if the TABLESPACE flag is set when creating a child table? If
> it's not set, just set the tablespace to whatever was set for the parent.
I am wondering h
On Wed, Apr 11, 2018 at 10:21:29PM +0200, Daniel Gustafsson wrote:
> Right, I misunderstood your initial email but I see what you mean. Yes, you
> are right and with that +1 on your patch.
OK, no problem.
> Naming it pg_checksums, with only verification as an option, seems to me to
> imply futur
Amit Langote wrote:
> Hi.
>
> I noticed that relispartition isn't set for index's partitions.
This patch should fix it.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/src/backend/catalog/index.c b/
So while looking at this, it suddenly occurred to me that probing with
SnapshotDirty isn't that safe for regular (non-TOAST) Oid assignment
either. SnapshotDirty will consider a row dead the instant the
deleting transaction has committed, but it may remain visible to other
transactions for awhile
On Wed, Apr 11, 2018 at 02:09:48PM +0300, Heikki Linnakangas wrote:
> I think the new behavior where the GUC only takes effect at next checkpoint
> is OK. It seems quite intuitive.
>
> > [rebased patch version]
>
> Looks good at a quick glance. Assuming no objections from others, I'll take
> a cl
> On 11 Apr 2018, at 01:53, Michael Paquier wrote:
>
> On Tue, Apr 10, 2018 at 10:27:19PM +0200, Daniel Gustafsson wrote:
>>> On 10 Apr 2018, at 06:21, Michael Paquier wrote:
>> Does it really imply that? Either way, the tool could potentially be useful
>> for debugging a broken cluster so I’m
On 11 April 2018 at 19:57, Tom Lane wrote:
> Pavan Deolasee writes:
>> Ok. I propose attached patches, more polished this time.
>
> I'll take these, unless some other committer is hot to do so?
Please go ahead.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 2
On 7 April 2018 at 18:45, Tom Lane wrote:
> Simon Riggs writes:
>> On 6 April 2018 at 17:22, Bruce Momjian wrote:
>>> My point was that people didn't ask you to work harder on fixing the
>>> patch, but in reverting it. You can work harder on fixing things in the
>>> hope they change their minds
> "Chapman" == Chapman Flack writes:
Chapman> There's precedent for that kind of thing in PL/Java already
Chapman> ... objects that Java considers alive as long as some code
Chapman> holds a reference to them, but proxy for things in PG that may
Chapman> only have function-call lifetime o
Teodor Sigaev wrote:
> Patch attached.
I wonder why this is a problem in opfamilies but not collations.
If we don't compare collations, wouldn't it make more sense to break out
of the loop once the number of keys is reached?
When this code was written, there was no question as to what length the
Actually, discovered bug is not related to patch except new test faces
with it,
problem is: CompareIndexInfo() checks rd_opfamily for equality for all
attributes, not only for key attribute.
Patch attached. But it seems to me, field's names of
IndexInfo structure are a bit confused now:
int
On 04/11/2018 03:04 PM, Tom Lane wrote:
> Chapman Flack writes:
>> that it might *not* be sufficient to find an applicable snapshot at
>> the time of constructing the object, and register that snapshot
>> on TopTransactionResourceOwner?
>
> The problem is to know which snapshot is applicable; if
Chapman Flack writes:
> But let me return to the earlier idea for a moment: are you saying
> that it might *not* be sufficient to find an applicable snapshot at
> the time of constructing the object, and register that snapshot
> on TopTransactionResourceOwner?
The problem is to know which snapsho
Pavan Deolasee writes:
> Ok. I propose attached patches, more polished this time.
I'll take these, unless some other committer is hot to do so?
regards, tom lane
Hi
I noticed new merge conflict, updated version attached.
regards, Sergeidiff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml
index bd22627..db98a98 100644
--- a/doc/src/sgml/ref/alter_table.sgml
+++ b/doc/src/sgml/ref/alter_table.sgml
@@ -215,8 +215,15 @@ WITH ( MOD
Thanks for the discussion. Per your suggestions, I changed the check
for default partition OID to an assert instead of the 'if' condition,
and removed the code that attempted vainly to verify the constraint when
attaching a foreign table as a partition. And pushed.
I think we're done here, so ma
On Wed, Apr 11, 2018 at 8:20 PM, Tom Lane wrote:
> Pavan Deolasee writes:
> > Or may be we simply err on the side of caution and scan the toast table
> > with SnapshotAny while looking for a duplicate? That might prevent us
> from
> > reusing an OID for a known-dead tuple, but should save us a s
On 04/11/2018 01:55 PM, Tom Lane wrote:
> Chapman Flack writes:
>> Well, the devilsAdvocate() function would stash the object
>> in a static, then try to look at it some time in a later call
>> in the same transaction.
>
> If you're worried about that, you should also worry about what happens
> i
I wrote:
> The WARNING seems to indicate that the error check in set_config_option
> is too aggressive. I kind of wonder why it was placed there at all,
> rather than in SQL-level operations like ExecSetVariableStmt.
BTW, looking back at the thread, nobody seems to have posted an analysis
of why
Chapman Flack writes:
> On 04/11/2018 11:33 AM, Tom Lane wrote:
>> OK, but if this object only lives within a single function call,
>> what's the problem? The underlying row must be visible to the
>> calling query, and that condition won't change for the duration
>> of the call.
> Well, the devi
On Wed, Apr 11, 2018 at 01:04:56PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Apr 11, 2018 at 12:35:41PM -0400, Tom Lane wrote:
> >> We can fix this by making submake-generated-headers be a recursive
> >> prerequisite for "check" as well as "all" and "install". I wonder
> >> wheth
On 04/11/2018 11:33 AM, Tom Lane wrote:
> Chapman Flack writes:
>> The mission is to implement java.sql.SQLXML, which has long been
>> missing from PL/Java.
>> This is the class of object your Java code can retrieve from a
>> ResultSet row from a query with an XML column type. (It's also
>> what c
On 04/11/2018 10:06 AM, Alvaro Herrera wrote:
Andres Freund wrote:
On 2018-04-11 13:54:34 -0300, Alvaro Herrera wrote:
The other proposal was that we could have a simple web app to track open
items. After all, we now know what we need from it. A wiki page seems
more laborious. (The commitfes
Magnus Hagander wrote:
> (And of course, if we want to go in *any* direction away from the wiki,
> it's not going to happen in time for *this* release..)
Absolutely. But if we never start, it'll never get done.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Developmen
Andres Freund wrote:
> On 2018-04-11 13:54:34 -0300, Alvaro Herrera wrote:
> > The other proposal was that we could have a simple web app to track open
> > items. After all, we now know what we need from it. A wiki page seems
> > more laborious. (The commitfest app also sprung from a wiki page.)
Bruce Momjian writes:
> On Wed, Apr 11, 2018 at 12:35:41PM -0400, Tom Lane wrote:
>> We can fix this by making submake-generated-headers be a recursive
>> prerequisite for "check" as well as "all" and "install". I wonder
>> whether anybody is expecting any other shortcuts to work.
> In case it w
On Wed, Apr 11, 2018 at 6:57 PM, Andres Freund wrote:
> On 2018-04-11 13:54:34 -0300, Alvaro Herrera wrote:
> > The other proposal was that we could have a simple web app to track open
> > items. After all, we now know what we need from it. A wiki page seems
> > more laborious. (The commitfest
On 2018-04-11 13:54:34 -0300, Alvaro Herrera wrote:
> The other proposal was that we could have a simple web app to track open
> items. After all, we now know what we need from it. A wiki page seems
> more laborious. (The commitfest app also sprung from a wiki page.)
Growing a number of non-iss
Jonathan S. Katz wrote:
> During some RMT discussions I had proposed formatting the open items
> into a table on the Wiki page with some useful info to help track the status
> and surface the necessary info to track down the open item.
The other proposal was that we could have a simple web app to
Just had someone report that pg_partman wasn't handling tablespaces for
native partitioning.
https://github.com/keithf4/pg_partman/issues/212
I'd assumed that that was a property that was being inherited from the
parent table, but apparently the TABLESPACE flag to CREATE TABLE is
completely ignor
Alvaro Herrera writes:
> Tom Lane wrote:
>> We can fix this by making submake-generated-headers be a recursive
>> prerequisite for "check" as well as "all" and "install". I wonder
>> whether anybody is expecting any other shortcuts to work.
> check-world certainly, but presumably that depends on
> On Apr 11, 2018, at 11:54 AM, Tom Lane wrote:
>
> Robert Haas writes:
>> On Wed, Apr 11, 2018 at 10:53 AM, Tom Lane wrote:
>>> What *does* take time is adding a link to the commit, so I'd happily
>>> drop that step. As Peter says, you can usually look in the commit
>>> log if you care.
>
>
Patch makes buildfarm almost red, patch is temporary reverted.
Actually, discovered bug is not related to patch except new test faces with it,
problem is: CompareIndexInfo() checks rd_opfamily for equality for all
attributes, not only for key attribute.
Obviously, CompareIndexInfo() needs more
Tom Lane wrote:
> We can fix this by making submake-generated-headers be a recursive
> prerequisite for "check" as well as "all" and "install". I wonder
> whether anybody is expecting any other shortcuts to work.
check-world certainly, but presumably that depends on check?
--
Álvaro Herrera
On Wed, Apr 11, 2018 at 12:35:41PM -0400, Tom Lane wrote:
> Andrew Gierth writes:
> > Tom> Please be more explicit about what state you're starting from.
>
> > This is consistently failing for me, on FreeBSD with GNU Make 4.2.1,
> > clang 3.9.1, at commit 651cb90941:
>
> > git clean -dfx
> > ./
Andrew Gierth writes:
> Tom> Please be more explicit about what state you're starting from.
> This is consistently failing for me, on FreeBSD with GNU Make 4.2.1,
> clang 3.9.1, at commit 651cb90941:
> git clean -dfx
> ./configure '--prefix=/home/andrew/work/pgsql/head' \
> '--with-includes=/u
Andres Freund writes:
> On 2018-03-12 20:44:01 -0700, Peter Geoghegan wrote:
>> I wonder why DefineCustomStringVariable() does not set var->reset_val.
>> We see that within DefineCustomEnumVariable(),
>> DefineCustomRealVariable(), DefineCustomIntVariable(), etc.
> Peter, have you investigated th
> "Tom" == Tom Lane writes:
Tom> No doubt this is related to the generated-headers changes I've
Tom> been making, but I find your recipe confusing. "make clean" should
Tom> not have removed the generated headers from the previous build. I
Tom> can believe that if you started from a bare g
Hello
Andres Freund wrote:
> On 2018-01-26 18:57:03 +0900, Amit Langote wrote:
> > I noticed that relispartition isn't set for index's partitions.
> > Is that intentional?
>
> This appears to be a question about
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=8b08f7d4820fd7a8ef
Hi,
On 2018-01-26 18:57:03 +0900, Amit Langote wrote:
> I noticed that relispartition isn't set for index's partitions.
>
> create table p (a int) partition by list (a);
> create table p12 partition of p for values in (1, 2);
> create index on p (a);
> select relname, relkind from pg_class where
On Wed, Apr 11, 2018 at 10:59:45AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I have discovered that:
> > make clean; make check
> > fails with:
>
> No doubt this is related to the generated-headers changes I've been
> making, but I find your recipe confusing. "make clean" should not
Hi Peter, Pavel,
On 2018-03-22 15:19:12 +0100, Pavel Stehule wrote:
> attached patch should to fix it
This is still broken, and has been an open item for a bit. Peter, Could
you check whether Pavel's fix resolves the issue for you?
Regards,
Andres
Hi,
On 2017-12-07 12:51:56 +1300, Thomas Munro wrote:
> 1. Removing es_query_dsa and injecting the right context into the
> executor tree as discussed.
>
> 2. Another idea mentioned by Robert in an off-list chat: We could
> consolidate all DSM segments in a multi-gather plan into one. See the
On 2018-03-12 20:44:01 -0700, Peter Geoghegan wrote:
> On Sun, Mar 11, 2018 at 10:15 PM, Jeff Janes wrote:
> > Then when I create in index, I get a warning:
> >
> > jjanes=# create index on pgbench_accounts (foobar(filler));
> > WARNING: cannot set parameters during a parallel operation
> > WARNI
Robert Haas writes:
> On Wed, Apr 11, 2018 at 10:53 AM, Tom Lane wrote:
>> What *does* take time is adding a link to the commit, so I'd happily
>> drop that step. As Peter says, you can usually look in the commit
>> log if you care.
> The trouble is that sometimes it's not very obvious which co
Chapman Flack writes:
> On 04/11/2018 10:41 AM, Tom Lane wrote:
>> So maybe we need to take two steps back and talk about the semantics
>> of what you're doing.
> The mission is to implement java.sql.SQLXML, which has long been
> missing from PL/Java.
> This is the class of object your Java code
On 04/11/2018 10:41 AM, Tom Lane wrote:
> The core of the problem now is that in a READ COMMITTED transaction, we
> may not be holding any snapshot at all between statements. So if you're
> hanging onto a toast pointer across statements you're at risk.
>
> On the other hand, it's also arguable th
On Wed, Apr 11, 2018 at 10:53 AM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> On Wed, Apr 11, 2018 at 6:53 PM, Peter Eisentraut
>> wrote:
>>> Do people find it useful to move the resolved items to a separate
>>> section on the page, instead of just removing them? I'm not sure that
>>> the resol
Bruce Momjian writes:
> I have discovered that:
> make clean; make check
> fails with:
No doubt this is related to the generated-headers changes I've been
making, but I find your recipe confusing. "make clean" should not
have removed the generated headers from the previous build. I can
be
Ashutosh Bapat writes:
> On Wed, Apr 11, 2018 at 6:53 PM, Peter Eisentraut
> wrote:
>> Do people find it useful to move the resolved items to a separate
>> section on the page, instead of just removing them? I'm not sure that
>> the resolved sections are useful, compared to just using the git lo
Pavan Deolasee writes:
> Or may be we simply err on the side of caution and scan the toast table
> with SnapshotAny while looking for a duplicate? That might prevent us from
> reusing an OID for a known-dead tuple, but should save us a second index
> scan and still work.
+1. We really don't want
Chapman Flack writes:
> On 04/10/2018 10:17 PM, Jan Wieck wrote:
>> If your session has a transaction snapshot that protects the old toast
>> slices from being vacuumed away, you are fine.
> That harks back to my earlier (naïve?) thought that, as long as
> my lazy datum doesn't have to outlive th
On Wed, 11 Apr 2018 07:29:09 -0700
Andres Freund wrote:
> If that room can be found, I might be able to make it. Being in SF, I'm
> probably the physically closest PG dev involved in the discussion.
OK, I've dropped the PC a note; hopefully you'll be hearing from them.
jon
On 4/10/18 07:33, Dagfinn Ilmari Mannsåker wrote:
> 1) both the jsonb_plperl and jsonb_plperlu extensions contain the SQL
>functions jsonb_to_plperl and plperl_to_jsonb, so can't be installed
>simultaneously
>
> 2) jsonb scalar values are passed to the plperl function wrapped in not
>o
Hi,
On 2018-04-11 06:05:27 -0600, Jonathan Corbet wrote:
> The event is April 23-25 in Park City, Utah. I bet that room could be
> found for somebody from the postgresql community, should there be
> somebody who would like to represent the group on this issue. Let me
> know if an introduction or
On 04/10/2018 10:17 PM, Jan Wieck wrote:
> If your session has a transaction snapshot that protects the old toast
> slices from being vacuumed away, you are fine.
That harks back to my earlier (naïve?) thought that, as long as
my lazy datum doesn't have to outlive the transaction, lazy
detoasting
Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes:
> On Wed, 2018-04-11 at 09:38 -0400, Tom Lane wrote:
>> *What* still doesn't work on current HEAD? I don't know what commands
>> you are running to get this.
> I think my build and Christoph's builds fail because of the same reason again
> (the same as
Hi,
On Wed, 2018-04-11 at 09:38 -0400, Tom Lane wrote:
> *What* still doesn't work on current HEAD? I don't know what commands
> you are running to get this.
I think my build and Christoph's builds fail because of the same reason again
(the same as yesterday):
=
_bt_mark_page_halfdead() looked like it had a problem, but it now
looks like I was wrong. I also verified every other
BTreeInnerTupleGetDownLink() caller. It now looks like everything is
good here.
Right - it tries to find right page by conlsulting in parent page, by taking of
next key.
--
On Wed, Apr 11, 2018 at 6:53 PM, Peter Eisentraut
wrote:
> On 2/18/18 22:42, Michael Paquier wrote:
>> Okay, I have created a skeleton of page here:
>> https://wiki.postgresql.org/wiki/PostgreSQL_11_Open_Items
>> Feel free to add any bugs or issues related to v11 that need to be
>> tracked before
Thank you, pushed
Amit Langote wrote:
Hi.
On 2018/04/11 0:36, Teodor Sigaev wrote:
Does the attached fix look correct? Haven't checked the fix with
ATTACH
PARTITION though.
Attached patch seems to fix the problem. However, I would rather get
rid of modifying stmt->indexParams. T
> On Apr 11, 2018, at 4:33 AM, Kyotaro HORIGUCHI
> wrote:
>
> Thank you for the comments.
>
> At Wed, 11 Apr 2018 13:51:55 +0900, Amit Langote
> wrote in
> <3d0fda29-986c-d970-a22c-b4bd44f56...@lab.ntt.co.jp>
>> Horiguchi-san,
>>
>> Thanks for working on this.
>>
>> On 2018/04/11 13:20, K
Christoph Berg writes:
> It still doesn't work on current HEAD:
*What* still doesn't work on current HEAD? I don't know what commands
you are running to get this.
regards, tom lane
Mark Rofail wrote:
> > In particular: it seemed to me that you decided to throw away the idea
> > of the new GIN operator without sufficient evidence that it was
> > unnecessary.
>
> I have to admit to that. But in my defence @> is also GIN indexable so the
> only difference in performance betwee
On Wed, Apr 11, 2018 at 2:34 AM, Chapman Flack wrote:
> On 04/10/2018 04:03 PM, Robert Haas wrote:
>
>> I suspect you want, or maybe need, to use the same snapshot as the
>> scan that retrieved the tuple containing the toasted datum.
>
> I'm sure it's worth more than that, but I don't know if it's
On 2/18/18 22:42, Michael Paquier wrote:
> Okay, I have created a skeleton of page here:
> https://wiki.postgresql.org/wiki/PostgreSQL_11_Open_Items
> Feel free to add any bugs or issues related to v11 that need to be
> tracked before the release.
Do people find it useful to move the resolved item
On 3/16/18 11:40, Tom Lane wrote:
> Michael Paquier writes:
>> On Fri, Mar 16, 2018 at 11:35:13AM +0530, Prabhat Sahu wrote:
>>> postgres=# CREATE OR REPLACE FUNCTION func1() RETURNS VOID
>>> LANGUAGE SQL
>>> AS $$
>>> select 10;
>>> $$;
>
>> Problem reproducible here, and the bug has been introd
On 3/3/18 07:35, Shinoda, Noriyoshi wrote:
> Hi, Hackers,
>
> The attached patch adds the following information to the document on Logical
> Replication.
> About the requirement of connection role of Logical Replication, written in
> 31.7 of the manual is as follows.
> --
> The role used for th
1 - 100 of 123 matches
Mail list logo
