On Sun, 16 Jun 2019 at 19:42, David Rowley wrote:
>
> I've rebased this on top of the current master. d25ea0127 conflicted
> with the old version.
... and again, per recent conflicting change in equivclass.c
I've also taken a fresh set of performance benchmarks since 1cff1b95a
has recently chang
On Thu, Jul 18, 2019 at 2:53 PM Andres Freund wrote:
> On 2019-07-18 14:24:29 +0900, Amit Langote wrote:
> > On Thu, Jul 18, 2019 at 10:09 AM Andres Freund wrote:
> > > 1) How come partition routing is done outside of ExecInsert()?
> > >
> > > case CMD_INSERT:
> > > /*
Hello Andres,
If a function reports an error to log, it should keep on doing it, otherwise
there would be a regression.
Err, huh. Especially if we change the signature, I fail to see how it's
a regression if we change the behaviour.
ISTM that we do not understand one another, because I'm o
Hi Peifeng,
On Fri, Mar 29, 2019 at 12:01:26AM +0900, Peifeng Qiu wrote:
> The current Windows build system supports compiling with Windows SDK up to
> v8.1. When building with the latest Windows SDK v10 which is the default
> for Visual Studio 2017, we will get the following error:
>
> error MSB
Hi Hackers,
We found a race condition in pg_mkdir_p(), here is a simple reproducer:
#!/bin/sh
basedir=pgdata
datadir=$basedir/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z
logdir=$basedir/logs
n=2
rm -rf $basedir
mkdir -p $logdir
# init databases concurren
On Wed, Jul 17, 2019 at 09:54:16PM +0700, r.zhar...@postgrespro.ru wrote:
> You are right. I tested branch REL_11_STABLE and it is my mistake.
>
> [...]
>
> The probability is very small. In one of our tests pg_ctl fails with that
> error sometime.
> In a test with multiple frequent restarts the pr
On Thu, Jul 18, 2019 at 04:17:22PM +0800, Ning Yu wrote:
> This is still wrong with current code logic, because when the statusdir is
> a file the errno is also EEXIST, but it can pass the check here. Even if
> we fix pg_mkdir_p() by following the `mkdir -p` way the errno check here is
> still wro
At Thu, 18 Jul 2019 14:04:34 +0700, Жарков Роман
wrote in
> Hello,
>
> Therefore, we suggest replace the deletion of a lock file by renaming it.
> unlink in windows is not an atomic operation.
> When we try to open the file between
> SetDispositionInformationFile and CloseFile we get ERROR_DEL
I have tested clean REL_11_STABLE.
Commit f02259fe was reverted by df8b5f3e in this branch.
So pg_ctl uses “old” open() function.
regards, Roman
> 18 июля 2019 г., в 15:51, Michael Paquier написал(а):
>
>> On Wed, Jul 17, 2019 at 09:54:16PM +0700, r.zhar...@postgrespro.ru wrote:
>> You are righ
On Thu, Jul 18, 2019 at 6:40 PM Amit Kapila wrote:
> On Wed, Jul 17, 2019 at 4:10 PM Amit Kapila wrote:
> > Yeah, that is a problem. Actually, what we need here is to
> > wait-for-workers-to-finish and collect all the instrumentation
> > information. We don't need to destroy the shared memory a
On Thu, Jul 18, 2019 at 4:57 PM Michael Paquier wrote:
> On Thu, Jul 18, 2019 at 04:17:22PM +0800, Ning Yu wrote:
> > This is still wrong with current code logic, because when the statusdir
> is
> > a file the errno is also EEXIST, but it can pass the check here. Even if
> > we fix pg_mkdir_p()
On Thu, Jul 18, 2019 at 4:51 PM Amit Langote wrote:
> On Thu, Jul 18, 2019 at 2:53 PM Andres Freund wrote:
> > On 2019-07-18 14:24:29 +0900, Amit Langote wrote:
> > > On Thu, Jul 18, 2019 at 10:09 AM Andres Freund wrote:
> > > > 1) How come partition routing is done outside of ExecInsert()?
> >
Hi All,
In the current code for ecpg, we can't use CALL statement to call
stored procedures. The attached patch adds the support for it.
With the attached patch, we can now have the following SQL statement
in ecpg application to call the stored procedures with IN or INOUT
params.
EXEC SQL CALL S
On Thu, Jul 18, 2019 at 11:18 AM Amit Langote wrote:
> On Tue, Jul 16, 2019 at 8:22 PM Etsuro Fujita wrote:
> > On Tue, Jul 2, 2019 at 6:29 PM Amit Langote wrote:
> > > 0001 - fix partitionwise join to work correctly with n-way joins of
> > > which some are full joins (+ cosmetic improvements ar
On Tue, Jul 16, 2019 at 8:39 AM Robert Haas wrote:
> Thomas has already objected to another proposal to add functions that
> turn 32-bit XIDs into 64-bit XIDs. Therefore, I feel confident in
> predicting that he will likewise object to GetEpochForXid. I think
> this needs to be changed somehow, m
Hi,
I've pushed the fixes listed in the previous message, with the exception
of the collation part, because I had some doubts about that.
1) handling of NULL values in Cons / MCV items
The handling of NULL elements was actually a bit more broken, because it
also was not quite correct for NULL v
On Tue, Jul 16, 2019 at 2:20 PM Dilip Kumar wrote:
>
Few comments on the new patch:
1.
Additionally,
+there is a mechanism for multi-insert, wherein multiple records are prepared
+and inserted at a time.
Which mechanism are you talking about here? By any chance is this
related to some old code
On Mon, Jul 1, 2019 at 1:24 PM Thomas Munro wrote:
>
> On Fri, Jun 28, 2019 at 6:09 AM Robert Haas wrote:
> > I happened to open up 0001 from this series, which is from Thomas, and
> > I do not think that the pg_buffercache changes are correct. The idea
> > here is that the customer might instal
Hi, Ryan
On 18.07.2019 6:01, Ryan Lambert wrote:
Hi Konstantin,
Thanks for your work on this. I'll try to do more testing in the next
few days, here's what I have so far.
make installcheck-world: passed
The v8 patch [1] applies, though I get indent and whitespace errors:
:79: tab in
Hi Laurenz,
On 7/17/19 5:21 PM, Laurenz Albe wrote:
That's factually wrong. "on" (wait for WAL flush) works fine with
pg_receivewal, only "remote_apply" doesn't.
Please, try
mkdir /tmp/wal
initdb /tmp/pgsql
pg_ctl -D /tmp/pgsql -l /tmp/logfile start
psql postgres
SELECT pg_create_physical_r
Hi,
On 7/18/19 1:29 AM, Michael Paquier wrote:
Or more simply like that?
"Note that while WAL will be flushed with this setting,
pg_receivewal never applies it, so synchronous_commit must not be set
to remote_apply if pg_receivewal is a synchronous standby, be it a
member of a priority-based (FI
> I have fixed all reported issues except one related with "dropdb --force"
> discussion.
> As far as this patch is not yet committed, I can not rely on it yet.
> Certainly I can just remove this sentence from documentation, assuming
> that this patch will be committed soon.
> But then some extra
Thomas Munro writes:
> Hmm, so something like a new argument "bool final" added to the
> ExecXXXShutdown() functions, which receives false in this case to tell
> it that there could be a rescan so keep the parallel context around.
I think this is going in the wrong direction. Nodes should *alway
On Tue, 16 Jul 2019 at 19:44, Alexander Korotkov
wrote:
>
> On Tue, Jul 16, 2019 at 9:22 PM Thom Brown wrote:
> > Now I'm looking at the @? and @@ operators, and getting a bit
> > confused. This following query returns true, but I can't determine
> > why:
> >
> > # SELECT '{"a":[1,2,3,4,5]}'::js
Tomas Vondra writes:
> I've pushed the fixes listed in the previous message, with the exception
> of the collation part, because I had some doubts about that.
Sorry for being slow on this.
> Now, for the collation part - after some more thought and looking at code
> I think the fix I shared befo
Andres Freund writes:
> Looks like that made the generated typedef lists sane. Any residual
> complaints?
Before ack'ing this, I've been waiting around for komodoensis to update
its typedefs list, in the hopes that the last couple of bogus entries
would go away. It still hasn't, and I just reali
I wrote:
> ... I just realized from looking at its
> config that you have it set to do so at most twice a week:
> 'dow' => [
> 1,
> 4
> ]
I was still conf
>>The suggested change pares down the "Tip" to more of a brief "Note", which
>>IMHO is a bit
>>terse for that section of the documentation (which has more of a tutorial
>>character),
>>and the contents of the original tip basically still apply for volatile
>>default values
>>anyway.
>>
>>I've at
> On 18 Jul 2019, at 17:46, Daniel Westermann (DWE)
> wrote:
>
>>> The suggested change pares down the "Tip" to more of a brief "Note", which
>>> IMHO is a bit
>>> terse for that section of the documentation (which has more of a tutorial
>>> character),
>>> and the contents of the original tip
pg_upgrade from 9.6 fails if old cluster had non-standard ACL
on pg_catalog functions that have changed between versions,
for example pg_stop_backup(boolean).
Error:
pg_restore: creating ACL "pg_catalog.FUNCTION "pg_stop_backup"()"
pg_restore: creating ACL "pg_catalog.FUNCTION
"pg_stop_backup"(
Gum
On 2019-07-18 11:27:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Looks like that made the generated typedef lists sane. Any residual
> > complaints?
>
> Before ack'ing this, I've been waiting around for komodoensis to update
> its typedefs list, in the hopes that the last couple of
> On 18 Jul 2019, at 17:42, Tom Lane wrote:
> return
> if (exists $oconf->{dow}
> && grep { $_ eq $wday } @{ $oconf->{dow} });
>
> I'm the world's worst Perl programmer, but isn't that backwards?
> It seems like it will return undef if today matches any entry
> of the
Andres Freund writes:
> On 2019-07-18 11:27:49 -0400, Tom Lane wrote:
>> Before ack'ing this, I've been waiting around for komodoensis to update
>> its typedefs list, in the hopes that the last couple of bogus entries
>> would go away. It still hasn't, and I just realized from looking at its
>> c
On 7/18/19 12:17 PM, Daniel Gustafsson wrote:
>> On 18 Jul 2019, at 17:42, Tom Lane wrote:
>> return
>>if (exists $oconf->{dow}
>> && grep { $_ eq $wday } @{ $oconf->{dow} });
>>
>> I'm the world's worst Perl programmer, but isn't that backwards?
>> It seems like it wil
Previous discussion:
https://postgr.es/m/1407012053.15301.53.camel%40jeff-desktop
This patch introduces a way to ask a memory context how much memory it
currently has allocated. Each time a new block (not an individual
chunk, but a new malloc'd block) is allocated, it increments a struct
member;
On Wed, Jul 17, 2019 at 2:13 AM Amit Kapila wrote:
> We add entries in queues only when we want them to be processed by
> background workers whereas hash table will contain the entries for all
> the pending undo requests irrespective of whether they are executed by
> foreground-transaction or by b
On Sun, 2019-07-14 at 15:27 +1200, Thomas Munro wrote:
> I take back the bit about reading an uninitialised value (X || Y
> doesn't access Y if X is true... duh), but I still think the other
> way
> of putting it is a bit easier to read. YMMV.
>
> Generally, +1 for this patch. I'll wait a couple
Jeff Davis writes:
> I went ahead and committed this using Thomas's suggestion to remove the
> parentheses.
The commit message claims this was back-patched, but I see no back-patch?
(The commit message doesn't seem to have made it to the pgsql-committers
list either, but that's probably an indep
On Thu, 2019-07-18 at 13:56 -0700, Jeff Davis wrote:
> I went ahead and committed this using Thomas's suggestion to remove the
> parentheses.
Thanks for the review and the commit!
Yours,
Laurenz Albe
On Wed, Jul 17, 2019 at 12:32 PM Tom Lane wrote:
>
> I tried to run the contrib/sepgsql tests, following the instructions,
> on a recently-set-up Fedora 30 machine. I've done that successfully
> on previous Fedora releases, but it's no go with F30.
>
> First off, building the sepgsql-regtest.pp p
On 7/19/19 12:51 AM, Daniel Gustafsson wrote:
On 18 Jul 2019, at 17:46, Daniel Westermann (DWE)
wrote:
The suggested change pares down the "Tip" to more of a brief "Note", which IMHO
is a bit
terse for that section of the documentation (which has more of a tutorial
character),
and the conte
On Thu, 2019-07-18 at 17:36 -0400, Tom Lane wrote:
> The commit message claims this was back-patched, but I see no back-
> patch?
Sorry, I noticed an issue after pushing: we were passing a datum
directly to DATE_NOT_FINITE, when we should have called
DatumGetDateADT() first. I ran through the test
On Thu, Jul 18, 2019 at 05:36:35PM -0400, Tom Lane wrote:
> Jeff Davis writes:
> > I went ahead and committed this using Thomas's suggestion to remove the
> > parentheses.
>
> The commit message claims this was back-patched, but I see no back-patch?
>
> (The commit message doesn't seem to have m
On Tue, Apr 30, 2019 at 5:58 PM Peter Geoghegan wrote:
> I will think about a simple fix, but after the upcoming point release.
> There is no hurry.
Attached draft patch uses RelationGetNumberOfBlocks() to size each of
the two Bloom filters that may be used by amcheck to perform
verification.
Th
On Thu, Jul 18, 2019 at 09:45:14AM +0900, Michael Paquier wrote:
> On Wed, Jul 17, 2019 at 07:46:10PM +0200, Julien Rouhaud wrote:
>> Is it ok to call pg_free(slots) and let caller have a pointer pointing
> to freed memory?
>
> The interface has a Setup call which initializes the whole thing, and
On Thu, Jul 18, 2019 at 08:39:48AM -0400, Jesper Pedersen wrote:
> mkdir /tmp/wal
> initdb /tmp/pgsql
> pg_ctl -D /tmp/pgsql -l /tmp/logfile start
> psql postgres
> SELECT pg_create_physical_replication_slot('replica1');
> CREATE ROLE repluser WITH LOGIN REPLICATION PASSWORD 'replpass';
> \q
>
> s
On Thu, Jul 18, 2019 at 08:40:36AM -0400, Jesper Pedersen wrote:
> On 7/18/19 1:29 AM, Michael Paquier wrote:
>> Or more simply like that?
>> "Note that while WAL will be flushed with this setting,
>> pg_receivewal never applies it, so synchronous_commit must not be set
>> to remote_apply if pg_rec
On Thu, 18 Jul 2019 at 14:30, Andres Freund wrote:
> I think the AM part of this patch might be the wrong approach - it won't
> do anything meaningful for an AM that doesn't directly map the ctid to a
> specific location in a block (e.g. zedstore). To me it seems the
> callback ought to be to get
Hi Kyotaro,
Thank-you for looking at the patch.
> On 18/07/2019, at 6:54 PM, Kyotaro Horiguchi wrote:
>
> Hello.
>
> If I'm not missing something, "SELECT " without
> having FROM clause doesn't need to be tweaked. Thus
> insert_set_clause is useless and all we need here would be
> something li
On Fri, Jul 19, 2019 at 09:04:03AM +0900, Ian Barwick wrote:
> To me it looks like a minor documentation correction to fix an omission
> from a patch already in PostgreSQL.
I think that it is better to register it in the commit fest anyway so
as we don't lose track of it. Things tend to get lost
On Thu, Jul 18, 2019 at 7:15 PM Tom Lane wrote:
>
> Thomas Munro writes:
> > Hmm, so something like a new argument "bool final" added to the
> > ExecXXXShutdown() functions, which receives false in this case to tell
> > it that there could be a rescan so keep the parallel context around.
>
> I th
On Thu, Jul 18, 2019 at 04:14:34PM +0700, Жарков Роман wrote:
> I have tested clean REL_11_STABLE.
> Commit f02259fe was reverted by df8b5f3e in this branch.
> So pg_ctl uses “old” open() function.
Yeah, that was a failure from me, so I tend to be rather very careful
about anything related to Wind
Hello.
At Thu, 18 Jul 2019 16:38:54 +0530, Ashutosh Sharma
wrote in
> Hi All,
>
> In the current code for ecpg, we can't use CALL statement to call
> stored procedures. The attached patch adds the support for it.
>
> With the attached patch, we can now have the following SQL statement
> in ec
Mike Palmiotto writes:
> On Wed, Jul 17, 2019 at 12:32 PM Tom Lane wrote:
>> $ runcon -t sepgsql_regtest_user_t psql --help
>> psql: fatal: could not look up effective user ID 1000: user does not exist
> I wonder what your password file is labeled. It ought to be:
> % ls -Z /etc/passwd
> system_
On Thu, Jul 18, 2019 at 07:57:41AM +, Fabien COELHO wrote:
> I'm unhappy with the function names though, feel free to improve.
I would have something rather close to what you are suggesting, still
not exactly that because we just don't care about the error strings
generated for the frontend.
Hi all,
(Peter Eisentraut in CC)
crake has just complained about a failure with the LDAP test suite:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2019-07-19%2001%3A33%3A31
# Running: /usr/sbin/slapd -f
/home/bf/bfr/root/HEAD/pgsql.build/src/test/ldap/tmp_check/slapd.conf
-h
On 2010-Jan-28, Scott Bailey wrote:
> Robert Haas wrote:
> > On Sun, Jan 17, 2010 at 11:33 AM, Jan Urbański wrote:
> > > [ detailed review ]
> >
> > Arie,
> >
> > Are you planning to submit an updated patch? If so, please do so soon.
> What is the time limit on this? I've been testing Arie's p
Here's what I found tonight in your latest patch (9). The output from git
apply is better, fewer whitespace errors, but still getting the following.
Ubuntu 18.04 if that helps.
git apply -p1 < builtin_connection_proxy-9.patch
:79: tab in indent.
Each proxy launches its own subse
On 07/18/19 23:33, Alvaro Herrera wrote:
> On 2010-Jan-28, Scott Bailey wrote:
>> What is the time limit on this? I've been testing Arie's patch and I want to
>> see it get in. I can make the changes Jan requested if Arie doesn't. How
>> long should I give him?
>
> I'm pretty sure that "nine years
Hi Tom,
(moving to -hackers)
On Wed, Jul 17, 2019 at 10:26:45PM +, Tom Lane wrote:
> Sync our copy of the timezone library with IANA release tzcode2019b.
>
> A large fraction of this diff is just due to upstream's somewhat
> random decision to rename a bunch of internal variables and struct
>
Hi all,
Is there any way to create a named portal except cursor in PG?
I tried postgres-jdbc driver and use PrepareStatement. Backend could
receive `bind` and `execute` message, but the portal name is still empty.
How can I specify the portal name?
--
Thanks
Hubert Zhang
Michael Paquier writes:
> This is causing a compilation warning on Windows:
> src/timezone/zic.c(2401): warning C4804: '-' : unsafe use of type
> 'bool' in operation
Hmmm ... the code looks like
boollocut,
hicut;
...
thistimecnt = -locut -
On Fri, Jul 19, 2019 at 12:28 AM Robert Haas wrote:
> On Wed, Jul 17, 2019 at 2:13 AM Amit Kapila wrote:
> > > Anyway, if you don't like this solution, propose something else. It's
> > > impossible to correctly implement a hard limit unless the number of
> > > aborted-but-not-yet-undone transacti
Hi,
On 2019-07-19 12:21:27 +0900, Michael Paquier wrote:
> On Thu, Jul 18, 2019 at 07:57:41AM +, Fabien COELHO wrote:
> > I'm unhappy with the function names though, feel free to improve.
>
> I would have something rather close to what you are suggesting, still
> not exactly that because we j
Michael Paquier writes:
> On Thu, Jul 18, 2019 at 04:14:34PM +0700, Жарков Роман wrote:
>> I have tested clean REL_11_STABLE.
>> Commit f02259fe was reverted by df8b5f3e in this branch.
>> So pg_ctl uses “old” open() function.
> Yeah, that was a failure from me, so I tend to be rather very carefu
First time we found pg_ctl errors while testing our fork.
I reproduced them on REL_11_STABLE.
I found three problems with pg_ctl do_stop/do_restart:
1 - "old" fopen() function;
2 - "delete pending" problem rarely happens with "new" fopen() function when
pg_ctl tries to open postmaster.pid file;
3
Hi
I find a suspicious code in libpq:PQconnectPoll(). I think it should be
fixed, but I could not produce a concrete problem.
What do you think about it?
I understand that PQconnectPoll() returns PGRES_POLLING_WRITING or
PGRES_POLLING_READ until state machine reaches terminal state(OK or BAD).
Th
Hi all,
Just browsing through the logs of the buildfarm, I have noticed that
some buildfarm animals complain with warnings (jacana uses MinGW):
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=jacana&dt=2019-07-19%2001%3A45%3A28&stg=make
There are two of them:
c:/mingw/msys/1.0/home/
On Fri, Jul 19, 2019 at 12:59:43AM -0400, Tom Lane wrote:
> Hm, I think 0ba06e0 is actually the relevant change here? Though
> 40cfe86 was a necessary cleanup fix.
Oops. Yes, I meant that.
> I'm too tired to dig in the buildfarm database to be sure, but my
> impression is that the failure rate
On Thu, Jul 18, 2019 at 8:58 PM Hubert Zhang wrote:
> Is there any way to create a named portal except cursor in PG?
> I tried postgres-jdbc driver and use PrepareStatement. Backend could
> receive `bind` and `execute` message, but the portal name is still empty.
> How can I specify the portal na
On Wed, 10 Jul 2019 at 17:12, Amit Khandekar wrote:
>
> On Wed, 10 Jul 2019 at 08:44, Andres Freund wrote:
> >
> > Hi,
> >
> > Thanks for the new version! Looks like we're making progress towards
> > something committable here.
> >
> > I think it'd be good to split the patch into a few pieces. I'
On Tuesday, July 9, 2019, Tomas Vondra wrote:
> >apparently v1 of the ALTER STATISTICS patch was a bit confused about
> >length of the VacAttrStats array passed to statext_compute_stattarget,
> >causing segfaults. Attached v2 patch fixes that, and it also makes sure
> >we print warnings about ignor
On Fri, Jul 19, 2019 at 2:35 AM Michael Paquier wrote:
>
> On Thu, Jul 18, 2019 at 09:45:14AM +0900, Michael Paquier wrote:
> > On Wed, Jul 17, 2019 at 07:46:10PM +0200, Julien Rouhaud wrote:
> >> Is it ok to call pg_free(slots) and let caller have a pointer pointing
> > to freed memory?
> >
> >
On Fri, 2019-07-19 at 10:27 +0900, Michael Paquier wrote:
> On Thu, Jul 18, 2019 at 08:40:36AM -0400, Jesper Pedersen wrote:
> > On 7/18/19 1:29 AM, Michael Paquier wrote:
> > > Or more simply like that?
> > > "Note that while WAL will be flushed with this setting,
> > > pg_receivewal never applies
74 matches
Mail list logo
