On Fri, Jun 12, 2020 at 6:11 PM Magnus Hagander wrote:
>
> On Fri, Jun 12, 2020 at 10:23 AM Amit Kapila wrote:
>>
>
>
> The problem with "lifetime of a process" is that it's not predictable. A
> replication process might "bounce" for any reason, and it is normally not a
> problem. But if you
On Fri, Jun 12, 2020 at 6:24 PM Masahiko Sawada
wrote:
>
> On Fri, 12 Jun 2020 at 19:24, Amit Kapila wrote:
> >
> > > > Which are these other online transactions? I had assumed that foreign
> > > > transaction resolver process is to resolve in-doubt transactions but
> > > > it seems it is also
On Fri, Jun 12, 2020 at 10:13:41PM -0400, Tom Lane wrote:
> On second thought, contrib/ is not quite the right place, because we
> typically expect modules there to actually get installed, meaning they
> have to have at least some end-user usefulness. The right place for
> a toy PL handler is
On Fri, Jun 12, 2020 at 4:57 PM Ashutosh Sharma wrote:
>
> Hi All,
>
> I've spent little bit of time going through the project discussion that has
> happened in this email thread and to start with I have few questions which I
> would like to put here:
>
> Q1) Are we also planning to read the
so 13. 6. 2020 v 1:28 odesílatel Andres Freund napsal:
> Hi,
>
> Currently using EXPLAIN (ANALYZE) without TIMING OFF regularly changes
> the resulting timing enough that the times aren't meaningful. E.g.
>
> CREATE TABLE lotsarows(key int not null);
> INSERT INTO lotsarows SELECT
Mark Wong writes:
> On Fri, Jun 12, 2020 at 03:10:20PM -0400, Tom Lane wrote:
>> I wonder if it'd be possible to adapt what you have here into some
>> tiny contrib module that doesn't do very much useful, but can at
>> least be tested to see that it compiles; moreover it could be
>> copied
On 06/12/20 16:17, Chapman Flack wrote:
> reason. Typically that reason is that it has been placed in a file that
> can only be edited by the admin who decides what certs to trust. By
> editing it into that file, that responsible person has vouched for it,
> and /that/ is why the TLS client should
On Fri, Jun 12, 2020 at 06:15:36PM +0900, Dong Wook Lee wrote:
> Oh, now I understand. and I added a test of --row-per-insert option.
That's more of an habit to look around, find similar patterns and the
check if these are covered.
I have applied your patch, and you may want to be careful about
On Thu, 11 Jun 2020 at 18:52, Andrew Gierth wrote:
>
> > "David" == David Rowley writes:
>
> David> Pending any objections, I'd like to push both of these patches
> David> in the next few days to master.
>
> For the second patch, can we take the opportunity to remove the
> extraneous blank
Hi,
On 2020-06-13 01:06:25 +0200, Tomas Vondra wrote:
> I agree, we should revert 4cad2534da and only project tuples when we
> actually need to spill them.
There are cases where projecting helps for non-spilling aggregates too,
but only for the representative tuple. It doesn't help in the case
Hi,
Currently using EXPLAIN (ANALYZE) without TIMING OFF regularly changes
the resulting timing enough that the times aren't meaningful. E.g.
CREATE TABLE lotsarows(key int not null);
INSERT INTO lotsarows SELECT generate_series(1, 5000);
VACUUM FREEZE lotsarows;
-- best of three:
SELECT
On Fri, Jun 12, 2020 at 03:29:08PM -0700, Jeff Davis wrote:
On Fri, 2020-06-12 at 14:37 -0700, Andres Freund wrote:
I don't see why it's ok to force an additional projection in the very
common case of hashaggs over a few rows. So I think we need to
rethink
4cad2534da6.
One possibility is to
On Thu, 11 Jun 2020 at 18:52, Andrew Gierth wrote:
> For the second patch, can we take the opportunity to remove the
> extraneous blank line at the top of pg_ltoa, and add the two missing
> "extern"s in builtins.h for pg_ultoa_n and pg_ulltoa_n ?
I think since we've branched for PG14 now that
On Fri, Jun 12, 2020 at 03:10:20PM -0400, Tom Lane wrote:
> Mark Wong writes:
> > Would some additional procedure language handler code examples in the
> > documentation be good to add? I've put some together in the attached
> > patch, and can log it to a future commitfest if people think it
On Fri, 2020-06-12 at 14:37 -0700, Andres Freund wrote:
> I don't see why it's ok to force an additional projection in the very
> common case of hashaggs over a few rows. So I think we need to
> rethink
> 4cad2534da6.
One possibility is to project only spilled tuples, more similar to
Melanie's
Em sex., 12 de jun. de 2020 às 15:15, Ranier Vilela
escreveu:
> Posgres13_beta1, is consistently writing to the logs, "could not rename
> temporary statistics file".
> When analyzing the source that writes the log, I simplified the part that
> writes the logs a little.
>
> 1. I changed from if
Hi,
On 2020-06-11 11:14:02 -0700, Jeff Davis wrote:
> On Thu, 2020-06-11 at 10:45 -0700, Andres Freund wrote:
> > Did you run any performance tests?
>
> Yes, I reproduced your ~12% regression from V12, and this patch nearly
> eliminated it for me.
I spent a fair bit of time looking at the
Hello Bruce.
The question is what should be put in the protocol, and I would tend to
think that some careful design time should be put in it.
I still don't see the value of this vs. its complexity.
Dunno. I'm looking for the value of having such a thing in core.
ISTM that there are no
Hello Masahiko-san,
Summarizing the discussed points so far, I think that the major
advantage points of your idea comparing to the current patch's
architecture are:
* More secure. Because it never loads KEK in postgres processes we can
lower the likelihood of KEK leakage.
Yes.
* More
On 06/12/20 15:13, Bruce Momjian wrote:
> On Wed, Jun 3, 2020 at 07:57:16PM -0400, Chapman Flack wrote:
>> here is a root.crt file for libpq containing only this exact cert, I
>> want libpq to connect only ever to this server with this cert and nothing
>> else. It's a pain because I have to roll
Robert Haas writes:
> On Fri, Jun 12, 2020 at 2:14 PM Tom Lane wrote:
>> Robert Haas writes:
>>> BTW, has there been any thought to supporting a negative scale for the
>>> numeric data type? If you can cut off digits after the decimal, why
>>> not before?
>> Hm, would there be any real
I wrote:
> Before v12, stddev_pop() had the following behavior with just a
> single input value:
> ...
> As of v12, though, all three cases produce 0. I am not sure what
> to think about that with respect to an infinity input, but I'm
> quite sure I don't like it for NaN input.
While I'm still
On Fri, Jun 12, 2020 at 2:14 PM Tom Lane wrote:
> Robert Haas writes:
> > BTW, has there been any thought to supporting a negative scale for the
> > numeric data type? If you can cut off digits after the decimal, why
> > not before?
>
> Hm, would there be any real use-case?
Compatibility...
On Wed, Jun 3, 2020 at 07:57:16PM -0400, Chapman Flack wrote:
> For example, we might agree that it is safe to trust nothing but the
> end-entity cert of my server itself. I made a server, here is its cert,
> here is a root.crt file for libpq containing only this exact cert, I
> want libpq to
Mark Wong writes:
> Would some additional procedure language handler code examples in the
> documentation be good to add? I've put some together in the attached
> patch, and can log it to a future commitfest if people think it would
> be a good addition.
Hmm. The existing doc examples are
Hi David,
No pain with CMake. It's pretty easy to use it in Windows for PostgreSQL
extensions. Example, https://github.com/dmitigr/pgnso
On Fri, 12 Jun 2020, 01:43 David Rowley, wrote:
> Hi,
>
> I've heard from a few people that building PostgreSQL extensions on
> Windows is a bit of a pain.
On Fri, Jun 12, 2020 at 6:58 PM Joshua Drake wrote:
> -Hackers,
>
> I came across this today [1], "
> 3 Results
>
> In most respects, PostgreSQL behaved as expected: both read uncommitted
> and read committed prevent write skew and aborted reads. We observed no
> internal consistency violations.
Posgres13_beta1, is consistently writing to the logs, "could not rename
temporary statistics file".
When analyzing the source that writes the log, I simplified the part that
writes the logs a little.
1. I changed from if else if to if
2. For the user, better to have more errors recorded, which
On Fri, Jun 12, 2020 at 04:17:34PM +0800, 李杰(慎追) wrote:
> As we all know, CIC has three transactions. If we recursively in n
> partitioned tables,
> it will become 3N transactions. If an error occurs in these transactions, we
> have too many things to deal...
>
> If an error occurs when an
Robert Haas writes:
> BTW, has there been any thought to supporting a negative scale for the
> numeric data type? If you can cut off digits after the decimal, why
> not before?
Hm, would there be any real use-case?
An implementation issue is that even in the "long" numeric format,
we cram
> "Tom" == Tom Lane writes:
[...]
Tom> so that a finite value should never map to INT[64]_MIN, making it
Tom> safe to do as you suggest. I agree that distinguishing +Inf from
Tom> NaN is probably more useful than distinguishing it from the very
Tom> largest class of finite values, so
-Hackers,
I came across this today [1], "
3 Results
In most respects, PostgreSQL behaved as expected: both read uncommitted and
read committed prevent write skew and aborted reads. We observed no
internal consistency violations. However, we have two surprising results to
report. The first is
On Thu, Jun 11, 2020 at 4:54 PM David Rowley wrote:
> I think someone at some point is not going to like the automatic
> choice. So perhaps a reloption to allow users to overwrite it is a
> good idea. -1 should most likely mean use the automatic choice based
> on relation size. I think for
On Fri, Jun 12, 2020 at 1:01 PM Tom Lane wrote:
> This does tie into something I have a question about in the patch's
> comments though. As the patch stands, numeric(numeric, integer)
> (that is, the typmod-enforcement function) just lets infinities
> through regardless of the typmod, on the
On Fri, Jun 12, 2020 at 09:17:37AM +0200, Fabien COELHO wrote:
> The question is what should be put in the protocol, and I would tend to
> think that some careful design time should be put in it.
I still don't see the value of this vs. its complexity.
--
Bruce Momjian
On Thu, Jun 11, 2020 at 1:41 PM Hamid Akhtar wrote:
> As far I understand, parallel backup is not a mandatory performance feature,
> rather, one at user's discretion. This IMHO indicates that it will benefit
> some users and it may not others.
>
> IMHO, parallel backup has obvious performance
Hi everyone,
Would some additional procedure language handler code examples in the
documentation be good to add? I've put some together in the attached
patch, and can log it to a future commitfest if people think it would
be a good addition.
Regards,
Mark
--
Mark Wong
2ndQuadrant - PostgreSQL
Robert Haas writes:
> On Thu, Jun 11, 2020 at 9:16 PM Tom Lane wrote:
>> We had a discussion recently about how it'd be a good idea to support
>> infinity values in type numeric [1].
> FWIW, I don't particularly like the idea. Back when I was an
> application developer, I remember having to
On Thu, Jun 11, 2020 at 9:16 PM Tom Lane wrote:
> We had a discussion recently about how it'd be a good idea to support
> infinity values in type numeric [1].
Only a minority of that discussion was actually on that topic, and I'm
not sure there was a clear consensus in favor of it.
FWIW, I
Hello,Ashutosh
Thank you for your response.
>We already have that infrastructure, IIUC through commit
That's good!
>Can we use that to fix this bug?
I'll try it.
But this is my first hack,I think I need time.
Regards
Kenichiro Tanaka
2020年6月8日(月) 22:11 Ashutosh Bapat :
>
> On Mon, Jun 1, 2020
Hi,
The document explains that "lost" value that
pg_replication_slots.wal_status reports means
some WAL files are definitely lost and this slot cannot be used to resume
replication anymore.
However, I observed "lost" value while inserting lots of records,
but replication could continue
> No, no kind of GUC switch is needed. Just drop underflow/overflow checks.
> You'll get 0 or Infinity in expected places, and infinities are okay since
> 2007.
This is out of scope of this thread. I am not sure opening it to
discussion on another thread would yield any result. Experienced
> Does anyone disagree that that's a bug? Should we back-patch
> a fix, or just change it in HEAD? Given the lack of user
> complaints, I lean a bit towards the latter, but am not sure.
The other functions and operators pay attention to not give an error
when the input is Inf or 0. exp() and
On Fri, 12 Jun 2020 at 16:17, Fabien COELHO wrote:
>
>
> Hello Masahiko-san,
>
> I'm not sure I understood your concern. I try to answer below.
>
> > If I understand your idea correctly we put both DEK and KEK
> > "elsewhere", and a postgres process gets only DEK from it.
>
> Yes, that is one of
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> +#define NUMERIC_ABBREV_PINF
> NumericAbbrevGetDatum(PG_INT64_MIN)
> Tom> +#define NUMERIC_ABBREV_PINF
> NumericAbbrevGetDatum(PG_INT32_MIN)
> I'd have been more inclined to go with -PG_INT64_MAX /
On Fri, 12 Jun 2020 at 19:24, Amit Kapila wrote:
>
> On Fri, Jun 12, 2020 at 2:10 PM Masahiko Sawada
> wrote:
> >
> > On Fri, 12 Jun 2020 at 15:37, Amit Kapila wrote:
> > >
> > > > >
> > > > > I think this is a corner case and it is better to simplify the state
> > > > > recording of foreign
> "Tom" == Tom Lane writes:
Tom> @@ -359,10 +390,14 @@ typedef struct NumericSumAccum
Tom> #define NumericAbbrevGetDatum(X) ((Datum) (X))
Tom> #define DatumGetNumericAbbrev(X) ((int64) (X))
Tom> #define NUMERIC_ABBREV_NAN
NumericAbbrevGetDatum(PG_INT64_MIN)
Tom>
On Fri, Jun 12, 2020 at 10:23 AM Amit Kapila
wrote:
> On Fri, Jun 12, 2020 at 11:20 AM Masahiko Sawada
> wrote:
> >
> > On Fri, 12 Jun 2020 at 12:21, Amit Kapila
> wrote:
> > >
> > > > Since the logical decoding intermediate files are written at per
> slots
> > > > directory, I thought that
On Wed, Jun 3, 2020 at 12:44 PM Amit Langote wrote:
>
> On Thu, May 28, 2020 at 11:08 PM Ashutosh Bapat
> wrote:
> > On Wed, May 27, 2020 at 6:51 PM Amit Langote
> > wrote:
> > > So in Rajkumar's example, the cursor is declared as:
> > >
> > > CURSOR IS SELECT * FROM tbl WHERE c1< 5 FOR
On Thu, Jun 11, 2020 at 09:37:09PM -0500, Justin Pryzby wrote:
> Some new bits,
> And some old ones.
I have merged 0003 and 0004 together and applied them. 0005 seems to
have a separate issue as mentioned upthread, and I have not really
looked at 0001 and 0002. Thanks.
--
Michael
On Fri, Jun 12, 2020 at 9:00 AM Michael Paquier wrote:
> On Tue, Jun 09, 2020 at 11:26:19AM +0100, Dagfinn Ilmari Mannsåker wrote:
> > Plus a note in the Win32 docs that Win32::Symlink may be required to run
> > some tests on some Perl/Windows versions..
>
> Planting such a check in individual
Is it possible to make cube extension with float(4bytes) precision instead
of double(8bytes)?
I use cube extension for storing embedding vectors and calculation distance
on them. During comparing vectors, a 4byte float precision is enough.
Storing 8 byte double precision is wasting disk space.
Hi All,
I've spent little bit of time going through the project discussion that has
happened in this email thread and to start with I have few questions which
I would like to put here:
Q1) Are we also planning to read the input data in parallel or is it only
about performing the multi-insert
On Fri, Jun 12, 2020 at 11:38 AM Dilip Kumar wrote:
>
> - Currently, while reading/writing the streaming/subxact files we are
> reporting the wait event for example
> 'pgstat_report_wait_start(WAIT_EVENT_LOGICAL_SUBXACT_WRITE);', but
> BufFileWrite/BufFileRead internally reports the read/write
On Fri, Jun 12, 2020 at 2:10 PM Masahiko Sawada
wrote:
>
> On Fri, 12 Jun 2020 at 15:37, Amit Kapila wrote:
> >
> > > >
> > > > I think this is a corner case and it is better to simplify the state
> > > > recording of foreign transactions then to save a CLOG lookup.
> > > >
> > >
> > > The main
On 6/11/20 6:42 PM, David Rowley wrote:
> I've heard from a few people that building PostgreSQL extensions on
> Windows is a bit of a pain. I've heard from these people that their
> solution was to temporarily add their extension as a contrib module
> and have the extension building code take care
Hello hackers,
Currently, I do some changes based on the last version:
1. Catch up to the current commit (c2bd1fec32ab54).
2. Add regression and document.
3. Add support to switch from xid-base snapshot to csn-base snapshot,
and the same with standby side.
Regards,
Highgo Software
Oh, now I understand. and I added a test of --row-per-insert option.
I'd better find more options missing test
2020년 6월 12일 (금) 오후 4:04, Michael Paquier 님이 작성:
> On Fri, Jun 12, 2020 at 02:30:35PM +0900, Dong Wook Lee wrote:
> > Thank you for your response
> > Do you mean to move it under the
On Fri, 12 Jun 2020 at 15:37, Amit Kapila wrote:
>
> On Fri, Jun 12, 2020 at 9:54 AM Masahiko Sawada
> wrote:
> >
> > On Fri, 12 Jun 2020 at 12:40, Amit Kapila wrote:
> > >
> > > On Fri, Jun 12, 2020 at 7:59 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Thu, 11 Jun 2020 at 22:21, Amit
On Fri, Jun 12, 2020 at 11:20 AM Masahiko Sawada
wrote:
>
> On Fri, 12 Jun 2020 at 12:21, Amit Kapila wrote:
> >
> > > Since the logical decoding intermediate files are written at per slots
> > > directory, I thought that corresponding these statistics to
> > > replication slots is also
On Wed, 15 Apr 2020 at 04:04, Teja Mupparti wrote:
>
> Thanks Kyotaro and Masahiko for the feedback. I think there is a consensus on
> the critical-section around truncate, but I just want to emphasize the need
> for reversing the order of the dropping the buffers and the truncation.
>
> Repro
Hi Justin,
> Maybe I'm wrong, but I don't think there's any known difficulty - just that>
> nobody did it yet. You should pay attention to what happens on error, but
> hopefully you wouldn't need to add much code and can rely on existing code to
> paths to handle that right.
yes, I am trying
>On Sat, Jun 06, 2020 at 09:23:32AM -0500, Justin Pryzby wrote:
> > On Wed, Jun 03, 2020 at 08:22:29PM +0800, 李杰(慎追) wrote:
> > > Partitioning is necessary for very large tables.
> > > However, I found that postgresql does not support create index
> > > concurrently on partitioned tables.
> > >
On Thu, Jun 11, 2020 at 09:37:09PM -0500, Justin Pryzby wrote:
> Some new bits,
> And some old ones.
I was looking at this patch set, and 0005 has attracted my attention
here:
> --- a/src/backend/utils/cache/relcache.c
> +++ b/src/backend/utils/cache/relcache.c
> @@ -4240,7 +4240,6 @@
On Thu, Jun 11, 2020 at 03:55:59PM +0200, Peter Eisentraut wrote:
> On 2020-01-16 13:56, Robert Haas wrote:
>> IMHO, custom enums for each particular case would be a big improvement
>> over supposedly-generic STATUS codes. It makes it clearer which values
>> are possible in each code path, and it
> "Tom" == Tom Lane writes:
Tom> * I'm only about 50% sure that I understand what the sort
Tom> abbreviation code is doing. A quick look from Peter or some other
Tom> expert would be helpful.
That code was originally mine, so I'll look at it.
--
Andrew (irc:RhodiumToad)
On Fri, Jun 12, 2020 at 09:16:04AM +0200, Peter Eisentraut wrote:
> committed
Yeah!
--
Michael
signature.asc
Description: PGP signature
On Thu, Jun 11, 2020 at 10:35:02AM -0500, Justin Pryzby wrote:
> Note, you could do this now using psql like:
> SELECT format('CREATE INDEX CONCURRENTLY ... ON %s(col)', a::regclass) FROM
> pg_partition_ancestors() AS a;
> \gexec
I have skimmed quickly through the patch set, and something has
Hello Masahiko-san,
I'm not sure I understood your concern. I try to answer below.
If I understand your idea correctly we put both DEK and KEK
"elsewhere", and a postgres process gets only DEK from it.
Yes, that is one of the option.
It seems to me this idea assumes that the place storing
On 2020-06-05 18:05, Tom Lane wrote:
Peter Eisentraut writes:
This is a patch to make use of RELKIND_HAS_STORAGE() where appropriate,
instead of listing out the relkinds individually. No behavior change is
intended.
This was originally part of the patch from [0], but it seems worth
moving
On Thu, Jun 11, 2020 at 07:58:43PM +0300, Anastasia Lubennikova wrote:
> I would be glad to add some test, but it seems to me that the infrastructure
> changes for cross-version pg_upgrade test is much more complicated task than
> this modest bugfix. Besides, I've read the discussion and it seems
On Thu, Jun 11, 2020 at 10:16:50AM -0400, Stephen Frost wrote:
> Uh, doesn't this pull these functions out of libpgcommon, where they
> might have been being used by utilities outside of our client tools?
This stuff is new to 13, and we are still in beta so it is fine in my
opinion to still
On Tue, Jun 09, 2020 at 11:26:19AM +0100, Dagfinn Ilmari Mannsåker wrote:
> Amusingly, Win32::Symlink uses a copy of our pgsymlink(), which emulates
> symlinks via junction points:
>
> https://metacpan.org/source/AUDREYT/Win32-Symlink-0.06/pgsymlink.c
Oh, interesting point. Thanks for the
On Fri, Jun 12, 2020 at 9:54 AM Masahiko Sawada
wrote:
>
> On Fri, 12 Jun 2020 at 12:40, Amit Kapila wrote:
> >
> > On Fri, Jun 12, 2020 at 7:59 AM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, 11 Jun 2020 at 22:21, Amit Kapila wrote:
> > > >
> > >
> > > > I have another question about
> > >
On Fri, Jun 12, 2020 at 12:40 AM Mark Dilger
wrote:
>
>
>
> > On Jun 11, 2020, at 9:14 AM, Dilip Kumar wrote:
> >
> > I have just browsed through the patch and the idea is quite
> > interesting. I think we can expand it to check that whether the flags
> > set in the infomask are sane or not
Just to help those who find themselves in the same situation, there is a simple
application-level workaround which consists in listening to the notifications
in the replica when they are issued by the master and vice versa.
We are programming in .NET and we use a code like this:
Code in the
On Thu, 11 Jun 2020 at 20:03, Fabien COELHO wrote:
>
>
> Hello Masahiko-san,
>
> >> If the KEK is ever present in pg process, it presumes that the threat
> >> model being addressed allows its loss if the process is compromised, i.e.
> >> all (past, present, future) security properties are void
77 matches
Mail list logo
