On Fri, May 16, 2008 at 5:24 AM, Jan Urbański
<[EMAIL PROTECTED]> wrote:
>
> ERROR: deadlock detected
> DETAIL: Process 25423 waits for AccessExclusiveLock on relation 16386 of
> database 1; blocked by process 25428.
>Process 25428 waits for AccessShareLock on relation 16390 of database
>
Hi, hackers.
I'm reading the source codes of hash and reviewing Neil's old patch of
improving hash index.
Here is some detail plan. I'm trying to adjust Neil's patch to the current
version of PostgreSQL first. I'm not quite familar with the code yet, so
please make some comment.
* Phase 1. Just s
On Wed, 2008-05-14 at 20:25 +0100, Gregory Stark wrote:
> The Linux kernel does have some macros meant to mark unlikely branches
> (usually assertion failures) but I'm not sure how they work. And Gcc also has
> a few optimizations which are driven by profiling data but I it doesn't sound
> like thi
I got this on HEAD while doing lots of CREATE -> COPY -> DROP on table.
(...)
DEBUG: ProcessUtility
DEBUG: drop auto-cascades to toast table pg_toast.pg_toast_16774
DEBUG: drop auto-cascades to type pg_toast.pg_toast_16774
DEBUG: drop auto-cascades to index pg_toast.pg_toast_16774_index
DEBUG
Andrew,
> Would this be reasonable and is there any community interest in
> open-sourcing the tool that I'm building?
yes, definitely.
We shoud find a way to bundle your tool together with other physical
integrity checking tools. Eventually we can have a "check crashed
postgresql suite".
--
On Fri, Mar 28, 2008 at 10:30 AM, Gurjeet Singh <[EMAIL PROTECTED]>
wrote:
>
> I am still looking for comments on the correctness of this script and above
> mentioned procedure for running it on an 8.2.x release.
>
Well, I came across a serious bug in the script. Here's the corrected
version of t
On 5/15/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > On 5/15/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> >>> Eg. how does src/backend/parser/gram.c not leak memory on syntax error?
> >>
> >> It's not a leak
I have submitted a patch that does two things: (1) fixes a bug in the
client SSL code that never appended the home directory to the root
revocation list. and (2) adds 4 new fields to the connect string:
sslkey=fullepath_to_file
sslcert=fullpath_to_cert
ssltrustcrt=fullpath_to_trusted_cert_file
ssl
Heikki Linnakangas wrote:
> The "TRUNCATE table while we're holding references to it" bug (3883), is
> causing an assertion failure on 8.2, when the TRUNCATE is called in a
> trigger:
[...]
> I think we need to backpatch the fix for this...
So, what's the patch that needs the be backpatched?
> [EMAIL PROTECTED] wrote:
>> > [EMAIL PROTECTED] writes:
>> >> Maybe we need to go even further and add it to the PQconnect API
>> >> sslkey=filename and sslcrt=filename in addition to sslmode?
>> >
>> > If there's a case to be made for this at all, it should be handled
>> > the same way as all ot
[EMAIL PROTECTED] wrote:
> > [EMAIL PROTECTED] writes:
> >> Maybe we need to go even further and add it to the PQconnect API
> >> sslkey=filename and sslcrt=filename in addition to sslmode?
> >
> > If there's a case to be made for this at all, it should be handled
> > the same way as all other libp
[EMAIL PROTECTED] wrote:
I think if you're going to provide for these then you should also
provide for the CA cert and CRL.
Otherwise, it seems sensible.
I thought about that, but the root and crl are for the server, and that
makes sense that the keys would be in the server directo
>
>
> [EMAIL PROTECTED] wrote:
>> Adding "sslkey" and "sslcert" to the PQconnectdb connection string.
>>
>> After some discussion, I think it is more appropriate to add the
>> key/cert
>> file for SSL into the connect string. For example:
>>
>> PQconnectdb("host=foo dbname=bar sslmode=require
>> ss
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> On 5/15/08, Tom Lane <[EMAIL PROTECTED]> wrote:
>> "Marko Kreen" <[EMAIL PROTECTED]> writes:
>>> Eg. how does src/backend/parser/gram.c not leak memory on syntax error?
>>
>> It's not a leak because the memory can be re-used during the next
>> command.
Alvaro Herrera wrote:
Zdenek Kotala wrote:
Alvaro Herrera napsal(a):
I try to play with lint now if it gets better results.
Ok, good.
Hmm, It generates a lot of unnecessary includes in *.c files. I have
checked only couple of them and it seems that they are really
unnecessary. A attach outp
[EMAIL PROTECTED] wrote:
Adding "sslkey" and "sslcert" to the PQconnectdb connection string.
After some discussion, I think it is more appropriate to add the key/cert
file for SSL into the connect string. For example:
PQconnectdb("host=foo dbname=bar sslmode=require
sslkey=/opt/myapp/share/ke
On 5/15/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > Eg. how does src/backend/parser/gram.c not leak memory on syntax error?
>
> It's not a leak because the memory can be re-used during the next
> command.
I may be blind, but I don't see any static varia
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> Eg. how does src/backend/parser/gram.c not leak memory on syntax error?
It's not a leak because the memory can be re-used during the next
command.
I believe you'll find that trying to make it use palloc is a failure
because it keeps static pointers that
Adding "sslkey" and "sslcert" to the PQconnectdb connection string.
After some discussion, I think it is more appropriate to add the key/cert
file for SSL into the connect string. For example:
PQconnectdb("host=foo dbname=bar sslmode=require
sslkey=/opt/myapp/share/keys/client.key
sslcert=/opt/my
Now that we have customizable segment sizes for heap and WAL at compilation
time i would like to have some runtime variables to query that information
(besides pg_controldata). I can imagine to have the following names:
segment_size: Reports heap segment size
wal_segment_size: Reports wal segme
On 5/15/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > How about following patch? I have bison 2.3 and it seems not to do
> > global allocation, so it should be fine. There may be early exit
> > with elog(ERRROR) inside so I'd like to avoid malloc() itse
>
> On May 15, 2008, at 6:31 AM, [EMAIL PROTECTED] wrote:
>
>>> Mark Woodward wrote:
I am using PostgreSQL's SSL support and the conventions for the
key and
certifications don't make sense from the client perspective.
Especially
under Windows.
I am proposing a few
> [EMAIL PROTECTED] writes:
>> Maybe we need to go even further and add it to the PQconnect API
>> sslkey=filename and sslcrt=filename in addition to sslmode?
>
> If there's a case to be made for this at all, it should be handled the
> same way as all other libpq connection parameters.
>
>
On May 15, 2008, at 6:31 AM, [EMAIL PROTECTED] wrote:
Mark Woodward wrote:
I am using PostgreSQL's SSL support and the conventions for the
key and
certifications don't make sense from the client perspective.
Especially
under Windows.
I am proposing a few simple changes:
Adding two API
vo
[EMAIL PROTECTED] writes:
> Maybe we need to go even further and add it to the PQconnect API
> sslkey=filename and sslcrt=filename in addition to sslmode?
If there's a case to be made for this at all, it should be handled the
same way as all other libpq connection parameters.
> Mark Woodward wrote:
>> I am using PostgreSQL's SSL support and the conventions for the key and
>> certifications don't make sense from the client perspective. Especially
>> under Windows.
>>
>> I am proposing a few simple changes:
>>
>> Adding two API
>> void PQsetSSLUserCertFileName(char *filen
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> How about following patch? I have bison 2.3 and it seems not to do
> global allocation, so it should be fine. There may be early exit
> with elog(ERRROR) inside so I'd like to avoid malloc() itself.
None of our other parsers fool with bison's memory al
Mark Woodward wrote:
I am using PostgreSQL's SSL support and the conventions for the key and
certifications don't make sense from the client perspective. Especially
under Windows.
I am proposing a few simple changes:
Adding two API
void PQsetSSLUserCertFileName(char *filename)
{
user_crt_
I am using PostgreSQL's SSL support and the conventions for the key and
certifications don't make sense from the client perspective. Especially
under Windows.
I am proposing a few simple changes:
Adding two API
void PQsetSSLUserCertFileName(char *filename)
{
user_crt_filename = strdup(filenam
Hi,
On Thu, May 15, 2008 at 11:59 AM, Pavel Stehule <[EMAIL PROTECTED]>
wrote:
> > I always use a ~/.cvsrc containing
> >
> > cvs -z3
> > update -d -P
> > checkout -P
> >
>
My .cvsrc also includes:
diff -c
So that a patch I submit does not get bounced back for a non-context diff :)
Regards,
N
On 5/15/08, Marko Kreen <[EMAIL PROTECTED]> wrote:
> On 5/15/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> > "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > > Hmm.. Now that I think about it, in my effort to remove malloc() calls
> > > in both scanner and parser I told bison to use alloca(). Is it
On 5/15/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > Hmm.. Now that I think about it, in my effort to remove malloc() calls
> > in both scanner and parser I told bison to use alloca(). Is it portability
> > concern?
>
> Yes.
How about following patch?
The "cardinal" in pgbuildfarm has been taken down for server/hardware
maintenance.
Regards,
Gevik
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> Hmm.. Now that I think about it, in my effort to remove malloc() calls
> in both scanner and parser I told bison to use alloca(). Is it portability
> concern?
Yes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsq
Hi,
as I posted already in the general newsgroup our company has decided
that we would like to sponsor the implementation of materialized views
for Postgres.
However at the moment we have no idea about the complexity of the
implementation and therefore what the cost would be. Since the point
is al
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> second pass. There are 130 files in this list. Offhand I'd say the vast
> majority should have markers.
Yeah, that list looks reasonably sane. The main thing I was worried
about was not plastering PostgreSQL markers on files that are simply
imported f
2008/5/15 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> I got some errors:
>
>> In file included from gistget.c:20:
>> ../../../../src/include/pgstat.h:15:36: error:
>> portability/instr_time.h: není souborem ani adresářem
>
> I'll bet you forgot -d in your last cvs
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I got some errors:
> In file included from gistget.c:20:
> ../../../../src/include/pgstat.h:15:36: error:
> portability/instr_time.h: nenà souborem ani adresáÅem
I'll bet you forgot -d in your last cvs update command.
I always use a ~/.cvsrc conta
On 5/15/08, Josh Berkus <[EMAIL PROTECTED]> wrote:
> On Wednesday 14 May 2008 13:29, Marko Kreen wrote:
> > - SGML documentation.
> > - Makefile review.
> > - Integrate regression tests into main test framework.
>
> Has PL/proxy been tested on other OSes? FreeBSD/Solaris/Windows?
It definitely
39 matches
Mail list logo
