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
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/.*
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
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
>
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.
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
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
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
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
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
>
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
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
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
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 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
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
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,
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
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
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
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.
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
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
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
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
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
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 {
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
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
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 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
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
>
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
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
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
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
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
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
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.
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
>>
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,
>
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
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
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
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
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 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
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
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.
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
> >
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
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
>
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
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
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.
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
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
> 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
>
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
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
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 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
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
> On 04 Jul 2019, at 02:58, Michael Paquier wrote:
>
>> On Wed, Jul 03, 2019 at 08:56:42PM +0200, Daniel Gustafsson wrote:
>> Agreed, I’ve updated the patch with a comment on this formulated such that it
>> should stand the test of time even as OpenSSL changes etc.
>
> I'd like to think that
65 matches
Mail list logo
