On 12/10/21 18:40, Tom Lane wrote:
Andrey Lepikhov writes:
But core jumbling code is good, fast and much easier in support.
A bigger issue is that query ID stability isn't something we are going
to promise on a large scale --- for example, what if a new release adds
some new fields to struct
On Thu, Oct 14, 2021 at 12:37 PM Andrey Lepikhov
wrote:
>
> On 12/10/21 18:45, Bruce Momjian wrote:
> > On Tue, Oct 12, 2021 at 09:40:47AM -0400, Tom Lane wrote:
> >> Andrey Lepikhov writes:
> >>> But core jumbling code is good, fast and much easier in support.
> > Also, the current code handles
It is very good, but it seems to me that there are some tab-completion
missing in COMMENT command.
For example,
- CONSTRAINT ... ON DOMAIN
- OPERATOR CLASS
- OPERATOR FAMILY
- POLICY ... ON
- [PROCEDURAL]
- RULE ... ON
- TRIGGER ... ON
I think these tab-comletion also can be improved and it's a
On 2021/10/12 15:46, Bharath Rupireddy wrote:
On Tue, Oct 12, 2021 at 5:37 AM Fujii Masao wrote:
On 2021/10/12 4:07, Bharath Rupireddy wrote:
Hi,
While working on [1], it is found that currently the ProcState array
doesn't have entries for auxiliary processes, it does have entries for
On 12/10/21 18:45, Bruce Momjian wrote:
On Tue, Oct 12, 2021 at 09:40:47AM -0400, Tom Lane wrote:
Andrey Lepikhov writes:
But core jumbling code is good, fast and much easier in support.
Also, the current code handles renames of schemas and objects, but this
would not.
Yes, It is good option
On Thu, Oct 14, 2021 at 4:51 AM John Naylor
wrote:
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/LDAP.framework/Headers/ldap.h:1:10:
> error: #include nested too deeply
> #include
> ^
I vaguely recall that PostgreSQL should build OK against Apple's
Edmund Horner writes:
> On Fri, 8 Oct 2021 at 20:01, David Fetter wrote:
>> What precisely is this supposed to do?
> The main patch 0001 was to add completion for "SELECT " using
> attributes, functions, and a couple of hard-coded options.
This sort of thing has been proposed a few times, but
On Wed, Oct 13, 2021 at 9:15 PM Tom Lane wrote:
> Looks like a transient/phase of the moon issue to me.
Yeah, I noticed that drongo is prone to them, though only after I hit send.
Thanks
--
Peter Geoghegan
Peter Geoghegan writes:
> Any idea what the problems on drongo are?
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo=2021-10-14%2001%3A27%3A19
It says
# pg_ctl start failed; logfile:
2021-10-14 02:10:33.996 UTC [491848:1] LOG: starting PostgreSQL 14.0, compiled
by Visual C++
On Thursday, September 30, 2021 12:15 PM Amit Kapila
> On Thu, Sep 30, 2021 at 8:22 AM Hou, Zhijie/侯 志杰
> wrote:
> >
> > On Tues, Sep 28, 2021 6:05 PM Amit Kapila wrote:
> > >
> > > Can't we keep the current and new stats both in-memory and persist on
> > > disk? So, the persistent stats data
On Fri, 8 Oct 2021 at 20:01, David Fetter wrote:
> On Sat, Sep 22, 2018 at 06:53:55PM +1200, Edmund Horner wrote:
> > Hi all,
> >
> > Here are some rebased versions of the last two patches. No changes in
> > functionality, except a minor case sensitivity fix in the "completion
> > after commas"
On Wed, Oct 13, 2021 at 2:09 PM Peter Geoghegan wrote:
> I just pushed v4, with the additional minor pg_amcheck documentation
> updates we talked about. No other changes.
Any idea what the problems on drongo are?
At Mon, 11 Oct 2021 15:27:41 +0900, Masahiko Sawada
wrote in
> .
>
> On Fri, Oct 8, 2021 at 4:50 PM Kyotaro Horiguchi
> wrote:
> > I came up with the third way. SnapBuildCommitTxn already properly
> > handles the case where a ReorderBufferTXN with
> > RBTXN_HAS_CATALOG_CHANGES. So this
On Wed, Oct 13, 2021 at 05:20:56PM +, Bossart, Nathan wrote:
> AFAICT the fact that these commands can succeed at all seems to be
> unintentional, and I wonder if modifying these options requires extra
> steps such as rebuilding the index.
I was looking at all this business with more
On Wed, Oct 13, 2021 at 7:55 AM Jeremy Schneider
wrote:
>
> On 10/10/21 23:27, Masahiko Sawada wrote:
> >
> > After more thought, given DDLs are not likely to happen than DML in
> > practice, ...
>
> I haven't looked closely at the patch, but I'd be careful about
> workloads where people create
At Wed, 13 Oct 2021 19:56:17 +0530, Bharath Rupireddy
wrote in
> Hi,
>
> I see that the recoveryStopsAfter() doesn't have any "recovery
> stopping after " sort of log for RECOVERY_TARGET_TIME recovery
> target type. It has similar logs for other recoveryTarget types
> though. Is there any
At Wed, 13 Oct 2021 11:05:19 +, "kuroda.hay...@fujitsu.com"
wrote in
> Dear Horiguchi-san, Fujii-san,
>
> Perfect work... Thank you for replying and analyzing!
>
> > A. "^-?[0-9]+.*" : returns valid padding. p goes after the last digit.
> > B. "^[^0-9-].*" : padding = 0, p doesn't
On Wed, 2021-10-13 at 10:03 -0400, Robert Haas wrote:
> Yeah. I think we should really only use predefined roles where it's
> not practical to have people use GRANT/REVOKE.
That sounds like a good rule.
A minor complaint though: to grant on pg_backend_memory_contexts, you
need two grant
On 10/13/21 5:46 PM, Andres Freund wrote:
> Hi,
>
> On 2021-10-13 16:06:32 -0400, Andrew Dunstan wrote:
>> If you prep a patch I'll test it.
> Well, right now I'm wondering if the better fix is to just remove the whole
> win32 block. I don't know how far back, but afaict it's not needed. Seems
On Sat, Oct 9, 2021 at 5:51 PM Peter Geoghegan wrote:
> While I'm no closer to a backpatchable fix than I was on Thursday, I
> do have some more ideas about what to do on HEAD. I now lean towards
> completely ripping analyze_only calls out, there -- the whole idea of
> calling amvacuumcleanup()
On Sun, Oct 10, 2021 at 12:39 PM Andres Freund wrote:
> Seems we need to replace -h & -p with a -H ldap://server:port/ style URI? I
> think that's fine to do unconditionally, the -H schema is pretty old I think
> (I seem to recall using it in the mid 2000s, when I learned to not like ldap
> by
As you might have seen from my email in another thread, thanks to
Stephen and Cybertec staff, I am back working on cluster file
encryption/TDE.
Stephen was going to research if XTS cipher mode would be a good fit for
this since it was determined that CTR cipher mode was too vulnerable to
IV
On 2021-Oct-13, Andres Freund wrote:
> Hi,
>
> On 2021-10-13 17:46:53 -0300, Alvaro Herrera wrote:
> > On 2021-Oct-13, Andres Freund wrote:
> >
> > > Something very roughly like the attached. Perhaps that's going a bit
> > > overboard
> > > though. But it seems like it might be something we
st 13. 10. 2021 v 1:54 odesílatel Andres Freund napsal:
>
> Hi,
>
> On 2021-10-13 01:19:27 +0200, Josef Šimánek wrote:
> > I tried to clean and start from scratch, but I'm getting different
> > error probably related to wrongly configured JIT (LLVM wasn't found
> > during meson setup). I'll debug
Hi,
On 2021-10-13 16:06:32 -0400, Andrew Dunstan wrote:
> If you prep a patch I'll test it.
Well, right now I'm wondering if the better fix is to just remove the whole
win32 block. I don't know how far back, but afaict it's not needed. Seems to
have been needed for narwhal at some point,
On Wed, 13 Oct 2021 at 11:48, Aleksander Alekseev
wrote:
>
> Hi Matthias,
>
> > Assuming this above is option 1. If I understand correctly, this
> > option was 'adapt the data type so that it understands how to handle a
> > shared dictionary, decreasing storage requirements'.
> > [...]
> >
Hi,
On 2021-10-13 17:46:53 -0300, Alvaro Herrera wrote:
> On 2021-Oct-13, Andres Freund wrote:
>
> > Something very roughly like the attached. Perhaps that's going a bit
> > overboard
> > though. But it seems like it might be something we could use in a few tests?
>
> Hah, our emails crossed.
On Mon, Oct 11, 2021 at 7:22 PM Mark Dilger
wrote:
> I agree that it is unlikely to make much difference in practice.
> I don't feel strongly about this. If you'd like me to remove those checks, I
> can do so. These are just my thoughts on the subject.
Okay. I don't feel strongly about it
Hi
On 2021-Oct-13, Andres Freund wrote:
> Something very roughly like the attached. Perhaps that's going a bit overboard
> though. But it seems like it might be something we could use in a few tests?
Hah, our emails crossed. If you want to turn this into a patch to the
026 test file, please go
> On Oct 13, 2021, at 8:43 AM, Robert Haas wrote:
>
> On Wed, Oct 13, 2021 at 10:40 AM Mark Dilger
> wrote:
>> 3a is a bit strange, when considered in the context of patterns. If db1,
>> db2, and db3 all exist and each have a table foo.bar, and psql is connected
>> to db1, how should the
This works nicely with the TAP test:
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Postgres is bloatware by design: it was built to house
PhD theses." (Joey Hellerstein, SIGMOD annual conference 2002)
>From e9bcdb3b44f36ffa1a2377f252d73ff3d7210fd9 Mon Sep
Hi,
On 2021-10-13 12:13:45 -0700, Andres Freund wrote:
> On 2021-10-13 15:52:46 -0300, Alvaro Herrera wrote:
> > I think I realized partway through writing the test that I could use
> > emit_message instead of using a batched row insert ... so, yeah, we
> > can use it here also.
>
> Cool. Even if
On 10/13/21 3:49 PM, Tom Lane wrote:
> Hans Buschmann writes:
>> In the long of this process Microsoft announced the general availability of
>> VS200 for Monday, November 8, see
>> https://devblogs.microsoft.com/visualstudio/join-us-november-8th-for-the-launch-of-visual-studio-2022/
>> This
On 10/13/21 1:26 PM, Andres Freund wrote:
>
>> pexports will be in the resulting path, and the build will use the
>> native compiler.
> I don't see pexports anywhere in the msys installation. I can see it available
> on sourceforge, and I see a few others asking where to get it from in the
>
On 2021-Oct-13, Andres Freund wrote:
> > > Another thing: filling a segment by inserting lots of very tiny rows is
> > > pretty
> > > expensive. Can't we use something a bit wider? Perhaps even emit_message?
>
> FWIW, the count of inserted rows is something like 171985 ;)
This does ~1600
Hans Buschmann writes:
> In the long of this process Microsoft announced the general availability of
> VS200 for Monday, November 8, see
> https://devblogs.microsoft.com/visualstudio/join-us-november-8th-for-the-launch-of-visual-studio-2022/
> This date is just some hours after the wrapup for
On Wed, Oct 13, 2021 at 12:15 PM Peter Geoghegan wrote:
> Are you sure? I know that nbtree index tuples for a single-column int8
> index are exactly the same size as those from a single column int4
> index, due to alignment overhead at the tuple level. So my guess is
> that hash index tuples
On Wed, Oct 13, 2021 at 3:44 AM Simon Riggs
wrote:
> > IMO it'd be nice to show some numbers to support the claims that storing
> > the extra hashes and/or 8B hashes is not worth it ...
>
> Using an 8-byte hash is possible, but only becomes effective when
> 4-byte hash collisions get hard to
Hi,
On 2021-10-13 15:52:46 -0300, Alvaro Herrera wrote:
> > Hm. I guess we can disable autovac. But that's not a great solution, there
> > might be WAL files due to catalog access etc too.
>
> Well, we don't expect anything else to happen -- the cluster is
> otherwise idle. I think we should do
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Oct 13, 2021 at 12:54 PM Justin Pryzby wrote:
> > It seems unfortunate if names from log messages qualified with datname were
> > now
> > rejected. Like this one:
> >
> > | automatic analyze of table
On 2021-Oct-13, Andres Freund wrote:
> I added LSNs to the error message:
> not ok 1 - 00010002 (0/2002350) differs from
> 00010002 (0/2099600)
>
> It appears that the problem is that inbetween the determination of
> rows_walsize the insert LSN moved to the next
On Wed, Oct 13, 2021 at 1:42 PM Andres Freund wrote:
> I pushed the fix for that.
Ok great, it builds now! :-) Now something's off with dynamic loading.
There are libraries in ./tmp_install/usr/local/lib/ but apparently initdb
doesn't know to look for them there:
$ cat
Hi,
On 2021-10-13 11:03:39 -0700, Andres Freund wrote:
> It seems that 026_overwrite_contrecord.pl test often fails under valgrind. I
> first thought that related failures on skink were due to me migrating the
> animal to a new host (and then running out of space due to a mistake in ccache
>
Thank you for comments.
I do not think this is an improvement. It will result in omitting
quotes in some cases where they're not optional. Try it with a
value such as "all", for example.
This would break the completion of enum entries that require quotes to
work properly for some of their
Hi,
It seems that 026_overwrite_contrecord.pl test often fails under valgrind. I
first thought that related failures on skink were due to me migrating the
animal to a new host (and then running out of space due to a mistake in ccache
config). But it happened again after I fixed those, and I just
Hi,
On 2021-10-13 13:19:36 -0400, John Naylor wrote:
> On Wed, Oct 13, 2021 at 12:37 PM Andres Freund wrote:
>
> > For the autoconf build CI currently does something similar via
> > LIBS="/usr/local/lib:$LIBS"
> > INCLUDES="/usr/local/include:$INCLUDES"
> > ...
> >
On 2021-Oct-13, Robert Haas wrote:
> On Wed, Oct 13, 2021 at 2:01 AM Amul Sul wrote:
> > Instead of abortedRecPtr point, isn't enough to write
> > overwrite-contrecord at XLogCtl->lastReplayedEndRecPtr? I think both
> > are pointing to the same location then can't we use
> >
On 2021/10/13 14:00, Bharath Rupireddy wrote:
On Tue, Oct 12, 2021 at 11:11 PM Fujii Masao
wrote:
BTW, I found file_fdw.c, dblink.c, postgres_fdw/option.c and foreign.c
use different error codes for the same error message as follows.
They should use the same error code? If yes, ISTM that
On 2021-Oct-13, Amul Sul wrote:
> I have one more question, regarding the need for other global
> variables i.e. abortedRecPtr. (Sorry for coming back after so long.)
>
> Instead of abortedRecPtr point, isn't enough to write
> overwrite-contrecord at XLogCtl->lastReplayedEndRecPtr? I think
Hi,
On 2021-10-13 08:55:38 -0400, Andrew Dunstan wrote:
> On 10/12/21 9:03 PM, Andres Freund wrote:
> > I managed to get this working. At first it failed because I don't have
> > pexports - it's not available inside msys as far as I could tell. And seems
> > to
> > be unmaintained. But replacing
On Wed, Oct 13, 2021 at 12:37 PM Andres Freund wrote:
> For the autoconf build CI currently does something similar via
> LIBS="/usr/local/lib:$LIBS"
> INCLUDES="/usr/local/include:$INCLUDES"
> ...
> LIBS="/usr/local/opt/openldap/lib:$LIBS"
>
On Wed, Oct 13, 2021 at 2:01 AM Amul Sul wrote:
> Instead of abortedRecPtr point, isn't enough to write
> overwrite-contrecord at XLogCtl->lastReplayedEndRecPtr? I think both
> are pointing to the same location then can't we use
> lastReplayedEndRecPtr instead of abortedRecPtr to write
>
On Wed, Oct 13, 2021 at 12:54 PM Justin Pryzby wrote:
> It seems unfortunate if names from log messages qualified with datname were
> now
> rejected. Like this one:
>
> | automatic analyze of table "ts.child.cdrs_2021_10_12"...
That's a good argument, IMHO.
--
Robert Haas
EDB:
On Wed, Oct 13, 2021 at 12:46:27PM -0400, Robert Haas wrote:
> On Tue, Oct 12, 2021 at 12:57 PM Justin Pryzby wrote:
> > I would prefer if it errored if the datname didn't match the current
> > database.
> > After all, it would've helped me to avoid making a confusing problem report.
>
> How
On Tue, Oct 12, 2021 at 8:13 AM Peter Eisentraut
wrote:
> So here is a patch. This does what I had in mind as a use case.
> Obviously, the naming and wording can be tuned. Input from other
> vendors is welcome.
I'm not a different vendor, but I do work on different code than you
do, and I like
On Tue, Oct 12, 2021 at 12:57 PM Justin Pryzby wrote:
> I would prefer if it errored if the datname didn't match the current database.
> After all, it would've helped me to avoid making a confusing problem report.
How would you have felt if it had said something like:
error: argument to \d
During October Patchday 2021 the Visual Studio components where upraded too.
Now VS2022 Preview 5 is out, also Visual Studio 2022 RC is available to be used
for production use (seems like our RC with respect to features).
In the long of this process Microsoft announced the general availability
Hi,
On 2021-10-13 11:51:03 -0400, John Naylor wrote:
> On Tue, Oct 12, 2021 at 4:59 PM Andres Freund wrote:
>
> > On 2021-10-12 15:55:22 -0400, John Naylor wrote:
> > > (I couldn't get a build working but I'll leave that aside for now).
> >
> > If you want to do that separately, I'll try to fix
> Does isdigit() understand multi-byte character correctly? The arguments
> of isdigit() is just a unsigned char, and this is 1byte.
> Hence I thought that they cannot distinguish 'ー'.
Sorry, but I referred some wrong doc. Please ignore here...
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
On Tue, Oct 12, 2021 at 4:59 PM Andres Freund wrote:
> On 2021-10-12 15:55:22 -0400, John Naylor wrote:
> > (I couldn't get a build working but I'll leave that aside for now).
>
> If you want to do that separately, I'll try to fix it.
Okay, I pulled the latest commits and tried again:
[51/950]
On Wed, Oct 13, 2021 at 10:40 AM Mark Dilger
wrote:
> 3a is a bit strange, when considered in the context of patterns. If db1,
> db2, and db3 all exist and each have a table foo.bar, and psql is connected
> to db1, how should the command \d db?.foo.bar behave? We have no problem
> with
On Wed, Oct 13, 2021 at 09:16:37AM -0400, Stephen Frost wrote:
> Greetings,
>
> * Ants Aasma (a...@cybertec.at) wrote:
> > On Wed, 13 Oct 2021 at 02:20, Bruce Momjian wrote:
> > > On Wed, Oct 13, 2021 at 12:48:51AM +0300, Ants Aasma wrote:
> > > > On Wed, 13 Oct 2021 at 00:25, Bruce Momjian
> On Oct 13, 2021, at 6:24 AM, Robert Haas wrote:
>
>> and when you stop doing that, passing additional dots through to the POSIX
>> regular expression for processing is the most natural thing to do. This is,
>> in fact, how v14 works. It is a bit debatable whether treating the first
>>
Hi, hackers!
• The last version of patch is correct applied. It changes 8 files from
/src/backend, and 9 other files.
• I have 1 error and 1 warning during compilation on Mac.
explain.c:4985:25: error: implicit declaration of function
'GetLockMethodLocalHash' is invalid in C99
Hi,
I see that the recoveryStopsAfter() doesn't have any "recovery
stopping after " sort of log for RECOVERY_TARGET_TIME recovery
target type. It has similar logs for other recoveryTarget types
though. Is there any specific reason for not having it?
I see that we have "starting point-in-time
On 10/5/21 10:26 PM, Robert Haas wrote:
Hearing no further comments, I've gone ahead and committed these
patches. I'm still slightly nervous that I may have missed some issue,
but I think at this point having the patches in the tree is more
likely to turn it up than any other course of action.
I
On Tue, Oct 12, 2021 at 8:33 PM Stephen Frost wrote:
> Or not. I can see the argument that, because it just goes into the log, that
> it doesn’t make sense to grant to a predefined role, since that role wouldn’t
> be able to see the results even if it had access.
Yeah. I think we should really
On Wed, Oct 13, 2021 at 9:06 AM Amul Sul wrote:
> I think the "elapsed time" part can be implicitly added to the error
> message inside ereport_startup_progress() which is common to all
> calls.
Not if it means having to call psprintf there!
If there's some way we could do it with macro tricks,
On Tue, Oct 12, 2021 at 5:21 PM Mark Dilger
wrote:
> I wasn't thinking critically enough about how psql handles \d when I accepted
> Justin's initial characterization of the bug. The psql client has never
> thought about the stuff to the left of the schema name as a database name,
> even if
Greetings,
* Ants Aasma (a...@cybertec.at) wrote:
> On Wed, 13 Oct 2021 at 02:20, Bruce Momjian wrote:
> > On Wed, Oct 13, 2021 at 12:48:51AM +0300, Ants Aasma wrote:
> > > On Wed, 13 Oct 2021 at 00:25, Bruce Momjian wrote:
> > >
> > > On Tue, Oct 12, 2021 at 11:21:28PM +0300, Ants Aasma
On Wed, Sep 29, 2021 at 11:10 PM Robert Haas wrote:
>
> On Wed, Sep 29, 2021 at 10:08 AM Nitin Jadhav
> wrote:
> > Sorry. There was a misunderstanding about this and for the patch
> > shared on September 27th, I had tested for the value '0' and observed
> > that no progress messages were getting
On Monday, October 11, 2021 3:28 PM Masahiko Sawada
wrote:
> On Fri, Oct 8, 2021 at 4:50 PM Kyotaro Horiguchi
> wrote:
> >
> > At Thu, 7 Oct 2021 13:20:14 +0900, Masahiko Sawada
> > wrote in
> > > Another idea to fix this problem would be that before calling
> > > SnapBuildCommitTxn() we
On 10/12/21 9:03 PM, Andres Freund wrote:
> Hi,
>
> On 2021-10-12 13:42:56 -0700, Andres Freund wrote:
>> On 2021-10-12 16:02:14 -0400, Andrew Dunstan wrote:
>>> You do that by putting a path to it at the start of the PATH. The wrinkle in
>>> this is that you need prove to point to one that
On 2021-Sep-25, Alvaro Herrera wrote:
>> On 2021-Sep-24, Alvaro Herrera wrote:
>>
>> > Here's the set for all branches, which I think are really final, in
>> > case somebody wants to play and reproduce their respective problem
>> scenarios.
>>
>> I forgot to mention that I'll wait until 14.0 is
> On 12 Oct 2021, at 21:01, Andres Freund wrote:
> One thing that is nice with meson's testrunner is that it can parse the output
> of tap tests and recognizes the number of completed / failed subtests. I
> wonder whether we could make pg_regress' output tap compliant without the
> output
Dear Horiguchi-san, Fujii-san,
Perfect work... Thank you for replying and analyzing!
> A. "^-?[0-9]+.*" : returns valid padding. p goes after the last digit.
> B. "^[^0-9-].*" : padding = 0, p doesn't advance.
> C. "^-[^0-9].*" : padding = 0, p advances by 1 byte.
> D. "^-" :
At Wed, 13 Oct 2021 13:39:24 +0530, Bharath Rupireddy
wrote in
> On Wed, Oct 13, 2021 at 4:25 AM Andres Freund wrote:
> >
> > Hi,
> >
> > On 2021-10-11 15:24:46 +0900, Fujii Masao wrote:
> > > How about modifying SharedInvalBackendInit() so that it accepts
> > > BackendId as an argument and
On Tue, 5 Oct 2021 at 20:06, Tomas Vondra wrote:
> >>> I have presented a simple, almost trivial, patch to allow multi-col
> >>> hash indexes. It hashes the first column only, which can be a downside
> >>> in *some* cases. If that is clearly documented, it would not cause
> >>> many issues,
On Tue, Oct 12, 2021 at 1:33 PM Etsuro Fujita wrote:
> On Mon, Oct 11, 2021 at 5:05 PM Etsuro Fujita wrote:
> > The comments for pgfdw_get_cleanup_result() say this:
> >
> > * It's not a huge problem if we throw an ERROR here, but if we get into
> > error
> > * recursion trouble, we'll end up
Hi Matthias,
> Assuming this above is option 1. If I understand correctly, this
> option was 'adapt the data type so that it understands how to handle a
> shared dictionary, decreasing storage requirements'.
> [...]
> Assuming this was the 2nd option. If I understand correctly, this
> option is
On Wed, Oct 13, 2021 at 2:19 PM Stephen Frost wrote:
>
> Greeting,
>
> On Wed, Oct 13, 2021 at 04:14 Bharath Rupireddy
> wrote:
>>
>> On Wed, Oct 13, 2021 at 1:24 PM Michael Paquier wrote:
>> >
>> > On Wed, Oct 13, 2021 at 11:15:16AM +0530, Bharath Rupireddy wrote:
>> > > IMO, we can just
On Wednesday, October 13, 2021 4:10 PM Greg Nancarrow
wrote:
> Also, I found the following scenario where the data is double-published:
>
> (1) PUB: CREATE PUBLICATION pub FOR TABLE sch1.sale_201901, TABLE
> sch1.sale_201902 WITH (publish_via_partition_root=true);
> (2) SUB: CREATE
Greeting,
On Wed, Oct 13, 2021 at 04:14 Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Wed, Oct 13, 2021 at 1:24 PM Michael Paquier
> wrote:
> >
> > On Wed, Oct 13, 2021 at 11:15:16AM +0530, Bharath Rupireddy wrote:
> > > IMO, we can just retain the "if (!superuser())"
On 13.10.2021 07:21, Michael Paquier wrote:
Looks fine seen from here, so I'll apply shortly.
Thank you!
--
Sergey Shinderukhttps://postgrespro.com/
On Wed, Oct 13, 2021 at 9:12 AM Michael Paquier wrote:
>
> On Wed, Oct 13, 2021 at 12:06:32AM +, Bossart, Nathan wrote:
> > At first glance, it looks like ALTER INDEX .. ALTER COLUMN ... SET
> > uses the wrong validation function. I've attached a patch where I've
> > attempted to fix that
On Wed, 13 Oct 2021 at 02:20, Bruce Momjian wrote:
> On Wed, Oct 13, 2021 at 12:48:51AM +0300, Ants Aasma wrote:
> > On Wed, 13 Oct 2021 at 00:25, Bruce Momjian wrote:
> >
> > On Tue, Oct 12, 2021 at 11:21:28PM +0300, Ants Aasma wrote:
> > > Page encrypting to all zeros is for all
On Wed, Oct 13, 2021 at 1:24 PM Michael Paquier wrote:
>
> On Wed, Oct 13, 2021 at 11:15:16AM +0530, Bharath Rupireddy wrote:
> > IMO, we can just retain the "if (!superuser())" check in the
> > pg_log_backend_memory_contexts as is. This would be more meaningful as
> > the error "must be
On Wed, Oct 13, 2021 at 4:25 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-10-11 15:24:46 +0900, Fujii Masao wrote:
> > How about modifying SharedInvalBackendInit() so that it accepts
> > BackendId as an argument and allocates the ProcState entry of
> > the specified BackendId? That is, the startup
On Wed, Oct 13, 2021 at 12:15 AM vignesh C wrote:
>
> Attached v40 patch has the fix for the above comments.
>
[Maybe this has some overlap with what Hou-san reported, and I have
not tested this against his proposed fixes]
If partitions belong to a different schema than the parent partitioned
Greetings,
On Wed, Oct 13, 2021 at 03:54 Michael Paquier wrote:
> On Wed, Oct 13, 2021 at 11:15:16AM +0530, Bharath Rupireddy wrote:
> > IMO, we can just retain the "if (!superuser())" check in the
> > pg_log_backend_memory_contexts as is. This would be more meaningful as
> > the error "must be
On Wed, Oct 13, 2021 at 11:15:16AM +0530, Bharath Rupireddy wrote:
> IMO, we can just retain the "if (!superuser())" check in the
> pg_log_backend_memory_contexts as is. This would be more meaningful as
> the error "must be superuser to use raw page functions" explicitly
> says that a superuser is
Thanks for the fix. It works for me.
Now I'm exploring another crash related to GTT, but I need a few days to
present a simple repro.
On Sat, Oct 9, 2021 at 2:41 PM wenjing wrote:
>
> Thank you for pointing it out.
> This is a bug that occurs during transaction rollback and process exit, I
>
On Wed, Oct 13, 2021 at 7:48 AM Bossart, Nathan wrote:
>
> On 10/12/21, 6:26 PM, "Michael Paquier" wrote:
> > On Tue, Oct 12, 2021 at 08:33:19PM -0400, Stephen Frost wrote:
> >> I would think we would do both…. That is- move to using GRANT/REVOKE, and
> >> then just include a GRANT to
Hi,
On Thu, Oct 7, 2021 at 6:57 PM Alvaro Herrera wrote:
>
> On 2021-Oct-07, Amul Sul wrote:
>
> > Make sense, thanks for the explanation.
>
> You're welcome. Also, I forgot: thank you for taking the time to review
> the code. Much appreciated.
:)
>
>
I have one more question, regarding the
94 matches
Mail list logo
