On 2019-12-18 16:53, Robert Haas wrote:
On Wed, Dec 18, 2019 at 3:56 AM Peter Eisentraut
wrote:
As a curious omission, DROP RULE does not check allow_system_table_mods.
Creating and renaming a rule does, and also creating, renaming, and
dropping a trigger does. The impact of this is
On Fri, Dec 20, 2019 at 6:04 AM Andrey Borodin wrote:
> I think proper solution here would be to add GUC to disallow cancellation of
> synchronous replication. Retry step 3 will wait on locks after hanging 1 and
> data will be consistent.
> Three is still a problem when backend is not canceled,
On Fri, Dec 20, 2019 at 02:45:26AM +, tsunakawa.ta...@fujitsu.com wrote:
> I've got interested in this. What's the current status of this
> patch? The CF entry shows it was committed.
>
> But I understood not, because the relevant code doesn't appear in
> HEAD, and Git log shows that it was
Hello,
I'm starting to take a closer look at this feature. I've just finished reading
the discussion, excluding other referenced materials.
The following IVM wiki page returns an error. Does anybody know what's wrong?
https://wiki.postgresql.org/wiki/Incremental_View_Maintenance
[screen]
On Thu, 19 Dec 2019 at 22:48, Robert Haas wrote:
>
> On Thu, Dec 19, 2019 at 12:41 AM Masahiko Sawada
> wrote:
> > Attached the updated version patch. This version patch incorporates
> > the above comments and the comments from Mahendra. I also fixed one
> > bug around determining the indexes
On Mon, 2 Dec 2019 at 17:32, Dilip Kumar wrote:
>
> On Sun, Dec 1, 2019 at 7:58 AM Michael Paquier wrote:
> >
> > On Fri, Nov 22, 2019 at 01:18:11PM +0530, Dilip Kumar wrote:
> > > I have rebased the patch on the latest head and also fix the issue of
> > > "concurrent abort handling of the
On Thu, 19 Dec 2019 at 19:27, Robert Haas wrote:
> On Wed, Dec 18, 2019 at 5:07 AM Simon Riggs wrote:
> > TransactionIdIsCurrentTransactionId() doesn't seem to be well optimized
> for the case when an xid has not yet been assigned, so for read only
> transactions.
> >
> > A patch for this is
Hi, hackers!
This is continuation of thread [0] in pgsql-general with proposed changes. As
Maksim pointed out, this topic was raised before here [1].
Currently, we can have split brain with the combination of following steps:
0. Setup cluster with synchronous replication. Isolate primary from
Hi,
Attached is the latest patch (v10) to add support for Incremental
Materialized View Maintenance (IVM).
IVM is a way to make materialized views up-to-date in which only
incremental changes are computed and applied on views rather than
recomputing the contents from scratch as REFRESH
At Fri, 20 Dec 2019 00:35:19 +0100, Jehan-Guillaume de Rorthais
wrote in
> On Fri, 13 Dec 2019 16:12:55 +0900
> Michael Paquier wrote:
The first one;
> > I mentioned a SRF function which takes an input argument, but that
> > makes no sense. What I would prefer having is just having one
> >
On Fri, 20 Dec 2019 at 12:18, Tom Lane wrote:
> Craig Ringer writes:
> > My understanding from reading the above is that Simon didn't propose to
> > make aborted txns visible, only in-progress uncommitted txns.
>
> Yeah, but an "in-progress uncommitted txn" can become an "aborted txn"
> at any
Hello,
On 2019/10/07 16:14, Anders Åstrand wrote:
Hello
Attached is a patch for adding uri as an encoding option for
encode/decode. It uses what's called "percent-encoding" in rfc3986
(https://tools.ietf.org/html/rfc3986#section-2.1).
Thank you for the patch. I'm not very familiar with
Craig Ringer writes:
> My understanding from reading the above is that Simon didn't propose to
> make aborted txns visible, only in-progress uncommitted txns.
Yeah, but an "in-progress uncommitted txn" can become an "aborted txn"
at any moment, and there's no interlock that would prevent its
On Thu, 19 Dec 2019 at 11:59, Amit Kapila wrote:
>
> On Wed, Dec 18, 2019 at 12:34 PM Amit Khandekar
> wrote:
> >
> > On Tue, 17 Dec 2019 at 17:40, Amit Khandekar wrote:
> > > By the way, the backport patch is turning out to be simpler. It's
> > > because in pre-12 versions, the file offset is
Vik Fearing writes:
> On 16/12/2019 22:13, Tom Lane wrote:
>> That being the case, I'm not in favor of using up SQL syntax space for it
>> if we don't have to.
> Do I understand correctly that you are advocating *against* using
> standard SQL syntax for a feature that is defined by the SQL
[un-top-postifying]
On Fri, Dec 20, 2019 at 2:53 PM Wu, Fei wrote:
>> On 02/10/2019 16:11, Tom Lane wrote:
>> > Tom Mercha writes:
>> >> I am using PostgreSQL's SPI to execute a simple SQL query (SELECT *
>> >> FROM
>> >> ...) via SPI_exec. As a a result, I get an SPITupleTable with the
>> >>
From: Michael Paquier
> Adding extra custom logging information, or plug that information
> elsewhere than Postgres. I have use cases for that when it comes to
> store external telemetry data or audit things for events happening
> specifically in Postgres.
>
> Well, hook authors can do a lot of
On Thu, Dec 19, 2019 at 11:28:55AM -0800, Jeremy Schneider wrote:
> On 12/19/19 08:12, Bruce Momjian wrote:
> > I don't see lossy BRIN indexes helping with the uniqueness use-case, and
> > I am not sure they would help with the rare case either. They would
> > help for range-based partitions, but
On Thu, 19 Dec 2019 at 23:36, Andres Freund wrote:
> Hi,
>
> > On the patch as proposed this wouldn't be possible because a toast row
> > can't be vacuumed and then reused while holding back xmin, at least as I
> > understand it.
>
> Vacuum and pruning remove rows where xmin didn't commit,
Hi,
I have had see your discussion about node EphemeralNamedRelation with the
Community.
Now, I want to use this node in SQL(for test), I have saw the manual but could
not understand,
can you show me a example on how to use it in SQL?
Thanks a lot~
Regards, wu fei
-Original Message-
On Thu, Dec 19, 2019 at 07:19:56PM +0100, Peter Eisentraut wrote:
On 2019-12-19 19:15, Dave Cramer wrote:
It seems that if you drop the publication on an existing slot it
needs to be recreated. Is this expected behaviour
A publication is not associated with a slot. Only a subscription is
Hello Michael,
> In short, attached is an updated version of your patch which attempts to
> solve that. I have tested this with some cplusplus stuff, and GCC for both
> versions (static_assert is available in GCC >= 6, but a manual change of c.h
> does the trick).
> I have edited the patch a
On Fri, Dec 20, 2019 at 1:26 PM Thomas Munro wrote:
> On Fri, Dec 20, 2019 at 12:41 PM Rui DeSousa wrote:
> > PostgreSQL 11
BTW, PostgreSQL 12 has an improvement that may be relevant for your
case: it suppresses a bunch of high frequency reads on the "postmaster
death" pipe in some scenarios,
On 12/20/19 1:01 AM, Ranier Vilela wrote:> First case:
src \ backend \ executor \ nodeSubplan.c (line 507)
if (node-> hashtable)
node-> hastable is assigned with NULL at line 498, so the test will
always fail.
Second case:
Here the case is similar, but worse.
src \ backend \ executor \
>1) long is 64 bits on Unix-like platforms
>2) checking a long against LONG_MIN/LONG_MAX is _definitely_ pointless
>3) it's being cast to an int for the from_char_set_int() call below
>Please take your time to read the whole context of the code you're
>changing, and consider other platforms than
From: Greg Nancarrow
> With the permission of the original patch author, Haribabu Kommi, I’ve
> rationalized the existing 8 patches into 3 patches, merging patches
> 1-5 and 6-7, and tidying up some documentation and code comments. I
> also rebased them to the latest PG12 source code (as of
On 16/12/2019 22:13, Tom Lane wrote:
> That being the case, I'm not in favor of using up SQL syntax space for it
> if we don't have to.
Do I understand correctly that you are advocating *against* using
standard SQL syntax for a feature that is defined by the SQL Standard
and that we have no
On Fri, Dec 20, 2019 at 12:41 PM Rui DeSousa wrote:
> I’m instrested in the kqueue patch and would like to know its current state
> and possible timeline for inclusion in the base code. I have several large
> FreeBSD systems running PostgreSQL 11 that I believe currently displays this
>
On Thu, Dec 19, 2019 at 02:27:01PM -0500, Robert Haas wrote:
On Wed, Dec 18, 2019 at 5:07 AM Simon Riggs wrote:
TransactionIdIsCurrentTransactionId() doesn't seem to be well optimized for the
case when an xid has not yet been assigned, so for read only transactions.
A patch for this is
On Thu, Dec 19, 2019 at 12:05 PM Robert Haas wrote:
> My impression is that this is more of an implementation restriction
> than a design goal. I don't really remember the details, but it seems
> to me that there were locking and/or cache invalidation problems with
> making ALTER OPERATOR CLASS
Ranier Vilela writes:
> More about expressions always false.
> 2. src/backend/utils/adt/formatting.c
> result is declared long. Comparison with int limits is always false.
> 3. src/backend/utils/adt/jsonfuncs.c
> lindex is declared long. . Comparison with int limits is always false.
1) long is
> On Apr 10, 2018, at 9:05 PM, Thomas Munro
> wrote:
>
> On Wed, Dec 6, 2017 at 12:53 AM, Thomas Munro
> wrote:
>> On Thu, Jun 22, 2017 at 7:19 PM, Thomas Munro
>> wrote:
>>> I don't plan to resubmit this patch myself, but I was doing some
>>> spring cleaning and rebasing today and I
On Fri, 13 Dec 2019 16:12:55 +0900
Michael Paquier wrote:
> On Wed, Dec 11, 2019 at 10:45:25AM -0500, Stephen Frost wrote:
> > I'm confused- wouldn't the above approach be a function that's returning
> > only one row, if you had a bunch of columns and then had NULL values for
> > those cases
More about expressions always false.
1. /src/backend/executor/execExprInterp.c
ndims <= 0 neve be negative, because ndims aways is added up +1
2. src/backend/utils/adt/formatting.c
result is declared long. Comparison with int limits is always false.
3. src/backend/utils/adt/jsonfuncs.c
lindex is
Hi,
While testing something unrelated, Tomas reported[1] that he could
make a parallel worker ignore a SIGTERM and hang forever in
ConditionVariableSleep(). I looked into this and realised that it's
more likely in master. Commit 1321509f refactored the latch wait loop
to look a little bit more
On Tue, Oct 29, 2019 at 6:06 AM Peter Eisentraut
wrote:
>
> Continuing the discussion from [0] and [1], here is a patch that
> automates the process of updating Unicode derived files. Summary:
>
> - Edit UNICODE_VERSION and/or CLDR_VERSION in src/Makefile.global.in
> - Run make update-unicode
>
On Wed, 11 Dec 2019 14:20:02 +0900
Michael Paquier wrote:
> On Thu, Sep 26, 2019 at 07:20:46PM +0200, Jehan-Guillaume de Rorthais wrote:
> > If this solution is accepted, some other function of the same family might
> > be good candidates as well, for the sake of homogeneity:
> >
> > *
On Thu, Dec 19, 2019 at 8:57 PM Robert Haas wrote:
> On Tue, Dec 17, 2019 at 1:38 PM Robert Haas wrote:
> > On Thu, Dec 12, 2019 at 2:54 PM Andres Freund
> wrote:
> > > I'd either add a test (if we have some) or placeholder kind
> > > initially. But I'd also be ok with going for either of the
On Wed, Nov 13, 2019 at 4:25 PM Peter Geoghegan wrote:
> I think that that's probably not desirable. There should at least be a
> strong practical advantage if we go that way. This would mean ALTER
> OPERATOR CLASS could change the "substance" of an opclass, which is
> fundamentally different
On Tue, Dec 17, 2019 at 1:38 PM Robert Haas wrote:
> On Thu, Dec 12, 2019 at 2:54 PM Andres Freund wrote:
> > I'd either add a test (if we have some) or placeholder kind
> > initially. But I'd also be ok with going for either of the other
> > versions directly - but it seems harder to tackle the
On Wed, Dec 18, 2019 at 5:07 AM Simon Riggs wrote:
> TransactionIdIsCurrentTransactionId() doesn't seem to be well optimized for
> the case when an xid has not yet been assigned, so for read only transactions.
>
> A patch for this is attached.
It might be an idea to first call
On Thu, Dec 19, 2019 at 5:47 AM Kyotaro Horiguchi
wrote:
> At Thu, 19 Dec 2019 11:15:26 +0900, Michael Paquier
> wrote in
> > Hi all,
> >
> > As discussed here, there is in the tree a couple of things related to
> > past versions of Windows:
> >
>
macOS does not support the socket option TCP_USER_TIMEOUT. Yet, I can
start a server with postgres -D ... --tcp-user-timeout=100 without a
diagnostic. Only when I connect I get a log entry
LOG: setsockopt(TCP_USER_TIMEOUT) not supported
Perhaps the logic in pq_settcpusertimeout() should be
On 2019-12-19 19:15, Dave Cramer wrote:
It seems that if you drop the publication on an existing slot it needs
to be recreated. Is this expected behaviour
A publication is not associated with a slot. Only a subscription is
associated with a slot.
drop publication dbz_publication ;
DROP
On Thu, 19 Dec 2019 at 11:59, Dave Cramer wrote:
> The publication exists but for some reason the function can't find it
>
> SELECT * FROM pg_logical_slot_get_binary_changes('debezium', NULL,
> NULL,'proto_version','1','publication_names','dbz_publication');
> ERROR: publication
On Thu, Dec 19, 2019 at 7:55 AM Tom Lane wrote:
> I don't think this is actually a good idea. What it is is a foot-gun,
> because if anyone adds code there that wants to access the special area
> of that particular page, it'll do the wrong thing, unless they remember
> to put back the assignment
On Thu, Dec 19, 2019 at 10:59 AM Tom Lane wrote:
> Bruce Momjian writes:
> > Good question. I am in favor of allowing a larger value if no one
> > objects. I don't think adding the min/max is helpful.
>
> I think there are pretty obvious performance and memory-consumption
> penalties to very
On Thu, Dec 12, 2019 at 10:20 AM Asif Rehman wrote:
> I have updated the patches (v7 attached) and have taken care of all issues
> pointed by Jeevan, additionally
> ran the pgindent on each patch. Furthermore, Command names have been renamed
> as suggested and I
> have simplified the SendFiles
The publication exists but for some reason the function can't find it
SELECT * FROM pg_logical_slot_get_binary_changes('debezium', NULL,
NULL,'proto_version','1','publication_names','dbz_publication');
ERROR: publication "dbz_publication" does not exist
CONTEXT: slot "debezium", output plugin
De: Bruce Momjian
Enviado: quinta-feira, 19 de dezembro de 2019 16:19
>Oh, I was not aware that was boilerplate code. I agree it should be
>consistent, so patch reverted. Sorry.
I apologize to you, Bruce.
It is difficult to define where a "boilerplate" exists.
I agree that decent compiler,
Arseny Sher writes:
> I'm sorry to bother you with this again, but due to new test our
> internal buildfarm revealed that ajacent assert on cmin is also lie. You
> see, we can't assume cmin is stable because the same key (relnode, tid)
> might refer to completely different tuples if tuple was
On Thu, Dec 19, 2019 at 09:48:40AM +0100, Jose Luis Tallon wrote:
> On 19/12/19 4:03, Bruce Momjian wrote:
> > On Mon, Nov 25, 2019 at 03:44:39PM -0800, Jeremy Schneider wrote:
> > > On 11/25/19 15:05, Jeremy Schneider wrote:
> > > > ... the cost of doing the individual index lookups across 180
>
On Thu, Dec 19, 2019 at 10:55:42AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Nov 26, 2019 at 01:45:10PM +, Ranier Vilela wrote:
> >> Same case on nbtpage.c at line 1637, with var opaque.
> >> make check, passed all 195 tests here with all commits.
>
> > You were right about
Hi,
On 2019-12-19 07:08:06 -0800, Mark Dilger wrote:
> > As soon as a transaction aborts, the TOAST rows can be vacuumed
> > away, but the READ UNCOMMITTED transaction might've already seen the
> > main tuple. This is not even a particularly tight race, necessarily,
> > since for example the
Bruce Momjian writes:
> Good question. I am in favor of allowing a larger value if no one
> objects. I don't think adding the min/max is helpful.
I think there are pretty obvious performance and memory-consumption
penalties to very large track_activity_query_size values. Who exactly
are we
Bruce Momjian writes:
> On Tue, Nov 26, 2019 at 01:45:10PM +, Ranier Vilela wrote:
>> Same case on nbtpage.c at line 1637, with var opaque.
>> make check, passed all 195 tests here with all commits.
> You were right about both of these, so removed in master. I am
> surprised no one else saw
Good question. I am in favor of allowing a larger value if no one
objects. I don't think adding the min/max is helpful.
---
On Tue, Nov 26, 2019 at 05:59:25PM +0300, v.maka...@postgrespro.ru wrote:
> Hi Hackers,
>
>
Hi,
On 2019-12-19 09:50:44 +, Simon Riggs wrote:
> On Thu, 19 Dec 2019 at 02:22, Andres Freund wrote:
>
> > Hi,
> >
> > On 2019-12-18 18:06:21 +, Simon Riggs wrote:
> > > On Wed, 18 Dec 2019 at 17:35, Robert Haas wrote:
> > >
> > > > On Wed, Dec 18, 2019 at 10:18 AM Simon Riggs
> > >
On Tue, Nov 26, 2019 at 01:45:10PM +, Ranier Vilela wrote:
> Same case on nbtpage.c at line 1637, with var opaque.
> make check, passed all 195 tests here with all commits.
>
> Ranier Vilela
You were right about both of these, so removed in master. I am
surprised no one else saw this
On 2019-Dec-19, Tom Lane wrote:
> I wrote:
> > Concretely, I propose the attached. Anybody want to editorialize on
> > my short descriptions of the auth methods?
>
> Pushed after a bit more fiddling with the wording.
Looks good, thanks.
--
Álvaro Herrera
On 12/19/19 7:08 AM, Mark Dilger wrote:
and instead get NULLs for all such rows
To clarify, I mean the toasted column is null for rows
where the value was stored in the toast table rather
than stored inline. I'd prefer some special value
that means "this datum unavailable" so that it could
Anastasia Lubennikova wrote:
> I attached new version with pg_opclass documentation update.
>
> One more thing I am uncertain about is array_ops. Arrays may contain bitwise
> and not bitwise element types.
> What is the correct value of opcisbitwise the array_ops itself?
How about setting
On 12/19/19 1:50 AM, Simon Riggs wrote:
It seems possible that catalog access would be the thing that makes this
difficult. Cache invalidations wouldn't yet have been fired, so that
would lead to rather weird errors, and as you say, potential issues from
data type changes which would not be
I wrote:
> Concretely, I propose the attached. Anybody want to editorialize on
> my short descriptions of the auth methods?
Pushed after a bit more fiddling with the wording.
regards, tom lane
On Wed, Dec 18, 2019 at 1:49 AM Amit Langote wrote:
> It seems that d986d4e87f6 forgot to update a comment upon renaming a variable.
>
> Attached fixes it.
Committed and back-patched to v12.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Dec 17, 2019 at 3:48 PM Tom Lane wrote:
> Oh, scratch that --- looking closer, I see that the only two use-cases in
> the patched code are via before_shmem_exit and PG_ENSURE_ERROR_CLEANUP,
> and both of those require a function with the signature of an on_exit
> callback.
Yeah, that's
On Thu, Dec 19, 2019 at 12:41 AM Masahiko Sawada
wrote:
> Attached the updated version patch. This version patch incorporates
> the above comments and the comments from Mahendra. I also fixed one
> bug around determining the indexes that are vacuumed in parallel based
> on their option and size.
On Wed, 18 Dec 2019 08:46:01 +0530
Amit Kapila wrote:
> On Tue, Dec 17, 2019 at 6:01 PM vignesh C wrote:
> >
> > On Tue, Dec 17, 2019 at 10:09 AM Amit Kapila
> > wrote:
> > >
> > > Attached patch with updated commit message based on suggestions. I am
> > > planning to commit this tomorrow
On Thu, 19 Dec 2019 at 12:42, Bernd Helmle wrote:
> Am Donnerstag, den 19.12.2019, 00:13 + schrieb Simon Riggs:
> > So the consensus is for a more-specifically named facility.
> >
> > I was aiming for something that would allow general SELECTs to run
> > with a
> > snapshot that can see
Am Donnerstag, den 19.12.2019, 00:13 + schrieb Simon Riggs:
> So the consensus is for a more-specifically named facility.
>
> I was aiming for something that would allow general SELECTs to run
> with a
> snapshot that can see uncommitted xacts, so making it a SRF wouldn't
> really
> allow
On 2019-12-18 16:14, Simon Riggs wrote:
On Wed, 18 Dec 2019 at 12:11, Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
As far as I understand with "read uncommitted" policy we can see two
versions of the same tuple if it was updated by two transactions
both of which
Hi All,
*All* phases are repeated in this case, not not just "finalizing
analyze", because ANALYZE repeatedly runs for each partition after the
parent partitioned table's ANALYZE finishes. ANALYZE's documentation
mentions that analyzing a partitioned table also analyzes all of its
partitions,
On Thu, Dec 19, 2019 at 11:11 AM Masahiko Sawada
wrote:
>
> On Wed, 18 Dec 2019 at 19:06, Amit Kapila wrote:
> >
>
> - /* Cap by the worker we computed at the beginning of parallel lazy vacuum */
> - nworkers = Min(nworkers, lps->pcxt->nworkers);
> + /*
> + * The number of workers required for
st 18. 12. 2019 v 21:12 odesílatel Merlin Moncure
napsal:
> On Wed, Dec 18, 2019 at 12:38 PM Pavel Stehule
> wrote:
> >
> > Hi
> >
> > I had a talk with one boy about development in plpgsql. He uses table's
> functions. More times he uses returns types based on some table type + few
>
On Thu, 19 Dec 2019 at 02:22, Andres Freund wrote:
> Hi,
>
> On 2019-12-18 18:06:21 +, Simon Riggs wrote:
> > On Wed, 18 Dec 2019 at 17:35, Robert Haas wrote:
> >
> > > On Wed, Dec 18, 2019 at 10:18 AM Simon Riggs
> > > wrote:
> > > > This was my first concern when I thought about it, but
On 19/12/19 4:03, Bruce Momjian wrote:
On Mon, Nov 25, 2019 at 03:44:39PM -0800, Jeremy Schneider wrote:
On 11/25/19 15:05, Jeremy Schneider wrote:
... the cost of doing the individual index lookups across 180
partitions (and 180 indexes) was very high, so they stored max and min
txn id per
76 matches
Mail list logo
