On Wed, Jan 06, 2021 at 11:28:36AM +0500, Andrey Borodin wrote:
> First patch fixes a bug with possible SLRU truncation around wrapping point
> too early.
> Basic idea of the patch is "If we want to delete a range we must be eligible
> to delete it's beginning and ending".
> So to test if page is
pg_dump can generate invalid SQL syntax if an aclitem in pg_init_privs
contains a GRANT OPTION (an asterisk in the aclitemout() representation).
Also, pg_dump uses REVOKE GRANT OPTION FOR where it needs plain REVOKE. For
more details, see the log message in the attached patch. I recommend
reviewi
On Fri, Jan 8, 2021 at 9:19 PM Ryan Lambert wrote:
>> Updated v11 with additional docs and some rewording of messages/tests
>> to use "system versioning" correctly.
>>
>> No changes on the points previously raised.
>>
> Thank you! The v11 applies and installs. I tried a simple test,
> unfortun
Hi, the building warning below is fixed now, no other changes. Also, I can
confirm that the corner case with offset=0 in lead and lag works correctly.
gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute -Wimplicit-fallt
On Fri, Jan 8, 2021 at 4:32 PM Amit Kapila wrote:
>
> On Thu, Jan 7, 2021 at 10:03 PM vignesh C wrote:
> >
> > This feature adds schema option while creating publication. Users will
> > be able to specify one or more schemas while creating publication,
> > when the user specifies schema option, t
On Sat, Jan 9, 2021 at 12:57 PM Amit Kapila wrote:
>
> On Tue, Jan 5, 2021 at 4:26 PM Amit Kapila wrote:
> >
> > On Tue, Jan 5, 2021 at 2:11 PM Ajin Cherian wrote:
> > >
> > >
> > > I've addressed the above comments and the patch is attached. I've
> > > called it v36-0007.
> > >
> >
> > Thanks,
On 2021-01-09 02:46, Michael Paquier wrote:
+/* LCOV_EXCL_START */
Does it really make sense to add those markers here? It seems to me
that we would ignore any new coverage if regression tests based on
older versions are added (we may really want to have such tests for
more in-core extensions to
>+ " create tables with using
>specified table access method,\n"
In my opinion, this sentence should be "create tables with specified table
access method" or "create tables using specified table access method".
"create tables with specified table access
On Sat, Jan 9, 2021 at 5:21 PM vignesh C wrote:
> > What do we do if the user Drops the schema? Do we automatically remove
> > it from the publication?
> >
> I have not yet handled this scenario yet, I will handle this and
> adding of tests in the next patch.
>
> > I see some use of such a feature
On Sat, Jan 9, 2021 at 8:08 PM Bharath Rupireddy
wrote:
> I think this feature can be useful, in case a user has a lot of tables
> to publish inside a schema. Having said that, I wonder if this feature
> mandates users to create the same schema with same
> permissions/authorizations manually on th
Hi, patch applies and compiles, all included and external tests and
building of the docs pass.
After the last run of the cfbot, there are no any building warnings.
I am using last version in our testing environment with real data and I
didn't find any bugs,
so I'm marking this patch as ready for th
> 9 янв. 2021 г., в 15:17, Noah Misch написал(а):
>
>> This
>> int diff_max = ((QUEUE_MAX_PAGE + 1) / 2) - 1,
>> seems to be functional equivalent of
>> int diff_max = ((QUEUE_MAX_PAGE - 1) / 2),
>
> Do you think one conveys the concept better than the other?
I see now that next comments ment
Hi,
For WinGetFuncArgInFrame():
+ if (winobj->null_treatment == NULL_TREATMENT_IGNORE)
{
...
+ if (target > 0)
+ step = 1;
+ else if (target < 0)
+ step = -1;
+ else if (seektype == WINDOW_SEEK_HEAD)
+ step = 1;
+ else if (seektype == WIN
Hi,
in expanded output, psql does not print the title if there are zero
results. In regular output, it prints the title ("foo") no matter how
many rows:
postgres=# \pset title foo
Title is "foo".
postgres=# SELECT 1 WHERE 1=1;
foo
?column?
--
1
(1 row)
postgres=# SELECT 1 WH
On Thu Jan 7, 2021 at 3:24 AM EST, Pavel Stehule wrote:
> čt 7. 1. 2021 v 9:15 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
> > > On Wed, Jan 06, 2021 at 09:22:53PM +0100, Pavel Stehule wrote:
> > >
> > > this case should to raise exception - the value should be changed or
> > error
Hi,
Since pg_test_fsync is supposed to simulate some aspects of
PostgreSQL's wal_sync_method settings, I think it should be updated to
use the same system calls (which changed in v12). That's mostly on
principle, though in practice, on one system I've managed to see a
small measurable difference.
On Thu, Dec 17, 2020 at 05:54:28PM +0300, Konstantin Knizhnik wrote:
> I am maintaining this code in
> g...@github.com:postgrespro/libpq_compression.git repository.
> I will be pleased if anybody, who wants to suggest any bug
> fixes/improvements of libpq compression, create pull requests: it will
so 9. 1. 2021 v 21:06 odesílatel Dian M Fay napsal:
> On Thu Jan 7, 2021 at 3:24 AM EST, Pavel Stehule wrote:
> > čt 7. 1. 2021 v 9:15 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> > napsal:
> >
> > > > On Wed, Jan 06, 2021 at 09:22:53PM +0100, Pavel Stehule wrote:
> > > >
> > > > this case
On Sat Jan 9, 2021 at 3:34 PM EST, Pavel Stehule wrote:
> so 9. 1. 2021 v 21:06 odesílatel Dian M Fay
> napsal:
>
> > On Thu Jan 7, 2021 at 3:24 AM EST, Pavel Stehule wrote:
> > > čt 7. 1. 2021 v 9:15 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> > > napsal:
> > >
> > > > > On Wed, Jan 06, 20
On Sat, Jan 09, 2021 at 08:25:39PM +0500, Andrey Borodin wrote:
> > 9 янв. 2021 г., в 15:17, Noah Misch написал(а):
> >> I'm a little bit afraid that this kind of patch can hide bugs (while
> >> potentially saving some users data). Besides this patch seems like a
> >> useful precaution. Maybe w
On 1/8/21 8:22 PM, Alvaro Herrera wrote:
> On 2020-Dec-31, Alvaro Herrera wrote:
>
>> Here's a rebase of Simon/Pavan's MERGE patch to current sources. I
>> cleaned up some minor things in it, but aside from rebasing, it's pretty
>> much their work (even the commit message is Simon's).
>
> Rebase
On Sat, Jan 9, 2021 at 08:08:16PM -0500, Bruce Momjian wrote:
> On Sat, Jan 9, 2021 at 01:17:36PM -0500, Bruce Momjian wrote:
> > I know we are still working on the hex patch (dest-len) and the crypto
> > tests, but I wanted to post this so people can see where we are, and we
> > can get some cur
On Sun, Jan 10, 2021 at 3:45 PM Bruce Momjian wrote:
> Does anyone know why the cfbot applied the patch listed second first
> here?
>
> http://cfbot.cputube.org/patch_31_2925.log
>
> Specifically, it applied hex..key.diff.gz before hex.diff.gz. I assumed
> it would apply attachments in th
> 10 янв. 2021 г., в 03:15, Noah Misch написал(а):
>
> No; it deletes the most recent ~1B and leaves the older segments. An
> exception is multixact, as described in the commit message and the patch's
> change to a comment in TruncateMultiXact().
Thanks for clarification.
One more thing: ret
24 matches
Mail list logo
