2013-03-17 04:48 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
[ 2-lock_timeout-v37.patch ]
Applied after a fair amount of additional hacking.
Thank you, thank you, thank you! :-)
I was disappointed to find that the patch introduced a new race
condition into
Please find attached the patches wanted:
- 20130317_reindexdb_concurrently.patch, adding an option -c/--concurrently
to reindexdb
Note that I added an error inside reindexdb for options -s -c as REINDEX
CONCURRENTLY does not support SYSTEM.
- 20130317_dump_only_valid_index.patch, a 1-line patch
I tried running PostgreSQL on the ARM64 (aka AArch64) emulator and
noticed that the version() string mixes up the host and target
architecture.
Before:
PostgreSQL 9.3devel on x86_64-pc-linux-gnu, compiled by
aarch64-linux-gnu-gcc-4.7 (Ubuntu/Linaro 4.7.2-21ubuntu3) 4.7.2, 64-bit
Now:
On Sun, Mar 17, 2013 at 3:17 PM, Marti Raudsepp ma...@juffo.org wrote:
Now:
PostgreSQL 9.3devel on aarch64-linux-gnu-gcc-4.7 (Ubuntu/Linaro
4.7.2-21ubuntu3) 4.7.2, compiled by x86_64-pc-linux-gnu, 64-bit
Sorry, that is clearly wrong. I'll come up with a better patch soon
(and actually check
On Sun, Mar 17, 2013 at 3:38 PM, Marti Raudsepp ma...@juffo.org wrote:
Sorry, that is clearly wrong. I'll come up with a better patch soon
(and actually check that it makes sense! :)
Sorry about the noise, I just misunderstood the configure --target and
--host arguments. If I set them correctly
Boszormenyi Zoltan z...@cybertec.at writes:
2013-03-17 04:48 keltezéssel, Tom Lane írta:
[ worries about stray SIGALRM events ]
Your reasoning seems to be correct. However, if we take it to the
extreme, enable_timeout_at/enable_timeout_after/enable_timeouts
should also disable the interrupt
On 3/14/13 4:48 PM, Boszormenyi Zoltan wrote:
The attached patch makes
SET PERSISTENT transactional and uses one setting per file.
It uses the currently existing parsing and validating code
and because of this, the patch is half the size of v12 from Amit.
That's not a completely fair
On Sun, 2013-03-17 at 16:06 +, Tom Lane wrote:
Move pqsignal() to libpgport.
We had two copies of this function in the backend and libpq, which was
already pretty bogus, but it turns out that we need it in some other
programs that don't use libpq (such as pg_test_fsync). So put it where
Guillaume Lelarge guilla...@lelarge.info writes:
On Sun, 2013-03-17 at 16:06 +, Tom Lane wrote:
Move pqsignal() to libpgport.
When I try to compile HEAD right after this commit, I have this issue
with pg_receivexlog:
Oddly, I didn't see that on the machine I was testing on --- it must
On Sun, 2013-03-17 at 14:13 -0400, Tom Lane wrote:
Guillaume Lelarge guilla...@lelarge.info writes:
On Sun, 2013-03-17 at 16:06 +, Tom Lane wrote:
Move pqsignal() to libpgport.
When I try to compile HEAD right after this commit, I have this issue
with pg_receivexlog:
Oddly, I
I just noticed that libpq no longer builds on my OS X machine:
Undefined symbols for architecture x86_64:
_pqsignal, referenced from:
-exported_symbol[s_list] command line option
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make[3]: ***
2013-03-17 16:07 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-03-17 04:48 keltezéssel, Tom Lane írta:
[ worries about stray SIGALRM events ]
Your reasoning seems to be correct. However, if we take it to the
extreme,
2013-03-17 17:05 keltezéssel, Greg Smith írta:
On 3/14/13 4:48 PM, Boszormenyi Zoltan wrote:
The attached patch makes
SET PERSISTENT transactional and uses one setting per file.
It uses the currently existing parsing and validating code
and because of this, the patch is half the size of v12
On 17 March 2013 00:41, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 15 March 2013 13:08, Andres Freund and...@2ndquadrant.com wrote:
I commented on this before, I personally think this property makes fletcher
a
not so good fit for this. Its not uncommon
On 13 March 2013 06:33, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2013-03-07 at 13:45 -0800, Jeff Davis wrote:
I need to do another self-review after these changes and some more
extensive testing, so I might have missed a couple things.
New patch attached.
Aside from rebasing, I also
On 3/15/13 5:32 AM, Ants Aasma wrote:
Best case using the CRC32 instruction would be 6.8 bytes/cycle [1].
But this got me thinking about how to do this faster...
[1]
http://www.drdobbs.com/parallel/fast-parallelized-crc-computation-using/229401411
The optimization work you went through here
On 3/17/13 1:41 PM, Simon Riggs wrote:
So I'm now moving towards commit using a CRC algorithm. I'll put in a
feature to allow algorithm be selected at initdb time, though that is
mainly a convenience to allow us to more easily do further testing on
speedups and whether there are any platform
On 03/09/2013 04:52 PM, Ian Pilcher wrote:
3. Once the root CA certificate is trusted, however, the bad client
can also connect by using a certificate chain that includes the
Server CA certificate --cat bad-client.crt server-ca.crt
~/.postgresql/postgresql.crt.
After looking at
Boszormenyi Zoltan z...@cybertec.at writes:
2013-03-17 16:07 keltezéssel, Tom Lane írta:
It suddenly occurs to me though that there's more than one way to skin
this cat. We could easily add another static flag variable called
sigalrm_allowed or some such, and have the signal handler test that
On Tue, Mar 12, 2013 at 11:53 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The attached patch is rebased one towards the latest master.
It newly added a hook being missed in the previous revision at ALTER
EVENT TRIGGER ENABLE / DISABLE, and adjusted argument of
finish_heap_swap() on REFRESH
Bruce Momjian br...@momjian.us writes:
On Fri, Mar 15, 2013 at 03:05:54PM -0400, Tom Lane wrote:
The quick-and-dirty fix for this is to just copy pqsignal() into
pg_test_fsync, and use that instead of calling signal() directly.
I wonder though if we shouldn't move that function into libpgport.
Hi,
Please find attached a patch to take 'make check' code-coverage of SCHEMA
from 33% to 98%.
Any feedback is more than welcome.
p.s.: I am currently working on more regression tests (USER / VIEW /
DISCARD etc). Please let me know if I need to post these as one large
patch, instead of
robins escribió:
Hi,
Please find attached a patch to take 'make check' code-coverage of SCHEMA
from 33% to 98%.
Any feedback is more than welcome.
I think you should use more explicit names for shared objects such as
roles -- i.e. not r1 but regression_user_1 and so on. (But be
careful
On 03/09/2013 04:52 PM, Ian Pilcher wrote:
After looking at be-secure.c and investigating the way that OpenSSL
validates certificates, I do not believe that there is any way of
achieving the desired behavior with the current codebase.
Test process:
SET UP SERVER VERIFIED SSL (NO CLIENT CERTS)
2013-03-18 03:52 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-03-17 16:07 keltezéssel, Tom Lane írta:
It suddenly occurs to me though that there's more than one way to skin
this cat. We could easily add another static flag variable called
sigalrm_allowed or
On Sun, Mar 17, 2013 at 5:50 PM, Greg Smith g...@2ndquadrant.com wrote:
On the testing front, we've seen on-list interest in this feature from
companies like Heroku and Enova, who both have some resources and practice
to help testing too. Heroku can spin up test instances with workloads any
2013-03-18 06:22 keltezéssel, Boszormenyi Zoltan írta:
2013-03-18 03:52 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-03-17 16:07 keltezéssel, Tom Lane írta:
It suddenly occurs to me though that there's more than one way to skin
this cat. We could easily add
Boszormenyi Zoltan z...@cybertec.at writes:
The volatile marking shouldn't even be necessary there.
The signal handler doesn't writes to it, only the main code.
Well, (a) that's not the case in the patch as committed, and (b) even if
it were true, the volatile marking is still *necessary*,
28 matches
Mail list logo
