On Wed, Mar 28, 2018 at 02:13:19PM +1030, Andrew Dunstan wrote:
> On Wed, Mar 28, 2018 at 12:57 PM, Michael Paquier wrote:
>> Something that would address the issue would be to enforce a segment
>> switch after each checkpoint, but that's a high price to pay on mostly
>> idle systems with large WA
>> I found the previous patch was broken and this can't handle
>> views that has subqueries as bellow;
>>
>> CREATE VIEW lock_view6 AS SELECT * from (select * from lock_tbl1) sub;
>>
>> I fixed this and attached the updated version including additional tests.
>
> This patch gives a warning whil
> On Tue, 27 Mar 2018 23:28:04 +0900
> Yugo Nagata wrote:
>
> I found the previous patch was broken and this can't handle
> views that has subqueries as bellow;
>
> CREATE VIEW lock_view6 AS SELECT * from (select * from lock_tbl1) sub;
>
> I fixed this and attached the updated version includin
At Tue, 27 Mar 2018 22:02:26 +0900, Michael Paquier wrote
in <20180327130226.ga1...@paquier.xyz>
> On Tue, Mar 27, 2018 at 09:01:20PM +0900, Kyotaro HORIGUCHI wrote:
> > The current UpdateFullPageWrites is safe on standby and promotion
> > so what we should consider is only the non-standby case.
On Wed, Mar 28, 2018 at 03:41:33PM +1100, Haribabu Kommi wrote:
> On Wed, Mar 28, 2018 at 12:54 PM, Michael Paquier
> wrote:
> Updated patch attached.
Thanks, switched as ready for committer.
--
Michael
signature.asc
Description: PGP signature
On Tue, Mar 27, 2018 at 04:21:09PM -0400, David Steele wrote:
> These updates address Michael's latest review and implement group access
> for pg_basebackup, pg_receivewal, and pg_recvlogical. A new internal
> GUC, data_directory_group_access, allows remote processes to determine
> the correct mod
On Wed, Mar 28, 2018 at 12:54 PM, Michael Paquier
wrote:
> On Wed, Mar 28, 2018 at 11:28:32AM +1100, Haribabu Kommi wrote:
> > I updated the pg_stat_wal_receiver patch with the new PQhost() function
> > behavior and updated the view with two columns, (remote_server and
> > remote_port) instead of
On Wed, Mar 28, 2018 at 8:28 AM, Peter Geoghegan wrote:
> On Tue, Mar 27, 2018 at 2:28 AM, Pavan Deolasee
> wrote:
> > (Version 26)
>
> I have some feedback on this version:
>
> * ExecMergeMatched() needs to determine tuple lock mode for
> EvalPlanQual() in a way that's based on how everything e
On Tue, Mar 27, 2018 at 2:23 AM, Kyotaro HORIGUCHI
wrote:
>> > If no one objects, I'll mark this as Ready for Commit in a couple
>> > of days.
>>
>> Thank you for the review, Horiguchi-san. It's hard to decide how
>> important each goal is when coming up with a back-patchable fix like
>> this. Whe
On 27 March 2018 at 23:42, Amit Langote wrote:
> I have managed to make the recursion go away in the attached updated
> version. I guess that's the result of employing the idea of a "output
> register" for individual pruning steps as mentioned in Robert's email
> upthread where he detailed the "p
On Wed, Mar 28, 2018 at 7:36 AM, Michael Paquier
wrote:
> On Tue, Mar 27, 2018 at 02:02:10PM -0400, Tom Lane wrote:
>
> >
> > Well, the point of checkpoints is that WAL data before the last one
> > should no longer matter anymore, isn't it?
>
> I have to agree with Tom here. If you force pg_rewi
Craig Ringer writes:
> TL;DR: Pg should PANIC on fsync() EIO return.
Surely you jest.
> Retrying fsync() is not OK at
> least on Linux. When fsync() returns success it means "all writes since the
> last fsync have hit disk" but we assume it means "all writes since the last
> SUCCESSFUL fsync hav
On Wed, Mar 28, 2018 at 12:57 PM, Michael Paquier wrote:
> On Tue, Mar 27, 2018 at 10:09:59PM -0400, Robert Haas wrote:
>>> I have to agree with Tom here. If you force pg_rewind to replay more
>>> WAL records from a checkpoint older than the checkpoint prior to where
>>> WAL has forked at promoti
Tomas Vondra writes:
> On 03/27/2018 04:51 AM, David Rowley wrote:
>> Seems I didn't mean "trans types". I should have said aggregate
>> function argument types.
> I'm not sure that's better than the check proposed by Tom. An argument
> type without send/receive function does not necessarily mean
On Tue, 27 Mar 2018 23:28:04 +0900
Yugo Nagata wrote:
I found the previous patch was broken and this can't handle
views that has subqueries as bellow;
CREATE VIEW lock_view6 AS SELECT * from (select * from lock_tbl1) sub;
I fixed this and attached the updated version including additional tests
On Tue, Mar 27, 2018 at 2:28 AM, Pavan Deolasee
wrote:
> (Version 26)
I have some feedback on this version:
* ExecMergeMatched() needs to determine tuple lock mode for
EvalPlanQual() in a way that's based on how everything else works;
it's not okay to just use LockTupleExclusive in all cases. Th
On Mon, Mar 12, 2018 at 12:43:20PM -0400, Tom Lane wrote:
> Another fundamental problem is that implicit casts mask mistakes.
> If there's an implicit cast to numeric, that applies everywhere not
> only where it was what you meant. For some context on this you might
> go back to the archives aroun
On Tue, Mar 27, 2018 at 10:09:59PM -0400, Robert Haas wrote:
>> I have to agree with Tom here. If you force pg_rewind to replay more
>> WAL records from a checkpoint older than the checkpoint prior to where
>> WAL has forked at promotion then you have a risk of losing data.
>
> Oh! I see now. G
On Wed, Mar 28, 2018 at 04:45:49AM +0900, Fujii Masao wrote:
> The patch looks good to me! Barring objection, I will commit it
> and back-patch to 9.5 where pg_rewind was added.
Thanks in advance! I just eyeballed the patch again and I don't see
issues with what's used here. The thing should app
Hi all
Some time ago I ran into an issue where a user encountered data corruption
after a storage error. PostgreSQL played a part in that corruption by
allowing checkpoint what should've been a fatal error.
TL;DR: Pg should PANIC on fsync() EIO return. Retrying fsync() is not OK at
least on Linux
On Tue, Mar 27, 2018 at 06:32:08PM -0400, Chapman Flack wrote:
> Is 2dd9322 a commit? I'm having difficulty finding it:
>
> https://git.postgresql.org/gitweb/?p=postgresql.git&a=search&h=HEAD&st=commit&s=2dd9322
>
> Am I searching wrong?
>
> I probably won't have more time to look at this tonigh
On Tue, Mar 27, 2018 at 10:06 PM, Michael Paquier wrote:
> On Tue, Mar 27, 2018 at 02:02:10PM -0400, Tom Lane wrote:
>> Robert Haas writes:
>>> On Tue, Mar 27, 2018 at 11:41 AM, Tom Lane wrote:
This is ignoring the possibility of damaged data in between, ie
A ... B ... CHKPT ... C ...
On Tue, Mar 27, 2018 at 02:02:10PM -0400, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 27, 2018 at 11:41 AM, Tom Lane wrote:
>>> This is ignoring the possibility of damaged data in between, ie
>>> A ... B ... CHKPT ... C ... a few zeroed pages ... D ... CHKPT ... E ... F
>
>> It's hard
On Wed, Mar 28, 2018 at 11:28:32AM +1100, Haribabu Kommi wrote:
> I updated the pg_stat_wal_receiver patch with the new PQhost() function
> behavior and updated the view with two columns, (remote_server and
> remote_port) instead of three as earlier.
>
> Updated patch attached.
Thanks Hari for th
On Wed, Mar 28, 2018 at 11:06:23AM +1100, Haribabu Kommi wrote:
> On Wed, Mar 28, 2018 at 3:35 AM, Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
>>
>> Committed after fixing up the documentation a bit as suggested by others.
>
> Thanks.
+1. Thanks for working on this Hari, Peter
Fujita-san,
On 2018/03/27 22:00, Etsuro Fujita wrote:
> Hi,
>
> While updating the tuple-routing-for-foreign-partitions patch, I noticed
> oddity in the COPY FROM handling of check constraints on partition
> tables. Here is an example:
>
> postgres=# create table pt (a int, b int) partition by
On 2018-03-27 10:19:37 +0100, Simon Riggs wrote:
> On 23 March 2018 at 15:26, Simon Riggs wrote:
>
> > Reviewing 0003-Add-support-for-logging-GID-in-commit-abort-WAL-reco
> >
> > Looks fine, reworked patch attached
> > * added changes to xact.h from patch 4 so that this is a whole,
> > committabl
On 03/24/2018 03:14 PM, Peter Eisentraut wrote:
> On 3/22/18 11:50, Tomas Vondra wrote:
>
>> 2) spi.c
>>
>> I generally find it confusing when there are negative flags, which are
>> then negated whenever used. That is pretty the "no_snapshots" case,
>> because it means "don't manage snapshots" a
On 03/27/2018 07:34 PM, Tomas Vondra wrote:
> On 03/27/2018 07:03 PM, Dean Rasheed wrote:
>> On 27 March 2018 at 14:58, Dean Rasheed wrote:
>>> On 27 March 2018 at 01:36, Tomas Vondra
>>> wrote:
4) handling of NOT clauses in MCV lists (and in histograms)
The query you posted doe
On Tue, Jan 30, 2018 at 4:02 PM, Michael Paquier
wrote:
> On Tue, Jan 30, 2018 at 03:10:12PM +1100, Haribabu Kommi wrote:
> > Ok, understood. As the libpq gives preference to hostaddr connection
> > parameter than host while connecting. How about going with one column
> > "remote_host" that displ
On Wed, Mar 28, 2018 at 1:21 AM, Pavan Deolasee
wrote:
>
>
> TBH I still don't see why this does not provide the same guarantee that the
> current code provides, but given the concerns expressed by others, I am not
> gonna pursue beyond a point. But one last time :-)
>
> The current code uses xl_p
On 03/28/2018 12:32 AM, Chapman Flack wrote:
> On 03/26/18 01:43, Michael Paquier wrote:
>
>> Have a look at BKP_REMOVABLE then. This was moved to page headers in
>> 2dd9322, still it seems to me that the small benefits outlined on this
>> thread don't justify breaking tools relying on this fla
On 03/27/2018 04:51 AM, David Rowley wrote:
> On 27 March 2018 at 13:45, David Rowley wrote:
>> On 27 March 2018 at 12:49, Tom Lane wrote:
>>> Oh, I thought of another thing that would need to get done, if we decide
>>> to commit this. array_agg_serialize/deserialize only work if the array
>>>
On Wed, Mar 28, 2018 at 3:35 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 3/27/18 02:20, Michael Paquier wrote:
> > On Tue, Mar 27, 2018 at 04:47:41PM +1100, Haribabu Kommi wrote:
> >> updated patch attached with additional doc updates as per the suggestion
> >> from the up
Peter Eisentraut writes:
> How about this one as well:
> portal->portalContext = AllocSetContextCreate(TopPortalContext,
> "PortalContext",
> ALLOCSET_SMALL_SIZES);
> + MemoryContextCopySetId
On 3/27/18 12:47, Tom Lane wrote:
> Here's an updated patch that adjusts the output format per discussion:
>
> - context identifier at the end of the line, so it's easier to see the
> numbers
>
> - identifiers truncated at 100 bytes, control characters replaced by
> spaces
>
> Also, I hacked
On Wed, Mar 28, 2018 at 8:32 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>>> pgindent already has a list of blacklisted typedefs (see lines 121 to 123)
>
> Oh, so it does.
>
>> Here's a patch to pgindent which I think will do what you want fairly
>> simply, assuming you have identified all the o
On Wed, Mar 28, 2018 at 04:13:25AM +0900, Fujii Masao wrote:
> This code is almost ok in practice, but using the check of
> "strstr(path, localpath) == path" is more robust here?
No problems with that either.
> Using the following code instead is more robust?
> This original code is almost ok in
On Tue, Mar 27, 2018 at 10:14 AM, Teodor Sigaev wrote:
>> b) I don't like an idea to limiting usage of that field if we can do not
>> that. Future usage could use it, for example, for different compression
>> technics or something else.Or even removing t_tid from inner tuples to save
>> 2 bytes in
select websearch_to_tsquery('simple', 'abc or!def');
websearch_to_tsquery
--
'abc' | 'def'
(1 row)
This is wrong ofc, I've attached the fixed version.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/src/backend/ts
On 03/26/18 01:43, Michael Paquier wrote:
> Have a look at BKP_REMOVABLE then. This was moved to page headers in
> 2dd9322, still it seems to me that the small benefits outlined on this
> thread don't justify breaking tools relying on this flag set, especially
> if there is no replacement for it.
Hi everyone,
I'd like to share some intermediate results. Here's what has changed:
1. OR operator is now case-insensitive. Moreover, trailing whitespace is
no longer used to identify it:
select websearch_to_tsquery('simple', 'abc or');
websearch_to_tsquery
--
'abc' & 'o
Andrew Dunstan writes:
>> pgindent already has a list of blacklisted typedefs (see lines 121 to 123)
Oh, so it does.
> Here's a patch to pgindent which I think will do what you want fairly
> simply, assuming you have identified all the offending tokens.
Hm, this does not work for me (with perl
On Tue, Mar 27, 2018 at 6:48 AM, Pavan Deolasee
wrote:
> + * When index-to-heap verification is requested, a Bloom filter is used to
> + * fingerprint all tuples in the target index, as the index is traversed to
> + * verify its structure. A heap scan later verifies the presence in the
> heap
> +
On 3/20/18 11:14 PM, Michael Paquier wrote:
> On Tue, Mar 20, 2018 at 05:44:22PM -0400, Stephen Frost wrote:
>> * David Steele (da...@pgmasters.net) wrote:
>>> On 3/16/18 11:12 AM, Stephen Frost wrote:
>>> It seems to me that pg_basebackup and pg_receivexlog should have a -g
>>> option to control t
On Sun, Mar 11, 2018 at 11:04 PM, Michael Paquier wrote:
> On Fri, Mar 09, 2018 at 08:22:49AM +, Tsunakawa, Takayuki wrote:
>> Thanks for reviewing. All done.
>
> Thanks. Please be careful with the indentation of the patch. Attached
> is a slightly-updated version with a small modification
On Tue, Mar 27, 2018 at 10:55 AM, Michael Paquier wrote:
> On Tue, Mar 27, 2018 at 01:32:41AM +0900, Fujii Masao wrote:
>> +1. It's better for us to focus on the code change of the fillter on
>> pg_rewind
>> rather than such "refactoring".
>
> (filter takes one 'l', not two)
>
> Okay. I had my m
On 23 March 2018 at 15:54, Simon Riggs wrote:
> So please could you make the change?
Committed, but I still think that change would be good.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi,
On 03/27/2018 01:46 PM, Jesper Pedersen wrote:
Running v41 with "partition_prune" under valgrind gives the attached
report.
The reports mostly involve interaction with catcache.c and dynahash.c,
so something for a separate thread.
Best regards,
Jesper
Colleagues incomprehensible situation:
it seems that the statistics for autovacuum analyze is not passed to the
slave.
After a manual run, vacuum analyze all comes to life.
the essence of this is a frequently changing table when I request a replica
I get on a big Heap Fetches: 18623
the request is
Hello,
I notice Explain report wrong counters with parallel plans :
create unlogged table t1 (c1 int);
insert into t1 select generate_series(1,1);
vacuum t1;
(stop PG, drop caches,start)
set track_io_timing to on;
explain (analyze,buffers) select count(*) from t1;
2018-03-27 11:35 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> I'd like to convince you to compromise, because otherwise I'm afraid we
> will not get this feature.
>
> 1. use special default string for formats that doesn't field sep - like
>>>
"not used" or some
2. I can implemet the op
On Tue, Mar 27, 2018 at 1:15 AM, Simon Riggs wrote:
> Accepted, the only question is whether it affects UPDATE as well cos
> it looks like it should.
If you mean an UPDATE FROM self-join, then I suppose that it does, in
a very limited way. The difference is that there are no hard-coded
assumption
Alvaro Herrera writes:
> Amit Langote wrote:
>> [Jesper] also pointed out a case with a
>> list-partitioned table where pruning doesn't a produce a result as one
>> would expect and what constraint exclusion would produce.
>>
>> create table lp (a char) partition by list (a);
>> create table lp_a
Robert Haas writes:
> On Tue, Mar 27, 2018 at 11:41 AM, Tom Lane wrote:
>> This is ignoring the possibility of damaged data in between, ie
>> A ... B ... CHKPT ... C ... a few zeroed pages ... D ... CHKPT ... E ... F
> It's hard for me to believe that this case matters very much. If
> you're t
Amit Langote wrote:
> [Jesper] also pointed out a case with a
> list-partitioned table where pruning doesn't a produce a result as one
> would expect and what constraint exclusion would produce.
>
> create table lp (a char) partition by list (a);
> create table lp_ad partition of lp for values in
On Tue, Mar 27, 2018 at 11:41 AM, Tom Lane wrote:
> Pavan Deolasee writes:
>> On Tue, Mar 27, 2018 at 7:28 PM, Tom Lane wrote:
>>> If you have to search backwards, this breaks it. Full stop.
>
>> We don't really need to fetch the previous record. We really need to find
>> the last checkpoint pr
Hi Amit,
On 03/27/2018 06:42 AM, Amit Langote wrote:
I have managed to make the recursion go away in the attached updated
version. I guess that's the result of employing the idea of a "output
register" for individual pruning steps as mentioned in Robert's email
upthread where he detailed the "p
On 03/27/2018 04:58 PM, Dean Rasheed wrote:
> On 27 March 2018 at 01:36, Tomas Vondra wrote:
>> BTW I think there's a bug in handling the fullmatch flag - it should not
>> be passed to AND/OR subclauses the way it is, because then
>>
>> WHERE a=1 OR (a=2 AND b=2)
>>
>> will probably set it t
On 2018-03-27 10:05:47 -0400, Peter Eisentraut wrote:
> On 3/13/18 19:40, Andres Freund wrote:
> > I've pushed a revised and rebased version of my JIT patchset.
>
> What is the status of this item as far as the commitfest is concerned?
7/10 committed. Inlining, Explain, Docs remain.
Greetings,
On 03/27/2018 07:03 PM, Dean Rasheed wrote:
> On 27 March 2018 at 14:58, Dean Rasheed wrote:
>> On 27 March 2018 at 01:36, Tomas Vondra wrote:
>>> 4) handling of NOT clauses in MCV lists (and in histograms)
>>>
>>> The query you posted does not fail anymore...
>>>
>> Ah, it turns out the previous
On 03/27/2018 04:58 PM, Tom Lane wrote:
> David Rowley writes:
>> On 27 March 2018 at 13:26, Alvaro Herrera wrote:
>>> synchronized_seqscans is another piece of precedent in the area, FWIW.
>
>> This is true. I guess the order of aggregation could be made more
>> certain if we remove the cost b
On Tue, Mar 27, 2018 at 7:42 AM, Robert Haas wrote:
> On Tue, Mar 27, 2018 at 1:45 AM, Amit Kapila wrote:
>> If we don't want to go with the upperrel logic, then maybe we should
>> consider just merging some of the other changes from my previous patch
>> in 0003* patch you have posted and then se
Alvaro Herrera writes:
> My only gripe is the pattern where the identifier needs to be
> re-installed when resetting the context. I don't think we need to hold
> push for that reason alone, but I bet we'll be revisiting that.
Yeah, that's slightly annoying; if I'd found more than one case of tha
On Tue, Mar 27, 2018 at 11:17 AM, Tom Lane wrote:
> So, your proposal is to do nothing and just hope we don't make the same
> mistake again in future?
That wasn't really my proposal, but if it were, it would be at least
as good as your proposal of making changing things in an unprincipled
fashion
On Tue, Mar 27, 2018 at 10:07 AM, Teodor Sigaev wrote:
> Storing number of attributes in now unused t_tid seems to me not so good
> idea. a) it could (and suppose, should) separate patch, at least it's not
> directly connected to covering patch, it could be added even before covering
> patch.
I t
b) I don't like an idea to limiting usage of that field if we can do not that.
Future usage could use it, for example, for different compression technics or
something else.Or even removing t_tid from inner tuples to save 2 bytes in IndexTupleData. Of
course, I remember about aligment, but it co
Great stuff.
My only gripe is the pattern where the identifier needs to be
re-installed when resetting the context. I don't think we need to hold
push for that reason alone, but I bet we'll be revisiting that.
I suppose this infrastructure can be used to implement the idea in
https://www.postgre
The last time I looked at this patch, in April 2017, I made the point
that we should add something like an "nattributes" argument to
index_truncate_tuple() [1], rather than always using
IndexRelationGetNumberOfKeyAttributes() within index_truncate_tuple().
Agree, it looks logical because a) readin
On 27 March 2018 at 14:58, Dean Rasheed wrote:
> On 27 March 2018 at 01:36, Tomas Vondra wrote:
>> 4) handling of NOT clauses in MCV lists (and in histograms)
>>
>> The query you posted does not fail anymore...
>>
> Ah, it turns out the previous query wasn't actually failing for the
> reason I th
>
>
> I'm rapidly losing interest. Unless this goes back toward the concrete and
> practical I think it's going nowhere.
Your message is exactly what I was hoping for. Thanks for your guidance and
support, really appreciate you.
Let me now get busy and earn your continued interest and suppo
On 3/27/18 02:20, Michael Paquier wrote:
> On Tue, Mar 27, 2018 at 04:47:41PM +1100, Haribabu Kommi wrote:
>> updated patch attached with additional doc updates as per the suggestion
>> from the upthreads.
>
> Thanks Hari for the quick update. It looks to me that this is shaped as
> suggested. A
Pavan Deolasee writes:
> On Tue, Mar 27, 2018 at 7:28 PM, Tom Lane wrote:
>> If you have to search backwards, this breaks it. Full stop.
> We don't really need to fetch the previous record. We really need to find
> the last checkpoint prior to a given LSN. That can be done by reading WAL
> segm
Simon Riggs writes:
> On 27 March 2018 at 14:58, Tom Lane wrote:
>> The point of the xl_prev links is, essentially, to allow verification
>> that we are reading a coherent series of WAL records, ie that record B
>> which appears to follow record A actually is supposed to follow it.
>> This throws
Robert Haas writes:
> On Mon, Mar 26, 2018 at 7:23 PM, Tom Lane wrote:
>> While the minimal patch would be fine for now, what I'm worried about
>> is preventing future mistakes. It seems highly likely that the reason
>> binary_upgrade_create_empty_extension is marked 'r' is that somebody
>> copi
Attached 14th version of the patches:
* refactored predicates, introduced 3-valued JsonPathBool type instead of
JsonPathExecResult
* refactored JsonPathExecResult: now it is typedefed to ErrorData *
* fixed recursive wildcard accessor (.**) in strict mode: structural errors
after .** are
Hi!
I took a look on patch and it seems to me it looks both incomplete and
oveflowing. It suggests cast from numeric and bool, but for numeric it suggests
only numeric, int4 and int8. This choice looks irrational.
I think, it should support from/to numeric/bool/text only. If we want to have
David Rowley writes:
> On 27 March 2018 at 13:26, Alvaro Herrera wrote:
>> synchronized_seqscans is another piece of precedent in the area, FWIW.
> This is true. I guess the order of aggregation could be made more
> certain if we remove the cost based optimiser completely, and just
> rely on a s
Hello!
I have attached the project proposal to develop the PostgreSQL
Performance Farm Website for GSOC 2018 with this email. Please review
my proposal.
Thanks!
Regards,
Ravindu Perera
GSOC 2018 Project Proposal - Performance Farm Web Application.pdf
Description: Adobe PDF document
On 27 March 2018 at 01:36, Tomas Vondra wrote:
> BTW I think there's a bug in handling the fullmatch flag - it should not
> be passed to AND/OR subclauses the way it is, because then
>
> WHERE a=1 OR (a=2 AND b=2)
>
> will probably set it to 'true' because of (a=2 AND b=2). Which will
> short-
Peter Eisentraut wrote:
> Since the row triggers patch has been committed, do you plan to send an
> update on this patch?
Yes, I'll do that shortly.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hello everyone,
> Since this patch was updated after being set a Ready for Committer and
> there appear to be some open questions, I have set it to Needs Review.
I decided to take a look.
The patch didn't apply after changes made in fd1a421f, but I fixed that.
Also there were no tests. I fixed t
On Tue, Mar 27, 2018 at 7:28 PM, Tom Lane wrote:
>
>
> I had not noticed that in the kerfuffle over the more extreme version,
> but I think this is a different route to breaking the same guarantees.
> The point of the xl_prev links is, essentially, to allow verification
> that we are reading a co
On 27 March 2018 at 14:58, Tom Lane wrote:
> The point of the xl_prev links is, essentially, to allow verification
> that we are reading a coherent series of WAL records, ie that record B
> which appears to follow record A actually is supposed to follow it.
> This throws away that cross-check jus
On 3/11/18 22:40, Alvaro Herrera wrote:
> [ Resending an email from yesterday. Something is going very wrong with
> my outgoing mail provider :-( ]
>
> Rebase of the prior code, on top of the improved row triggers posted
> elsewhere. I added some more tests too, and fixed a couple of small
> bug
Tom Lane wrote:
>> -Maybe document examples of how to do bulk-editing of data files?
>
> +1. In the end, that's the reason we're doing all this work, so showing
> people how to benefit seems like a good thing.
I'll hold off on posting a new patchset until I add this to the
documentation, but I w
On Tue, 6 Feb 2018 11:12:37 -0500
Robert Haas wrote:
> On Tue, Feb 6, 2018 at 1:28 AM, Tatsuo Ishii wrote:
> >> But what does that have to do with locking?
> >
> > Well, if the view is not updatable, I think there will be less point
> > to allow to lock the base tables in the view because lockin
Tom Lane wrote:
> Tomas Vondra writes:
> > I think number of index tuples makes sense, as long as that's what the
> > costing needs. That is, it's up to the index AM to define it. But it
> > clearly should not flap like this ...
>
> > And it's not just BRIN. This is what I get with a GIN index:
>
Markus Winand wrote:
Hi Markus,
> I’ve found two issues with XML/XPath integration in PostgreSQL. Two
> patches are attached. I’ve just separated them because the second one
> is an incompatible change.
Thanks for these. I'll have a look at them after the commitfest is
over. In the meantime, i
Tomas Vondra writes:
> I think number of index tuples makes sense, as long as that's what the
> costing needs. That is, it's up to the index AM to define it. But it
> clearly should not flap like this ...
> And it's not just BRIN. This is what I get with a GIN index:
Sounds like the same kind of
> On 27 Mar 2018, at 15:04, Arthur Zakirov wrote:
> But the patch breaks options parsing in another place. After the patch:
> So the right fix could be as it done in postgres_fdw_validator() for
> 'fetch_size' option.
Doh. I had a strtol() first but found the defGetInt32() version elegantly
sm
On 3/13/18 19:40, Andres Freund wrote:
> I've pushed a revised and rebased version of my JIT patchset.
What is the status of this item as far as the commitfest is concerned?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training &
On 27 March 2018 at 01:36, Tomas Vondra wrote:
> 4) handling of NOT clauses in MCV lists (and in histograms)
>
> The query you posted does not fail anymore...
>
Ah, it turns out the previous query wasn't actually failing for the
reason I thought it was -- it was failing because it had a
ScalarArr
Robert Haas writes:
> Taking a look at this version, I think the key thing we have to decide
> is whether we're comfortable with this:
> --- a/src/include/access/xlogrecord.h
> +++ b/src/include/access/xlogrecord.h
> @@ -42,7 +42,7 @@ typedef struct XLogRecord
> {
> uint32 xl_tot_len;
Hi,
The Release Management Team (RMT) for the PostgreSQL 11 release
has been assembled and has determined that the feature freeze date
for the PostgreSQL 11 release will be April 7, 2018. This means that any
feature that will be going into the PostgreSQL 11 release must be
committed before 2018-04
On Tue, Mar 27, 2018 at 8:50 AM, Peter Geoghegan wrote:
> On Fri, Mar 23, 2018 at 7:13 AM, Andrey Borodin
> wrote:
> > I've just flipped patch to WoA. But if above issues will be fixed I
> think that patch is ready for committer.
>
> Attached is v7, which has the small tweaks that you suggested.
Thank you, pushed
David Steele wrote:
On 3/26/18 1:06 PM, Stephen Frost wrote:
* Teodor Sigaev (teo...@sigaev.ru) wrote:
Will autovacuum (or something else) complain about absense of relfile during
orphan table deleting? I mean, you get a base backup without temp tables,
then you try to run p
Hello everyone,
I would like to let you know that unfortunately these patches don't apply
anymore. Also personally I'm a bit confused by the last message that has 0001-
and 0003- patches attached but not the 0002- one.
Attached patch fixes two very minor typos in pgbench recently added
documentations:
- one about the mod() function
- two about the hash() function
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 41d9030..e4b37dd 100644
--- a/doc/src/sgml/ref/pgben
On Tue, Mar 27, 2018 at 01:17:20PM +0200, Daniel Gustafsson wrote:
> I recently had a usecase for dict_int, typoed my script and spent longer than
> I’d like to admit finding said typo. The attached patch scratches my itch by
> ensuring that the maxlen parameter to dict_int is integer, instead of
1 - 100 of 139 matches
Mail list logo
