On Tue, Jul 02, 2019 at 09:56:03AM +0200, Daniel Gustafsson wrote:
> Looks good, passes tests, provides value to the code. Bumping this to ready
> for committer as I no more comments to add.
Thanks. I have spent more time testing the different error paths and
the new checks in base64.c, and comm
On Wed, Jul 03, 2019 at 08:23:44PM +0200, Julien Rouhaud wrote:
> So the patch compiles and works as intended. I don't have much to say
> about it, it all looks good to me, since the concerns about xactdesc.c
> aren't worth the trouble.
>
> I'm not sure that I understand Michael's objection though
On Wed, Jul 03, 2019 at 04:37:00AM +, osumi.takami...@fujitsu.com wrote:
> I really appreciate your comments.
> Recently, I'm very busy because of my work.
> So, I'll fix this within a couple of weeks.
Please note that I have switched the patch as waiting on author.
--
Michael
signature.asc
On Tue, Jul 02, 2019 at 11:31:49AM -0300, Fabrízio de Royes Mello wrote:
> New version attached.
This looks in pretty good shape to me, and no objections from me to
get those functions as the min() flavor is useful for monitoring WAL
retention for complex deployments.
Do you have a particular use
On Thu, Jul 4, 2019 at 9:45 AM Michael Paquier wrote:
>
> On Wed, Jul 03, 2019 at 08:23:44PM +0200, Julien Rouhaud wrote:
> > So the patch compiles and works as intended. I don't have much to say
> > about it, it all looks good to me, since the concerns about xactdesc.c
> > aren't worth the troubl
> 3 июля 2019 г., в 18:06, Binguo Bao написал(а):
>
> Paul Ramsey 于2019年7月2日周二 下午10:46写道：
> This looks good to me. A little commentary around why
> pglz_maximum_compressed_size() returns a universally correct answer
> (there's no way the compressed size can ever be larger than this
> because..
On Tue, May 28, 2019 at 6:57 AM Amit Langote
wrote:
>
> On 2019/05/27 21:56, Tom Lane wrote:
> > Amit Langote writes:
> >> On 2019/05/24 23:28, Tom Lane wrote:
> >>> So my thought, if we want to do something about this, is not "find
> >>> some things we can pfree at the end of planning" but "find
On 07/01/2019 11:04 AM, Amit Khandekar wrote:
Also, in the updated patch (v11), I have added some scenarios that
verify that slot is dropped when either master wal_level is
insufficient, or when slot is conflicting. Also organized the test
file a bit.
One scenario where replication slot removed
On Wed, Jul 3, 2019 at 12:27 AM David Rowley
wrote:
> On Tue, 2 Jul 2019 at 21:00, Thomas Munro wrote:
> > 2. SELECT i, MIN(j) FROM t GROUP BY i could benefit from this if
> > you're allowed to go forwards. Same for SELECT i, MAX(j) FROM t GROUP
> > BY i if you're allowed to go backwards. Thos
On Tuesday, July 2, 2019 4:59 PM (GMT+9), Masahiko Sawada wrote:
> Thank you for updating the patch. Here is the review comments for v2 patch.
Thank you so much for review!
I indicated the addressed parts below and attached the updated patch.
---
visibilitymap.c: visibilitymap_truncate()
> I don
On 2019-03-25 12:04, Panagiotis Mavrogiorgos wrote:
> Last November snowball added support for Greek language [1]. Following
> the instructions [2], I wrote a patch that adds fulltext search for
> Greek in Postgres. The patch is attached.
I have committed a full sync from the upstream snowball re
On Thu, 4 Jul 2019 at 15:52, tushar wrote:
>
> On 07/01/2019 11:04 AM, Amit Khandekar wrote:
>
> Also, in the updated patch (v11), I have added some scenarios that
> verify that slot is dropped when either master wal_level is
> insufficient, or when slot is conflicting. Also organized the test
> f
On Mon, Jul 1, 2019 at 1:24 PM Thomas Munro wrote:
>
> Another small change/review: the function UndoLogGetNextInsertPtr()
> previously took a transaction ID, but I'm not sure if that made sense,
> I need to think about it some more.
>
The changes you have made related to UndoLogGetNextInsertPtr(
On Thu, 4 Jul 2019 at 17:21, Amit Khandekar wrote:
>
> On Thu, 4 Jul 2019 at 15:52, tushar wrote:
> >
> > On 07/01/2019 11:04 AM, Amit Khandekar wrote:
> >
> > Also, in the updated patch (v11), I have added some scenarios that
> > verify that slot is dropped when either master wal_level is
> > in
In my case, I want to sleep 3 seconds in xxx.sql for pg_regress program.
but I don't want to run 'select pg_sleep(3)' . so it is possible for
pg_regress?
in psql, I can run \! sleep(3); exit;
but looks pg_regress doesn't support it.
The new version of the patch is attached.
This version is even simpler than the previous one,
thanks to the recent btree design changes and all the feedback I received.
I consider it ready for review and testing.
[feature overview]
This patch implements the deduplication of btree non-pivot tuples
On Tue, Jun 25, 2019 at 7:22 PM Tomas Vondra
wrote:
>
> On Tue, Jun 25, 2019 at 04:53:40PM -0400, James Coleman wrote:
> >
> >Unrelated: if you or someone else you know that's more familiar with
> >the parallel code, I'd be interested in their looking at the patch at
> >some point, because I have
On 7/3/19 11:59 PM, Alexander Korotkov wrote:
Hi!
On Wed, Jul 3, 2019 at 5:27 PM Liudmila Mantrova
wrote:
I have rechecked the standard and I agree that we should use "filter
expression" whenever possible.
"A filter expression must be enclosed in parentheses..." looks like an
oversight, so I
On Wed, 5 Jun 2019 at 18:50, Andres Freund wrote:
> Hi,
>
> On 2019-06-05 18:47:57 -0400, Dave Cramer wrote:
> > So one of the things they would like added is to get not null information
> > in the schema record. This is so they can mark the field Optional in
> Java.
> > I presume this would also
On Thu, Jul 4, 2019 at 4:17 AM Michael Paquier wrote:
> Do you have a particular use-case in mind for max() one? I can think
> of at least one case: monitoring the flush LSNs of a set of standbys
> to find out how much has been replayed at most.
It would be pretty silly to have one and not the o
On Wed, Jul 03, 2019 at 07:03:06PM -0700, Jeff Davis wrote:
On Wed, 2019-07-03 at 02:17 +0200, Tomas Vondra wrote:
What does "partitioned hash strategy" do? It's probably explained in
one
of the historical discussions, but I'm not sure which one. I assume
it
simply hashes the group keys and uses
On Thu, Jul 04, 2019 at 09:29:49AM -0400, James Coleman wrote:
On Tue, Jun 25, 2019 at 7:22 PM Tomas Vondra
wrote:
On Tue, Jun 25, 2019 at 04:53:40PM -0400, James Coleman wrote:
>
>Unrelated: if you or someone else you know that's more familiar with
>the parallel code, I'd be interested in the
On 2019-07-02 22:56, Tom Lane wrote:
> I took a look through these and see nothing objectionable. There are
> probably more places that can be improved, but we need not insist on
> getting every such place in one go.
>
> Per Robert's position that variables ought to have well-defined widths,
> th
On 2019-07-02 17:09, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 2019-06-30 14:50, Fabien COELHO wrote:
>>> I'm wondering whether pg_random_uuid() should be taken out of pgcrypto if
>>> it is available in core?
>
>> That would probably require an extension version update dance in
>> pgcrypt
Peter Eisentraut writes:
> I think the alternatives are:
> 1. We keep the code in both places. This is fine. There is no problem
> with having the same C function or the same SQL function name in both
> places.
> 2. We remove the C function from pgcrypto and make an extension version
> bump.
Hi Guys,
Can you please help here?
Below reported issue in past about duplicate key entries for primary key.
https://www.postgresql.org/message-id/534c8b33.9050...@pgexperts.com
the solution was provided in 9.3 version of postgres but it seems issue is
still there in 9.5 version which I am runn
On 2019-Jul-04, Tom Lane wrote:
> A possible option 3 is to keep the function in pgcrypto but change
> its C code to call the core code.
This seems most reasonable, and is what José Luis proposed upthread. We
don't have to bump the pgcrypto extension version, as nothing changes
for pgcrypto exte
Paul Eggert, in https://mm.icann.org/pipermail/tz/2019-June/028172.html:
> zic’s -p option was intended as a transition from historical
> System V code that treated TZ="XXXnYYY" as meaning US
> daylight-saving rules in a time zone n hours west of UT,
> with XXX abbreviating standard time and YYY ab
On Thu, Jul 04, 2019 at 01:37:01PM +, Kumar, Pawan (Nokia - IN/Bangalore)
wrote:
Hi Guys,
Can you please help here?
Below reported issue in past about duplicate key entries for primary key.
https://www.postgresql.org/message-id/534c8b33.9050...@pgexperts.com
the solution was provided in 9
On Thu, Jul 4, 2019 at 10:57 AM Robert Haas wrote:
>
> On Thu, Jul 4, 2019 at 4:17 AM Michael Paquier
wrote:
> > Do you have a particular use-case in mind for max() one? I can think
> > of at least one case: monitoring the flush LSNs of a set of standbys
> > to find out how much has been replaye
On Thu, Jul 4, 2019 at 5:17 AM Michael Paquier wrote:
>
> On Tue, Jul 02, 2019 at 11:31:49AM -0300, Fabrízio de Royes Mello wrote:
> > New version attached.
>
> This looks in pretty good shape to me, and no objections from me to
> get those functions as the min() flavor is useful for monitoring WA
On Thu, Jul 4, 2019 at 5:06 AM Anastasia Lubennikova
wrote:
> i - number of distinct values in the index.
> So i=1 means that all rows have the same key,
> and i=1000 means that all keys are different.
>
> i / old size (MB) / new size (MB)
> 121588
> 100021590
> 100
On Thu, Jul 04, 2019 at 11:10:24AM +0200, Andrey Borodin wrote:
3 июля 2019 г., в 18:06, Binguo Bao написал(а):
Paul Ramsey 于2019年7月2日周二 下午10:46写道：
This looks good to me. A little commentary around why
pglz_maximum_compressed_size() returns a universally correct answer
(there's no way the co
On Thu, Jul 04, 2019 at 05:34:21PM +, Kumar, Pawan (Nokia - IN/Bangalore)
wrote:
Thanks a lot Tomas for the reply.
Which version are you running, exactly? Whih minor version?
[Pawan]: Its (PostgreSQL) 9.5.9
You're missing 2 years of bugfixes, some of which are addressing data
corruption
On Thu, Jul 4, 2019 at 10:46 AM Tomas Vondra
wrote:
>
> On Thu, Jul 04, 2019 at 09:29:49AM -0400, James Coleman wrote:
> >On Tue, Jun 25, 2019 at 7:22 PM Tomas Vondra
> > wrote:
> >>
> >> On Tue, Jun 25, 2019 at 04:53:40PM -0400, James Coleman wrote:
> >> >
> >> >Unrelated: if you or someone else
Of course, I forgot to attach the files, so here they are.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
t.data.gz
Description: application/gzip
(gdb) bt
#0 toast_decompress_datum (attr=0x12572e0) at
Hello Vik,
On 2018-Jun-05, Vik Fearing wrote:
> > I understand that your patch is just to allow defining periods, but I
> > thought I'd share my own hopes earlier rather than later, in case you
> > are doing more work on this.
>
> Yes, I plan on doing much more work on this. My goal is to imple
i am some pullzed by Snapbuild.c
it seem some code can not reach for ever.
SnapBuildCommitTxn
{
//can not reach there
if (builder->state == SNAPBUILD_START ||
(builder->state == SNAPBUILD_BUILDING_SNAPSHOT &&
TransactionIdPrecedes(xid, SnapBuildNextPhaseAt(builder
}
DecodeXactOp {
On Thursday, July 4, 2019 8:04 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
> Hello Vik,
> On 2018-Jun-05, Vik Fearing wrote:
>
>>> I understand that your patch is just to allow defining periods, but I
>>> thought I'd share my own hopes earlier rather than later, in case you
>>> are doing m
I noticed that this patch has a // comment about it segfaulting. Did
you ever figure that out? Is the resulting code the one you intend as
final?
Did you make any inroads regarding Jeff Davis' suggestion about
implementing "multiranges"? I wonder if that's going to end up being a
Pandora's box.
On Thu, Jul 04, 2019 at 06:28:03PM +, Kumar, Pawan (Nokia - IN/Bangalore)
wrote:
Thanks for reply.
This has happened very often and at different production system.
There is no version change. System running with same version since 1 year but
duplicate key issue came quiet a time.
And impac
Hi Nikolay,
I have had a crack at re-basing the current patch against 12b2, but I didn’t
trivially succeed.
It’s probably more my bodged fixing of the rejections than a fundamental
problem. But I now get compile fails in — and seems like only — vacuum.c.
gcc -Wall -Wmissing-prototypes -Wpointe
Hello Vik, Paul,
On 2019-Jul-04, Vik Fearing wrote:
> I've been working on this as an extension instead. It allows me to do some
> stuff in plpgsql which is much easier for me.
>
> https://github.com/xocolatl/periods/
Hmm, okay.
> I would love to have all this in core (especially since Maria
Thanks for reply.
This has happened very often and at different production system.
There is no version change. System running with same version since 1 year but
duplicate key issue came quiet a time.
And impact is big because of that and only way to fix is to delete the
duplicate primary key.
An
Thanks a lot Tomas for the reply.
Which version are you running, exactly? Whih minor version?
[Pawan]: Its (PostgreSQL) 9.5.9
sai=> select version();
version
--
Hello,
The first 2 lc_monetary and lc_numeric are useful if the client for some
reason executes set lc_*. We don't get a report and in many cases can't
continue to parse numerics or money.
Now it it possible to get these at startup by issuing show or querying the
catalog, but it seems much cleaner
On 4/7/19 17:30, Alvaro Herrera wrote:
On 2019-Jul-04, Tom Lane wrote:
A possible option 3 is to keep the function in pgcrypto but change
its C code to call the core code.
This seems most reasonable, and is what José Luis proposed upthread. We
don't have to bump the pgcrypto extension version
On Mon, Jun 03, 2019 at 09:21:48PM +0200, Peter Eisentraut wrote:
> After many years of trying, it seems the -fsanitize=undefined checking
> in gcc is now working somewhat reliably. Attached is a patch that fixes
> all errors of the kind
>
> runtime error: null pointer passed as argument N, which
On Thu, Jul 4, 2019 at 10:38 AM Peter Geoghegan wrote:
> I tried this on my own "UK land registry" test data [1], which was
> originally used for the v12 nbtree work. My test case has a low
> cardinality, multi-column text index. I chose this test case because
> it was convenient for me.
>
> On v1
On Tue, Jul 02, 2019 at 10:38:29AM +0200, Tomas Vondra wrote:
On Sun, Jun 30, 2019 at 08:30:33PM -0400, Tom Lane wrote:
Tomas Vondra writes:
Attached is a slightly improved version of the serialization patch.
I reviewed this patch, and tested it on hppa and ppc. I found one
serious bug: in
Tomas Vondra writes:
> I was about to push into REL_12_STABLE, when I realized that maybe we
> need to do something about the catversion first. REL_12_STABLE is still
> on 201906161, while master got to 201907041 thanks to commit
> 7b925e12703. Simply cherry-picking the commits would get us to
>
On Fri, Mar 22, 2019 at 7:21 AM Shawn Debnath wrote:
>
> On Sat, Mar 16, 2019 at 03:27:17PM -0700, Shawn Debnath wrote:
> > > + * Track the current time so that we can calculate the
> > > remaining timeout
> > > + * if we are woken up spuriously.
> > >
> > > I think tha "track" means chasi
On Thu, Jul 04, 2019 at 08:24:13AM +0200, Daniel Gustafsson wrote:
> LGTM, thanks.
Okay, done, after rechecking the shape of the key. Thanks!
--
Michael
signature.asc
Description: PGP signature
Hi,
> I updated the patch based from comments, but it still fails the regression
> test as indicated in (5) above.
> Kindly verify if I correctly addressed the other parts as what you intended.
>
> Thanks again for the review!
> I'll update the patch again after further comments.
I updated the p
On Sun, Jun 30, 2019 at 8:05 AM Peter Eisentraut
wrote:
> Attached is a very hackish patch to implement this. It works like this:
>
> # (assuming you have a primary already running somewhere)
> initdb -D data2 --minimal
> $EDITOR data2/postgresql.conf # set primary_conninfo
> pg_
On Thu, Jul 04, 2019 at 01:48:24PM -0300, Fabrízio de Royes Mello wrote:
> On Thu, Jul 4, 2019 at 10:57 AM Robert Haas wrote:
>> It would be pretty silly to have one and not the other, regardless of
>> whether we can think of an immediate use case.
>
> +1
OK, applied with a catalog version bump.
On Tue, Jun 25, 2019 at 11:08 PM Peter Eisentraut
wrote:
> For the implementation, I support both backtrace() provided by the OS as
> well as using libunwind. The former seems to be supported by a number
> of platforms, including glibc, macOS, and FreeBSD, so maybe we don't
> need the libunwind s
On Thu, Jul 04, 2019 at 07:44:42PM +0100, Dent John wrote:
> I see that your patch removed that particular type, so I guess that
> feature in vacuum.c has been added in the meantime.
>
> Would you have a more recent patch?
I have switched the patch as waiting on author.
--
Michael
signature.as
On Sun, Jun 30, 2019 at 09:35:52PM +0900, Michael Paquier wrote:
> The refactoring looks good to me (including what you have just fixed
> with PG_RETURN_LSN). Thanks for considering it.
This issue was still listed as an open item for v12, so I have removed
it.
--
Michael
signature.asc
Descripti
On Fri, Jun 28, 2019 at 10:57 PM Surafel Temesgen wrote:
> In addition to the above change in the attached patch i also change
> the syntax to ERROR LIMIT because it is no longer only skip
> unique and exclusion constrain violation
Hi Surafel,
FYI copy.sgml has some DTD validity problems.
https
On Thu, Jun 20, 2019 at 1:51 AM Binguo Bao wrote:
> Hi hackers!
> This proposal aims to provide the ability to de-TOAST a fully TOAST'd and
> compressed field using an iterator and then update the appropriate parts of
> the code to use the iterator where possible instead of de-TOAST'ing and
> d
On Sat, Feb 9, 2019 at 6:16 AM wrote:
> The purpose of this patch is to stop the execution of continuous
> requests in case of a disconnection from the client. In most cases, the
> client must wait for a response from the server before sending new data
> - which means there should not remain unrea
Hi,
I realized that TransactionIdAbort is declared in the transam.h but
there is not its function body. As far as I found there are three
similar functions in total by the following script.
for func in `git ls-files | egrep "\w+\.h$" | xargs cat | egrep
"extern \w+ \w+\(.*\);" | sed -e "s/.* \(.*
Hi
út 2. 7. 2019 v 0:38 odesílatel Jeff Davis napsal:
> On Fri, 2019-05-03 at 15:56 -0700, Paul Jungwirth wrote:
> > Hello,
> >
> > I wrote an extension to add a range_agg function with similar
> > behavior
> > to existing *_agg functions, and I'm wondering if folks would like
> > to
> > have it
On Fri, Jul 5, 2019 at 5:36 PM Thomas Munro wrote:
> On Sat, Feb 9, 2019 at 6:16 AM wrote:
> > The purpose of this patch is to stop the execution of continuous
> > requests in case of a disconnection from the client. In most cases, the
> > client must wait for a response from the server before se
> The purpose of this patch is to stop the execution of continuous
> requests in case of a disconnection from the client.
Pgpool-II already does this by sending a parameter status message to
the client. It is expected that clients are always prepared to receive
the parameter status message. This w
> Regarding apply_scanjoin_target_to_paths in 0001 and 0007, it seems
> like what happens is: we first build an Append path for the topmost
> scan/join rel. That uses paths from the individual relations that
> don't necessarily produce the final scan/join target. Then we mutate
> those relations
> This seems like a reasonable idea to me. There is no point in running
> a monster 24 hour OLAP query if your client has gone away. It's using
> MSG_PEEK which is POSIX, and I can't immediately think of any reason
> why it's not safe to try to peek at a byte in that socket at any time.
I am not
On 2019-04-12 17:51, Fabien COELHO wrote:
> Hmmm. I obviously agree that PQexec is beyond awkward.
>
> Now I'm not sure how anyone is expected to guess the actual function
> working from the available documentation, and without this knowledge I
> cannot see how to write meaningful code for the m
69 matches
Mail list logo
