On 05/14/2014 07:33 AM, Sergey Muraviov wrote:
I've got this compiler warning:
relation.c: In function ‘sepgsql_relation_drop’:
relation.c:472:25: warning: ‘tclass’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
sepgsql_avc_check_perms(object,
^
I have performed a new benchmark related to my ongoing experimentation
around caching and buffer manager scalability. The benchmark tests a
minor refinement of the prototype patch previously posted [1]. The
patch itself is still very much a prototype, and does not
significantly differ from what I
On 2014-05-15 22:27:42 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Mysteriously, commit 6b2a1445ec8a631060c4cbff3f172bf31d3379b9 has broken
the PDF build (openjade + pdfjadetex) in the 9.0 branch only. The error
is
[256.0.28
! pdfTeX error (ext4): \pdfendlink
On 05/15/2014 11:58 PM, Andres Freund wrote:
On 2014-05-15 22:30:53 +0300, Heikki Linnakangas wrote:
Attached patch fixes things, but I want to add some regression tests
before commit.
Looks good to me.
Attached are two patches. One for the unitialized dbId/tsId issue; one
for the decoding
I'm rebasing another implementation of this against current HEAD at the
moment. It was well tested but has bitrotted a bit, in particular it
needs merging with the multixact changes (eep).
That should provide a useful basis for comparison and a chance to share
ideas.
I'll follow up with the
Hi,
Thanks all for being patient, apparently I didn't quite understand the
norms of trigger execution.
On 16 May 2014 07:55, Craig Ringer cr...@2ndquadrant.com wrote:
On 05/16/2014 08:06 AM, Blagoj Petrushev wrote:
Hi,
I'm thinking of an extension to trigger functionality like this:
CREATE
Hi,
After Heikki has fixed the bit btree_gist bugs my valgrind run shows a
bug in macaddr.
Presumably it's because the type is a fixed width type with a length of
6. I guess it's allocating stuff sizeof(macaddr) but then passes the
result around as a Datum which doesn't work well.
==14219==
Hello,
I applied the patch to current HEAD. There was one failure (attached),
freelist.rej
http://postgresql.1045698.n5.nabble.com/file/n5804200/freelist.rej
Compiled the provided pgbench.c and added following in .conf
shared_buffers = 128MB # min 128kB
Shared_buffers=64MB
2014-05-16 16:26 GMT+09:00 Heikki Linnakangas hlinnakan...@vmware.com:
On 05/14/2014 07:33 AM, Sergey Muraviov wrote:
I've got this compiler warning:
relation.c: In function ‘sepgsql_relation_drop’:
relation.c:472:25: warning: ‘tclass’ may be used uninitialized in this
function
On 20 Feb 2014, at 01:38, Tom Lane t...@sss.pgh.pa.us wrote:
Haribabu Kommi kommi.harib...@gmail.com writes:
I want to propose a new feature called priority table or cache table.
This is same as regular table except the pages of these tables are having
high priority than normal tables. These
On 05/16/2014 04:46 PM, Craig Ringer wrote:
I'll follow up with the patch and a git tree when it's ready, hopefully
tonight.
Here's a rebased version of Simon's original patch that runs on current
master.
I still need to merge the isolation tests for it merged and sorted out,
and after
On 05/16/2014 01:28 PM, Andres Freund wrote:
Hi,
After Heikki has fixed the bit btree_gist bugs my valgrind run shows a
bug in macaddr.
Presumably it's because the type is a fixed width type with a length of
6. I guess it's allocating stuff sizeof(macaddr) but then passes the
result around as
On 2014-05-16 17:08:40 +0300, Heikki Linnakangas wrote:
On 05/16/2014 01:28 PM, Andres Freund wrote:
Hi,
After Heikki has fixed the bit btree_gist bugs my valgrind run shows a
bug in macaddr.
Presumably it's because the type is a fixed width type with a length of
6. I guess it's
Hello,
Can we get that fixed please? It seems rather bad behavior for
pg_basebackup to fatal out because of the permissions on a backup file
of all things. Instead, we should do WARNING and say skipped.
JD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Hi,
On 2014-05-16 07:28:42 -0700, Joshua D. Drake wrote:
Can we get that fixed please? It seems rather bad behavior for pg_basebackup
to fatal out because of the permissions on a backup file of all things.
Instead, we should do WARNING and say skipped.
Doesn't sound like a good idea to me.
On Thu, May 15, 2014 at 11:11 AM, Amit Kapila amit.kapil...@gmail.comwrote:
Data with LWLOCK_STATS
--
BufMappingLocks
PID 7245 lwlock main 38: shacq 41117 exacq 34561 blk 36274 spindelay 101
PID 7310 lwlock main 39: shacq 40257 exacq 34219 blk
Quite some time ago, we made the chr() function accept Unicode code points
up to U+1F, which is the largest value that will fit in a 4-byte UTF8
string. It was pointed out to me though that RFC3629 restricted the
original definition of UTF8 to only allow code points up to U+10 (for
On 05/16/2014 07:30 AM, Andres Freund wrote:
Hi,
On 2014-05-16 07:28:42 -0700, Joshua D. Drake wrote:
Can we get that fixed please? It seems rather bad behavior for pg_basebackup
to fatal out because of the permissions on a backup file of all things.
Instead, we should do WARNING and say
Joshua D. Drake j...@commandprompt.com writes:
On 05/16/2014 07:30 AM, Andres Freund wrote:
On 2014-05-16 07:28:42 -0700, Joshua D. Drake wrote:
Can we get that fixed please? It seems rather bad behavior for pg_basebackup
to fatal out because of the permissions on a backup file of all things.
On 2014-05-16 08:13:04 -0700, Joshua D. Drake wrote:
On 05/16/2014 07:30 AM, Andres Freund wrote:
Hi,
On 2014-05-16 07:28:42 -0700, Joshua D. Drake wrote:
Can we get that fixed please? It seems rather bad behavior for pg_basebackup
to fatal out because of the permissions on a backup file
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 05/16/2014 01:28 PM, Andres Freund wrote:
Presumably it's because the type is a fixed width type with a length of
6. I guess it's allocating stuff sizeof(macaddr) but then passes the
result around as a Datum which doesn't work well.
I've
On 05/16/2014 08:19 AM, Tom Lane wrote:
pg_hba.conf~ is not an important file.
Rather than blaming the messenger, you should be asking why there are
files in $PGDATA that the server can't read. That's a recipe for trouble
no matter what.
Or in words of one syllable: this is a bug in your
At a minimum:
Check to see if there is going to be a permission error BEFORE the base
backup begins:
starting basebackup:
checking perms: ERROR no access to pg_hba.conf~ base backup will fail
JD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Hi,
On 2014-05-16 08:45:12 -0700, Joshua D. Drake wrote:
Software is supposed to make our lives easier, not harder. I should be able
to evaluate the errors for the conditions they create. This is why rsync is
and for the forseeable future will be king for creating base backups.
It's dangerous
On 05/16/2014 08:48 AM, Andres Freund wrote:
Hi,
On 2014-05-16 08:45:12 -0700, Joshua D. Drake wrote:
Software is supposed to make our lives easier, not harder. I should be able
to evaluate the errors for the conditions they create. This is why rsync is
and for the forseeable future will be
On Fri, May 16, 2014 at 5:46 PM, Joshua D. Drake j...@commandprompt.comwrote:
At a minimum:
Check to see if there is going to be a permission error BEFORE the base
backup begins:
starting basebackup:
checking perms: ERROR no access to pg_hba.conf~ base backup will fail
That's pretty
On 2014-05-16 18:20:35 +0200, Magnus Hagander wrote:
On Fri, May 16, 2014 at 5:46 PM, Joshua D. Drake
j...@commandprompt.comwrote:
At a minimum:
Check to see if there is going to be a permission error BEFORE the base
backup begins:
starting basebackup:
checking perms: ERROR no
On Fri, May 16, 2014 at 6:25 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2014-05-16 18:20:35 +0200, Magnus Hagander wrote:
On Fri, May 16, 2014 at 5:46 PM, Joshua D. Drake j...@commandprompt.com
wrote:
At a minimum:
Check to see if there is going to be a permission error
On 2014-05-16 18:29:25 +0200, Magnus Hagander wrote:
On Fri, May 16, 2014 at 6:25 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2014-05-16 18:20:35 +0200, Magnus Hagander wrote:
On Fri, May 16, 2014 at 5:46 PM, Joshua D. Drake j...@commandprompt.com
wrote:
At a minimum:
On 05/16/2014 06:05 PM, Tom Lane wrote:
Quite some time ago, we made the chr() function accept Unicode code points
up to U+1F, which is the largest value that will fit in a 4-byte UTF8
string. It was pointed out to me though that RFC3629 restricted the
original definition of UTF8 to only
On 05/16/2014 09:20 AM, Magnus Hagander wrote:
On Fri, May 16, 2014 at 5:46 PM, Joshua D. Drake j...@commandprompt.com
mailto:j...@commandprompt.com wrote:
At a minimum:
Check to see if there is going to be a permission error BEFORE the
base backup begins:
starting
On 05/16/2014 12:43 PM, Heikki Linnakangas wrote:
On 05/16/2014 06:05 PM, Tom Lane wrote:
Quite some time ago, we made the chr() function accept Unicode code
points
up to U+1F, which is the largest value that will fit in a 4-byte
UTF8
string. It was pointed out to me though that RFC3629
Andres Freund-3 wrote
On 2014-05-16 18:29:25 +0200, Magnus Hagander wrote:
On Fri, May 16, 2014 at 6:25 PM, Andres Freund lt;
andres@
gt;wrote:
On 2014-05-16 18:20:35 +0200, Magnus Hagander wrote:
On Fri, May 16, 2014 at 5:46 PM, Joshua D. Drake lt;
jd@
gt; wrote:
At a
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 05/16/2014 06:05 PM, Tom Lane wrote:
I think this probably means we need to change chr() to reject code points
above 10. Should we back-patch that, or just do it in HEAD?
+1 for back-patching. A value that cannot be restored is bad,
On Fri, May 16, 2014 at 11:05:08AM -0400, Tom Lane wrote:
I think this probably means we need to change chr() to reject code points
above 10. Should we back-patch that, or just do it in HEAD?
The compatibility risks resemble those associated with the fixes for bug
#9210, so I recommend
Noah Misch n...@leadboat.com writes:
On Fri, May 16, 2014 at 11:05:08AM -0400, Tom Lane wrote:
I think this probably means we need to change chr() to reject code points
above 10. Should we back-patch that, or just do it in HEAD?
The compatibility risks resemble those associated with the
Hi,
elog.c's log_line_prefix() processes %d with:
case 'd':
if (MyProcPort)
{
const char *dbname = MyProcPort-database_name;
if (dbname == NULL || *dbname == '\0')
dbname = _([unknown]);
Andres Freund and...@2ndquadrant.com writes:
elog.c's log_line_prefix() processes %d with:
case 'd':
if (MyProcPort)
{
const char *dbname = MyProcPort-database_name;
if (dbname == NULL || *dbname == '\0')
On 2014-05-16 14:02:44 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
elog.c's log_line_prefix() processes %d with:
case 'd':
if (MyProcPort)
{
const char *dbname = MyProcPort-database_name;
Tom Lane-2 wrote
Noah Misch lt;
noah@
gt; writes:
On Fri, May 16, 2014 at 11:05:08AM -0400, Tom Lane wrote:
I think this probably means we need to change chr() to reject code
points
above 10. Should we back-patch that, or just do it in HEAD?
The compatibility risks resemble those
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-16 14:02:44 -0400, Tom Lane wrote:
Not directly related to your gripe, but: where did this padding logic
come from, and what prevents it from creating invalidly-encoded output by
means of truncating multibyte characters in the middle?
David G Johnston david.g.johns...@gmail.com writes:
Tom Lane-2 wrote
While I'd be willing to ignore that risk so far as code points above
10 go, if we want pg_utf8_islegal to be happy then we will also
have to reject surrogate-pair code points. It's not beyond the realm
of possibility
On 2014-05-16 14:51:01 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-16 14:02:44 -0400, Tom Lane wrote:
Not directly related to your gripe, but: where did this padding logic
come from, and what prevents it from creating invalidly-encoded output by
means of
Andres Freund and...@2ndquadrant.com writes:
After Heikki has fixed the bit btree_gist bugs my valgrind run shows a
bug in macaddr.
AFAICT none of these traces represent live bugs, but I've pushed fixes
for them into HEAD.
regards, tom lane
--
Sent via pgsql-hackers
On 05/16/2014 06:43 PM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 05/16/2014 01:28 PM, Andres Freund wrote:
Presumably it's because the type is a fixed width type with a length of
6. I guess it's allocating stuff sizeof(macaddr) but then passes the
result around as
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 05/16/2014 06:43 PM, Tom Lane wrote:
Dunno what's the problem for the varlena types, but that's a completely
separate code path.
It seems to be a similar issue to what I fixed in the bit type earlier.
When the lower+upper keys are stored
Heikki Linnakangas hlinnakan...@vmware.com writes:
ISTM the correct fix would be to define a gbtreekey12 data type and
use that. That's not back-patchable though, and introducing a whole new
type to save a few bytes is hardly worth it. What you did makes sense.
BTW, the *real* problem with
On 05/16/2014 08:11 PM, David G Johnston wrote:
Can we simply backup the non-data parts of $PGDATA first then move onto the
data-parts? For the files that we'd be dealing with it would be
sufficiently quick to just try and fail, immediately, then check for all
possible preconditions first. The
Hi,
On 2014-05-16 15:31:52 -0400, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 05/16/2014 06:43 PM, Tom Lane wrote:
Dunno what's the problem for the varlena types, but that's a completely
separate code path.
It seems to be a similar issue to what I fixed in the
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-16 14:51:01 -0400, Tom Lane wrote:
Ah, you're right, so sprintf shouldn't attempt to truncate the data
anywhere. Nonetheless, this has created a hazard that wasn't there
before: with any padding spec, sprintf has to determine the
On 2014-05-16 15:44:53 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-16 14:51:01 -0400, Tom Lane wrote:
Ah, you're right, so sprintf shouldn't attempt to truncate the data
anywhere. Nonetheless, this has created a hazard that wasn't there
before: with any
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-16 15:44:53 -0400, Tom Lane wrote:
But according to previous research, we don't
really guarantee that glibc thinks the encoding is what we think, anyway.
The commit messages for 54cd4f04576833abc394e131288bf3dd7dcf4806 and
On 2014-05-16 16:19:28 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-16 15:44:53 -0400, Tom Lane wrote:
But according to previous research, we don't
really guarantee that glibc thinks the encoding is what we think, anyway.
The commit messages for
I am finding that my logical walsender connections are being terminated
due to a timeout on the CREATE REPLICATION SLOT command. with
terminating walsender process due to replication timeout
Below is the stack trace when this happens
#3 0x0067df28 in WalSndCheckTimeOut
Hi,
On 2014-05-16 16:37:16 -0400, Steve Singer wrote:
I am finding that my logical walsender connections are being terminated due
to a timeout on the CREATE REPLICATION SLOT command. with terminating
walsender process due to replication timeout
Below is the stack trace when this happens
On 05/16/2014 04:43 PM, Andres Freund wrote:
Hi,
I don't think that's going to cut it though. The creation can take
longer than whatever wal_sender_timeout is set to (when there's lots of
longrunning transactions). I think checking whether last_reply_timestamp
= 0 during timeout checking is
On 16 May 2014 13:21, Craig Ringer cr...@2ndquadrant.com wrote:
On 05/16/2014 04:46 PM, Craig Ringer wrote:
I'll follow up with the patch and a git tree when it's ready, hopefully
tonight.
Here's a rebased version of Simon's original patch that runs on current
master.
I still need to
Hi,
On 2014-05-16 19:54:56 +0200, Andres Freund wrote:
Hi,
elog.c's log_line_prefix() processes %d with:
case 'd':
if (MyProcPort)
{
const char *dbname = MyProcPort-database_name;
if (dbname == NULL ||
More fun with my torn page injection test program on 9.4.
24171 2014-05-16 14:00:44.934 PDT:WARNING: 01000: page verification
failed, calculated checksum 21100 but expected 3356
24171 2014-05-16 14:00:44.934 PDT:CONTEXT: xlog redo split_l: rel
1663/16384/16405 left 35191, right 35652, next
Andres Freund and...@2ndquadrant.com writes:
It's imo pretty annoying that neither bgworkers nor autovacuum workers
show the proper database in the log. Why don't we just populate a global
variable in InitPostgres() once we're sure which database the backend is
connected to? We could fill fake
On 2014-05-16 17:48:28 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
It's imo pretty annoying that neither bgworkers nor autovacuum workers
show the proper database in the log. Why don't we just populate a global
variable in InitPostgres() once we're sure which
On 2014-05-17 00:17:46 +0200, Andres Freund wrote:
On 2014-05-16 17:48:28 -0400, Tom Lane wrote:
This is basically reintroducing a variable that used to exist and was
intentionally gotten rid of, on the grounds that it'd fail to track
any renaming of the session's current database (cf
On 2014-05-16 17:02:33 -0400, Steve Singer wrote:
I don't think that's going to cut it though. The creation can take
longer than whatever wal_sender_timeout is set to (when there's lots of
longrunning transactions). I think checking whether last_reply_timestamp
= 0 during timeout checking is
On Fri, May 16, 2014 at 10:51 AM, Amit Kapila amit.kapil...@gmail.comwrote:
Thrds (64) Thrds (128) HEAD 45562 17128 HEAD + 64 57904 32810 V1 + 64
105557 81011 HEAD + 128 58383 32997 V1 + 128 110705 114544
I haven't actually reviewed the code, but this sort of thing seems like
good
On Fri, May 16, 2014 at 7:51 AM, Amit Kapila amit.kapil...@gmail.comwrote:
shared_buffers= 8GB
scale factor = 3000
RAM - 64GB
Thrds (64) Thrds (128) HEAD 45562 17128 HEAD + 64 57904 32810 V1 + 64
105557 81011 HEAD + 128 58383 32997 V1 + 128 110705 114544
shared_buffers= 8GB
scale
On Sat, May 17, 2014 at 6:29 AM, Peter Geoghegan p...@heroku.com wrote:
On Fri, May 16, 2014 at 7:51 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
shared_buffers= 8GB
scale factor = 3000
RAM - 64GB
I'm having a little trouble following this. These figure are transactions
per second for
On Sat, May 17, 2014 at 6:02 AM, Robert Haas robertmh...@gmail.com wrote:
I haven't actually reviewed the code, but this sort of thing seems like
good evidence that we need your patch, or something like it. The fact that
the patch produces little performance improvement on it's own (though it
On 05/17/2014 05:24 AM, Thomas Munro wrote:
I noticed that in applyLockingClause, Simon has rc-waitMode |=
waitMode. Is that right? The values are 0, 1, and 2, but if you had
both NOWAIT and SKIP LOCKED somewhere in your query you could up with
rc-waitMode == 3 unless I'm mistaken.
I do not
68 matches
Mail list logo
