Dear PostgreSQL developers,
Plese find attached a patch so that:
Make psql -1 file.sql work as with -f
Make psql --single-transaction option work on a non-interactive
standard input as well, so that psql -1 input.sql behaves as
psql -1 -f input.sql.
This saner/less
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org]
On Behalf Of Tom Lane
We've had a couple of complaints recently from people who were unhappy
because the
syslogger's log_truncate_on_rotation logic does not fire during the first
log rotation after it's
On Tue, Jul 31, 2012 at 4:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
IMHO, the way we have it now is kind of a mess. SpinLockAcquire and
SpinLockRelease are required to be CPU barriers, but they are not
required to be compiler barriers. If we changed
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 31, 2012 at 4:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I agree that volatile-izing everything in the vicinity is a sucky
solution, but the last time we looked at this there did not seem to
be a better one.
Well, Linux has a barrier()
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Geoghegan
Sent: Sunday, July 29, 2012 9:09 PM
I made what may turn out to be a useful observation during the
development of the patch, which was that for both the tpc-b.sql and
insert.sql
On Wed, Aug 1, 2012 at 10:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Solving the problem for linux only, or gcc only, isn't going to get us
to a place where we can stop volatile-izing call sites. We need to be
sure it works for every single case supported by s_lock.h.
Yep, that's the problem
[ getting back to this now after assorted distractions ]
Marko Kreen mark...@gmail.com writes:
Just to show agreement: both PQgetRowData() and optimized PGresult
do not belong to 9.2.
OK, we're all on board with leaving those for later.
Only open questions are:
* Is there better API than
On 1 August 2012 15:14, Amit Kapila amit.kap...@huawei.com wrote:
I shall look into this aspect also(setting commit_delay based on raw sync).
You also suggest if you want to run the test with different configuration.
Well, I was specifically interested in testing if half of raw sync
time was a
On Wed, Aug 1, 2012 at 10:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think you may be right that using __asm__ __volatile__ in gcc
S_UNLOCK cases would be a big step forward, but it needs more research
to see if that's the only fix needed.
Looking through the spinlock implementations in
Hi,
please find attached version 1 of the patch introducing Array
ELEMENT Foreign Keys support. This new thread and related patch
substitute any previous discussion about Support for foreign keys with
arrays, as anticipated in
http://archives.postgresql.org/pgsql-hackers/2012-07/msg01098.php
Il 30/07/12 19:16, Gabriele Bartolini ha scritto:
And it can be also interchanged with Array element Foreign Key.
As promised, we have sent a patch for the Array ELEMENT foreign key
support.
We are discontinuing this thread here and continue discussing the former
Foreign Keys with
On Wed, Aug 1, 2012 at 6:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com writes:
* Is there better API than PQsetSingleRowMode()? New PQsend*
functions is my alternative.
After thinking it over, I'm really unexcited about adding new versions
of all the PQsend
Marko Kreen mark...@gmail.com writes:
On Wed, Aug 1, 2012 at 6:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
So I'm working from the first set of patches in your message
20120721194907.ga28...@gmail.com.
Great!
Here's an updated draft patch. I've not looked at the docs yet so
this doesn't
13 matches
Mail list logo